„Wir haben Zugriff auf die API“ ist kein Ownership. Ownership heißt:

  • Sie besitzen und versionieren Quellcode, Build-Skripte, IaC, Konfigurationen und die zugehörige Dokumentation.

  • Sie kontrollieren die Modelle: Gewichte (oder ein klarer Reproduktionspfad), Tokenizer, Training-/Eval-Pipelines, Hyperparameter, Datenschnitte.

  • Sie haben ein SBOM für jede Komponente und können CVEs bewerten und gezielt patchen.

  • Sie können ein System aus dem Nichts neu bauen: deterministisch, auditierbar, in einer definierten Zeit.

  • Sie können Komponenten austauschen, ohne das System zu zerlegen (Ports-and-Adapters-Architektur, saubere Domänenschnittstellen).

Ein praktisches Muster: Trennen Sie kritisch-systemische Domänenlogik strikt von Infrastrukturadaptern. Der Vektorstore ist ein Port, Qdrant/Milvus/pgvector sind Adapter. Das Modell ist ein Port, Model-Server sind Adapter. So vermeiden Sie Produkt-Lock-in und erlauben Ersatzteile über die Produktlebensdauer hinweg.

6. Lifecycle-Denken: 18 Monate vs. 18 Jahre

Fabriklinien, Züge, Flugsimulatoren und Weitverkehrssysteme werden in Dekaden gerechnet. Das widerspricht der Release-Kadenz typischer Cloud-SaaS. Folgende Maßnahmen bringen die Zeitachsen in Einklang:

  • Version Pinning und Langzeitwartung: Planbarer Update-Kadenz, Backporting-Strategie, definierte End-of-Support-Pfade.

  • Komponententausch unter Kontrolle: Abstraktionen, Migrationspfade, Kompatibilitätstests in CI.

  • Vertragsrealität: Serviceverträge an nicht-funktionalen Anforderungen ausrichten (Recovery-Ziele, Reaktionszeiten, Offline-Fähigkeit), nicht an Feature-Roadmaps.

7. Migrationspfad: Vom SaaS-Prototyp zum souveränen Betrieb

Viele Teams starten bewusst mit SaaS, um Hypothesen zu testen. Die Migration gelingt, wenn Sie früh „Entkopplung“ bauen:

  • Strangler-Pattern: Neue, souveräne Services übernehmen schrittweise Pfade, während das alte System parallel läuft.

  • Dual-Run/Shadow-Mode: On-prem-Inferenz shadowt SaaS-Ergebnisse, Metriken und Abweichungen werden gemessen, bis Parität erreicht ist.

  • Datenhaltung: Eigenes Datenmodell und eigene Storage-Pfade etablieren, selbst wenn Inferenz temporär extern läuft.

  • Tooling-Parität: Evaluationsharness und Testdaten on-prem aufbauen, bevor der Cut-over erfolgt.

  • Cut-over unter Last: Traffic-Steuerung (z. B. Feature Flags, Prozent-Rollouts), Rollbackpläne, Change-Fenster.

8. Beispielhafte Entscheidungssituationen aus der Praxis

8.1 Visuelle Qualitätskontrolle in der Fertigung

  • Anforderungen: Millisekunden-Latenz an der Linie, Offline-Betrieb, reproduzierbare Modelle, Auditlog, wartbare Edge-Hardware.

  • Warum Build: Fertige Cloud-Lösungen scheitern an Latenz/Offline, übertragen Bilddaten ins Außenverhältnis, und passen nicht in OT-Sicherheitszonen.

  • Architektur: Edge-K3s-Cluster mit GPU-fähigen Knoten, On-prem-Registry, signierte Container, MinIO als lokaler Store, Canary-Rollouts pro Linie, Monitoring ohne Telemetrie-Abfluss.

8.2 Flottenintelligenz für Schienenfahrzeuge

  • Anforderungen: Heterogene Fahrzeuge, intermittent Connectivity, Safety-Case, lange Lebensdauer.

  • Warum Build: Standard-Telemetrieplattformen verstehen Safety-Prozesse, Offline-Pufferung und Re-Zertifizierungen nicht tief genug.

  • Architektur: Event-getriebene Pipeline (MQTT/Kafka in der DMZ), Feature-Engineering on-edge, serverseitige Inferenz mit deterministisch versionierten Modellen, strikte Trennung von Safety-relevantem und Non-Safety-Bereich.

