Bausteine:

  • Edge-Compute-Boxen mit Härtung: TPM-gestützte Secure Boot-Ketten, Container-Orchestrierung lokal, OTA-Updates über gesicherte Artefaktpfade.

  • Drift-Detection: Online-Statistiken pro Kamera/Produktvariante; Trigger für Labeling-Batches; Feedback-Schleifen mit Werker-Annotationen.

  • Gray-Fail-Strategie: Bei Unsicherheit oder Sensorproblemen schaltet das System in einen „Conservative Mode“ (z. B. höhere Fehlalarmsensitivität, manuelle Verifikation).

  • Testdeck: Synthetische und reale Szenarien als goldenes Dataset, das jede neue Modellversion passieren muss. Bei Nichterfüllung blockiert ein Gate das Deployment.

Warum es funktioniert: Produktionslinien brauchen planbare, konservative Systeme. Dieses Pattern baut absichtlich Sicherheitsnetze ein und gibt Werken operative Eingriffsmöglichkeiten.

Wo „Buy“ sinnvoll bleibt – aber richtig entkoppelt

Nicht alles muss individuell sein. Hardware-Treiber, Visualisierungs-Frameworks, generische Message Broker, Datenbanken, Observability-Stacks – hier lohnt „Buy“ oft. Entscheidend ist, die Abhängigkeit zu begrenzen:

  • Adapter-Layer: Jede COTS-Komponente hinter einem klaren Interface. Der Domänenkern spricht über stabile Ports/Adapter, nicht direkt mit Vendor-SDKs.
  • Datenebene unter Kontrolle: Selbst wenn ein gekauftes System Daten speichert, verbleibt der autoritative Datensatz in Ihrer souveränen Ebene. Exporte/Backups sind dokumentiert und unabhängig wiederherstellbar.
  • Schlüssel und Lizenzen: Kein externer Lizenzserver-Zwang. Offline-taugliche Lizenzen, Escrow-Vereinbarungen für kritische Komponenten.
  • Telemetrie-Whitelists: Keine ausgehenden Verbindungen ohne explizite Freigabe. Default: Deny.

Damit nutzen Sie Standardkomponenten dort, wo sie reif sind, ohne das Systemgehirn aus der Hand zu geben.

Kosten und Risiko realistisch bewerten

„Build“ ist kein Freifahrtschein für unbegrenzte Budgets. Die Kosten werden aber oft falsch modelliert. Ein praktisches Raster:

  • Initiale Architektur und Domänenmodellierung: Legen Sie explizit fest, was „diff“ gegenüber Commodity ist. Alles andere konsequent kaufen.
  • Produktfähige Kern-Assets:
  • Domänenmodell und Invarianten (maschinenlesbar, testbar)
  • Operative Schnittstellen (Runbooks, SLOs, Telemetrie-Standards)
  • Test-Assets (Golden Datasets, Simulations- und Replays)
  • Security-Basis (Secrets, Signaturen, SBOM, Patch-Prozess)
  • Wiederverwendbare Platform-Bausteine: Einmal bauen, vielfach nutzen (z. B. Air-Gap-CI/CD, GPU-Orchestrierung, Agent-Observability, Audit-Backplane).
  • Rollout-Reife zählt doppelt: Ein Feature ohne reproduzierbares Deployment ist eine Haftung, kein Asset.
  • CapEx/OpEx-Ausgleich: On-prem GPU-Kapazität via Pooling (z. B. Multi-Tenancy pro Werk) auslasten; Standardisierungsgrad erhöhen, um Betriebskosten pro Instanz zu senken.

Kostenfallen vermeiden:

  • Anpassungskauf statt Build: Ein COTS so umbauen, dass es domänentauglich wird, erzeugt Schattenentwicklung ohne Kontrolle über den Lebenszyklus.

  • Hidden Cloud Dependencies: „On-prem“-Produkte, die Backchannel brauchen (Aktivierung, Updates, Telemetrie), hebeln Souveränität aus.

  • Individuelle Pipelines ohne Repro: Ohne standardisierte, signierte Artefaktflüsse sind Audit und Root-Cause-Analysen erschwert.

Technical Ownership als Projektversicherung

