• Morgen: Review offener Changes – Fokus auf Auswirkungen auf Non-Functionals und Sicherheit; Freigaben stoppen, wenn Traceability oder Evidenzen fehlen.
  • Mittag: Architekturentscheid – Abwägung zwischen Latenzoptimierung und Diagnosefähigkeit; Entscheidung dokumentieren, Auswirkungen auf Teststrategie festlegen.
  • Nachmittag: Risk-Burndown-Check – neue Messwerte aus HIL-Läufen prüfen; ein PBI umpriorisieren, weil ein Degradationspfad noch nicht stabil ist.
  • Tagesende: Baseline-Abgleich – Releasekandidat erfüllt Evidenzkriterien; Backport sicherheitsrelevanter Fix in vorige Linie.

Warum On-Prem keine „Rückwärtsgewandtheit“ ist

Souveränität ist kein Selbstzweck. Es geht um Wiederholbarkeit, Auditfähigkeit und Kontrolle über Ausfallmodi. In sicherheitskritischen Bereichen sind:

  • Daten- und Modellflüsse nachvollziehbar nur unter eigener Kontrolle beherrschbar.

  • Rezneutralität und deterministische Ausführung auf definierter Hardware ein Risikokiller.

  • Lebenszykluslängen (10+ Jahre) nur mit Portierbarkeit und Lieferantenneutralität zu tragen.

On-Prem bedeutet nicht, auf moderne Praktiken zu verzichten. Im Gegenteil: Evidence-generating CI/CD, Artefakt-Graphen, reproduzierbare Container – all das lässt sich auf eigener Infrastruktur exzellent betreiben. Agilität entsteht aus der Gestaltung des Flows, nicht aus der Standortwahl der Server.

Fazit

Agilität in regulierten Branchen ist ein Handwerk. Wer sie als Haltung („schnell, flexibel“) verkauft, scheitert. Wer sie als strukturiertes Liefermodell versteht, liefert: Inkremente, die gleichzeitig Funktion, Sicherheit und Nachweise enthalten. Der Kern ist Technical Ownership – die disziplinierte Führung über Architektur, Non-Functionals, Risiken und Souveränität. Mit einem Steel-Thread-MVP und evidenzerzeugender Toolchain entstehen Produkte, die auditierbar sind, im Feld funktionieren und sich trotzdem im zweiwöchigen Takt verbessern.

FAQ

1) Wie viel „Agilität“ vertragen regulierte Projekte wirklich?
So viel, wie Sie die Nachweisführung in den Fluss integrieren. Wenn Evidenzen Sprint-Output sind, gibt es keine harte Grenze. Agilität scheitert nicht an der Regulierung, sondern an fehlender Disziplin in Traceability, Tests und Change-Management.

2) Ist ein MVP in sicherheitskritischen Umfeldern nicht per se riskant?
Ein funktionales, aber unsicheres MVP ist riskant. Ein Steel-Thread-MVP mit Sicherheitsrahmen, definierten Betriebsgrenzen, Degradationspfaden und aktiver Evidenzpipeline reduziert Risiken früh und macht sie sichtbar. Das ist der sicherere Weg.

3) Wie verhindere ich, dass Traceability zur Bürokratie wird?
Automatisieren und in den Entwicklerfluss ziehen: IDs in Code-Kommentaren/Annotations, PR-Checks, die Links erzwingen, Tests, die Evidenz als Artefakte publizieren. Manuelle Nachpflege ist das Problem, nicht die Traceability an sich.

4) Was gehört zwingend in die Definition of Done?

  • Aktualisierte Trace-Links

  • Grüne, evidenzerzeugende Tests (inkl. Nicht-Funktionales, wo relevant)

  • Aktualisiertes Risikoregister/Impact

  • SBOM/Build-Reproduktion

  • Aktualisierte Betriebs-/Diagnose-Hooks, falls betroffen

5) Wie gehe ich mit AI/ML-Komponenten in regulierten Systemen um?
Behandeln Sie Daten, Modelle und Inferenzpfade als Teil der kritischen Lieferkette: on-prem Versionierung, deterministische Pre-/Postprocessing-Pfade, dokumentierte Betriebsgrenzen, Observability für Drift/Fehlermodi und klare Richtliniendurchsetzung bei agentischen Komponenten. Ohne diese Governance sind AI-Komponenten audit- und betrieblich schwer beherrschbar.