• Minimum Viable Safety Case (MVSC): Der kleinste Teil des Systems, der einen in sich geschlossenen Sicherheitsargument-Abschnitt liefert. Beispiel Bahn-Flottenintelligenz: Start mit „advisory-only“-Anomalieerkennung, read-only Datenpfad, strikte Trennung vom aktiven Leitsystem, mit prüfbaren Falsch-Positiv-/Falsch-Negativ-Metriken und klaren Escalation-Policies.
  • Minimum Viable Certification Candidate (MVCC): Der kleinste Release-Kandidat mit vollständiger Nachweisführung für eine klar eingegrenzte Funktion, inklusive deterministischer Build-/Test-Umgebung, dokumentierter Toolchain und SBOM. Wichtig: Auch wenn die Funktion noch „nur Empfehlung“ ist, ist der Weg zum Nachweis schon produktionsreif.

Warum so? Weil in regulierten Umgebungen frühe Feldexposition ohne Sicherheitsfall nur Scheinschnelligkeit ist. Geschwindigkeit entsteht, wenn wir von Tag 1 Nachweise mitschleifen – automatisiert.

Technische Muster, die in der Praxis tragen

1) Shadow-Mode und Advisory-Only für ML/AI

  • Shadow-Mode: Das ML-Modul läuft parallel zum produktiven Pfad, erzeugt Handlungsempfehlungen, aber keine Aktorenansteuerung. Wir sammeln Evidenz über Stabilität, Drift und Edge Cases.

  • Advisory-Only: Empfehlungen werden über definierte Mensch-in-der-Schleife-Workflows eingebunden. Metriken und Feedback fließen zurück in das Trainings-/Evaluationssetup.

  • Safety-by-Design: Selbst wenn spätere Automatisierung geplant ist, wird der Kontrollfluss so entworfen, dass ein „Kill Switch“ und sichere Degradationsmodi existieren.

2) Daten- und Modell-Governance on-prem

  • Dataset-Versionierung mit lineage: Jeder Trainings-/Eval-Lauf referenziert exakt definierte Datasets, Seeds, Feature-Engineering-Pipelines und Umgebungen.

  • Offline-Evaluationsharness: reproduzierbare SIL-Szenarien, deterministische Seeds, Metrikverträge (z. B. maximale zulässige Rate an false alarms pro Betriebsstunde).

  • On-Prem-Inferenz: Wenn Souveränität gefordert ist, laufen Modelle und ggf. LLMs vollständig on-prem, ohne US-Cloud-Abhängigkeit. Tool-Aufrufe von Agenten sind strikt erlaubnisbasiert, auditiert und isoliert.

3) Traceability-as-Code

  • Anforderungen in strukturiertem Format (z. B. YAML/ReqIF) im Repo, mit IDs, Attributen (Safety-Klasse, Gültigkeit, Quelle) und Links auf Design-/Test-/Evidence-Artefakte.

  • Generierter Traceability-Graph pro Commit. Build bricht, wenn Lücken entstehen (z. B. Anforderung ohne Test, Test ohne zugeordnete Anforderung).

  • Reports für Audits aus der Pipeline, nicht manuell in DTPs gepflegt.

4) Vertragsgetriebene Schnittstellen

  • ICDs als versionierte Artefakte, kompatibilitätsbewertet (SemVer-Regelwerk mit Safety-Erweiterungen: breaking change ≠ nur API, sondern auch Verhaltenskontrakt).

  • Contract-Tests, die beide Enden der Schnittstelle in CI validieren. Abnahme von Zulieferkomponenten erfolgt über Contract-Test-Suiten, nicht PDF-Reviews.

5) Deterministische Builds und Promotions

  • Hermetische Builds: gepinnte Toolchains, Reproducible-Builds where possible, Inhalte gehasht und signiert.

  • Promotionsstufen: dev → integ → vorabnahme → release, mit identischen Bits, auditierbaren Signaturen und Umgebungsfixpunkten (z. B. Kernel-Versionen).

  • SBOM-Erzeugung und Drift-Detection in jeder Stufe. Kein „Works on my cluster“.

