Build vs Buy: Wann individuelle Entwicklung die einzige Option ist

Die falsche Frage ist: „Welche KI-Plattform ist die beste?“ Die richtige Frage ist: „Welche Anforderungen kann ich nicht verhandeln – und welche Architektur hält dem in meiner Domäne stand?“ In sicherheitskritischen und regulierten Industrien kippt die Antwort oft von „Buy“ zu „Build“, und zwar nicht aus Prinzip, sondern weil das System sonst seine Verpflichtungen nicht erfüllt: Datenhoheit, Auditierbarkeit, deterministische Laufzeit, Integrationsfähigkeit in OT/Legacy, Betrieb ohne Internet, reproduzierbare Qualität.

Ich schreibe das aus der Perspektive eines Softwarearchitekten, der in Defense, Luftfahrt, Bahn, Fertigung und Bauwesen reale Systeme gebaut, integriert und verantwortet hat. Off-the-Shelf-Lösungen scheitern dort nicht an Features, sondern an Randbedingungen. Souveränität ermöglicht Intelligenz – oder anders: ohne Kontrolle über Datenflüsse, Deployment und Betrieb bleibt „KI“ ein schönes Demo-Video.

Worum es wirklich geht: nicht verhandelbare Anforderungen

Bevor Sie eine Linie Code schreiben oder eine Lizenz bestellen, definieren Sie die Constraints, die nicht verhandelbar sind. Alles andere ist Optimierung.

  • Datenhoheit und -residenz:
  • Keine US-Cloud-Abhängigkeit, keine Telemetrie ins Internet, keine Hintergrund-„Phone-Home“-Mechanismen.
  • DSGVO-konformes Logging, PII-Minimierung, Löschkonzepte und klare Zweckbindung.
  • Physische und logische Isolation: Air-Gap, dedizierte Netze, egress-kontrollierte Segmente.
  • Nachvollziehbarkeit und Zertifizierbarkeit:
  • Reproduzierbare Builds, nachvollziehbare Entscheidungen (insbesondere bei ML/LLM), versionierte Modelle und Datensätze.
  • Audit-Pfade: Wer hat wann welches Modell/Prompt/Tool mit welchem Ergebnis verwendet?
  • Erklärbarkeit im Rahmen der Domäne: Keine Blackbox an sicherheitskritischen Aktuatoren.
  • Latenz, Verfügbarkeit, Resilienz:
  • Echtzeitnahe Inferenz an der Edge, deterministische Latenzen.
  • Betrieb auch bei WAN-Ausfall; saubere Degradationsmodi und Offline-Fallbacks.
  • Wartung ohne Produktionsstillstand, Rolling Updates, Blue/Green unter OT-Bedingungen.
  • Integration in OT/Legacy:
  • Industrielle Protokolle (z. B. OPC UA, Modbus, Profinet), ältere Feldbusse, proprietäre Schnittstellen.
  • Lesen/Schreiben mit Bedacht: Safety-Grenzen einhalten, Write-Paths strikt kontrollieren.
  • Schema- und Schnittstellenstabilität, Versionierung, Contract Tests.
  • Bedrohungsmodell und Lieferkettensicherheit:
  • SBOMs, signierte Artefakte, offline-verifizierbare Updates.
  • Minimaler Angriffsvektor: keine unnötigen Abhängigkeiten, Härtung auf OS/K8s/Runtime-Ebene.
  • Trennung von Kontroll- und Datenpfad; Zero-Trust-Prinzipien intern.
  • Operative Ownership:
  • Klare SLOs (z. B. Latenz, Fehlerrate), 24/7-Betriebsfähigkeit ohne externes NOC.
  • Runbooks, On-Call, synthetische Checks, Observability on-prem.
  • Domänenwissen im Team – kein exklusives Wissen beim Lieferanten.

