Agil mit Struktur: Produktentwicklung in regulierten Branchen ohne Sicherheitskompromisse

Agilität ist kein Synonym für Planlosigkeit. In sicherheitskritischen Umgebungen bedeutet Agilität, Risiken kontrolliert zu verkleinern, statt sie bis zum „Big Bang“ der Abnahme aufzuschieben. Die meisten Teams kennen die Zwangslage: Feature-Druck und Innovationsdruck auf der einen Seite, Nachweisführung, Auditierbarkeit und Betriebsreife auf der anderen. Klassische Wasserfallpläne brechen unter Ungewissheit zusammen, klassisches „Agile“ ohne harte Leitplanken scheitert am Zertifizierungsschock kurz vor Go-Live.

Unser Standpunkt aus Defense, Luftfahrt und Bahn: Agilität funktioniert in regulierten Branchen genau dann, wenn sie technisch verankert ist – in der Architektur, in der Delivery-Pipeline und in der Verantwortungsstruktur. Drei Bausteine sind dafür entscheidend:

  • Architekturtrennung zwischen deterministischem Sicherheitskern und adaptiven Komponenten (z. B. ML/LLM).

  • Evidence-driven Development: Jede Änderung erzeugt verifizierbare Nachweise und schließt an den Assurance Case an.

  • Technical Ownership: Eine klare technische Instanz, die End-to-End-Verantwortung für Architektur, Risiken, Betrieb und Compliance trägt.

Dieser Artikel beschreibt konkrete Muster und Entscheidungen, die in der Praxis funktionieren – ohne Scrum-Evangelisierung, mit Fokus auf technische Trade-offs.

Warum „Standard-Agile“ in regulierten Umgebungen scheitert

Vier typische Bruchstellen:
1) Fehlende Traceability: User Story fertig, aber keine eindeutige Kette von Anforderung → Architekturbeschluss → Implementierung → Verifikation → Betriebsmetriken → Nachweis. Bei Audits fehlen damit Belege, und jede Regressionsanalyse wird zur Detektivarbeit.
2) NFRs als Nachgedanke: Latenz, deterministisches Verhalten, Failsafe-Mechanismen, Testbarkeit und Auditierbarkeit landen im „später“. Später ist immer zu teuer.
3) Pipeline ohne Assurance: CI/CD prüft Stil und Tests, aber nicht Evidenz. Zertifizierungsrelevante Artefakte werden separat „dokumentiert“, statt automatisch mitzuwachsen.
4) Betriebsferner MVP: Prototypen laufen im Labor, lassen sich aber nicht sicher in die reale Umgebung bringen (kein Air-Gap-fähiger Updatefluss, keine Rollback-Strategie, keine Sicherheitsgrenzen für Fehlverhalten).

Agil heißt hier: Wir liefern nicht nur Features inkrementell, sondern auch Sicherheit, Nachvollziehbarkeit und Betriebsreife – inkrementell, messbar, auditierbar.

Architekturprinzipien: Sicherheitskern + Adaptive Intelligenz

Das zentrale Muster ist die harte Trennung zwischen einem deterministischen Sicherheitskern (Safety Kernel) und einem adaptiven „Advisor“ (z. B. ML-Modell, LLM-Agent). Diese Trennung reduziert Zertifizierungsrisiko, beschleunigt Iterationen und erhöht die Testbarkeit.

