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

Es gibt zwei typische Anlässe, an denen sich „Build vs. Buy“ in der Industrie zuspitzt: Erstens, wenn eine Abteilung schnell Ergebnisse braucht und ein Cloud-Produkt scheinbar alles auf Knopfdruck löst. Zweitens, wenn spätestens bei Security-Review, Datenschutzfolgeabschätzung oder Testbetrieb klar wird: Das Produkt passt nicht in die eigene Architektur und bedroht die Souveränität über Daten, Betrieb und Weiterentwicklung.

Ich schreibe aus der Perspektive eines Softwarearchitekten, der sicherheitskritische Systeme (Defense, Luftfahrt) und industrielle Plattformen verantwortet hat. Meine These ist einfach: In Domänen, in denen Datenhoheit, Zertifizierbarkeit und determinierbarer Betrieb nicht verhandelbar sind, ist individuelle Entwicklung keine Kür, sondern Grundvoraussetzung. Sie ist nicht „teurer Luxus“, sondern die einzige belastbare Methode, unter harten Randbedingungen verlässlich zu liefern. Aber: Man muss sie richtig aufsetzen – technisch, organisatorisch und mit einem klaren Blick auf Trade-offs.

Problemrahmen statt Technologieliebe

Bevor es um Tools, Modelle oder Frameworks geht, ist die Problemformulierung der eigentliche Hebel. In regulierten Umgebungen sind es selten algorithmische Wunder, die Projekte scheitern lassen, sondern unscharfe Anforderungen, ungeklärte Betriebsmodelle und unterschätzte Integrationskosten in Altlandschaften.

Die fünf Achsen, entlang derer Build vs. Buy sauber entschieden werden muss:

  • Souveränität und Rechtsrahmen: Dürfen Daten die Infrastruktur verlassen? Akzeptieren wir Multi-Tenancy? Wer kontrolliert Logs, Modelle, Trainingsartefakte?
  • Bedrohungsmodell und Angriffsfläche: Welches Risiko entsteht durch externe Abhängigkeiten (Software Supply Chain, Telemetrie, Supportzugänge)?
  • Latenz, Verfügbarkeit, Topologie: Müssen Systeme offline/air-gapped funktionieren? Welche Reaktionszeiten sind zwingend? Wo liegen Edge, Werk, Zentrale?
  • Lebenszyklus und Änderungsdynamik: Wer trägt das technische Eigentum (Technical Ownership) über Jahre? Wie schnell müssen wir auf Regulatorik, Sicherheitslücken, Domänenwissen reagieren?
  • Zertifizierbarkeit und Audit: Wie werden Nachvollziehbarkeit, deterministisches Verhalten (so weit erreichbar) und Tests nachgewiesen?

Ein Produkt „von der Stange“ kann nur dann passen, wenn diese Achsen unkritisch sind. In der Praxis sind sie es in unseren Branchen selten.

Wann Buy funktioniert – und wann nicht

Buy eignet sich, wenn:

  • Die Domäne commodity ist: CRM-ähnliche Abläufe, Office-Workflows, generische Kollaborationstools.
  • Daten- und Zugriffsanforderungen entspannt sind: keine sensiblen Betriebsdaten, keine personenbezogenen Daten, keine Geheimhaltungsstufen.
  • Cloud-first akzeptiert ist: Externe Telemetrie, US- oder außereuropäische Jurisdiktionen sind kein Showstopper.
  • Integrationstiefe gering bleibt: wenige Schnittstellen, keine Safety- oder Echtzeit-Anforderungen.

Typische Beispiele: Ticketing, Standard-BI auf pseudonymisierten Daten, interne Kommunikation.

Buy scheitert zuverlässig, wenn:

  • Air-Gap oder De-Internet zwingend ist: Produkt braucht permanente Cloud-Telemetrie, Online-Lizenzierung oder schiebt Diagnosedaten nach außen.
  • Multi-Tenancy inakzeptabel ist: Mandantentrennung reicht nicht, es muss Single-Tenant- oder On-Prem-Deployment sein – inklusive Logs und Modellartefakten.
  • Zertifizierung erfordert, dass Artefakte, Toolchains und Build-Pfade unter eigener Kontrolle stehen.
  • SLA-relevante Latenzen/Verfügbarkeiten nur mit lokaler Nähe erreichbar sind.
  • Das Fachproblem nicht „Standard“ ist: Qualitätssicherung an der Linie, domänenspezifische Computer Vision, komplexe Flottenintelligenz, Agentensysteme im Betrieb.

