Charakteristika eines echten MVPs:

  • End-to-End-Trace: Vom (abgespeckten) System-Requirement mit Safety‑Attribut über Architektur-Skizze und Implementierung bis hin zum Test-Ergebnis und Evidence-Snippet im Safety Case.

  • Minimale Sicherheitsfunktionalität: Nur der kleinste sinnvolle Teil des Sicherheitskerns, vollständig verifiziert mit den vorgesehenen Methoden (z. B. statische Analyse, Ziel-Coverage, Boundary-Tests).

  • Betrieb in sicherer Umgebung: Erst in SIL‑/DAL‑konformen Simulationen, HIL‑Rigs oder als Shadow Deployment ohne aktiven Eingriff. Keine Lebensgefahr für Nutzer, kein Risiko für Assets.

  • Instrumentierung und Observability: Vollständige Telemetrie, reproducible builds, sigierte Artefakte. Wenn KI/LLM/Agenten beteiligt sind: strenge Policy‑Durchsetzung, Protokollierung jeder Entscheidung, Replay‑Fähigkeit.

Was nicht dazugehört: Das “MVP” eines Bremssystem-Controllers im Feldtest ohne Safety-Case-Rahmen. In sicherheitskritischen Domänen ist „Probe-and-learn am echten System“ kein MVP, sondern ein Verstoß gegen grundlegende Engineering-Prinzipien.

Data- und Deployment-Souveränität als Voraussetzung

Souveränität ermöglicht Intelligenz – dieser Satz ist in regulierten Branchen wörtlich zu nehmen. Ohne Daten- und Deploymentsouveränität bleiben viele moderne Ansätze (ML, LLM‑Agenten, Telemetrie-getriebene Optimierung) regulatorisch blockiert.

Praktische Leitplanken:

  • On-Premise-first: Quellcode-Management, CI/CD, Artefakt-Repository, Model Registry, Feature Store, Observability – selbst gehostet oder in souveränen Infrastrukturen. DSGVO-konform, ohne Abhängigkeit von außereuropäischen Cloud‑Rechtsräumen.

  • Air‑gapped MLOps: Datenversionierung (z. B. DVC/LakeFS), reproduzierbare Trainingsumgebungen (Infrastructure as Code), deterministische Seeds, signierte Model‑Artefakte. Kein Datenaustausch mit Drittdiensten.

  • Supply-Chain-Sicherheit: SBOM, verifizierbare Provenance (z. B. SLSA‑Prinzipien), reproduzierbare Builds, Schlüsselverwaltung on‑prem. Ohne das sind Nachweise lückenhaft.

  • Observability & Governance: Ereignisprotokolle als manipulationssichere, append‑only Streams; Richtliniendurchsetzung zur Laufzeit (z. B. für Agenten: begrenzter Aktionsraum, Quoten, Freigabe-Workflows), Audit-Exports auf Knopfdruck.

Diese Infrastruktur ist nicht „Overhead“, sondern macht Agilität überhaupt erst revisionssicher. Sie senkt den Preis pro Änderung, weil Nachweise entstehen, während Sie entwickeln – nicht Jahre später.

Konkrete Entwicklungs- und Testmuster

Damit die obigen Prinzipien im Alltag tragen, brauchen Teams greifbare Muster:

  • Test-Pyramide mit Assurance-Fokus:

  • Unit- und Property-based Tests für Kernlogik

  • Integrations- und Schnittstellentests mit deterministischen Stubs

  • Systemtests auf HIL/SIL‑Plattformen mit definierten Betriebsprofilen

  • Negative Tests und Fuzzing für Protokolleingänge

  • Coverage-Metriken, die zu den Assurance-Zielen passen (und nicht blind maximiert werden)

  • Statik vor Dynamik: Statische Analyse, Regeln (z. B. MISRA/CERT‑ähnlich) und Architektur-Linting laufen in jedem Merge. Findings sind sprintrelevant, nicht „machen wir später“.

  • Change-Impact-Analyse als Graph: Anforderungen, Design, Code und Tests sind in einer Trace-Graph-Datenbank verbunden. Ein Änderungsantrag markiert betroffene Knoten; CI löst automatisch die relevanten Tests aus und fordert gezielte Reviews an.

  • Qualitätsgates in der Pipeline: Kein Merge ohne

  • grüne Tests

  • aktualisierte Trace

  • signierte Artefakte

  • aktualisierte ADRs

  • genehmigte Reviewer-Checkliste

  • Feature Toggles mit Safety-Gating: Neue Funktionen laufen zunächst im Shadow Mode. Aktivierung erfordert erfüllte Evidenzkriterien (z. B. Nachweis stabiler Performance in N definierten Szenarien, keine Verstöße gegen Safety‑Constraints im Log).

