Agil in regulierten Branchen: Geschwindigkeit ohne Kompromisse bei Sicherheit und Souveränität

Agilität in Defense, Luftfahrt, Bahn oder hochautomatisierter Fertigung scheitert selten an Scrum, sondern an zwei Illusionen. Erstens: „Regulatorik verhindert Veränderung“ – falsch. Regulatorik verhindert unbelegte Veränderung. Zweitens: „Agilität ersetzt Architektur und Nachweisführung“ – ebenfalls falsch. In sicherheitskritischen Umgebungen funktioniert Agilität nur, wenn sie die Nachweisziele und Randbedingungen der Domäne zuerst adressiert: Safety, Security, Determinismus, Reproduzierbarkeit, Daten- und Modellsouveränität. Aus der Praxis: Wer Nachweisführung als Beiprodukt behandelt, baut Schulden ins System, die spätestens beim Audit schlagend werden – und dann wird es wirklich langsam.

Dieser Beitrag skizziert, wie „Agil mit Struktur“ in regulierten Domänen funktioniert. Ohne Folklore, mit konkreten technischen Mustern: von Traceability über Simplex-Architekturen, Toolqualifikation und Evidence-as-Code bis hin zu MVP-Strategien für KI-Komponenten. Perspektive: Wir bauen seit Jahren Softwareprodukte in Defense, Railway, Aviation und Industrie. Wir sind keine Berater, die PowerPoints verkaufen, sondern übernehmen Requirements Engineering, Technical Ownership, Entwicklung, Qualitätssicherung und Betrieb – on-premise, DSGVO-konform, ohne US-Cloud-Abhängigkeit.

Problemstellung: Der eigentliche Engpass ist nicht der Sprint, sondern die Evidenzkette

Alle gängigen Normen fordern in Variationen dasselbe: nachvollziehbare Anforderungen, systematische Gefahrenanalyse, Architektur- und Designentscheidungen, verifizierbare Implementierung, qualifizierte Tools, wiederholbare Tests, Konfigurationsmanagement, kontrollierte Releases. Beispiele:

  • Luftfahrt: DO-178C/DO-254, ARP4754A/ARP4761

  • Bahn: EN 50128/EN 50657, EN 50126

  • Funktionale Sicherheit: IEC 61508, ISO 13849

  • Security: IEC 62443

  • Medizin (analog übertragbar): IEC 62304

  • Defense: MIL-STD-882E (System Safety), diverse STANAGs

Der Trugschluss: „Das klingt nach Wasserfall, also ist Agil hier ungeeignet.“ In Realität fordern diese Standards nicht Wasserfall, sondern Belege. Die Frage heißt deshalb: Wie erzeugen wir die Belege iterativ, ohne architekturelle und prozessuale Kurzschlüsse?

Konsequenzen für Architektur und Vorgehen:

  • Anforderungen sind Verträge. Sie brauchen stabile Schlüssel (Req-IDs), semantische Struktur (z. B. mithilfe von ReqIF) und eine Nachweiskette bis in Code und Tests.

  • Änderungen sind erlaubt – aber nur mit Impact-Analyse. Jede Anpassung muss bewerten, welche Sicherheitsziele, Komponenten und Nachweise betroffen sind.

  • Tooling ist nicht neutral. CI/CD, Generatoren, statische Analyse, Testwerkzeuge müssen je nach Normlage qualifiziert werden (z. B. DO-330 in der Luftfahrt, Toolklassen T2/T3 in EN 50128).

  • Evidenz ist ein Produktartefakt. Ohne automatisierte Erzeugung, Prüfung und Paketierung der Evidenz bricht Agilität beim ersten Audit zusammen.

Agil mit Struktur: Ein Arbeitsmodell, das Audits integriert statt sie zu fürchten

1) Compliance-Matrix am Anfang, nicht am Ende

  • Leiten Sie aus den relevanten Normen konkrete Objectives ab und mappen Sie diese auf Artefakte und Pipelines. Beispiel: „Anforderungstrace bis Unit-Test, Integrationstest mit Trace, strukturelle Abdeckung bis MC/DC für DAL A“.

  • Pflegen Sie diese Matrix als lebendes Objekt. Jede User Story verweist auf betroffene Objectives, jede Pipeline packt die passende Evidenz.

