Build vs Buy: Wann individuelle Entwicklung in regulierten Industrien die einzige Option ist

Wenn Sie als CTO oder Leiter Digitalisierung in einer regulierten Industrie eine neue Plattform oder ein AI-basiertes System bauen sollen, wirkt Buy zunächst rational: schnell, mit “Best Practices” und ohne langjährige Teamentwicklung. In der Praxis scheitern solche Entscheidungen oft nicht an der Technologie, sondern an den Randbedingungen: Datenhoheit, Auditierbarkeit, Lebenszyklus von 10–20 Jahren, deterministisches Verhalten, Legacy-Integration. Das sind keine “nice to have”-Anforderungen, sondern nicht verhandelbare Eigenschaften. Und genau an diesen Punkten kippt die Bilanz von Buy zu Build.

Dieser Beitrag fasst zusammen, wann individuelle Entwicklung die einzig tragfähige Option ist, wie man die Entscheidung strukturiert und welche Architektur- und Qualitätsmuster in sicherheitskritischen und industriellen Kontexten funktionieren.

Problem zuerst: Die eigentlichen Showstopper von Buy

Die meisten Standardlösungen und Cloud-APIs sind für horizontale, konsumige Workloads gebaut. Folgende harte Anforderungen treiben Sie aus diesem Mainstream heraus:

  • Souveränität und Datenresidenz: Keine Daten dürfen Ihr Werk, Ihr nationales Hoheitsgebiet oder Ihre isolierte Zone verlassen. Sie benötigen garantierte Datenlokalität, nachvollziehbare Datenflüsse, keine versteckten Telemetrie-Kanäle und keine Abhängigkeit von US-Cloud-Anbietern aufgrund regulatorischer und vertraglicher Risiken.
  • Determinismus, Latenz und Verfügbarkeit: KI hin oder her – Ihre Linie stoppt, Ihr Zug steht, Ihre Einsatzführung wartet nicht auf einen externen API-Token oder unvorhersehbare Cloud-Latenz. Sie brauchen vorhersagbare Antwortzeiten und kontrolliertes Degradationsverhalten, auch offline.
  • Lebenszyklus und Nachweispflichten: Zertifizierungen (z. B. in Bahn, Luftfahrt, Safety), Audit-Trails, vollständige Anforderungs-Nachverfolgbarkeit von Requirements bis Tests, reproduzierbare Builds und stabile API-Verträge über ein Jahrzehnt und länger.
  • Brownfield-Integration: Steuerungen, Protokolle, Spezialhardware, schlechte oder intermittierende Netze, Edge-Standorte, Offline-Betrieb mit späterer Synchronisation. Sie brauchen Anti-Corruption-Layer statt “direkter Cloud-Connector”.
  • Observability und Governance: Sie müssen erklären, was das System wann entschieden hat, inklusive Modellversion, Eingaben, Parameter und Policies. Black-Box-Services verhindern diese Revisionssicherheit.
  • Lieferkettensicherheit: SBOM, reproduzierbare Builds, geprüfte Dependencies, kontrollierte Update-Kanäle, keine heimlichen Upgrades. In kritischen Umgebungen ist Supply-Chain oft das größere Risiko als ein einzelner Exploit.

Wenn zwei oder mehr dieser Punkte nicht verhandelbar sind, wird Buy schnell zum Fremdkörper in Ihrer Architektur.

Eine Entscheidungsmatrix: Wo bauen, wo kaufen, wo trennen

Statt Build vs Buy binär zu sehen, trennen Sie entlang klarer Verantwortungsgrenzen:

  • Domänkern selbst bauen: Alles, wo Fehler existenziell sind – Entscheidungslogik, Sicherheitsfunktionen, kritische Datenhaltung, Audit-Trails, Integrationsschichten zu Anlagen/Flotten – gehört in Ihre Ownership.
  • Commodity-Komponenten kaufen: Datenbanken, Message-Broker, Storage, Observability-Stacks, GPU-Server, Open-Source-Modelle oder -Runtimes, sofern sie hinter Ihrer Perimeter-Kontrolle laufen und hart eingefasst sind.
  • Anpassbare statt unkontrollierbare Externals: Wenn externe Services nötig sind, dann nur solche, die in Ihrem Perimeter betreibbar sind (on-premises, air-gapped tauglich) und sich deterministisch versionieren lassen.