8.3 LLM-gestützte Betriebsassistenz im Werk

  • Anforderungen: Strikte Datenhoheit, straffe Rechteprüfung, Tool-Use nur für freigegebene Aktionen, Auditierbarkeit jeder Interaktion.

  • Warum Build: SaaS-LLMs sind nicht akzeptabel; generische „Chatbots“ ohne Governance sind Produktionsrisiko.

  • Architektur: On-prem LLM-Serving, Retrieval über einen lokalen Vektorstore, Agenten-Control-Plane mit Policy-Engine, Observability/Tamper-proof-Audit, Offline-Evaluationsharness, definierte Tool-Adapter in isolierten Sandboxes.

9. Qualitätssicherung für sicherheitskritische und datengetriebene Systeme

Klassische QS-Methoden müssen für ML/Agenten erweitert werden:

  • Daten- und Modell-Traceability: Jede Metrik ist an Datenschnitte, Commit-Hashes und Hyperparameter gebunden; reproduzierbare Trainingsruns sind Pflicht.

  • Metamorphe Tests: Prüfen erwarteter Invarianzen (z. B. Beleuchtung, Reihenfolge, Sprache), anstatt auf „richtige Antwort“ zu hoffen.

  • Property-based Testing in Domänenlogik: Für deterministische Teile weiterführend nutzen; grenzt Unsicherheit auf ML-Komponenten ein.

  • Safe-by-Design: Fail-Closed-Mechanismen, Confidence- und Out-of-Distribution-Checks, Fallback-Strategien, Watchdogs.

  • Operational QA: Canary-Einführungen, Shadow-Mode, automatische Drift-Erkennung, klare Degradationspfade und Alarmierung, die in Ihr bestehendes NOC/SOC passt.

10. Sicherheits- und Supply-Chain-Aspekte

  • SBOM und CVE-Management: Keine Blackbox-Container. Komponenten müssen inventory-fähig sein.
  • Signierte Artefakte: Verifizieren vor Deploy, nicht nur beim Build.
  • Air-Gap-geeignete Prozesse: Spiegel-Registries, Offline-Keys, Transfer-Gates mit Scan und Freigabe.
  • Least Privilege durchziehen: Für Agenten-Tools, Services, Nutzer. Kein „God-Mode“-Service-Account.
  • Secrets-Management on-prem: KMS/HSM, Rotationsrichtlinien, kein externer Secret-Backbone.

11. Kostenmodell realistisch rechnen

Kauf wirkt günstig, solange man nur Lizenz und „Erstintegration“ betrachtet. Rechnen Sie mindestens:

  • Integrations- und Anpassungsentwicklung über Produktlebensdauer,

  • Betrieb/Monitoring im eigenen SOC/NOC,

  • Freigabe-/Zertifizierungsaufwände je Update,

  • Ausfallkosten bei Abhängigkeiten (z. B. Connectivity),

  • Exit-Kosten (Datenrückführung, Schnittstellenersatz),

  • Skill-Aufbau und Retention im Team.

Build gewinnt in regulierten Kontexten häufig, weil es Planbarkeit und Kontrollierbarkeit maximiert. Sie ersetzen volatile, externe Risiken durch interne, steuerbare Engineering-Aufwände.

12. Minimalistische Produktstrategie: Kaufen Sie Komponenten, nicht Plattformen

Die Praxis zeigt: „Plattformen“ sind oft Monokulturen mit unscharfen Grenzen. Besser:

  • Kaufen/verwenden Sie austauschbare Bausteine (z. B. Message Broker, Vektorstore, Serving-Layer).

  • Standardisieren Sie auf Protokolle und Schnittstellen, nicht auf Anbieter.

  • Verankern Sie Abstraktionsschichten im Code (Ports/Adapter), nicht in PowerPoint.

So entsteht eine souveräne Plattform – ohne sich selbst in eine unwartbare Eigenkonstruktion zu verrennen.

13. Checkliste: Wenn eines davon zutrifft, tendieren Sie zu Build