Wo „Buy“ typischerweise scheitert

  • SaaS/APIs (insbesondere generative KI):
  • Datenabfluss (Inhalte, Telemetrie), unsichtbare Modellupdates, unbekannte Trainingsdaten.
  • Juristische Grauzonen bei IP/PII, fehlende Möglichkeit zur Auditierung des Inferenzpfads.
  • Latenz/Verfügbarkeit außerhalb Ihrer Kontrolle.
  • COTS-Software mit „Plugin“-Versprechen:
  • Roadmap- und Upgrade-Zwang, begrenzte Anpassbarkeit dort, wo es wehtut (Persistenz, Echtzeit, Security).
  • Lizenzmodelle, die Edge/Offline-Betrieb erschweren oder verteuern.
  • Abhängigkeit von Vendor-spezifischen Stacks, die Ihre langfristige Architektur einschränken.
  • „Managed“ Open-Source:
  • Gutes Starttempo, aber Betriebs- und Datensouveränitätsfragen bleiben ungelöst.
  • Feature-Freeze, wenn Sie eine exotische Integrationsanforderung haben, die nicht „Mainstream“ ist.
  • Systemintegrationen „ohne Source“:
  • Kurzfristig bequem, langfristig Lock-in. Ohne Quelltext und Build-Pipeline verlieren Sie Kontrolle über Sicherheit, Performance und Änderbarkeit.
  • Incident-Response und Hotfixes hängen von Ticketwarteschlangen Dritter ab.

Heißt „Build“ alles selbst erfinden? Nein. Es heißt, dass Architektur, Code und Betrieb in Ihrer Hand liegen. Sie nutzen Open-Source und Standardkomponenten – aber so, dass Austauschbarkeit, Nachvollziehbarkeit und Offline-Betrieb gewährleistet sind.

Architekturpatterns für Build in regulierten Umgebungen

1) Plattform-Basics on-prem (Foundation)

  • Kubernetes on-prem (voll oder K3s), aber egress-kontrolliert:
  • Private Container Registry, periodische Offline-Spiegelung, Image-Signing (Cosign).
  • GitOps (z. B. Argo CD/Flux) mit Mirror-Repos; keine direkten Internet-Abhängigkeiten.
  • Netzwerksegmentierung (CNI-Policies), Pod Security Standards, minimalistische Base-Images.
  • Identität und Zugriff:
  • Lokaler IdP (OIDC), kurzlebige Tokens, feingranulares RBAC bis auf Namespace/Service-Ebene.
  • Secrets-Management on-prem (z. B. Vault-ähnliche Konzepte), Hardware-Backed Keys, kein Secret im Git.
  • Observability:
  • Metriken, Traces, Logs in Ihrer Domäne; keine externe Telemetrie.
  • Synthetische Checks, Blackbox-Monitoring, Alarmierung mit Playbooks.
  • Kapazitätsmanagement: Sizing, GPU/CPU-Reservations, Quotas.
  • Software Supply Chain:
  • SBOM-Erzeugung in CI, Artefakt-Signing, reproduzierbare Builds.
  • Policy-as-Code (z. B. Admission Controller) für Compliance-Gates im Cluster.

2) Daten- und Integrationsschicht

  • Ingestion:
  • Connectors zu MES/ERP/PLM/SCADA; für OT-Protokolle dedizierte Gateways mit strikter Trennung zum IT-Netz.
  • Change Data Capture für Legacy-DBs, schema-versionierte Topics/Streams.
  • Datenmodell:
  • Domain-driven Design, klar definierte Bounded Contexts.
  • Schema Registry, evolutionäre Schemata, Backward/Forward-Kompatibilität.
  • PII-Minimierung, Pseudonymisierung, Field-Level-Encryption wo nötig.
  • Persistenz:
  • Getrennte Stores pro Workload (OLTP vs. Zeitreihen vs. Blob), Verschlüsselung at rest.
  • Backups, Restore-Übungen, Air-Gap-Export, WORM-Storage für Audit.

3) ML-/AI-Schicht

  • MLOps on-prem:
  • Feature Store, versionierte Datensätze, Model Registry, reproduzierbare Trainingspipelines.
  • Trainingsjobs mit Ressourcenquoten, deterministische Seeds, Datenkarten/Modellkarten als Artefakte.
  • Offline-Benchmarking gegen Zielmetriken, Bias/Drift-Checks.
  • Inferenz:
  • Lokale Inferenz-Server, GPU-Scheduling, Quantisierung/Optimierung (z. B. INT8), CPU-Fallbacks.
  • Concurrency-Limits, Zeitouts, Circuit Breaker, Canary-Rollouts für neue Modelle.
  • Guardrails: Input-Validierung, Output-Sanitization, Score-Thresholds plus Human-in-the-Loop vor Aktuatoren.