Build vs. Buy in regulierten Industrien: Wann individuelle Entwicklung die einzige Option ist – und wie Sie sie beherrschbar machen

Problemstellung aus der Praxis
Als Softwarearchitekt in sicherheitskritischen und industriellen Umgebungen sehe ich regelmäßig dieselbe Ausgangslage: Ein Fachbereich will ein Problem gelöst wissen (z. B. visuelle Fehlererkennung in der Fertigung, Analyse von Flottendaten im Bahnnetz, ein KI-gestützter Assistent für Instandhaltung). Der Einkauf vergleicht „Lösungen“ und findet SaaS-Produkte mit beeindruckenden Demos. Die IT-Sicherheit ruft Datenschutz, Exportkontrolle, On-Prem-Auflagen. Die Produktionsleitung fordert deterministische Latenzen und Null-Downtime. Am Ende klemmt das Projekt an einer Stelle, an die im Auswahlprozess selten jemand denkt: Souveränität, Auditierbarkeit, Integrationsaufwand und Betriebsrisiko.

Es gibt Domänen, in denen Build vs. Buy keine Lifestyle-Frage ist, sondern eine Architekturanforderung. Genauer: In Umgebungen mit nicht verhandelbarer Datensouveränität, langen Lebenszyklen, regulatorisch geforderter Nachvollziehbarkeit und physischer Weltkopplung (OT/PLC, Sensorik, Aktorik) ist individuelle Entwicklung häufig die einzige Option, die nicht in versteckte Abhängigkeiten oder Betriebsunterbrechungen führt. Das ist keine Anti-Produkt-Haltung. Es ist die Einsicht, dass ein generisches Produkt selten die Randbedingungen von Defense, Bahn, Luftfahrt, Fertigung oder Bauvermessung erfüllt – zumindest nicht ohne so starke Anpassungen, dass man ohnehin Entwicklungs- und Ownership-Verantwortung übernehmen muss.

Die Entscheidungslogik: Ein technischer Entscheidungsrahmen
Anstatt Produktkataloge zu vergleichen, lohnt sich ein kurzer, technischer Prüfkatalog. Wenn eine der folgenden Fragen mit „ja“ beantwortet wird, kippt die Balance in Richtung Build (oder zumindest „Build um einen schlanken, selbst-gehosteten Baustein herum“):

  • Datensouveränität: Dürfen Daten, Modelle oder Metadaten das eigene Rechenzentrum nicht verlassen? Sind Air-Gap-Segmente gefordert?
  • Determinismus und Latenz: Benötigen Sie harte Latenzbudgets (z. B. 50–100 ms Inferenz am Edge) oder deterministisches Verhalten über alle Versionen?
  • Auditierbarkeit: Müssen Sie jede Änderung (Code, Modell, Konfiguration) über Jahre nachvollziehen, reproduzierbar bauen und gegenüber Prüfern belegen?
  • Lebenszyklus und Vendor-Risiko: Muss das System 7–15 Jahre stabil laufen – auch wenn der Anbieter sein Geschäftsmodell ändert oder Features abkündigt?
  • Integrationsrealität: Sind Sie tief in OT integriert (OPC UA, Profinet, CAN, ARINC 429, proprietäre Bordrechner), sodass Standard-APIs nicht ausreichen?
  • Offline-Fähigkeit: Müssen Kernfunktionen vollständig offline laufen – nicht „degraded“, sondern voll funktionsfähig, inkl. Updates über Offline-Repositories?
  • Policy- und Governance-Kontrolle: Müssen Sie KI-Komponenten (LLMs, CV-Modelle) vollständig transparent betreiben, mit eigener Observability und Freigabeprozessen?

Wenn Sie mehrere Punkte abhaken, spricht vieles für ein Architekturprinzip: Bauen Sie die fachlich-differenzierenden Teile selbst, halten Sie die Plattform selbst in der Hand, und kaufen Sie nur dort zu, wo es Commodity-Bausteine sind, die Sie on-prem kontrollieren können (z. B. Container-Orchestrierung, interne Message-Broker, Vektordatenbank). Wichtig ist: Keine Black-Box-Abhängigkeiten in sicherheits- oder betriebsrelevanten Ketten.

