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

Das eigentliche Problem ist nie „Welche KI nehmen wir?“, sondern: „Welche Systeme dürfen unsere Daten überhaupt sehen und welche Systeme dürfen Entscheidungen treffen?“ Wenn Sie in einer Fertigungslinie Defekte erkennen, in einer Leitstelle Züge disponieren oder in einer Simulationsumgebung Piloten trainieren, dann entscheidet sich die Architektur nicht an einem hübschen Demo-Video, sondern an fünf harten Realitäten:

  • Datenhoheit: Wer darf auf Rohdaten zugreifen? Können Sie ein komplettes Audit fahren – inklusive Modellversion, Prompt, Kontextdaten und Entscheidungspfad?

  • Latenz und Determinismus: Rechnet Ihr System konsistent unter 50 ms, air-gapped, ohne Cloud-Abhängigkeit?

  • Integrationstiefe: Wie integrieren Sie in gewachsene SPS-/MES-Landschaften, in Flotten-Telemetrie oder in proprietäre Vermessungsgeräte – ohne deren Takt zu stören?

  • Sicherheitsdomäne: Dürfen Sie Updates nur in Wartungsfenstern einspielen, mit Signaturkette und SBOM? Brauchen Sie reproduzierbare Builds und deterministische Artefakte?

  • Verantwortlichkeit: Wem gehört die Roadmap? Wer behebt ein Edge-Case in Woche 47, wenn das Standardprodukt sagt: „Kommt im Q2 nächsten Jahres“?

Aus dieser Perspektive wird „Build vs. Buy“ weniger zur Einkaufsfrage und mehr zur Systemarchitekturentscheidung. Und in vielen industriellen, sicherheitskritischen oder hochregulierten Umgebungen ist „Build“ keine Boutique-Option, sondern die einzige vernünftige.

Wann „Buy“ scheitert – konkrete technische Kanten

Nehmen wir drei typische Szenarien:

1) Visuelle Qualitätskontrolle in der Fertigung:

  • Kamerastreams mit 120 FPS, lokale Inferenz, deterministische Reaktionszeiten <100 ms zur Ansteuerung von Ausschleusersystemen.

  • Daten dürfen das Werk nicht verlassen; Trainingsdaten enthalten IP-kritische Konstruktionsdetails.

  • SaaS-Angebot: Schickt Frames in die Cloud, liefert Inferenz in 500–1500 ms, speichert Daten in einem Multi-Tenant-Backend. Ein „On-Prem-Agent“ puffert nur – die Entscheidung fällt in der Cloud.

  • Resultat: Latenz, Datenschutz und Audit scheitern. Der Nachbau mit Edge-Inferenz, lokalem Feature-Store und modellbasiertem Versioning ist faktisch ein „Build“.

2) Flottenintelligenz im Bahnumfeld:

  • Fahrzeuge funken über unzuverlässige Links (GSM-R/4G), Datenfenster sind begrenzt, Software-Updates müssen signiert, staged und rückrollbar sein.

  • Vendor-Lösung bietet ein zentrales Cloud-Portal, erfordert permanente Connectivity, Client-Agent ist Closed-Source.

  • Resultat: Keine deterministische Update-Kontrolle, kein belastbares Offline-Verhalten, keine nachvollziehbare Supply-Chain der Binaries. „Buy“ kollidiert mit Betriebswirklichkeit.

3) LLM-gestützte Assistenz für Wartungsdokumentation:

  • Dokumente sind vertraulich, Metadaten sind geschäftskritisch. Es braucht revisionsfeste Protokollierung: Wer hat welche Antwort basierend auf welchem Kontext erzeugt?

  • API-LLM-Anbieter wirbt mit BYOK und EU-Region. Der Control-Plane-Traffic, Telemetrie und Model-Updates laufen dennoch über den SaaS-Backbone.

  • Resultat: Datenhoheit bleibt unvollständig, Audit-Pfade sind fragmentiert, Inferenzkosten schwer vorhersagbar. Für regulierte Umgebungen führt der Weg zu einem On-Prem-Stack mit eigener Observability und Policy-Enforcement.

Diese Beispiele zeigen: Das Problem ist nicht „SaaS ist schlecht“, sondern „SaaS ist ein Multi-Tenant-Betriebsmodell mit Annahmen, die in Ihrer Domäne nicht gelten“. Sobald Souveränität, deterministische Latenz, Offline-Fähigkeit und tiefe Integration unverhandelbar sind, wird Buy zur Anpassungsbaustelle – und die teuerste Form von Build: Build-by-Workaround.