Kernelemente:

  • Safety Kernel: Minimaler, deterministischer Funktionsumfang mit klaren Zeit- und Ressourcenbudgets, implementiert in einer strikt kontrollierten Technologie (z. B. native, ressourcenkontrollierte Umgebungen). Er definiert das „sichere Verhalten“ und besitzt die letzte Autorität für Aktorentscheidungen. Watchdogs, Heartbeats und definierte Safe-States sind Teil seines Verantwortungsbereichs.

  • Adaptive Advisor: KI-Komponenten liefern Empfehlungen, Klassifikationen oder Priorisierungen. Diese laufen isoliert (Prozess/Container), kommunizieren über stabile, versionierte Schnittstellen und liefern Konfidenzmetriken sowie Telemetrie für Audits. Entscheidend: Der Advisor darf nicht autonom die Systemgrenzen überschreiten; der Safety Kernel gate-keeped Entscheidungen.

  • Vertrag statt Bauchgefühl: Schnittstellen sind Verträge (Schemas, Units, Grenzwerte, Timing). Contract-Tests sichern vor jedem Merge, dass neue Modell- oder Agent-Versionen das Protokoll einhalten und Degenerationsfälle sauber signalisieren.

  • Fail-safe Defaults: Fallbacks, Degradation-Strategien und „Open Loop Safe State“ sind vorgedacht. Wenn der Advisor schweigt, spinnt oder zu unsicher ist, definiert der Kernel ein sicheres Verhalten.

  • Ressourcen- und Fault-Isolation: Prozess- und Ressourcengrenzen (z. B. cgroups, Prioritäten), Timeouts, Budget Enforcement, Circuit Breaker gegen Hänger und Degenerationslawinen.

  • Observability-by-Design: Telemetrie ist Bestandteil der Schnittstelle: Inputhashes, Modellversion, Datenversion, Konfidenz, Latenzen, Kernelentscheidungsweg, Overrides. Ohne diese Signale gibt es kein grünes Licht für Produktion.

Trade-offs:

  • Ein modularer Monolith mit klaren Domänengrenzen schlägt oft einen Zoo an Microservices. Weniger Betriebsvariablen, einfachere Nachweisführung.

  • Dynamische Sprachen und JIT sind im Feld problematisch. Training und Auswertung im Labor, aber Produktion mit deterministischer, statisch gebundener Komponente.

  • Feature-Flexibilität wird gebündelt in den Advisor, Stabilität im Kernel. Das beschleunigt die Innovation, ohne Zertifizierungsflächen unnötig zu vergrößern.

Assurance-Pipeline statt „nur CI/CD“

Inkrementelle Sicherheit braucht eine Pipeline, die Evidence produziert und verwaltet. Jedes Merge erzeugt einen nachvollziehbaren, reproduzierbaren Fußabdruck im Assurance Case.

Bausteine:

  • Evidence-as-Code: Nachweise sind Artefakte mit Version, Hash und Herkunft: Architekturentscheidungen (ADRs), Verifikationsberichte, Datensatz-Snapshots, Auswertungsmetriken, Lastprofile, Trace-Mapping von Anforderungen zu Tests. Diese Artefakte leben im Repo, nicht in Sharepoint.

  • Two-Track-Backlog: Ein Produkt-Backlog (Funktionalität) und ein Assurance-Backlog (Nachweisführung, Prüfmittel, Beobachtbarkeit, Failsafes). Beide werden priorisiert. Kein Feature ohne Assurance-Schnitt.

  • Definition of Done++: Ein Item ist erst done, wenn a) Implementierung, b) Tests inkl. Worst-Case-Szenarien, c) Observability-Hooks, d) aktualisierte ADRs und e) aktualisierte Assurance-Knoten geliefert sind.

  • Promotions mit Gates: Artefakte wandern von Dev → Simulation → Labor-Hardware → Shadow Mode im Feld → begrenzte Live-Freigabe. Jedes Gate hat objektive Kriterien (Metrikschwellen, Abdeckungsgrade, Latenzbudgets, Override-Rate, Fehlklassifikationsprofil).

  • Teststrategie: Schichtweise Absicherung

  • Unit- und Contract-Tests für Schnittstellen.

  • Szenario- und Property-Based-Tests mit generierten Störungen, Timingvariationen und Datenfehlern.

  • SIL/HIL-Setups mit deterministischen Seeds und verifizierter Reproduzierbarkeit.

  • Golden-Datasets und Regression auf Metrikebene (nicht nur Accuracy, sondern Kosten von Fehlklassifikationen, z. B. Fn vs. Fp asymmetrisch gewichtet).

  • Daten- und Modell-Governance: Jede Modellauswertung bindet an ein datentragendes Artefakt (Dataset-Manifest mit Hashes), eine Trainingskonfiguration, einen Evaluationsreport und einen Modellsteckbrief (Einsatzbereich, Ausschlusskriterien, bekannte Schwächen). Drift-Detektion und Re-Evaluation laufen on-prem – Daten verlassen die Umgebung nicht.

LLM-/Agent-Governance