Praktisch bedeutet das: Zwischen Nutzer und Modell gehört eine Observability-/Governance-Schicht, die alle Interaktionen protokolliert, bewertet und steuert. In unserer Arbeit setzen wir genau so eine Schicht ein, weil ohne sie weder Audits noch forensische Analysen möglich sind und Risiken (z. B. Datenabfluss über generierte Antworten) unkalkulierbar bleiben.

Ein Entscheidungsrahmen: Vier Achsen, die Build erzwingen können

1) Nicht verhandelbare Compliance

  • Frage: Können Sie die Compliance-Last (Datenlokation, Audit, Langzeitbetrieb) auf einen Dritten auslagern?

  • Wenn nein: Build. Denn Compliance ist dann keine Vertragsklausel, sondern eine Produkteigenschaft.

2) Variabilität über die Lebensdauer

  • Frage: Wie oft und wie tiefgreifend ändern sich Domänenlogik, Integrationspunkte, Randbedingungen?

  • Hohe Variabilität bevorzugt Build mit klaren Modulen und sauberen Verträgen. Kaufen verschiebt Kosten in langwierige Anpassungsprojekte.

3) Abhängigkeitsfläche und Souveränität

  • Frage: Wie groß ist die kritische Abhängigkeitsfläche (Cloud-Regionen, proprietäre Protokolle, Lizenzschlüssel, Telemetrie)?

  • Große, intransparente Abhängigkeitsflächen sind ein No-Go in sicherheitskritischen Netzen. Build reduziert sie gezielt.

4) Performance- und Betriebs-SLAs

  • Frage: Sind deterministische Latenzen, harte Ressourcenbudgets, Offline-Betrieb oder definierte Updatefenster zwingend?

  • Wenn ja, kollidieren generische Plattformen schnell mit Ihren SLAs. Build erlaubt SLA-gerechtes Design.

Wie man Build wirtschaftlich und risikoarm aufsetzt

„Build“ ist nicht automatisch teurer – er ist nur ehrlicher. Die Kosten verschieben sich von Lizenz zu Engineering. Um das Risiko zu kontrollieren:

Startarchitektur

  • Enge Domänenschnittstellen: Beginnen Sie mit einem sauberen Domain-Modell, definierten Events und klaren Ports. Infrastruktur bleibt austauschbar.

  • Strangler-Pattern für Legacy: Neue Funktionen kapseln, alte schrittweise über Interfaces entkoppeln. Niemals Big Bang.

  • Contract-Tests mit Drittsystemen: Automatisierte Schnittstellen-Tests verhindern Integrations-Regressionen.

  • Schattenbetrieb: Neue Pfade an realen Daten „mitlaufen“ lassen, ohne in die Produktion einzugreifen. Abweichungen sichtbar machen, bevor Sie umschalten.

Quality-by-Design

  • Anforderungen messbar formulieren: Nicht „schnell“, sondern „p95-Latenz < X ms unter Y Last“.

  • Property-basiertes Testen und Fuzzing für Protokollschichten.

  • Statische Analyse, linientreue C++/Rust/Go-Profile je nach Komponente; sichere Defaults; defensives Parsen.

  • Traceability: Jede Anforderung referenziert Tests und Artefakte. Ohne Traceability keine Abnahme.

Sicherheitsmodell

  • Threat Modeling (z. B. STRIDE) pro Domänenkomponente; Abwehrmaßnahmen als Code (Policies, CI-Gates).

  • Secrets-Management zentral, kurzlebige Tokens, rotierende Schlüssel. Keine eingebetteten Secrets.

  • Minimaler Angriffsraum: Nur notwendige Binärmodule, abgeschaltete Standarddienste, gehärtete Container Base Images.

Betrieb und Beobachtbarkeit

  • Einheitliche Korrelations-IDs über Services; mitlaufende Domänen-Events als First-Class-Logs.

  • Kapazitätsmanagement mit realistischen Lastprofilen, nicht mit „Hello World“-Benchmarks.

  • Rollierende Updates in Wartungsfenstern; Blue/Green auf Service-Inseln; deterministische Rollback-Pfade.

LLM-spezifische Betriebspraxis on-prem

  • Prompt- und Tooling-Katalog versionieren; Rollouts kontrolliert; Gatekeeping mit vordefinierten Policies.

  • Datenklassifizierung automatisiert vor jeder Modellinteraktion.

  • Risikorelevante Antworten markieren (z. B. unsichere Extraktionen) und in Review-Queues routen.

  • Explizite „Kein Internet“-Garantie auf Inferenzebene, dokumentiert und technisch erzwungen.

