2) Safety‑Envelope / Simplex‑Architektur

  • Muster: Ein verifizierter, schlichter Sicherheitsregler überwacht/überschreibt einen leistungsstarken, aber weniger formell abgesicherten Regler oder eine KI‑Komponente. Der Safety‑Regler erzwingt Invarianten (Grenzwerte, Rate‑Limiter, Fallback).

  • Einsatz: Bahn (Zustandsüberwachung mit Eingriffsgrenzen), Produktion (Assistenz‑KI, die nicht autonom schaltet), Defence (Entscheidungsassistenz mit menschlicher Autorität).

  • Trade‑off: Doppelentwicklung, aber Zulassungspfad für Innovationen ohne gesamte Systemklassifizierung zu erhöhen.

3) Kontraktbasierte Schnittstellen

  • Idee: Komponenten kommunizieren über explizite Verträge (Assume/Guarantee), maschinenlesbar versioniert. Kontrakt‑Tests laufen in CI.

  • Nutzen: Inkrementelle Zertifizierbarkeit, isolierte Änderungen, klare Aufwände bei Re‑Zertifizierung.

4) Ereignislog/Audit‑First (Event Sourcing/Append‑Only)

  • Vorteil: Lückenlose Nachvollziehbarkeit, Replays für Tests, forensische Auswertbarkeit.

  • Trade‑off: Komplexere Konsistenzmodelle, aber Audit‑Gewinn und einfachere „Shadow“-Betriebsmodi.

5) Determinismus und Side‑Effect‑Isolation

  • Praxis: Keine Hidden I/O in Domänenlogik, deterministische Seeds für stochastische Komponenten in Tests, reproduzierbare Builds, feste Compiler‑Versionen, pinned Dependencies.

  • Nutzen: Reproduzierbarkeit ist in Audits Gold wert.

6) Speicher- und Typsicherheit

  • Wahl: Für sicherheitskritische Echtzeit‑Teile C/C++ mit strengen MISRA‑Regeln oder Rust für Speicher‑Safety; UI/Business‑Layer flexibel (z. B. C++/Qt, Web).

  • Trade‑off: Höhere Disziplin, aber weniger undefiniertes Verhalten.

7) Betriebsarchitektur mit Souveränität

  • On‑Prem‑Kubernetes in Air‑Gap: Private Registry, signierte Container (z. B. Sigstore/Cosign), SBOMs (CycloneDX), Git‑Ops (ArgoCD/Flux) mit Offline‑Mirrors.

  • Observability: Metriken/Logs/Traces lokal, Langzeitarchiv DSGVO‑konform. Keine Third‑Party‑SaaS für Betriebsdaten in Defence/Bahn.

  • Update‑Strategien: Blue‑Green in Depotumgebung, rollierende Flotten‑Wellen, Hardware‑Gate (nur im Instandhaltungsfenster), stets mit Rollback‑Plan und Fleet‑Health‑Monitoring.

MLOps in regulierten Umgebungen: offline‑fähig und evidenzgetrieben

  • Datenhoheit: Daten verbleiben im Werk/Rechenzentrum. Zugriff per Rollen/Prozessen, Pseudonymisierung wo nötig.

  • Reproduzierbare Trainingspipelines: Versionierte Datasets/Features (z. B. DVC/LakeFS), fixierte Lib‑Stacks, deterministische Seeds, Pipeline‑Definition als Code.

  • Modell‑Governance: Modellkarten, Validierungsberichte, Einsatzgrenzen (Operational Design Domain, ODD), Drift‑Monitore, Freigabeprozesse mit Vier‑Augen‑Prinzip.

  • Shadow‑Mode/Parallelbetrieb: Neue Modelle beobachten/empfehlen, greifen aber nicht ein, bis Nachweise und Monitoring passen.

  • Kein US‑Cloud‑Zwang: GPU‑Cluster On‑Prem, Job‑Scheduler, bewusste Bibliothekswahl ohne Telemetrie‑Exfiltration.

LLM‑Einsatz für Operator‑Assistenz: nur mit Observability und Governance

  • Prinzipien: On‑Prem‑Modelle oder souveräne Hosting‑Partner; Prompt/Output‑Logging mit Zugriffskontrolle; strikte Retrieval‑Scopes; keine ungeprüften externen Aufrufe; human‑in‑the‑loop.

  • Governance: Policies als Code (z. B. zulässige Datenquellen), regelbasierte Guardrails, Auswertung/Audit von Dialogen, klare Deaktivierung bei Drift/Fehlverhalten.

  • Deployment: Containerisiert in isolierten Namespaces, egress‑restricted, mit Not‑Aus‑Schalter. Audit‑Export in das Nachweisarchiv.