6) On-Prem CI/CD in Air-Gap-Szenarien

  • Spiegel-Registry und Repo-Proxys mit genehmigten Upstream-Snapshots.

  • Outbound-Freeze für releasekritische Stufen, Ingress nur über geprüfte Paketquellen.

  • Evidence-Store als WORM-Speicherklasse, durchgängig referenziert im Safety Case.

7) Change-Impact-Analyse als Standard

  • Jeder Change trägt Impact-Tags (Schnittstellen, Safety-Klassen, Performance-Constraints).

  • Ein Impact-Graph steuert, welche Testpakete und welche Evidenzen erneuert werden müssen. Ziel: Minuten für Analyse, Stunden für Verifikation, Tage für Audit – nicht umgekehrt.

8) Documentation-as-Code statt PDFs

  • ADRs, ICDs, Safety Case, Hazard-Logs als versionierte Dateien mit Review-Workflows.

  • Ausleitung in menschenlesbare Reports bei Bedarf; Single Source of Truth bleibt im Repo.

Organisationsmuster: Wer trägt was?

  • Technical Owner: Verantwortet Architektur, Safety Case-Kohärenz, Traceability-Integrität, Build-Governance. Hält die „rote Linie“: keine Features ohne Nachweisstrategie.
  • Produktmanagement/Domäne: Formuliert Capabilities, priorisiert Nutzen – innerhalb der technischen Leitplanken.
  • System Engineering/Safety: Erarbeitet Gefährdungsanalysen, Sicherheitsanforderungen und -argumente, validiert die Safety-Claims.
  • Test/QA: Definiert Metrikverträge, betreibt SIL/HIL, wartet den Evidenzspeicher, automatisiert Reports.
  • Dev-Teams: Implementieren, pflegen Contract-Tests, erweitern Traceability-Links, liefern exekutierbare Evidenzen.
  • Zulieferer: Liefern Artefakte in standardisierten Paketen (ICDs, Contract-Tests, SBOMs), keine Black Boxes ohne Prüfanker.

Trade-offs, offen benannt

  • Geschwindigkeit vs. Nachweis: Ohne Automatisierung gewinnt Nachweis. Mit Traceability-as-Code, generierten Reports und deterministischen Pipelines wird beides möglich. Aber: initiale Investition ist Pflicht.
  • Cloud-Komfort vs. Souveränität: In Defense/Bahn/Luftfahrt überwiegt Souveränität. On-Prem-Infrastruktur ist kein Feind schneller Entwicklung, wenn sie als Produkt gedacht wird (Observability, Kapazitätsplanung, GPU-Scheduling, Reproduzierbarkeit).
  • Featurebreite vs. Inkrementalität im Safety Case: Besser eine vertikale Scheibe mit geschlossener Argumentation als fünf halbe Features ohne durchgängige Evidenz.
  • „Flexibler Scope“ vs. Schnittstellenstabilität: ICD-Disziplin ist kein Bürokratie-Fetisch; sie spart Zeit. Konsequent: Feature-Flags und Forward/Backward-Kompatibilität statt API-Breaks im Takt der Sprints.

Ein Sprint, der zählt: Wie sieht das konkret aus?

  • Sprint-Planning:
  • Stories nur „ready“ mit Safety-Tags und Impact-Klassifikation.
  • ADR-Placeholder benannt, wenn Architekturänderungen anstehen.
  • Contract-Tests geplant für jede berührte Schnittstelle.
  • Umsetzung:
  • Code, Contract-Tests, Anforderungs-YAML mitgeführt. PR bricht, wenn Traceability-Lücken entstehen.
  • SIL-Tests laufen lokal deterministisch (fixierte Seeds, fixe Artefakte).
  • Evidence-Artefakte (Reports, Logs) werden bei Erfolg automatisch in den Evidence-Store geschrieben und im Safety Case verlinkt.
  • Review:
  • Nicht nur Code-Review: ADR-Review, Traceability-Diff (was ist neu/veraltet), Safety Case-Diff.
  • Demo zeigt nicht nur UI/Output, sondern das grüne Ende-zu-Ende der Nachweise.
  • Abschluss:
  • Promotionskandidat wird signiert und durch Stufen gehoben.
  • Audit-Report wird generiert; offene Lücken sind bewusst dokumentiert mit Risikobewertung.

Metriken, die wirklich etwas aussagen