Technical Ownership bedeutet, dass Architektur, Qualität, Betrieb und Wissenstransfer nicht fragmentieren. Praktisch heißt das:

  • Architekturdokumentation als lebendes System: Architekturentscheidungen (ADRs), Schnittstellenverträge, Boundaries; nicht in PowerPoint, sondern im Repo, versioniert.
  • Operability-first: SLOs, Alarme, Dashboard-Standards, Notfall-Runbooks. Audits beziehen sich auf konkrete Artefakte, nicht auf Absichtserklärungen.
  • Test als Asset:
  • Contract-Tests an Integrationsgrenzen (MES, OPC UA, Flotten-Telemetrie)
  • Property-based Tests für Kerninvarianten
  • Golden Datasets / Dialoge für ML/LLM
  • Chaos- und Failover-Drills für Resilienz
  • Wissenssicherung: Onboarding-Guides, Architektur-Tours, Code-Readability-Standards, Rotations. Senken Sie die Bus-Faktor-Risiken.

Ohne Technical Ownership trivialisiert man Komplexität – bis das erste Audit, der erste Zwischenfall oder die erste regulatorische Anpassung kommt.

Migration ohne Betriebsunterbrechung

Größte Praxisbarriere ist selten Technik, sondern Stillstandsangst. Bewährte Migrationsmuster:

  • Strangler-Pattern: Altsystem bleibt die Fassade, neue Services übernehmen schrittweise Funktionen über Proxies. Keine Big-Bang-Umschaltung.
  • Shadow-Mode: Neue Entscheidungspfade laufen parallel und loggen, beeinflussen aber nicht. Erst bei stabiler Übereinstimmung erfolgt eine Gate-Freigabe.
  • Replay-Harness: Historische Datenströme (Vision-Frames, Sensortelemetrie, Tickets) werden durch neue Pipelines gespielt, um deterministische Abweichungen zu finden.
  • Blue/Green mit Domänenmetriken: Cutover nur, wenn domänenspezifische KPIs im Grünbereich liegen (Fehlalarmquote, Mean Time to Detect, First Pass Yield).
  • Wartungsfenster minimieren: Artefaktvorbereitungen, Datenmigrationen und Tests offline vorziehen; Umschalter als schnelle, im Voraus geprobte Schritte.

Diese Muster lassen sich in regulierten Umfeldern auditierbar dokumentieren und reduzieren Betriebsrisiken erheblich.

Konkrete Integrationskanten: Beispiele aus der Praxis

  • Fertigung: Vision-Befunde als Events in ein bestehendes MES pushen, nicht das MES ersetzen. OPC UA Gateways als Boundary; strikte Contract-Tests, damit Linienwechsel die Vision-Pipeline nicht brechen.
  • Bahnflotte: Telemetriedaten in einen domänenspezifischen Event-Stream normalisieren; Vorhersagen als Anreicherungen, nicht als invasive Änderungen im Dispositionskern.
  • Luftfahrt-Training: Content-Pipelines (Szenarien, Auswertungen) strikt getrennt von der User-Verwaltung; Trainingsauswertung reproduzierbar, damit jeder Pilotenslot auditfest ist.
  • Defense: Air-Gap-first Design; Updatetransfer via signierter Wechseldatenträger; vollständige Offline-Funktionalität inklusive Schlüsseldrehung.

LLM-Agenten: Observability und Governance sind kein „Nice to have“

Sobald Agenten Tools bedienen, brauchen Sie:

  • Vollständige Protokolle: Prompt, Kontext, Tool-Calls, Antworten, Policies, Entscheidungserklärungen.

  • On-prem Observability: Keine Ausleitung in externe SaaS; Metriken und Traces unter eigener Kontrolle.

  • Policy-Engine: Wer darf welche Tools, unter welchen Eingaben? Wie werden sensible Inhalte behandelt? Welche Grenzfälle werden hart abgelehnt?

  • Evaluationsschleifen: Golden Dialogs pro Anwendungsfall, Regressionen bei jedem Modellwechsel, Canary-Rollouts.

In der Praxis setzen wir dazu eine dedizierte Observability- und Governance-Schicht ein, die Agentenverhalten transparent macht und Audits vereinfacht. Der entscheidende Punkt ist die Kontrollierbarkeit – nicht die Modellauswahl.

Build vs Buy: Entscheidungs-Checkliste