Ein Beispielpfad aus der Praxis: Bei einer Flotten‑Diagnoseplattform im Bahnkontext trennt die Architektur die sicherheitsrelevanten Leittechnik‑Signale strikt von der ML‑basierten Zustandsanalyse. Neue Modelle werden on‑prem trainiert, versioniert und nur im Shadow Mode an Echtflotten gespiegelt. Ein Guardian bewertet jede Modellentscheidung gegen konservative Grenzwerte. Erst nach dokumentierter Evidenz über definierte Betriebsprofile und einer formalen Freigabe wechselt die Funktion in den aktiven Modus – mit weiterhin aktiver Überwachung und Rückfallebene.

Organisation und Rhythmus: Wie Teams wirklich arbeiten

Nicht die Nomenklatur entscheidet (Scrum, Kanban, SAFe), sondern die Kopplung von Arbeit und Nachweisen:

  • Sprintlänge: 2–3 Wochen sind oft praktikabel, sofern die Definition of Done die oben genannten Artefakte enthält. Längere Zyklen verstecken technische Schulden, kürzere zerstückeln Nachweise.

  • Systemintegrationstakt: Neben Team‑Sprints braucht es einen getakteten Systemintegrationslauf (z. B. alle 2 Sprints) auf repräsentativer Hardware/SIL/HIL.

  • Querschnittsrollen: Safety Engineer, Security Engineer, QA und Technical Owner arbeiten eingebettet in die Teams, nicht als nachgelagerte Prüfinstanz. Reviews sind gemeinschaftlich.

  • Decision Logs statt „Meeting-Gedächtnis“: Jede relevante Richtungsentscheidung wird als ADR erfasst, versioniert, querverlinkt. Audits werden zu Export-Jobs, nicht zu Archäologieprojekten.

Harte Trade-offs ehrlich managen

Regulierte Systeme sind voller echter Zielkonflikte:

  • Geschwindigkeit vs. Rigorosität: Nicht jede Geschichte braucht formale Verifikation – aber die im Sicherheitskern schon. Der Technical Owner priorisiert den Einsatz teurer Methoden dort, wo sie Risiko wirklich senken.

  • Wiederverwendung vs. Tool-Qualifikation: Ein tolles Open‑Source‑Tool spart Zeit, kann aber Qualifikationsaufwand erzeugen. Manchmal ist ein schlichteres, gut zu qualifizierendes Tool günstiger im Gesamtkostenbild.

  • Performance vs. Nachvollziehbarkeit in ML: Black‑box Modelle liefern top Kennzahlen, aber schwache Erklärbarkeit. Für sicherheitsnahe Funktionen zieht man bewusst Grenzen: interpretable Modelle, Post‑hoc Erklärungen, Konfidenzschranken plus Guardian.

Ein praktikabler Startfahrplan

Wenn Sie heute ein agiles Vorhaben in einer regulierten Domäne starten, setzen Sie in den ersten 6–8 Wochen auf:

  • Traceability-Backbone aufbauen: Git, Issue‑Tracker, CI/CD, Test-Runner, Requirements-Dokumente als Code, automatisierte Trace-Generierung.

  • Definition of Done neu schneiden: Evidenzpflichten je Artefaktklassen festlegen; Checklisten in PR‑Vorlagen integrieren.

  • Safety Case Skelett aufsetzen: Struktur, Claims, geplante Evidenzartefakte, initiale Hazard‑Liste. Von Anfang an versioniert.

  • Architekturgrenzen definieren: Safety-Kern vs. Evolutionsschicht, Schnittstellen und Ressourcengrenzen.

  • Technical Ownership verankern: Verantwortliche Person mit Mandat, Engineering‑Risk‑Backlog anlegen, erste ADRs schreiben.

  • On‑prem Infrastruktur klären: Repos, Artefakt-Registry, Model‑Registry, Observability, Signierung, SBOM. Datenabflüsse aus regulatorischer Sicht schließen.