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

In sicherheitskritischen und regulierten Branchen wird die Entscheidung „Bauen oder Kaufen“ oft als reine Kostenfrage diskutiert. Aus Architektur-Sicht ist das der falsche Startpunkt. Die Kernfrage lautet: Welche Kontroll-Ebenen benötigen wir, um Systemsouveränität, Auditierbarkeit und Betriebsstabilität über Jahre zu gewährleisten? Erst wenn diese Anforderungen sauber adressiert sind, lohnt sich ein Blick auf Feature-Listen und Lizenzpreise.

Ich schreibe aus der Perspektive eines Softwarearchitekten, der Lösungen in Defense, Luftfahrt und industrieller Fertigung verantwortet hat. In diesen Umfeldern scheitern Off-the-Shelf-Produkte nicht an fehlenden Funktionen, sondern an nicht-funktionalen Anforderungen: Datenhoheit, deterministische Ausführung, Update-Beherrschbarkeit, Latenzbudgets an der Linie, DSGVO-konforme Protokollierung, Air-Gap-Restriktionen, erweiterbare Domänenmodelle. Genau dort entscheidet sich „Build vs Buy“.

Der eigentliche Entscheid: Nicht Feature-Listen, sondern Kontrolle

Bevor Sie Tools evaluieren, definieren Sie Ihre Kontrollbedarfe entlang dieser Ebenen:

  • Datenebene: Wo liegen Rohdaten, abgeleitete Features, und wer hält kryptografische Schlüssel? Können wir jede Datenbewegung nachvollziehen und stoppen?
  • Modelle/Algorithmen: Können wir Trainings- und Inferenzpfade reproduzieren, Daten- und Modellversionen auditierbar machen und Modellverhalten über Zeit vergleichen?
  • Entscheidungslogik: Können wir jede Automationsentscheidung auf Eingaben, Regeln, Modellversion und Tools zurückführen?
  • Betriebsführung: Steuern wir Deployment-Frequenzen, Rollbacks, Patches und Sicherheitsupdates ohne Zulieferer-Tickets oder US-Cloud-Abhängigkeit?
  • Integrationsseams: Haben wir stabile, testbare Grenzen zu Legacy-Systemen (MES, SCADA, Flottensteuerung, Avionik-Testumgebungen), die unter Last und Ausfallbedingungen halten?

Wenn auf diesen Ebenen die Antwort wiederholt „Nein“ ist, wird individuelle Entwicklung zur Pflicht, nicht zur Option.

Nicht-funktionale Anforderungen, die „Buy“ disqualifizieren

1) Souveränität und DSGVO

  • Anforderungen: Datenlokalität on-premises oder in einem souveränen EU-Cloud-Setup; keine Telemetrie nach außen; Schlüsselverwaltung unter eigener Hoheit; Audit-Trails als WORM-Logs.

  • Warum „Buy“ scheitert: Viele Produkte benötigen Lizenzserver-Verbindungen, senden Fehlerberichte oder anonymisierte Nutzungsdaten, oder erzwingen Managed-Services bei US-Providern. Selbst „on-prem“ Editionen sind häufig nur Remote-verwaltete Appliances.

2) Determinismus und Auditierbarkeit

  • Anforderungen: Reproduzierbare Builds, deterministische Pipeline-Läufe, SBOM (Software Bill of Materials), nachvollziehbare Trainingsdaten-Linien, Gültigkeitsbereiche von Modellen (Daten, Betriebsbedingungen).

  • Warum „Buy“ scheitert: Geschlossene Trainingspipelines, undurchsichtige Pre-/Postprocessing-Schritte, fehlende Artefakt- und Metrikversionierung.

3) Latenz und Resilienz an der Kante

  • Anforderungen: Harte Latenzbudgets (z. B. <50 ms pro Bild für Fehlererkennung an der Linie), lokales Fallback bei Netzwerkverlust, definierte Degradationsmodi.

  • Warum „Buy“ scheitert: Zentrale Cloud-Inferenz, aggressive Telemetrie, fehlender „Gray-Fail“-Betrieb (reduzierte Funktion statt Totalausfall).

