• Woche 1–2: Inventur
  • Anforderungen, Hazards, Schnittstellen: sammeln, normalisieren, versionieren.
  • Toolchain‑Check: VCS, CI/CD, Registry, Artefakt‑Store, Observability – alles on‑prem?
  • Rollen klären: Wer ist Technical Owner pro Capability?
  • Woche 3–4: Strukturelle Fundamente
  • Definition of Ready/Done mit Evidenz aufnehmen.
  • Traceability‑Schema festlegen (IDs, JSON/YAML‑Links), Skripte in CI integrieren.
  • Safety/Compliance Case als Code initialisieren (Skeleton, GSN‑Top‑Claims).
  • GitOps‑Pfad einrichten; Signaturen/Policies aktivieren.
  • Woche 5–8: Erstes Inkrement (MVP + MVPS)
  • Einen Capability‑Slice auswählen (am besten nicht sicherheitskritisch in Aktorik).
  • Shadow‑Mode betreiben; Metriken erfassen; Gates definieren.
  • Monitors/Interlocks entwickeln; Worst‑Case‑Timing/Robustheit testen.
  • Review mit Stakeholdern/Auditoren: Artefakte gemeinsam sichten; Lücken priorisieren.
  • Ab Woche 9: Iterativ härten
  • Feature‑Flags an Safety‑Gates hängen; Advisory‑Mode aktivieren, wenn Gates grün.
  • Evidenzlücken abbauen; Toolqualifikationen dokumentieren.
  • Betriebsprozesse etablieren: Change‑Control, Incident‑Response, Patch‑Fenster.

Warum dieser Ansatz in der Praxis trägt

  • Er ist „audit‑friendly by construction“: Es gibt keine spätere Aufholjagd, die Evidenz entsteht mit dem Code.
  • Er verbessert Teamfokus: Technical Ownership bündelt Verantwortung und beschleunigt Entscheidungen.
  • Er reduziert Betriebsrisiken: On‑prem GitOps mit signierten Artefakten und reproduzierbaren Builds verhindert „Works on my cloud“.
  • Er ermöglicht echte Agilität: Iteration findet innerhalb klarer Sicherheits- und Schnittstelleninvarianten statt – so schnell wie verantwortbar.

FAQ

Frage: Wie überzeuge ich ein skeptisches Management, dass der zusätzliche Assurance‑Aufwand sich lohnt?
Antwort: Zeigen Sie die Kosten der Alternative: ungeplante Zertifizierungs‑Nacharbeiten, verschobene Inbetriebnahmen, Sicherheitsvorfälle. Planbarer, inkrementeller Assurance‑Aufwand ist günstiger als spätes „Big Bang“-Hardening. Außerdem macht er Risiken sichtbar – früh genug, um Optionen zu haben.

Frage: Wir setzen bereits Scrum ein. Muss ich die Methode wechseln?
Antwort: Nein. Ergänzen Sie Scrum um drei Dinge: einen Assurance‑Backlog, DoR/DoD mit Evidenz, und Traceability‑Automatisierung in der CI. Kombinieren Sie das mit einem frühen Architektur‑/Schnittstellen‑Freeze (Hybrid‑V). Das ist methodenneutral und funktioniert auch mit Kanban.

Frage: Wie viel Automatisierung ist realistisch in einer regulierten Umgebung?
Antwort: Sehr viel – solange Transparenz und Kontrolle gewahrt bleiben. Build‑Reproduzierbarkeit, signierte Artefakte, automatisierte Trace‑Reports, Test‑ und Timing‑Pipelines, GitOps‑Deployments: alles on‑prem möglich. Kritisch ist, dass jede Automatisierung nachvollziehbar, versioniert und durch Policies abgesichert ist.

Frage: Wie gehe ich mit häufigen Datenänderungen bei ML‑Systemen um?
Antwort: Behandeln Sie Daten wie Code: versionieren, reviewen, testen. Fixieren Sie Trainings- und Validierungssets pro Release, dokumentieren Sie Label‑Qualität, messen Sie Drift im Betrieb. Modell‑Updates laufen durch denselben Change‑Control‑Prozess wie Code – mit eigenen Gates (z. B. robustere Performance in kritischen Szenarien).

Frage: Kommen wir ohne US‑Cloud aus, ohne die Entwicklungsgeschwindigkeit zu verlieren?
Antwort: Ja. Mit einer sauberen on‑prem Toolchain (Git, CI/CD, Registry, Artefakt‑Store, Observability) und GitOps erreichen Sie kurze Lead‑Times und hohe Reproduzierbarkeit – ohne Daten- und Lieferkettenrisiken. Der anfängliche Setup‑Aufwand amortisiert sich, sobald das erste Release ohne Compliance‑Feuerwehr live geht.

Fazit

Agil in regulierten Branchen ist kein Widerspruch, wenn Sie Agilität als disziplinierte, evidenzgetriebene Iteration verstehen. Frieren Sie die Ränder ein, iterieren Sie im Inneren. Liefern Sie Features und Nachweise in einem Takt. Verankern Sie Technical Ownership. Bauen Sie eine souveräne, on‑prem Lieferkette. Und denken Sie das MVP immer als Doppel: Produktwert plus Minimum Viable Proof‑of‑Safety. So entstehen Systeme, die nicht nur clever sind – sondern verantwortbar, auditierbar und nachhaltig betreibbar. Genau darum geht es.