Entscheidungskriterien: Vier Achsen statt Checkliste

Statt Feature-Checklisten empfehle ich eine Bewertung entlang vier Achsen. Sobald zwei davon „rot“ sind, ist Build sehr wahrscheinlich die bessere Wahl.

1) Souveränität und Governance

  • Datenfluss: Können Sie jeden Datenfluss belegen? Existiert ein Modus, in dem kein Byte das Netz verlässt – auch kein Telemetrie-Metadatum?

  • Auditierbarkeit: Versionierte Modelle, Prompts, Retrieval-Kontexte, Feature-Transformationen – alles revisionsfest, maschinenlesbar.

  • Tenant-Isolation: Single-Tenant-Deployment, separater Keyspace, kein Shared Control Plane.

  • Entscheidung: Wenn Sie hier streng sind, fallen Multi-Tenant-SaaS, „Phone-Home“-Appliances und BYOK-Illusionen raus.

2) Echtzeit- und Betriebsanforderungen

  • Latenzbudget: 1–100 ms schließt Roundtrips zur Cloud praktisch aus.

  • Jitter-Toleranz: SPS- oder Motion-Control-Integration verlangt geringe Varianz.

  • Offline-Betrieb: Air-gapped? Muss der letzte Known-Good-Stand ohne Internet funktionieren?

  • Entscheidung: Edge-Inferenz mit lokalem Message-Bus, deterministische Schedulings, predictable GC – das ist Build-Territorium.

3) Integrationslandschaft

  • Protokolle: OPC UA, Modbus, proprietäre Feldbusse, CAN, ARINC 429 – mit restriktiven Timing-Vorgaben.

  • Datenmodelle: Historian, MES, PLM, DMS – in individuellen Schemata mit Evolutionszwang.

  • Change-Policy: Backwards compatibility, contract tests, Maintenance-Fenster.

  • Entscheidung: Tiefe, bidirektionale Integration mit Legacy-Systemen ist selten ein Produkt-Feature, sondern ein Projekt.

4) Lebenszyklus und Eigentum

  • Roadmap-Kontrolle: Feature X bis Datum Y – garantiert?

  • Reproduzierbarkeit: Build deterministisch (Bazel/Nix), SBOM, Sigstore/Notary, Air-Gap-Update-Pfade.

  • Personengebundenes Wissen vs. Dokumentierte Entscheidungen (ADR, RFC).

  • Entscheidung: Wenn Sie die Betriebshoheit brauchen, übernimmt ein Produkt-Hersteller Ihre kritische Lieferkette – oder Sie übernehmen sie.

Architekturbausteine für „Build“ – pragmatisch, nicht ideologisch

Wenn Build die logische Konsequenz ist, heißt das nicht „alles neu erfinden“. Es heißt: Eine produktlinienfähige Architektur aufbauen, die wiederverwendbare Bausteine nutzt und Ihre Domänenlogik kapselt. Einige bewährte Muster:

Edge-to-Core Referenzarchitektur (industriell)

  • Edge Layer:

  • Containerisierte Inferenzdienste (z. B. TensorRT/ONNX Runtime) hinter einem lokalen gRPC/REST-Gateway.

  • IPC via ZeroMQ oder Shared-Memory, je nach Latenzbedarf.

  • Message-Bus (NATS/Kafka) für Ereignisse und Telemetrie, lokal persistierend.

  • Echtzeitfähige Komponenten unter Linux mit PREEMPT_RT oder in Userspace mit isolierten CPU-Cores; deterministische GC vermeiden, wo es kritisch ist.

  • Core Layer (On-Prem-Cluster):
  • Kubernetes on-prem (k3s/microk8s/OpenShift je nach Governance), NetworkPolicies strikt, PodSecurity/verifizierte Signaturen.
  • Feature Store on-prem (Feast mit Postgres/Redis), Model Registry (lokal, OCI-konform in Artifactory/Harbor).
  • CI/CD: GitOps (ArgoCD/Flux), signierte Artefakte, Promotion über Stages (dev → staging → canary → prod), Air-Gap-Sync via signierten Bundles.
  • Observability: Prometheus/Grafana, OpenTelemetry, Graylog/ELK – alles lokal, mit Langzeitarchiv auf WORM-Speicher wenn nötig.