4) Lebenszyklus und Update-Beherrschung

  • Anforderungen: Langzeit-Support, kontrollierte Patch-Fenster, offline-fähige Updates, qualifizierte Rollbacks, Test-Gates, die regulatorische Nachweise stützen.

  • Warum „Buy“ scheitert: „Evergreen“-Release-Zyklen, Forcierung auf Monatsupdates, Unvereinbarkeit mit Validierungsaufwänden und Safety-Cases.

5) Tool-Use-Sicherheit bei LLM-Agenten

  • Anforderungen: Strikte Gating-Mechanismen für Tools, Inhaltsfilter, PII-Minimierung, vollständige Protokollierung von Prompts/Outputs in souveränem Speicher, reproduzierbare Auswertungen.

  • Warum „Buy“ scheitert: Externe Tool-Anbindungen ohne Policy-Layer, Cloud-only Observability, keine Kontrollpunkte für Agenten-Verhalten.

Architektur-Patterns für „Build“, die in der Praxis tragen

Pattern A: On-Prem AI Fabric

Ziel: Einheitliches Fundament für Computer Vision, Zeitreihenprognose, Anomalieerkennung oder LLM-Inferenz, vollständig souverän betreibbar.

Bausteine:

  • Inferenz-Serving: Kubernetes mit GPU-Device-Plugins, Node Pools mit Taints/Tolerations, damit produktive Modelle isoliert von Experimenten laufen.

  • Feature Store und Model Registry: Versionierte Feature-Pipelines, Artefakte (Modelle, Tokenizer, Pre-/Postprocessing), mit strikter Zugriffskontrolle und Audit-Trail.

  • CI/CD über Air-Gap: Signierte Container-Images, Offline-Registries, Promotion-Pfade (Dev → Staging → Prod) mit Gatechecks (Metriken, Evals, Compliance-Checklisten).

  • Secrets und Schlüssel: HSM-unterstützte Key-Management-Workflows; kryptografische Signaturen für Modelle und Datensätze; Rotation ohne Downtime.

  • Observability: Metriken (Inferenzlatenz, Throughput, GPU-Utilization), Traces über Services hinweg, strukturierte Logs; domänenspezifische Events (z. B. „Defektklasse X über Schwelle Y“).

  • Policy-Enforcement: Admission Controller/OPA-Gatekeeper-Policies, die nur signierte, geprüfte Artefakte in produktive Namespaces lassen.

Warum es funktioniert: Diese Fabric erlaubt harte SLOs, deterministische Deployments und Audits, ohne externe Abhängigkeiten. Gleichzeitig bleibt sie erweiterbar: neue Modelle, andere Sensoren oder zusätzliche Agenten sind orthogonal integrierbar.

Pattern B: LLM-Agenten hinter der Firewall

Ziel: Einsatz generativer Modelle für Wissensabruf, Störungsdiagnose oder Flottenkoordination, aber vollständig kontrolliert.

Bausteine:

  • Retrieval Control: On-prem Vektorindizes, kuratierte Wissensquellen, Mandantenfähigkeit pro Werk/Flotte, strikte Chunking/Redaktions-Policies.

  • Tool Use Gating: Jede Aktion eines Agenten (Ticket eröffnen, Konfiguration ändern, Workflow anstoßen) wird über eine Policy Engine freigegeben. Safety Checks sind deterministisch und loggen Entscheidungsgründe.

  • Prompt/Output Governance: PII-Minimierung vor Speicherung, redaktionelle Filter, Signierung von wichtigen Interaktionen, WORM-Archiv für Audit.

  • Evaluationsharness: Regression-Tests auf Prompts/Tools, Messung von Halluzinationsraten, „Golden Dialogs“ für domänenspezifische Aufgaben, Canary-Deployments für neue Modelle.

  • Inferenzmodelle: Souveräne Basismodelle on-prem, wahlweise feinjustiert; bei Bedarf Inferenz-Isolierung pro Sicherheitsdomäne.

Warum es funktioniert: Das Agenten-Verhalten wird kontrollierbar, wiederholbar und auditierbar. Sie können Fehlerpfade nachvollziehen und das Risiko von unautorisierten Aktionen minimieren.

Pattern C: Computer Vision am Band

Ziel: Visuelle Qualitätsprüfung, Montagefehlererkennung, Predictive Maintenance, ohne Netzabhängigkeit und mit klaren Betriebsgrenzen.