Architekturprinzipien, die in der Praxis tragen
1) Souveräne Kern-Domäne, entkoppelte Bounded Contexts

  • Domänenzerlegung: Trennen Sie streng zwischen Kernfunktion (z. B. Defekterkennung, Flottenprognose) und generischer Infrastruktur (Datenaufnahme, Monitoring, Auth).

  • Entkopplung: Nutzen Sie klar definierte Schnittstellen (z. B. gRPC mit protobuf, OPC UA Informationsmodelle) und versionieren Sie Verträge (SemVer mit Abwärtskompatibilitätsregeln).

  • Austauschbarkeit: Modell-Inferenz als klare Boundary (Input-Schema, Output-Schema). Das erlaubt modellseitige Upgrades ohne HMI/PLC neu zu schneiden.

2) On-Prem-First, Cloud-Optional

  • Deployment: Kubernetes on-prem (Bare-Metal oder virtualisiert), interne Container-Registry mit signierten Artefakten, GitOps mit lokalem Mirror.

  • Air-Gap: Offline-Update-Prozesse, SBOM-Prüfung (Software Bill of Materials), reproduzierbare Builds (z. B. hermetische Build-Container).

  • Storage: Objekt-Storage on-prem (z. B. S3-kompatibel) mit WORM-Policies für Audit-Trails.

3) Daten-Infrastruktur, die OT und IT verbindet

  • Edge: Kamera/PLC-Adapter nahe an der Maschine, deterministische Preprocessing-Pfade, Hardware-Beschleuniger (z. B. dedizierte GPUs/TPUs) mit festgelegten Thermal-Budgets.

  • Bus: MQTT/Kafka als Rückgrat, klare QoS-Levels, Backpressure-Strategien.

  • Historisierung: Zeitreihen- und Blob-Store getrennt, um Abfragen nicht gegen große Binärdaten fahren zu müssen.

4) KI-Governance als Produktmerkmal, nicht als Papierprozess

  • Observability: Jede Inferenz, jeder Prompt, jede Antwort mit Hashes, Policy-Labels und Kontext-IDs protokollieren. Privacy by design: selektives Redacting optionaler Felder vor Persistierung.

  • Policy Engine: Durchsetzbare Richtlinien (z. B. Ausleitungsverbote, Benutzende-Rollen, genehmigungspflichtige Tools für Agenten).

  • Evaluation: Dataset-Versionierung, Goldensets, adversariale Tests, Drift-Monitoring.

Wir haben selbst ein Governance-Werkzeug für LLM-Agenten aufgebaut (Alpi-M), genau weil es On-Prem-Observability, Policy-Durchsetzung und Audits braucht, die Sie nicht an einen US-Cloud-Endpunkt outsourcen können. Die Lektion ist allgemeingültig: Ohne instrumentierte Governance sind KI-Systeme in regulierten Umgebungen nicht betreibbar.

Konkrete Muster pro Domäne
Fertigung: Visuelle Defekterkennung am Band

  • Edge-Pipeline: Kamera -> deterministisches Preprocessing (Kalibrierung, Entzerrung) -> On-Prem-Inferenz-Service (Container mit fest definiertem Modell + Runtime) -> Ergebnis auf MQTT mit Trace-ID.

  • Rückkopplung: Entscheidungen an HMI/PLC via OPC UA Method Calls, mit Fallback-Modus bei Unsicherheit (z. B. manuelle Entscheidungspflicht über ein Andon-Board).

  • Training: Offline im gesicherten Cluster; Datasets versioniert; Modellartefakte signiert, Update via Blue-Green im Edge-Cluster.

Bahn: Flottenintelligenz

  • Datenaufnahme: Event-Streaming von Bordgeräten (asynchron, zeitgestempelt), CDC aus Betriebsdatenbanken.

  • Prognose: Batch- und Near-Real-Time-Modelle getrennt; „Cold path“ für große Analysen, „Hot path“ für Zustandsalarme.

  • Sicherheit: Keine Remote-Kontrollpfade ohne Hardware-Gates; Update-Fenster aligned mit Betriebsplanung; Shadow-Mode vor Aktivierung von Maßnahmenempfehlungen.