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

In der Industrie hört man oft: „Wir kaufen erst einmal etwas Fertiges, um Geschwindigkeit zu gewinnen. Später sehen wir weiter.“ In regulierten Domänen – Defense, Bahn, Luftfahrt, kritische Fertigung – ist „später“ meist teurer, riskanter und operativ schwieriger als „jetzt richtig“. Das ist keine ideologische Aussage gegen Standardsoftware. Es ist eine nüchterne Feststellung aus Projekten, in denen Datenhoheit, Nachvollziehbarkeit und Betriebsstabilität nicht verhandelbar sind.

Souveränität ermöglicht Intelligenz: Ohne technische Souveränität über Datenflüsse, Modelle, Tooling und Deployments bleibt KI in kritischen Systemen eine Blackbox. Und Blackboxen lassen sich nicht auditieren, nicht zertifizieren und im Zweifel auch nicht schnell genug reparieren.

Dieser Beitrag skizziert einen Entscheidungsrahmen aus Engineering-Perspektive: Wann ist „Buy“ tragfähig, und ab wann ist „Build“ die einzige Option? Mit konkreten Architekturmustern, Trade-offs und einer Checkliste, die wir in sicherheitskritischen und industriellen Projekten bewährt sehen.

1. Ausgangspunkt: Problem, nicht Technologie

Klingt banal, wird aber im Alltag gern übergangen: Die Entscheidung Build vs. Buy folgt den nicht-funktionalen Anforderungen, nicht einer Liste an „AI-Features“.

Typische harte Anforderungen in regulierten Umgebungen:

  • Datenhoheit und Residency: Verarbeitung on-prem oder in EU-only-Cloud, strenge Segmentierung zwischen OT und IT, oft luftgetrennte Netze.

  • Auditierbarkeit/Traceability: Vollständige Nachvollziehbarkeit von Trainings-, Test- und Inferenzpfaden (Daten, Modelle, Parameter, Artefakte).

  • Betrieb unter Randbedingungen: Edge-Deployments ohne Internet, strikte Latenzbudgets, deterministische Updates, definierte Wartungsfenster.

  • Langfristiger Lifecycle: 10–20 Jahre Betrieb, Komponenten müssen ersetzbar bleiben, ohne komplette Re-Zertifizierung.

  • Sicherheits- und Freigabeprozesse: SBOM, reproduzierbare Builds, signierte Artefakte, kontrollierte Supply-Chain.

  • Integrationsrealität: Brownfield-IT/OT, proprietäre Feldbusse, historisch gewachsene Datensilos, heterogene Hardware.

Wenn Sie diese Anforderungen ehrlich gegen eine Produktbroschüre halten, kristallisiert sich schnell heraus, was „kaufbar“ ist und was nicht.

2. Wann „Buy“ funktioniert – und wann nicht

Buy ist sinnvoll, wenn:

  • die Domäne nicht-reguliert ist oder Compliance vollständig an den Anbieter delegierbar ist,

  • Daten ohne Risiko in eine Fremdumgebung transferiert werden dürfen,

  • die Lösung entkoppelt von Ihren Kernprozessen betrieben werden kann,

  • der Funktionsumfang weitgehend standardisiert ist (z. B. Office, Commodity-ERP-Module).

Buy scheitert regelmäßig, wenn mindestens eines gilt:

  • Daten dürfen das Werk/Behörde nicht verlassen oder benötigen strikt kontrollierte Residency.

  • Es existiert ein Safety-Case (z. B. DO-178C, EN50128/EN50657, ISO 26262 als Referenzdenken), der deterministische Updates und vollständige Traceability verlangt.

  • Latenz und Verfügbarkeit haben „Hard Realities“ (z. B. 24/7 Linienbetrieb, Zugleittechnik, Simulatoren).

  • Sie brauchen Modell- und Toolchain-Souveränität (Gewichte, Tokenizer, Vektordatenbanken, Evaluationsharness).

  • Lieferkettenrisiken (SaaS-Abhängigkeit, Exportbeschränkungen, einseitige AGB-Änderungen) sind inakzeptabel.

