Neben Durchsatz und Lead‑Time braucht es Metriken, die Assurance sichtbar machen:

  • Traceability‑Deckungsgrad: Anteil Anforderungen mit verknüpften Tests/Evidenzen.

  • Evidence‑Burn‑Down: Offene Nachweise pro Inkrement vs. Plan.

  • Änderungs‑Impact‑Zeit: Dauer von Change‑Antrag bis implementierter, nachgewiesener Änderung.

  • Fehlalarm/Fehlklassifikationsraten im Shadow‑Mode, kontextualisiert im ODD.

  • Betriebs‑Stabilitätsmetriken: Mean Time Between Incidents, Rollback‑Häufigkeit, Flotten‑Abdeckung.

  • Security‑Hygiene: Anteil signierter Artefakte, SBOM‑Vollständigkeit, Vulnerability‑Backlog‑Alter.

On‑Prem statt Cloud‑Abhängigkeit: Cloud‑native Muster lokal betreiben

Souveränität ist kein Nice‑to‑have. In Defence/Bahn/Teilen der Aviation ist sie Grundbedingung. Das heißt aber nicht, auf moderne Praktiken zu verzichten. Man repliziert sie lokal:

  • Infrastruktur: On‑Prem‑Kubernetes, isolierte Build‑Pipelines, Artefakt‑Signaturen, interne Paketmirror. IaC mit Terraform/Ansible für Reproduzierbarkeit.

  • Observability: Prometheus/Grafana/Tempo/Loki lokal, Langzeitarchiv nach Datenklassifizierung. Kein Outbound‑Push in externe SaaS.

  • Supply‑Chain‑Sicherheit: SBOMs, verifizierte Builds, Sigstore/Cosign‑Signaturen, Freigabe‑Gateways. Kein Pull aus dem Internet im Build, sondern kuratierte Mirrors.

  • Datenräume: Objekt‑Speicher im eigenen RZ, Zugriff per RBAC, Data‑Lineage als fester Teil der MLOps‑Pipelines.

Trade‑offs bewusst treffen:

  • Weniger „Managed Convenience“, dafür Audit‑ und Betriebs‑Kontrolle.

  • Höherer initialer Aufbauaufwand, dafür geringere Betriebsrisiken und Vendor‑Lock‑in‑Kosten.

Praktische Routinen, die die Lücke zwischen Agilität und Audit schließen

  • Architecture Decision Records (ADRs): Jede relevante Entscheidung mit Kontext, Optionen, Trade‑offs, Konsequenzen. Kurz, textbasiert, versioniert.
  • Change‑Windows by Design: Technische Maßnahmen, die sichere Deploy‑Zeitfenster erzwingen (Depot‑Bindung, Wartungsfenster).
  • Feature‑Gates mit Assurance‑Levels: Funktionen sind gebunden an gemessene Evidenzstufen; Release schaltet nur frei, wenn Level‑Kriterien erfüllt.
  • Risk‑Storming früh und wiederkehrend: Quer durch Rollen (Engineering, Betrieb, Safety, Security, Datenschutz).
  • „Test wie du fliegst“: Realitätsnahe Testumgebungen/digitale Zwillinge, reproduzierbar, mit echten Datenwegen – aber DSGVO‑ und Sicherheitskonform.
  • Dokumentation als Nebenprodukt: Templates, CI‑Generierung (z. B. Reports aus Pipelines), kein End-of‑Project‑Doku‑Marathon.

Fazit: Agilität mit Struktur ist ein Engineering‑Vorteil, kein Compliance‑Kompromiss

Wer in sicherheitskritischen Branchen schnell lernen will, braucht kein anderes Agil – er braucht ein belastbares Rahmenwerk für Evidenz, Architektur und Betrieb. Technical Ownership als klares Verantwortungsbild, ein Agile‑V‑Prozess mit Assurance‑Sprints, Architekturen wie Safety‑Envelope und Kontrakt‑Schnittstellen, und ein MVP‑Begriff, der auf Minimum Viable Proof zielt – das ist der Unterschied zwischen „wir basteln“ und „wir liefern“.

FAQ

1) „Unsere Auditoren mögen Agil nicht“ – was tun?
Auditoren mögen keine Unsicherheit und fehlende Nachweise. Zeigen Sie ihnen ein Evidence‑Backlog, eine saubere Traceability‑Kette, signierte Artefakte und regelmäßige Assurance‑Reviews. Agilität ist für Audits kein Problem, wenn jede Iteration nachvollziehbare Evidenz erzeugt. Laden Sie Auditoren früh ein – als Feedbackgeber, nicht als Endgegner.

2) Wie passt das zu Standards wie DO‑178C (Aviation) oder EN‑Normen in der Bahn?
Standards verlangen keine Wasserfall‑Abläufe, sondern Nachweise, Pläne und Disziplin. Inkrementelles Vorgehen funktioniert, wenn Sie:

  • Pläne (z. B. Software‑Aspekte, Qualitätssicherung) als lebende Artefakte führen,

  • Anforderungen und Tests bidirektional verknüpfen,

  • Änderungen streng verwalten und

  • Verifikation kontinuierlich betreiben.

Wichtig ist die frühzeitige Abstimmung mit Zulassungsstellen über den geplanten inkrementellen Nachweisweg.

3) Können wir Open‑Source‑Komponenten einsetzen?
Ja – mit Governance. Kritisieren Sie Black‑Box‑Abhängigkeiten. Führen Sie SBOMs, bewerten Sie Lizenzen, pinnen Sie Versionen, betreiben Sie interne Mirrors, patchen Sie proaktiv und dokumentieren Sie Sicherheitsbewertungen. In sicherheitskritischen Pfaden nutzen Sie konservative, gut auditierbare Bibliotheken und vermeiden unnötige Dynamik.

4) Wie bringe ich ML‑Modelle in die Flotte, ohne Risiken zu erhöhen?
Mit Shadow‑Mode, ODD‑Begrenzung, Safety‑Envelope und stufenweisem Rollout. Ein Modell beobachtet erst, liefert Erklärungen und Metriken, bevor es Empfehlungen freischaltet – Eingriffe gibt es erst nach Evidenzreife und mit klaren Fallbacks. Deployments sind signiert, nur im Wartungsfenster, mit Rollback‑Plan. Monitoring prüft Drift und Fehlalarme, ein Kill‑Switch ist Pflicht.

5) Sind LLM‑Assistenten in regulierten Umgebungen überhaupt vertretbar?
Ja, wenn sie als Operator‑Assistenz mit strenger Governance betrieben werden: On‑Prem‑Modelle, eingeschränkte Datenräume, vollständige Protokollierung, Guardrails, keine autonomen Aktionen, menschliche Freigabe. Ohne externe Cloud‑Abhängigkeiten und mit Audit‑Fähigkeit werden sie zu einem produktiven, kontrollierbaren Werkzeug – nicht zu einem Compliance‑Risiko.

Wer diese Prinzipien ernst nimmt, gewinnt Geschwindigkeit an der einzigen Stelle, an der sie in regulierten Branchen zählt: beim schnellen Lernen mit tragfähigen Nachweisen – souverän, auditierbar, und bereit für den echten Betrieb.