5) Change Envelope: Was darf sich ändern, ohne den Safety Case neu zu öffnen?

  • Vorab definierte, messbare Änderungsbereiche:

  • ML-Modelle: Gewichts-Updates innerhalb validerter Performance-Bänder auf einem referenzierbaren Gold-Dataset; jede Version mit Evaluationsbericht.

  • Regelwerke/Konfiguration: Änderungen in freigegebenen, versionierten Konfigs, die automatisch geprüft werden.

  • UI/Texte: Sicherheitlich unkritisch, solange Telemetrie/Bedienfluss unverändert sicher bleibt.

  • Gated Deployments: Jede Änderung innerhalb der Envelope durchläuft Tests, Canary/Shadow-Phasen und erfordert keinen vollständigen Safety-Review. Alles außerhalb triggert formalen Change Control mit Technical Owner und Sicherheitsingenieur.

6) Release-Trains, Baselines, on-prem Delivery-Pipeline

  • Takt: Feste Release-Züge (z. B. alle 6–8 Wochen), dazwischen Continuous Delivery in Integrations- und Shadow-Umgebungen.

  • Baselines: Jeder Release-Zug erzeugt eine eingefrorene Version inkl. Evidenzpaket. Spätere Patches sind differenziell nachvollziehbar.

  • Branching-Strategie: Trunk-based Development mit kurzlebigen Feature-Branches; Release-Branches nur für Stabilisierung/Hotfixes. Alles andere vergrößert die Divergenz.

  • Air-Gap-fähige Pipeline:

  • Build in kontrollierter Zone, Promotion in Betriebsnetz per signierten Bundles.

  • Interne Registries/Repos, keine externen Cloud-Abhängigkeiten.

  • Ephemere Runner, definierte Toolchain-Container, Policy-as-Code (Build darf nur, was erlaubt ist).

7) Technical Ownership: Rolle mit Mandat, nicht nur Titel

  • Aufgaben:

  • Eigentümerschaft für Systemqualitäten: Sicherheit, Performanz, Testbarkeit, Observability, Betriebsability.

  • Budgetierung von NFRs: z. B. maximale Latenz, Ressourcenverbrauch, Startzeit, Datenhaltung.

  • Change Control gemeinsam mit Safety: Go/No-Go für Änderungen außerhalb der Envelope.

  • Testarchitektur und Evidenzfluss: Welche Arten von Tests wo? Welche Artefakte in welcher Pipeline-Stufe?

  • Architekturentscheidungen dokumentieren (ADRs), lebende Systemdokumentation kuratieren.

  • Audit-Schnittstelle: Artefaktzugang, Nachweise, Demos der Toolchain.

  • Anti-Pattern: „Product Owner priorisiert nur Features“. Ohne Technical Owner degeneriert Agilität zu Feature-Bingo mit anschließender Dokumentationshölle.

MVP in sicherheitskritischen Systemen: Minimum Viable Safety Slice

Ein MVP ist kein hübscher Prototyp und auch kein Demo-Video. Ein MVP ist ein vertikaler End-to-End-Slice, der in einer repräsentativen Umgebung läuft und folgende Kriterien erfüllt:

  • Klare Risikogrenze: Der MVP operiert innerhalb einer definierten, freigegebenen Change Envelope und kann keine sicherheitskritische Aktion autonom auslösen.
  • Evidenz inkludiert: Der MVP produziert denselben Typ an Artefakten wie das Endprodukt – nur in kleinerem Umfang. Dazu gehören Anforderungen, Testprotokolle, Traceability, Betriebslogs, Modell-/Datenversionen.
  • Repräsentative Daten und Betriebsbedingungen: Keine synthetische Labor-Idylle. Wenn produktive Systeme nicht zugänglich sind, dann ein Schattenbetrieb auf realen Datenstreams mit striktem Read-Only.
  • Rückfall und Abschaltbarkeit: Technischer Kill-Switch, definierte Degradationsmodi, klare Übergabepunkte an den Menschen.