In diesen Fällen kippt die Nutzenfunktion: Was anfangs wie Time-to-Market-Gewinn aussieht, kehrt sich später als Integrationsaufwand, Betriebsschatten und Re-Zertifizierungskosten gegen Sie.

3. Die versteckten Kosten des Kaufens

  • Integrationskomplexität: Jedes „fertige“ System braucht am Ende Adapter in Ihre AuthN/AuthZ, in Ihr Logging, Ihre Netzsegmente, Ihre Datenquellen. Diese Adapter sind Softwareentwicklung, nur ohne vollständige Kontrolle.
  • Update-Takt vs. Freigabeprozess: Ein Anbieter liefert monatlich Features; Ihr Change Advisory Board gibt quartalsweise frei. Ergebnis: Patch-Stau oder „Evergreen“-Zwang mit unkalkulierten Seiteneffekten.
  • Datenegress und Kopplung: Daten rein ist einfach, Daten heraus inklusive Kontext, Schemas und Historie ist schwer. Diese Asymmetrie erzeugt Lock-in.
  • Reproduzierbarkeit: Modelle, die außerhalb trainiert und evaluiert werden, sind schwer reproduzierbar. Ohne deterministische Trainings- und Evaluationspfade bleibt der Safety-Case lückenhaft.
  • Supportpfad: Tickets eskalieren über Zeitzonen, ohne Zugriff auf Code oder Build-Pipeline bleiben Sie am Ende selbst der Incident-Manager – nur ohne Werkzeuge.

4. Architekturmuster, die Off-the-Shelf oft nicht erfüllt

4.1 Souveräne MLOps on-prem

  • Build-Toolchain: Hermetische, reproduzierbare Builds (z. B. Bazel/Nix), signierte Artefakte (Cosign), Supply-Chain-Policy (in-toto/SLSA-Methodik).

  • Daten/Features: On-prem Object Storage (z. B. Ceph/MinIO), Feature Store mit Versionierung, Daten-Governance-Layer mit Zugriffs-Policies.

  • Modellverwaltung: On-prem Model Registry (Versionen, Signaturen, lineage), reproduzierbare Trainingsjobs (Pipeline-as-Code), Dataset-Versionierung.

  • Inferenz: Dedizierte Serving-Layer (GPU/CPU), Circuit Breaker, Canary-Rollouts, Observability (Metriken, Traces, Drift/Outlier-Detection) ohne Telemetrie-Abfluss nach außen.

4.2 Edge/OT-Integration

  • Orchestrierung: k3s/MicroK8s auf Edge-Knoten, Containerd statt Docker-Daemon, eingeschränkte Syscalls (seccomp/AppArmor).

  • Softwarelieferung: Air-Gap-Fähigkeit, Offline-Registries, Artefakt-Signing, A/B-Updates, deterministische Rollbacks.

  • Datenpfade: Store-and-forward, Ereignisbus (MQTT/Kafka in der DMZ), Pufferung für intermittierende Verbindungen, priorisierte Topics für Safety.

4.3 LLM-Agenten mit Governance

  • Policy-first: Tool-Use nur über eine kontrollierte Toolschnittstelle mit Policy-Engine (z. B. OPA-ähnliche Denkweise), Least Privilege pro Agent.

  • Observability: Token-, Prompt- und Tool-Call-Telemetrie on-prem, Replaybarer Auditlog, Prompt-/Output-Diffing, PII-Redaction vor Persistenz.

  • Evaluation: Offline-Eval-Harness mit Golden Sets, kontrafaktische Tests (Prompt-Injection, Jailbreaks), Regressionstests bei Modellwechsel.

  • Isolation: Sandboxing von Tools, Netzwerkkontrollen, explizite Allow-Listen für Datenzugriffe, Timeouts, Rate Limits.

Hinweis: Eine Observability- und Governance-Schicht für LLM-Agenten ist kein „Nice-to-have“, sondern die technische Voraussetzung, um Agenten in produktionsrelevante Prozesse zu integrieren, ohne Sicherheits- und Compliance-Budgets zu sprengen.

5. Technische Ownership als Entscheidungskriterium