MVP neu denken: Minimum Viable Proof statt Minimalprodukt

Ein MVP für ein sicherheitskritisches System ist kein halbgares Feature in der Produktion. Es ist ein minimaler, aber vollständiger Nachweisstrang für einen eng begrenzten Nutzwert – technisch funktionsfähig, betrieblich abgesichert, regulatorisch vertretbar. Elemente:

  • Enges ODD: Präzise begrenzte Einsatzbedingungen (z. B. nur Depotbetrieb, nur Analyse ohne Eingriff, nur bestimmte Flottensegmente).

  • Sicherheitsfall‑Skelett (GSN): Claim–Argument–Evidence sind vorhanden, wenn auch schlank. Annahmen und Einschränkungen sind explizit dokumentiert.

  • Shadow‑Mode oder Read‑Only‑Eingriff: Beobachten/empfehlen statt steuern; Messbarkeit ohne Risikoerhöhung.

  • Technische Schutzschicht: Safety‑Envelope/Rate‑Limiter/Konfidenz‑Gates, die Fehlverhalten technisch unterbinden.

  • Rollout‑Plan mit Kill‑Switch: Klare Abbruchkriterien, sofortige Rollback‑Fähigkeit, Monitoring‑Schwellen.

  • Auditreife Artefakte: Anforderungen, Architektur, Tests, Evidenz, Betriebs‑SOPs – traceable, versioniert.

So sieht ein 12‑Wochen‑Pfad zu einem echten Minimum Viable Proof aus:

  • Wochen 1‑2: Hazard‑Workshop, ODD‑Abgrenzung, Architektur‑Schnitt (Safety‑Envelope, Ports/Adapter), Evidence‑Plan. Aufsetzen von Repro‑Builds, Signing, Private Registry.

  • Wochen 3‑6: Implementierung Domänenkern und technische Schutzschicht, Kontrakt‑Tests, initiale Validierung auf synthetischen/archivierten Daten. GSN‑Skelett mit ersten Evidenzen.

  • Wochen 7‑9: Shadow‑Mode im Zielbetrieb (Air‑Gap vorbereitet), Observability, Drift‑Monitore, Verfahren zur Datenaufnahme DSGVO‑konform. Evidence‑Reviews, Härtung der Betriebsprozesse.

  • Wochen 10‑12: Gesteuerter Feldtest im ODD mit Kill‑Switch, Abschluss‑Nachweise, Go/No‑Go anhand definierter Metriken (Fehlalarmrate, Evidenzabdeckung, Betriebsstabilität).

Konkrete Muster aus realen Industrien

  • Bahn: Fleet Intelligence mit stufenweisem Eingriff

Entscheidung: Ereignisgetriebene Architektur, Audit‑Log als primäre Wahrheit; Modell‑Einsatz ausschließlich im Shadow‑Mode über 90 Tage, danach schrittweise Aktivierung nicht‑sicherheitskritischer Empfehlungen. Deployments nur im Depot, signierte Artefakte, Blue‑Green pro Fahrzeuggruppe. Trade‑off: Spätere direkte Kostenersparnis, dafür früher regulatorischer Frieden und keine Betriebsüberraschungen.

  • Produktion: Visuelle Fehlererkennung mit Safety‑Envelope

Entscheidung: KI klassifiziert, aber SPS‑Eingriffe nur über einen verifizierten Grenzwert‑Controller (Simplex). ODD: Nur Produktionslinien X/Y, nur optische Prüfstationen, menschliche Freigabe für Ausschuss bis Evidenzreife. Trade‑off: Weniger Automatisierungsgrad am Anfang, dafür schnell nutzbares Qualitätsfeedback ohne Zertifizierungsblocker.

  • Defence: Entscheidungsassistenz ohne Datenabfluss

Entscheidung: LLM‑Assistent on‑prem mit strikt begrenzten Retrieval‑Quellen, kein Internet‑Egress, vollständige Protokollierung. Kein Autonomiegrad, nur Vorschläge; Human‑on‑the‑loop als Policy. Trade‑off: Kein schicker SaaS‑Komfort, aber Daten‑ und Missions‑Souveränität.

Metriken, die zählen: Velocity ja – aber mit Evidenz