Ein erprobtes Stufenmodell:

  • Stufe 0 – Offline-Analyse: Daten aufnehmen, Golden Dataset definieren, Baseline-Metriken erstellen. Ergebnis: Datenkatalog, erste Modell/Algorithmus-Kandidaten, Evaluationsberichte.

  • Stufe 1 – Shadow Mode: System läuft nebenher, gibt Empfehlungen/Ergebnisse, die noch keine Aktion triggern. Ergebnis: Vergleich mit Mensch/Legacy, Fehlertypologie, Driftmonitoring.

  • Stufe 2 – Advisory Mode mit Human-in-the-Loop: Empfehlungen werden aktiv konsumiert, aber ein Mensch trifft die Entscheidung. Ergebnis: Protokollierte Entscheidungsqualität, Latenz, Belastung, Fehlalarme.

  • Stufe 3 – Gated Automation: Teilautomatisierung mit Interlocks, nachgewiesener Performance und klaren Ausstiegsbedingungen.

Beispiel, vereinfacht: Bahn-Fahrzeugflotte, Anomalieerkennung in Zustandsdaten.

  • Stufe 0: Segmentierung der Sensorkanäle, Feature-Engineering, Basisanomaliekriterien; Evaluation gegen historische Ausfälle.

  • Stufe 1: Shadow-Deployment im Depotnetz, keine Aktionen; Metriken: Precision/Recall pro Fehlerklasse, MTTA (Time to Alert), False-Positive-Rate.

  • Stufe 2: Dispatcher erhält Alarme mit Begründung (Top-K Beiträge); menschliche Bestätigung wird protokolliert und fließt in das Golden Dataset.

  • Stufe 3: Automatisierte Ticket-Erstellung mit definierter Priorität, aber keine Zugausfälle ohne menschliche Freigabe.

Wichtig: Jeder Stufe hat „Done++“-Kriterien inklusive Evidenz. So baut man den Safety Case inkrementell auf, statt ihn am Ende zu erfinden.

ML-spezifische Anforderungen sicherheitsverträglich gestalten

  • Daten- und Modellversionierung: Jede Trainings-/Inferenzversion mit eindeutiger ID, Hash, Datensatzreferenzen, Trainingsparametern, Validierungsbericht.

  • Evaluation-Harness als Code: Feste Testbatterie, die Kennzahlen pro Modellversion produziert. Keine Ad-hoc-Notebooks als Wahrheitsquelle.

  • Drift- und Bias-Monitoring: Definierte Schwellen, die zur Degradierung oder zum Rückrollen führen.

  • Fail-Safe Defaults: Bei Unsicherheit – konservatives Verhalten. Empfehlungen statt Aktionen, wenn Metriken schwächeln.

  • Offline-fähige Inferenz: Keine Laufzeitabhängigkeit von externen Clouds; deterministische Reproduzierbarkeit.

Zusammenarbeit mit Prüfern und Safety: früh, kontinuierlich, automatisiert

  • Prüfer sind Stakeholder: Sie brauchen nicht mehr Meetings, sondern besseren Zugang zu Artefakten. Ein Self-Service-Portal mit Versionen, Prüfreports, Build-Logs, Traceability und „How-to-Verify“-Anleitungen reduziert Reibung massiv.
  • Toolchain zeigen, nicht nur Ergebnisse: Wenn der Pipeline-Run nachvollziehbar Artefakte erzeugt, steigt Vertrauen. Trockene Audits („dry runs“) vor offiziellen Meilensteinen helfen.
  • Lebende Systemdokumentation: Architekturbilder, Schnittstellen, Datenflüsse – automatisch aus Code/Deployments generiert, nicht manuell gepflegt. Jede Version hat ihr eingefrorenes PDF, aber die Quelle bleibt Code.
  • Inkrementelle Reviews: Kleinere, häufigere Abnahmen schlagen das eine große Gate am Ende. Das ändert nicht die Formalität, aber die Fehler werden früher gefunden.

Metriken, die tatsächlich helfen

  • Evidence Lead Time: Zeit von Commit bis zu einem aktualisierten, konsistenten Evidenzpaket.

  • Traceability Coverage: Anteil der Anforderungen mit verknüpften Tests/Commits/Artefakten, gewichtet nach Kritikalität.

  • Change Failure Rate (kritische Pfade): Anteil der Änderungen an sicherheitskritischen Komponenten, die rollbacks/Hotfixes auslösen.

  • MTTR im Build: Zeit, um fehlschlagende Pipelines wieder grün zu bekommen – Indikator für technische Schulden.

  • Audit Readiness Index: Prozentsatz der Artefaktkategorien, die für die aktuelle Baseline vollständig und verlinkt sind.