Bahn: Flottenintelligenz für Zustandsüberwachung

  • Forderung: Verfügbarkeit auch bei Netzausfall, Datenschutz, nachvollziehbare ML-Entscheidungen.

  • Vorgehen: On-Prem Data Lake mit versionierten Datasets, ML Eval Harness, Drift-Alarmierung; Failover-Strategien und Offline-Puffer.

  • Ergebnis: MVP im Shadow Mode auf ausgewählten Zügen, harte Go/No-Go-Kriterien, abgestufter Rollout.

Kulturelle Hebel: Rituale mit Biss

  • Definition of Done enthält explizit Evidenz-Artefakte. “Feature fertig” ohne Trace/Tests ist “nicht fertig”.
  • “No PR without Trace”: Jeder Merge verlangt verknüpfte Anforderung und Testplan.
  • “Red Teams” für kritische Reviews: Nicht das Feature-Team prüft seine Safety-Entscheidungen.
  • Dokumentation als Code: Anforderungen, Architektur, Hazard Logs in Git, versioniert, prüfbar.

Start-Checkliste für die ersten 6 Wochen

Vor Sprint 1:

  • Regulatorische Landkarte erstellen: Welche Normen, welche Zulassungswege, welche Artefakte?

  • Safety/Security/Privacy-Grundkonzepte definieren: ODD, Bedrohungsmodell, Datenschutz-Flüsse.

  • Toolchain einfrieren: Compiler, Linter, Testframeworks, Build-Orchestrierung; Container publizieren.

  • Traceability-Format und IDs festlegen; Minimal-Set an Templates (ADR, ICD, Testplan, Hazard Log).

  • CI-Basis aufsetzen: Build, Unit-Tests, Statische Analyse, SBOM-Generierung, Artefaktsignatur.

Sprints 1-3:

  • Architekturschnitt setzen und als ADR fixieren.

  • Erstes Ende-zu-Ende-Inkrement mit Shadow Mode-Fähigkeit.

  • Evaluation Harness für ML (falls relevant) mit fixierten Datasets.

  • Observability on-prem: Metrik- und Log-Pipeline, Audit-Logging.

  • Regelmäßige Evidence-Drops; Review mit Stakeholdern inkl. Prüfinstanz-Vertretung.

Ab Sprint 4:

  • Safety Cage aktivieren; begrenzte Automatisierung mit Fail-Safe.

  • Canary Rollout; Metriken in Go/No-Go-Kriterien umsetzen.

  • Prozesshygiene prüfen: Reproduzierbarkeit, Trace-Lücken, Review-Qualität.

Meinungsstarkes Fazit

Agilität in regulierten Branchen ist möglich – wenn Sie die Nachweisführung nicht als lästige Doku am Ende, sondern als integralen Bestandteil jedes Inkrements behandeln. Technical Ownership ist der Katalysator: klare Architektur, harte Tradeoffs, reproduzierbare Toolchains, kompromisslose Traceability. On-Prem ist nicht Nostalgie, sondern Voraussetzung für Souveränität, Verfügbarkeit und Datenschutz. Ein MVP ist nicht die schnellste Demo, sondern die kleinste zulassungsfähige Scheibe mit Safety Cage und klaren Grenzen.

Wer so arbeitet, liefert schneller echte, auditierbare Wertschöpfung – und spart sich die teuren Überraschungen im Zertifizierungsendspurt.

FAQ

Frage: Wie passt Scrum mit Audits zusammen?
Antwort: Indem Sie die Artefakte auditierbar machen. Planen Sie pro Story die Evidenz mit ein: Trace-Links, Testprotokolle, Coverage, SBOM, ADR-Updates. Ihre CI/CD-Pipeline produziert pro Inkrement ein “Audit-Paket”. Ergänzen Sie Sprint-Reviews um Evidence-Reviews und halten Sie stabile Baselines mit signierten, reproduzierbaren Builds.

Frage: Was ist der minimale Umfang eines MVP in sicherheitskritischen Systemen?
Antwort: Ein MVP braucht einen Safety Cage, einen klar abgegrenzten Betriebsrahmen (ODD), einen Shadow Mode vor produktiver Wirkung, definierte Fallbacks und evidenzierte Performance-Grenzen. Dazu gehören deterministische Builds, versionierte Anforderungen, Tests und Daten-/Modell-Governance. Keine Abkürzung führt an diesen Minimalbausteinen vorbei.

Frage: Wie gehen wir mit LLM/GenAI in einer regulierten Umgebung um?
Antwort: On-Prem betreiben, RAG-Quellen kuratieren und versionieren, Prompt- und Output-Logging aktivieren, Policy-Checks vorschalten, Rechte eng schneiden. Agenten erhalten Guardrails und dürfen keine sicherheitskritischen Aktionen ohne deterministische Kontrollen auslösen. Observability und Governance sind Pflicht – inklusive Auditierbarkeit und Reproduzierbarkeit.

Frage: Wie überzeugen wir die Prüfinstanz frühzeitig?
Antwort: Laden Sie sie in die Evidence-Drops ein. Zeigen Sie pro Sprint nicht nur Features, sondern Traceability, Tests, Hazard-Log-Updates und Build-Nachweise. Vereinbaren Sie vorab Formate (z. B. Trace-Matrix, Testberichte) und liefern Sie diese kontinuierlich. Transparenz reduziert Reibung und Nachforderungen.

Frage: Cloud oder On-Prem?
Antwort: Für regulierte, sicherheits- und missionskritische Anwendungen: On-Prem by default. Gründe: Datenhoheit, Verfügbarkeit unter Krisenbedingungen, Nachvollziehbarkeit der Lieferkette, DSGVO-Konformität, Air-Gap-Fähigkeit. Wenn Cloud, dann nur dort, wo keine Safety- oder Datenschutzrisiken entstehen und mit klaren Exit-Strategien.

Hinweis zur Quellenlage

Dieser Beitrag spiegelt praxisnahe Vorgehensweisen aus Projekten in Defense, Fertigung, Bahn und Luftfahrt wider. Er vermeidet spekulative Behauptungen und fokussiert auf erprobte Muster, Artefakte und Architekturen. Wenn Sie spezifische Normen und Kapitelverweise benötigen, definieren wir gern gemeinsam die anwendbaren Regelwerke und übersetzen sie in einen projektkonkreten Evidence-Plan.