In DACH/BENELUX/Nordics sehen wir zusätzlich den Souveränitätsanspruch: keine Abhängigkeit von US-Clouds für produktionsnahe Systeme, DSGVO-Konformität, Lieferkettenkontrolle. Das beeinflusst Architektur und Tooling:

  • Trainings- und Inferenzinfrastruktur on-prem oder in souveränen EU-Clouds.

  • LLM- und Agentensysteme nur mit lokaler Ausführung, vollständiger Observability und Richtlinienkontrolle (z. B. Rollenschutz, Prompt-Hardening, PI/PHI-Filter, Audit-Feeds).

  • Datenhaltung und -zugriffe nach Need-to-Know, Zero-Trust-Netzwerke, Härtung nach IEC 62443.

Wie sich das im Alltag anfühlt

Agile Rituale bleiben – aber sie sind angereichert:

  • Refinements starten mit Compliance-Impact: „Welche Objectives sind berührt? Welche Evidenz wird fällig?“

  • Sprint Goals enthalten mindestens ein Evidenz-Ziel („MC/DC für Komponente X auf 100 %“ oder „GSN-Safety-Case-Knoten Y mit Beleg Z schließen“).

  • Dailies adressieren Blocker in Tests, Monitore, Toolqualifikation – nicht nur Features.

  • Reviews zeigen nicht nur Funktion, sondern den Evidenzstatus (Ampel auf Trace, Coverage, Security, Drift).

Das Ergebnis ist messbar: Weniger Überraschungen vor Audits, bessere Vorhersehbarkeit von Release-Terminen, kontrollierte Risiken, und trotzdem schnelle Lernzyklen – weil jeder Zyklus reale Belege erzeugt.

FAQ

Frage: Passt Agilität überhaupt zum V‑Modell, das viele Normen implizit voraussetzen?
Antwort: Ja. Viele Standards verlangen keine sequentielle Entwicklung, sondern konsistente Nachweise. Man kann architektur- und hazardgetrieben iterieren und jede Iteration „V‑förmig“ abschließen: Anforderungen und Architektur verfeinern, implementieren, verifizieren, Evidenz paketieren. Damit bleiben Sie agil in der Taktung, aber diszipliniert in der Nachweisführung.

Frage: Wie bringt man DO‑178C‑Anforderungen (z. B. hohe Coverage) mit kurzen Sprints zusammen?
Antwort: Indem Coverage und Traceability Gates in der Pipeline sind und Stories so geschnitten werden, dass testbare, abgeschlossene Verticals entstehen. Für hohe DALs benötigen Sie zusätzliche Maßnahmen (z. B. MC/DC, strikte Coding-Standards, Reviews). Diese Aktivitäten sind keine „harten Meilensteine“, sondern laufende Sprint-Arbeit. Wichtig: Testumgebungen und -daten sind First-Class-Citizens.

Frage: Wie sieht ein „MVP“ für ein sicherheitskritisches System aus, ohne die Zulassung zu gefährden?
Antwort: MVP heißt hier: echter Lerneffekt ohne sicherheitskritische Wirkung. Typisch: Shadow Mode, Advisory-Only, enge ODD, Safety Cage mit Interlocks. Jedes MVP-Inkrement erzeugt evidenzfähige Artefakte (Performance, Fehlerklassen, Drift-Profile, Monitor-Wirksamkeit) und speist den späteren Safety Case.

Frage: Müssen Entwicklungs- und Testtools formell qualifiziert werden?
Antwort: Kommt auf Norm und Kritikalität an. Grundsatz: Wenn ein Tool Fehler erzeugen kann, die nachgelagerte Prüfungen nicht entdecken, ist Qualifikation fällig (z. B. DO‑330, Tool-Klassen in EN 50128). Pragmatik: Reduzieren Sie Tool-Vertrauen, indem Sie Cross-Checks und unabhängige Verifikationen einbauen. Dokumentieren Sie Bewertung und getroffene Maßnahmen.

Frage: Wie setzen wir LLMs im regulierten Umfeld ein, ohne Compliance- und IP-Risiko?
Antwort: On‑prem oder in souveräner EU‑Cloud, mit strikter Observability und Governance: keine Produktionsdaten in offene APIs, Richtlinien für erlaubte Inhalte, Rollen- und Freigabekonzepte, Audit-Logs, Content-Filter. Für produktive Agenten zusätzlich Safety Envelopes und Fallbacks. Unsere Plattform Alpi-M adressiert genau diese Anforderungen und integriert sich in Evidence‑Pipelines.

Schlussgedanke

Agil in regulierten Branchen ist kein Widerspruch, sondern ein Qualitätshebel – wenn Sie Evidenz als Produkt begreifen, Architektur aus Gefahren ableiten, Technical Ownership ernst nehmen und Souveränität technisch verankern. Dann entstehen Systeme, die auditierbar, sicher und lernfähig sind. Genau dort gehört KI hin: hinter Safety Cages, mit Messpunkten, in einer Infrastruktur, die Ihrer Organisation gehört.