Build vs Buy: Wann individuelle Entwicklung die einzige Option ist

In regulierten Industrien entscheiden Sie nicht über Technologie, sondern über Verantwortung. Es geht nicht darum, ob ein Toolkit schneller ist als ein eigenes Modul. Es geht darum, ob Sie die Kontrolle über Datenflüsse, Risiken und Änderungen behalten. Das ist der Grund, warum “Souveränität ermöglicht Intelligenz” für uns keine Marketingfloskel ist, sondern eine Architekturentscheidung.

Wer heute KI-gestützte Systeme in sicherheitskritischen Umgebungen bauen will (Defense, Bahn, Fertigung), wird mit Standardsoftware in eine Reihe nicht verhandelbarer Widersprüche laufen: Daten dürfen das Werk nicht verlassen, aber das Produkt ist Cloud-only. Änderungen müssen in Wochen in den Flugbetrieb, aber das Releasefenster des Anbieters ist quartalsweise. Sie brauchen eine auditierbare Begründung für jede Modellentscheidung, aber die Box ist zu.

Dieses Stück erklärt präzise, wann Build statt Buy keine Frage der Präferenz ist, sondern die einzige Option. Und es zeigt, wie man baut, ohne sich in Jahren an Eigenentwicklung zu verlieren.

Das eigentliche Problem: Kontrolle über Verhalten, nicht über Features

Buy-Entscheidungen orientieren sich oft an Featurelisten. In kritischen Domänen sind Features selten das Nadelöhr. Die Engstellen sind:

  • Entscheidungsnachvollziehbarkeit: Können Sie in sechs Monaten reproduzieren, warum das System eine Entscheidung getroffen hat – inklusive Datenstand, Modell- und Softwareversion?

  • Betriebsmodell: Läuft das System dort, wo es muss – on-premise, am Edge, air-gapped, mit deterministischen Latenzen?

  • Änderungsautorität: Wer bestimmt, wann ein Update kommt, wie es getestet wird und welche Evidenz (Tests, Nachweise) existiert?

  • Integrationslast: Können Sie mit Ihren Protokollen, Ihren Datenmodellen und Ihren Lebenszyklen arbeiten – ohne fragile Bridges zu bauen?

  • Souveränität: Können Sie regulatorische Auflagen (z. B. DSGVO, Exportkontrollen, Geheimhaltungsstufen) technisch garantieren – nicht nur vertraglich?

Wenn eine dieser Dimensionen “nicht verhandelbar” ist, kippt die Entscheidung in Richtung Build – auch wenn Buy kurzfristig schneller erscheint.

Sechs harte Kriterien für Build

1) Souveränität und Jurisdiktion

  • Harte Datenlokalisierung: Wenn Daten das Werk, den Landesverbund oder ein klassifiziertes Netz nicht verlassen dürfen, scheidet jede Lösung aus, die Cloud-only oder nur über US-Hyperscaler verfügbar ist.

  • Gerichtsbarkeit und Zugriffsebenen: Selbst “EU-Rechenzentrum” hilft nicht, wenn der Anbieter unter ausländischer Jurisdiktion steht und Sie keinen technischen Zugriffsschutz gegen Herausgabeanforderungen implementieren können.

  • Beweisführung: In regulierten Umgebungen reicht “Privacy by Policy” nicht. Sie brauchen “Privacy by Architecture”: technische Durchsetzung von Flüssen, Logs, Rechten.

2) Domänenspezifika und Sicherheitsanforderungen

  • Determinismus: In Safety-Kontexten sind nichtdeterministische Laufzeitpfade ein Risiko. ML-Modelle und stochastische Komponenten müssen mit deterministischen Hüllen betrieben werden (z. B. feste Seeds, begrenzte Suchräume, konservative Fallbacks).

  • Erklärbarkeit: Wenn ein Inspektionssystem Ausschuss markiert, brauchen Qualitätssicherung und Audit eine begründbare Kausalkette. Black-Box-Entscheider ohne Einsicht in Feature-Attributionen und Datenstände sind unzureichend.

  • Standards und Nachweise: Ob Luftfahrt, Bahn oder Verteidigung – Sie müssen Testevidenz, Abdeckungsgrade, Traceability von Requirements bis Code/Modell vorlegen. Das ist selten sauber in generischen Produkten eingebaut.