In diesen Fällen ist Build nicht nur möglich, sondern geboten. Die Frage ist dann: Wie baut man so, dass Risiken reduziert, Lernkurven beschleunigt und Total Cost of Ownership im Griff bleiben?

Technical Ownership statt Tool-Zoo

Der größte Fehler in Build-Projekten ist nicht die Wahl von Sprache X oder Framework Y, sondern fehlende Technical Ownership. Ohne klare Produkt- und Architekturverantwortung ertrinken Teams im Tool-Zoo.

Technical Ownership heißt:

  • Eine verantwortliche Architekturinstanz, die Long-Term-Entscheidungen dokumentiert (ADR – Architecture Decision Records) und verteidigt.
  • Eine Roadmap, die Fachwert, Risikoabbau und technische Schulden austariert – mit expliziten Kill-Criteria für Pfade, die nicht tragen.
  • Eine Governance über Artefakte: Jede Binary, jedes Modell, jeder Container ist reproduzierbar baubar, signiert und tracebar (SBOM).
  • Infrastruktur als Produkt: CI/CD, Paket- und Container-Registries, Observability, Secret-Management – alles unter eigener Kontrolle, auch air-gapped.
  • Ein klarer Plan für Wissensdiffusion: Wissen hängt nicht an Einzelnen, Pairing, Reviews, Onboarding-Pfade sind fester Bestandteil.

Diese Ownership ist die Versicherungspolice gegen Personenrisiken, Regulatorikänderungen und Lieferkettenprobleme.

Architekturpatterns für souveräne Systeme

Souveränität entsteht aus architektonischen Entscheidungen, nicht aus Folien. Folgende Patterns haben sich bewährt:

1) Data Plane on-prem, Control Plane unter eigener Hoheit

  • Datenverarbeitung (ETL, ML Inferenz, Agentenlaufzeit) läuft in eigenen Rechenzentren, Werken oder Edge-Knoten.

  • Control- und Management-Ebenen (Deployment, Policy, Observability) sind ebenfalls selbst betrieben; kein externer Telemetrie-Backchannel.

  • Artefakte werden über signierte, offline-fähige Pipelines verteilt.

2) Minimaler, hart gemachter Runtime-Footprint

  • Für Safety/Echtzeit-nahe Teile: C++/Rust, statisch verlinkte Artefakte, bewusst kleines OS-Image (z. B. distroless).

  • Sandboxing (seccomp, AppArmor) und Read-only-Dateisysteme, wo möglich.

  • Für ML-Inferenz: ONNX Runtime/TensorRT/CPU-Backends je nach Hardware-Budget; strikte Versionierung und Reproduzierbarkeit.

3) Edge-First-Topologien mit klaren Degradationsmodi

  • Lokale Entscheidungen bleiben lokal; zentrale Systeme orchestrieren, aber blockieren nicht.

  • Degradationsmodi sind fachlich sinnvoll definiert: Was darf offline weiterlaufen, was wird konservativ abgeschaltet?

  • Synchronisation ist asynchron und idempotent.

4) Integration über robuste, versionierte Verträge

  • Schnittstellen sind versioniert und mit Contract-Tests abgesichert.

  • Altsysteme werden über Gateways entkoppelt (z. B. OPC UA/Modbus für OT, gesicherte Adapter für proprietäre Protokolle).

  • Keine impliziten Abhängigkeiten auf proprietäre Datenbank-Tricks; Portabilität bleibt Designziel.

5) Auditierbarkeit „by design“

  • Jeder Modell- und Software-Release ist referenzierbar: Trainingsdaten-Snapshots, Hyperparameter, Code-Commit, Compiler-Toolchain.

  • Observability on-prem: Traces, Metriken, Logs mit eigener Retention-Policy; kein Datenabfluss.

  • Test- und Freigabeprozesse sind reproduzierbar und belegbar.

Was bedeutet das konkret bei KI/ML?