Konkrete Situationen, in denen Build alternativlos ist

  • Air-gapped Fertigungslinie mit Echtzeit-Inspektion:
  • Hochauflösende Bilddaten, Latenzbudgets im niedrigen Millisekundenbereich, keine Cloud. Notwendig: Edge-Inferenz, lokaler Vektorspeicher, deterministisches Scheduling, Hardware-nahe Pipelines.
  • Flottenweite Zustandsüberwachung mit intermittierender Konnektivität:
  • Fahrzeuge/Anlagen senden sporadisch; lokale Vorverarbeitung, robuste Pufferung, konfliktfreie Zusammenführung. Notwendig: Event-Sourcing, konfliktfreie Replikation, Offline-First-UX.
  • Sicherheitskritische Planungs-/Entscheidungshilfen:
  • Erklärbarkeit und Audit oberste Priorität. Notwendig: entscheidbare, nachvollziehbare Algorithmen, nachweisbare Bounding-Boxen für KI-Komponenten, reproduzierbare Ausgaben.
  • LLM-Assistenz in vertraulichen Entwicklungsumgebungen:
  • Quellcode und Konstruktionsdaten dürfen nie die Organisation verlassen. Notwendig: on-prem Modellbereitstellung, Agent-Governance, Telemetrie ohne Datenabfluss, signierte Prompt-Bibliotheken.

„Buy“ bleibt relevant – aber bewusst und eingehegt

Es gibt legitime Gründe, zu kaufen:

  • Commodity-Komponenten mit klaren Standardprotokollen (z. B. Zeitreihendatenbanken, Message Broker)

  • Werkzeuge, die Entwicklungsproduktivität erhöhen (IDE/Static Analysis/CI-Runner), sofern on-prem betreibbar

  • Visualisierung/BI, wenn Datenhoheit gewahrt bleibt

Strategien, um Vendor-Lock-in zu begrenzen:

  • Datensouveränität zuerst: Daten bei Ihnen, Formate offen, Export jederzeit vollständig.

  • Infrastruktur-Kontrollpunkte: Eigene Registry, eigene Observability, eigene AuthN/AuthZ – nicht die des Vendors.

  • Architekturalternativen stets parallel im Blick (z. B. austauschbarer Storage-Treiber, Message-Broker via Ports/Adapters).

Kosten ehrlich bewerten: Run-Cost Envelope und Change Tax

  • Run-Cost Envelope: Welche fixen Betriebskosten (Hardware, Energie, Personal, Lizenzen) müssen planbar sein? Cloud-Variabilität ist hier oft ein Problem – on-prem kann günstiger und vorhersagbarer sein, wenn die Auslastung stabil ist.
  • Change Tax: Wie teuer ist eine Anpassung funktionaler oder regulatorischer Anforderungen? Bei COTS ist die Change Tax häufig höher als beim eigenen Code, sobald man den Lernkurvenpunkt überschritten hat.
  • Lernkurve amortisieren: Build lohnt sich, wenn Wissen und Tooling wiederverwendbar sind (gemeinsame Plattform, Komponentenbibliothek, Test- und Delivery-Patterns).

Schritt-für-Schritt: Von Entscheidung zu Umsetzung

1) Non-Negotiables festlegen

  • Datenschutz, Jurisdiktion, Latenz, Offline, Audit. Schriftlich fixieren, vom Management mittragen lassen.

2) Architektur-Grenzen definieren

  • Welche Teile müssen zwingend in Ihrem Kontrollbereich liegen (Code, Daten, Infrastruktur)? Welche dürfen standardisiert werden?

3) Technische Spike-Phase, 6–8 Wochen

  • Realistische Last- und Datenprofile, keine Demo-Datensätze. Ziel: Risiko-Reduktion, nicht Feature-Vergleich.

4) Delivery-Kern aufsetzen

  • Monorepo oder Polyrepo mit klaren Regeln, CI/CD hermetisch, Observability von Tag 1, Security-Gates verpflichtend.

5) Strangler-Integration planen

  • Identifizieren Sie Schnittstellen zum Legacy, bauen Sie Gateways und schalten Sie Funktionen stufenweise um. Kein Big Bang.