• User Stories ohne Systemanforderungen: Feingranulare Stories verdrängen Systemarchitektur. Gegenmaßnahme: Systemanforderungen und -schnitte explizit im Backlog halten; Architektur- und Qualitäts-Tasks timeboxen und sichtbar machen.
  • Definition of Done ohne Evidenz: “Tests grün” reicht nicht. Gegenmaßnahme: DoD++ mit Traceability, Risikoupdate, SBOM, Security-Scan, Artefaktarchivierung – als Pipeline-Gates erzwingen.
  • MLOps entkoppelt von DevOps: Modelle werden “nebenher” betrieben. Gegenmaßnahme: Einheitliche CI/CD inklusive Daten- und Modellartefakten, versionierte Datenpipelines, gemeinsame Observability.
  • Cloud-Abhängigkeiten in souveränen Umgebungen: Schneller PoC, später Sackgasse. Gegenmaßnahme: Früh On-Prem-Optionen evaluieren, Architektur so schneiden, dass Cloudersatz möglich ist; Toolauswahl unter Souveränitätskriterien treffen.
  • Compliance als Endaktivität: Gegenmaßnahme: Assurance-Backlog etablieren, monatliche Baselines, Delta-Analysen je Change, Auditoren früh einbinden.

LLM- und Agenten-Systeme in regulierten Umgebungen

Sprachmodelle und Agenten sind kein “einfacher” Use Case. Wer sie in regulierten Umfeldern einsetzt, braucht Governance und Observability als Produktanforderung:

  • Daten- und Zugriffshoheit: Self-Hosted Embeddings, Vektorspeicher und Indizierung; Zugriff über ABAC; Dokumente vor Indizierung auf PII/IP prüfen; RAG-Korpora versionieren.

  • Prompt- und Tool-Governance: Prompt-Templates unter Versionskontrolle; Tool-Aufrufe nur über geprüfte Adapter mit klaren Verträgen (Input/Output-Schemas, Timeout, Idempotenz). Keine “freien” Shell-/Netzwerkzugriffe.

  • Evaluations- und Red-Team-Suites: Offline-Testsets für Kernaufgaben; adversarial Tests (Prompt-Injection, Jailbreaks, Data Leakage); deterministische Decoding-Parameter auf kritischen Pfaden.

  • Observability: Vollständige Protokollierung von Interaktionen, Tool-Calls, Entscheidungspfaden und Policies, inklusive Governance-Metadaten (wer hat was freigegeben?); Audit-sichere Speicher auf On-Prem-Infrastruktur.

  • Freigabeflüsse: Änderungen an Modellen, Prompts, Tools laufen durch denselben Baseline-/Change-Prozess wie Code.

Als Hersteller bauen wir solche Systeme on-prem mit klaren Governance-Schichten. Das Prinzip bleibt: Agil entwickeln, aber jede Änderung ist auch eine Governance-Änderung – mit Nachweis.

Pragmatische Checkliste für den Start

  • Benennen Sie eine Technical Ownership mit Entscheidungskompetenz für Architektur, Qualität, Toolchain und Assurance.
  • Ergänzen Sie Ihr Backlog um einen Assurance-Track mit eigener Kapazität und Definition of Done++.
  • Heben Sie CI/CD auf On-Prem-Niveau mit reproduzierbaren, signierten Builds und Artefaktarchiven.
  • Definieren Sie MVP als Minimum Valuable & Provable mit ODD, Shadow-Phase und Safe-State.
  • Verankern Sie Datenhoheit: Kein kritischer Pfad darf von externer Cloud abhängen; planen Sie Air-Gap-Betrieb.
  • Bauen Sie eine Evidence Map und einen lebenden Assurance Case; etablieren Sie monatliche Baselines.
  • Integrieren Sie MLOps/LLM-Governance in denselben Prozess, statt sie als Sonderwege zu führen.

Fazit

Agilität mit Struktur ist kein Widerspruch, sondern der einzige Weg, in regulierten Branchen schnell und sicher zu liefern. Das Rezept ist weder ein neues Framework noch mehr Meetings. Es ist die konsequente technische Ownership, die Assurance-Arbeit als Erstbürger im Entwicklungsfluss verankert, eine souveräne Architektur ohne Black-Box-Abhängigkeiten, und ein MVP-Verständnis, das Wert und Nachweis zusammen denkt. So entstehen Produkte, die nicht nur funktionieren, sondern deren Funktionsfähigkeit man auch belegen kann – heute und in zehn Jahren.

FAQ

Wie vereinbaren wir Sprints mit Stage-Gates oder formalen Reviews?

  • Planen Sie monatliche (oder quartalsweise) Compliance-Baselines, in die 2–3 Sprints einzahlen. Die Stage-Gates bewerten nicht nur Features, sondern die Vollständigkeit der Evidenzpakete. So bleibt die Taktung im Team kurz, ohne Gate-Reife zu opfern.

Wie viel Dokumentation ist genug?

  • So viel, wie nötig ist, um Claims nachvollziehbar zu belegen und Änderungen delta-basiert zu verstehen. Ersetzen Sie Freitext, wo möglich, durch generierte Evidenzen aus Pipelines (Testreports, SBOMs, Signaturen) und pflegen Sie einen strukturierten Assurance Case statt monolithischer PDFs.

Wie gehen wir mit Daten um, die das Werk nicht verlassen dürfen?

  • Bauen Sie Ihre komplette Daten- und ML-Toolchain on-prem auf: Versionierung von Daten und Modellen, lokale Artefakt- und Registry-Server, kontrollierte Spiegelung externer Abhängigkeiten. Etablieren Sie ABAC, Pseudonymisierung und Audit-Trails; Air-Gap-Betrieb muss eine Option sein, nicht der Ausnahmefall.

Wie testen wir ML- und LLM-Komponenten in sicherheitskritischen Kontexten?

  • Trennen Sie strikt zwischen Shadow- und Active-Betrieb, definieren Sie ODDs, setzen Sie auf reproduzierbare Trainings- und Auswertungspipelines, messen Sie Verteilungen statt nur Mittelwerte und implementieren Sie Drift-Überwachung. Für LLMs sind Tool-Governance, deterministische Settings auf kritischen Pfaden und adversariale Tests Pflicht.

Unser Auditor “mag kein Scrum”. Was tun?

  • Übersetzen Sie Agil in Assurance-Sprache: Zeigen Sie Traceability, reproduzierbare Builds, Evidenzmaps und Baselines. Erklären Sie, dass Sprints die Taktung der Arbeit sind, nicht der Freigaben. Binden Sie Auditoren früh ein und führen Sie durch den lebenden Assurance Case – Technik überzeugt hier mehr als Framework-Namen.