2) Architektur vor Sprint-Takt – hazard-driven, nicht feature-driven

  • Starten Sie mit Gefahren- und Risikoanalysen (z. B. FMEA, HAZOP, Fault Tree), leiten Sie Safety Goals und Sicherheitsanforderungen ab und allokieren Sie sie auf Architekturbausteine.

  • Verwenden Sie Muster, die komplexe Intelligenz kapseln und Sicherheit garantieren:

  • Simplex-Architektur: ein komplexer (lernender) Controller liefert Performance, ein mathematisch einfacher, verifizierter Sicherungsregler greift bei Abweichungen ein.

  • Safety Monitor/Runtime Assurance: unabhängiges Monitoring gegen formalisierte Safety Envelopes, mit Fail-Safe-Mechanismen.

  • Zeit-/Raumtrennung: partitionierte Systeme (z. B. nach ARINC 653-Prinzipien), deterministische Scheduling- und Speicherbudgets.

  • Safety Cage für KI: ML-Komponenten laufen in einer „Sicherheitsbox“ mit strikten I/O-Verträgen, plausibilisiert durch redundante Checks.

3) Evidence-as-Code in der CI/CD

  • Treat evidence like code: versioniert, reproduzierbar, unveränderbar signiert. Artefakte: Anforderungen, Architekturdokumente, Designentscheidungen (ADRs), Testpläne/-reports, Coverage, Static-Analysis-Reports, SBOMs, Compliance-Check-Logs.

  • Pipelines erzwingen Qualität:

  • Traceability-Check: Jede Codeänderung muss mindestens eine Anforderung referenzieren. Jede Anforderung muss auf Tests gemappt sein.

  • Coverage-Gates je nach Kritikalität (z. B. Statement/Branch; für sehr hohe Kritikalität auch MC/DC, wo anwendbar).

  • Security-Gates: SAST/DAST, Dependency-Scans, SBOM (SPDX/CycloneDX), Signierung (SLSA Level 2+ als Minimum).

  • Reproduzierbare Builds, deterministische Artefakterstellung.

  • Audit-Pakete automatisch erstellen: pro Release ein vollständig reproduzierbares Evidence-Bundle mit Inhaltsverzeichnis und Hash-Manifest.

4) Technical Ownership als Betriebssystem des Teams

  • Ein Technical Owner (nicht Product Owner) verantwortet Systemkohärenz: Schnittstellen, nichtfunktionale Anforderungen (Timing, Speicher, deterministische Latenzen), Safety/Security-Budgets, Toolkette, Change-Impact.

  • Entscheidungen werden hart dokumentiert (ADRs) und stehen prüfbar neben dem Code. Kein „Slack-Entscheid“ ohne Referenz in der Repo-Historie.

  • Der Owner besitzt Stop-the-line-Autorität: Wenn Evidenz bricht oder Safety-Ziele bedroht sind, stoppt er Releases – unabhängig vom Sprint-Plan.

5) MVPs für sicherheitskritische Systeme: Funktion ja, Exposure nein

  • Schlanke, risikominimierte Scheiben statt „Feature komplett“:

  • Advisory-Only: Das System gibt Empfehlungen, der Mensch entscheidet. Auswirkung: keine sicherheitskritische Wirkungskette, aber realer Dateninput.

  • Shadow Mode: Algorithmus läuft parallel, Entscheidungen werden geloggt, nicht wirksam. Vergleich gegen Golden Truth.

  • ODD-Begrenzung (Operational Design Domain): Betrieb nur in streng definierten, überwachten Kontexten.

  • Digital Twins, SIL/HIL: Iterationen finden zuerst im Labor statt, mit realistischen Stimuli und Fault-Injection.

  • Sicherheitsgehäuse und Interlocks: Neue Logik ist hinter harten Interlocks und Grenzwertplausis abgesichert.

  • Release-Reifestufen (Capability Release Levels):

  • CRL0: Labor, synthetische Daten

  • CRL1: Shadow Mode in Produktion

  • CRL2: Limitierter Einsatz unter Aufsicht

  • CRL3: Erweitere ODD, Nachweise gereift

  • CRL4: Voller Betrieb im zugelassenen Sicherheitsrahmen

  • Jeder Sprung zwischen Stufen ist ein Audit-Event: Evidenzpaket, Impact-Analyse, Risk Acceptance.

KI-spezifische Besonderheiten: Daten, Modelle, Governance