Ein pragmatisches Bewertungsraster (vereinfachte Checkliste):

  • Muss ohne Internet funktionieren? Wenn ja, API-First-Cloud fällt raus, lokale Deployability ist Pflicht.
  • Brauchen Sie vollständige Revisionssicherheit? Wenn ja, Event-Sourcing/Audit-Logging, deterministische Replays und versionierte Modelle sind ein Muss – Black-Box SaaS wird schwierig.
  • Gilt ein Latenz-Budget <100 ms End-to-End? Dann Edge-Inferenz und lokal gecachte Features/Modelle vorziehen.
  • Lebenszyklus >10 Jahre? Vermeiden Sie proprietäre SDKs mit kurzer Halbwertszeit, setzen Sie auf stabile, dokumentierte Schnittstellen und reproduzierbare Toolchains.
  • Daten dürfen rechtlich nicht in US-Jurisdiktion? Dann keine US-Cloud-Abhängigkeiten, selbst bei EU-Regionen. On-prem-first Architektur.

Architekturmuster, die in der Praxis tragen

Air-gapped Edge-Inferenz mit zentralem Training

  • Edge: Geräte/Kameras/PLC nahe Prozess, Inferenz auf GPU/TPU/CPU (z. B. Jetson, RTX Industrial, CPU-optimiert mit int8-Quantisierung), lokale Puffer für Daten und Features, mTLS-gesicherte Kommunikation, kein Internetzugang.

  • Zentrale: On-prem-Cluster für Training/Feinjustierung, Model Registry, Feature Store, Offline-Update-Kanal (signierte Artefakte), GitOps für Verteilung in Stages (Canary/Shadow/Blue-Green).

  • Vorteile: Vorhersagbare Latenz, resiliente Offline-Fähigkeit, kontrollierte Modell-Rollouts, klare Datenhoheit.

Strangler-Pattern für Legacy-Migration

  • Bestehende Monolithen bleiben zunächst unangetastet.

  • Anti-Corruption Layer kapselt proprietäre Protokolle/Binaries.

  • Neue Services übernehmen schrittweise Funktionen durch Routing-Regeln, bis der Legacy-Kern entbehrlich wird.

  • Vorteil: Keine Betriebsunterbrechung, harte Schnittstellenverträge, reduzierte Risiken.

Event-Sourcing plus revisionssichere Datenhaltung

  • Wichtige Geschäftsereignisse als unveränderliche Events mit fortlaufender Sequenznummer speichern.

  • Projektionen (Materialized Views) sind abgeleitet und jederzeit neu aufbaubar.

  • Vollständige Nachvollziehbarkeit und Replays, besonders wichtig bei Sicherheits-, Qualitäts- und Compliance-Fällen.

Multi-Model-Serving und kontrollierte Experimente

  • Modellversionen parallel betreiben (Shadow/Canary), klare Abort-Kriterien, Evaluationsmetriken vor Produktionsfreigabe.

  • Feature-Parität und Daten-Drift-Monitoring lokal, ohne Telemetrie nach außen.

  • Gated Deployment: Keine Freigabe ohne dokumentierte Evaluierung.

On-prem MLOps als Standardbausteine

  • Feature Store, Model Registry, Pipeline-Orchestrierung, Artefakt-Registry, alles innerhalb Ihres Netzwerks.

  • Reproduzierbare Builds (Bazel/Nix), SBOM-Generierung und Policy-Gates in der CI.

  • Private Container-Registry, signierte Images, SLSA-orientierte Lieferkette.

Sicherheits- und Governance-Bausteine

  • HSM/KMS für Schlüsselverwaltung, mTLS per Service Mesh nur, wenn Komplexität vertretbar ist; sonst klare mTLS Point-to-Point.

  • Signierte Updates, offline verifizierbare Metadaten, Whitelisting statt Blacklisting.

  • Least-Privilege-RBAC/ABAC durchgängig, besonders für Modelle und Feature Stores.