• LLM/Agenten-Governance:
  • Policy-Engine für Toolzugriffe (welcher Agent darf welche Aktion), Least Privilege.
  • Prompt/Response/Tool-Call-Logging mit PII-Scrubbing; Reproducibility durch Fixierung von Modellversion und Konfiguration.
  • Evaluationsharness mit Domänen-Tasks, offline; Rollback-Pfade.
  • Air-gapped Update-Mechanismen für Modellartefakte, klar signiert und auditierbar.

4) Edge-Architektur und Air-Gap-Betrieb

  • Edge Nodes:
  • Minimal-Footprint Runtimes, Read-only Root-FS, transaktionale Updates (A/B-Partition).
  • Remote-Management über Pull-basierte, signierte Bundles; keine dauerhafte eingehende Ports.
  • Lokale Caches für Modelle/Policies, definierte TTLs, Degradationsverhalten bei Stale-Content.
  • Steuerungslogik:
  • Strikte Trennung: Empfehlungen (AI) vs. Steuerbefehle (PLC/Safety). Kein Direktdraht ohne Freigabe.
  • „Human-in-the-Loop“ als Systemkomponente: UI/UX für schnelle Freigaben, Eskalation, Begründungserfassung.

Qualitätssicherung: Wie „Done“ in sicherheitskritischen Domänen aussieht

  • Testpyramide konsequent:
  • Unit-Tests als Standard, Property-based Tests für kritische Logik.
  • Contract-Tests zwischen Services und zu Legacy-Gateways.
  • Simulations-/Hardware-in-the-Loop-Tests für OT-Interaktionen.
  • Fuzzing an Schnittstellen (Parser, Protokolle), Fault Injection, Chaos-Experimente unter kontrollierten Bedingungen.
  • Statische Analyse und Code-Standards:
  • Sprachspezifische Regeln (z. B. MISRA-ähnliche Strenge, wo passend), Linter/Gates in CI.
  • Pair-/Peer-Reviews mit Checklisten, dokumentierte Architekturentscheidungen (ADRs).
  • Nachweisführung:
  • Traceability vom Requirement über Testfall zum Artefakt/Build.
  • Unveränderliche Artefaktablage (WORM), signierte Reports, Auditbarkeit ohne Internet.

Kosten, Zeit und die Illusion der Abkürzung

„Buy“ wirkt schneller und billiger – bis die ersten nicht verhandelbaren Anforderungen auftauchen: Datenresidenz, Offline-Betrieb, Integrationen, Audit. Dann stapeln sich Workarounds, Gateways und Vertragszusätze. Die Gesamtkosten verschieben sich in die Zukunft – und verketten Fachlichkeit mit Vendor-spezifischer Technik.

„Build“ braucht eine ehrliche Planung:

  • Vertical Slice statt Big Bang:
  • Ein Ende-zu-Ende-Use-Case mit allen Schichten (Ingestion, Verarbeitung, Inferenz, HMI, Betrieb).
  • Früh sichtbare Risiken: Latenz, Datenqualität, Akzeptanz im Betrieb.
  • Plattform vor Feature-Feuerwerk:
  • CI/CD, Observability, Security, GitOps stehen vor „dritten Use-Case“.
  • Operative Fähigkeiten (On-Call, Runbooks) parallel zur Entwicklung aufbauen.
  • Entscheidungen bewusst reversibel halten:
  • Austauschbare Komponenten wählen (z. B. Message-Bus, Registry, Inferenz-Server).
  • Adaptermuster und klare Ports/Adapter statt Direktbindungen.

Migrationsstrategie ohne Betriebsunterbrechung

  • Strangler-Fig-Pattern:
  • Neue Funktionen außen herum aufbauen, Legacy schrittweise strangulieren.
  • Proxy-Schicht, die Alt-/Neu-Routing kapselt, mit Telemetrie und Feature-Flags.
  • Dual Run/Shadow Traffic:
  • Neue Services mitlesen lassen, Ergebnisse vergleichen, Drift tracken.
  • Graduelle Umschaltung mit Canary, Rollback definiert.
  • Datenmigration:
  • CDC für schrittweises Umschalten, Backfill-Jobs, Idempotenz sicherstellen.
  • Konsistenzprüfungen, Cutover-Fenster planen, Notfallpfade dokumentiert.
  • Schnittstellenhygiene:
  • Versionierte APIs/Schemata, Deprecation-Pläne, Contract-Tests als Gate.