3) Betriebsmodell: On-Prem, Edge, Air-Gapped

  • Harte Latenzbudgets: Ein System, das am Band innerhalb von 50 ms entscheidet, kann keine Roundtrip-Latenzen zur Cloud akzeptieren.

  • Offline-Fähigkeit: Militärische oder Bahn-Betriebsszenarien mit intermittenter Konnektivität erfordern robuste Sync- und Degradationsmodi.

  • Reproduzierbare Deployments: Sie brauchen ein Build- und Release-System, das ohne Internetzugang deterministisch Artefakte erzeugt und verteilt.

4) Lifecycle- und Sicherheitskontrolle

  • Schwachstellen-Management: Sie müssen Patches in Ihrem Takt fahren können – nicht im Takt eines SaaS-Anbieters.

  • Validierte Updates: Jedes Update braucht Regressionstests, Freigaben, ggf. Safety Cases. Sie kontrollieren die Release-Pipeline.

  • Roadmap-Risiko: Kauf heißt, die Produktstrategie eines Fremden ist Ihr Zukunftsplan. Bei Kernsystemen ist diese Abhängigkeit oft nicht tragbar.

5) Brownfield-Integration und Protokolle

  • Feldbusse und OT-Protokolle: OPC UA, Profinet, EtherCAT, CAN – fertige Tools behandeln das oft stiefmütterlich oder nur via teurer Gateways.

  • Semantik-Landschaft: Sie haben historisch gewachsene Datenmodelle, die nicht “gemappt”, sondern technisch ernst genommen werden müssen (inkl. Datenqualität, Zeitreihencharakteristika).

  • Zero-Downtime-Migrationen: Strangler-Pattern statt Big Bang. Standardprodukte erzwingen häufig disruptive Cutovers.

6) KI-/LLM-Governance on-premise

  • Prompt-, Kontext- und Tool-Nachvollziehbarkeit: Jede Agentenaktion muss auditierbar sein – inklusive Datenzugriff, Tool-Aufrufen, Policy-Entscheidungen.

  • Policy Enforcement: Guardrails, Rollen, Red-Teaming, Eval-Suites müssen lokal laufen. Kein Routing sensibler Prompts in externe APIs.

  • Modellverwaltung: Modelle, Tokenizer, Embeddings, Vektordatenbanken – alles lokal, versioniert, reproduzierbar.

Architekturmuster, die in Build-Projekten funktionieren

1) Minimaler Kern mit Erweiterbarkeit

  • Bausteinprinzip: Ein kleiner, hart getesteter Domänenkern (State Machine, Regelsystem, Planungslogik) plus Plugins für Integrationen, Modelle, UI.

  • Versionierte Verträge: Klare, stabil versionierte Interfaces (z. B. Protobuf/gRPC) zwischen Kern und Erweiterungen. Sorgt für unabhängige Releasezyklen.

2) Contract-First-Integration

  • Schnittstellen als Ausgangspunkt: Datenverträge und Event-Schemata sind artefaktisch versioniert, generieren Server- und Client-Stubs, Tests und Migrationshinweise.

  • Evolvierbare Schemas: Semantische Versionierung, Deprecation-Policies, Backfilling-Strategien.

3) Event Sourcing + CQRS, wo Nachvollziehbarkeit Pflicht ist

  • Schreibpfad als Event-Log: Jede fachliche Entscheidung ist ein Event mit Ursprung, Zeit, Identität. Reproduzierbar, rückspielbar.

  • Lesemodelle getrennt: Optimierte Sichten für UI/Reporting können neu aufgebaut werden, ohne Historie zu verlieren.

  • Auditierbarkeit: Veränderungen sind nachvollziehbar, unverfälschbar (Write-Once-Prinzip mit kryptographischer Signierung, wo nötig).

4) Policy as Code

  • Einheitliche Entscheidungslogik: Zugriff, Routing, Fallbacks, Tool-Nutzung werden über deklarative Policies gesteuert (z. B. OPA-ähnliche Ansätze), versioniert und getestet.

  • Reproduzierbare Tests: Jede Policy bekommt Unit- und Szenariotests, Teil der CI/CD.