Technical Ownership: Was es konkret bedeutet

  • Eine accountable Einheit:
  • Ein Team trägt Ende-zu-Ende-Verantwortung für NFRs, SLOs, Kosten, Security.
  • Kein „Throw over the wall“ zu Betrieb oder Fachbereich.
  • Entscheidungsdisziplin:
  • ADRs für Architekturentscheidungen; regelmäßige „Readiness Reviews“ vor Releases.
  • Messbare SLOs, Fehlerbudgets, Budgets für Zuverlässigkeit (Zeit und Geld).
  • Dokumentation, die benutzt wird:
  • Runbooks, Arch-Skizzen, Sequenzdiagramme für Kernpfade; keine PowerPoint-Architektur.

Fallskizzen aus der Praxis (anonymisiert)

  • Defense: Bildauswertung an der Edge, komplett offline. Modelle werden als signierte Bundles verteilt, auf GPU-Edge-Knoten quantisiert ausgeführt. Jeder Inferenzpfad ist nachvollziehbar, Ausnahmen lösen definierte Eskalationsketten aus. „Buy“ scheiterte an Air-Gap und Auditierbarkeit.
  • Fertigung: Visuelle Fehlererkennung in einer Montagelinie mit Sekunden-Taktzeit. Integration in bestehende PLC-Signale, Empfehlungen nur als „Assist“ mit Mensch-Freigabe. LLM-gestützte Störgrund-Ursache-Analyse läuft on-prem, ohne externe API. „Buy“ scheiterte an Latenz und OT-Integration.
  • Bahn: Flottenintelligenz mit Event-Streaming von Fahrzeug- und Depotanlagen. Predictive-Modelle versioniert, Rollouts gestaffelt nach Depot. Reporting und Audit vollständig im eigenen Rechenzentrum. „Buy“ scheiterte an Datenresidenz und Vendor-Lock-in in der Streaming-Schicht.

Entscheidungs-Checkliste: Ist Build hier zwingend?

  • Müssen Daten, Telemetrie und Modelle die eigene Domäne niemals verlassen?
  • Gibt es harte Latenz-/Verfügbarkeitsanforderungen an der Edge/OT?
  • Ist Auditierbarkeit/Reproduzierbarkeit eine Zulassungsvoraussetzung oder vertragliche Pflicht?
  • Benötigen Sie Anpassungen an Protokollen/Legacy, die ein Standardprodukt nicht sauber abbildet?
  • Dürfen Sie Vendor-Binaries/Closed-Source-Komponenten nicht in sicherheitskritische Pfade aufnehmen?
  • Haben Sie eine Organisation, die Technical Ownership übernehmen kann oder aufbaut?

Wenn Sie mehrere Fragen mit „Ja“ beantworten, ist Build nicht Luxus, sondern zwingend. Der operative Aufwand ist real – aber kalkulierbar, wenn Sie Plattform, Governance und Qualität von Anfang an ernst nehmen.

Praktische Startempfehlung (90 Tage)

  • Woche 1-2:
  • Nicht verhandelbare Anforderungen dokumentieren, Threat Model erstellen.
  • Entscheidungsprinzipien und ADR-Template festlegen.
  • Woche 3-6:
  • On-prem Grundplattform (GitOps, Registry, Observability, IdP) aufbauen.
  • Vertical Slice definieren (ein Use-Case), Dummy-Integrationen erstellen, Latenz-Budgets festlegen.
  • Woche 7-10:
  • Echte Integrationen zu einem Altsystem, Datenpfad und Inferenzpfad Ende-zu-Ende fertigstellen.
  • Testpyramide und Runbooks anlegen, SLOs instrumentieren.
  • Woche 11-13:
  • Canary-Rollout im Schattenbetrieb, Metriken evaluieren, Incident-Drills durchführen.
  • Entscheidungsvorlage: Skalieren oder Kurs korrigieren.

Ein Wort zu LLMs in Industrien

Generative Systeme sind wertvoll für Wissensarbeit, Störungsanalyse, Prozedurengenerierung. Aber:

  • On-prem-Inferenz reduziert Datenrisiken und Latenz. Für viele Aufgaben reichen mittelgroße Modelle, quantisiert, mit Retrieval aus Ihrer Domäne.

  • Agenten brauchen harte Zäune: Tool-Permissions, Transparenz über Aktionen, Freigabepunkte.

  • Beobachtbarkeit ist kein Nice-to-have: Prompt- und Antwort-Logging, Evaluationssets, Drift-Erkennung und reproduzierbare Konfigurationen sind Pflicht. Ohne das betreiben Sie eine unprüfbare Blackbox.

Fazit