• Keine Änderung ohne Assurability: Jeder PR, der das Verhalten ändert, muss Metriken, Tests und ADRs anfassen. Sonst kein Merge.
  • Stabilität gewinnt: Bevor eine neue Funktion live geht, muss die Degradationsstrategie für diese Funktion getestet sein.
  • Monotone Verbesserung: Promotionskriterien sind monoton – ohne bessere Nachweise als die vorherige Version keine Beförderung.
  • Blackbox-Umgang: Externe Bibliothek? Erst in den Adapter, dann in den Kern. Nie umgekehrt.
  • Daten sind Produkt: Ohne Versionierung, Provenienz und rechtlich geklärten Nutzungspfad nicht antrainieren – und nicht deployen.
  • Kein „Hidden Cloud“-Pfad: Wenn ein Teil des Systems stillschweigend doch auf externe Dienste zugreift, ist das ein Architekturmangel, kein Feature.

Wie AlpiType das in Projekten umsetzt

Wir bauen industrielle KI-Systeme on-prem, DSGVO-konform und ohne US-Cloud-Abhängigkeiten. Unser Fokus liegt auf Requirements Engineering, Technical Ownership, Softwareentwicklung und Qualitätssicherung. Für LLM-basierte Komponenten setzen wir Alpi-M ein, um Agentenläufe auditierbar und steuerbar zu machen. Wichtiger als einzelne Tools ist jedoch das Technikgerüst: Sicherheitskern/Advisor-Architektur, Assurance-Pipeline, on-prem MLOps und ein klar benannter Technical Owner, der diese Leitplanken aktiv verteidigt.

Fazit

Agil in regulierten Branchen heißt nicht, schneller zu scheitern – sondern früher die richtigen Sicherheiten zu schaffen. Mit einer bewusst geteilten Architektur, einer Evidence-orientierten Pipeline und echter Technical Ownership lassen sich Iterationsgeschwindigkeit und Nachweisführung vereinbaren. Das Ergebnis ist nicht weniger Dokumentation, sondern bessere, automatisch mitwachsende Dokumentation – und Systeme, die man ruhigen Gewissens betreibt.

FAQ

1) Wie messe ich in diesem Setup Fortschritt, ohne mich auf Velocity zu verlassen?

  • Nutzen Sie Gate-Kriterien als harte Metriken: stabile Latenzbudgets, Override-Raten im Shadow Mode, Grenzfallabdeckung in Simulation/HIL, Rückgang kritischer Incidents, Vollständigkeit des Assurance-Knotens pro Feature. Diese Metriken korrelieren mit Betriebsreife, nicht mit Story Points.

2) Wie gehe ich mit Lieferanten-Blackboxes oder Closed-Source-Komponenten um?

  • Kapseln Sie jede Blackbox hinter einem Adapter mit strengem Vertrag, deterministischen Timeouts und Fallback. Fahren Sie eine eigene Akzeptanztest-Suite gegen den Adapter. Telemetrie am Adapter, nicht innerhalb der Blackbox. Kein direkter Zugriff des Kerns auf die Blackbox, nur über den Adapterkanal. Promotionsentscheidungen basieren auf beobachtbarem Verhalten, nicht auf Versprechen.

3) Wie integriere ich LLM/GenAI sicher in ein sicherheitskritisches System?

  • LLMs nur im Advisor-Bereich, „advisory-only“ bis ein sauberer Nutzen-/Risiko-Nachweis vorliegt. Werkzeuge des Agenten sind strikt whitelisted, Laufzeitbudgets begrenzt, jede Ausführung ist versioniert und auditierbar. Keine direkten Aktorzugriffe. Observability- und Governance-Schicht on-prem, inklusive Red-Teaming und Policy-Engine.

4) Welche Tools brauche ich für Evidence-as-Code?

  • Unerlässlich sind: Versionsverwaltung für Code und Evidenz, ein Artefakt-Registry mit Signaturen und SBOMs, eine CI/CD, die Contract-Tests, Evaluationsreports und Dokumentgenerierung als erste Bürger behandelt, sowie ein Observability-Stack, der Metriken/Logs/Traces on-prem speichert. Das konkrete Tool ist zweitrangig; entscheidend ist, dass Artefakte unveränderlich versioniert und Promotions an harte Kriterien gebunden sind.

5) Wie verhindere ich, dass Agilität zur Regulatorik-Erbsenzählerei verkommt?

  • Trennen Sie Produkt- und Assurance-Backlog, aber koppeln Sie sie über die Definition of Done++. Pflegen Sie ADRs als kurze, prägnante Entscheidungen statt seitenlanger Gutachten. Automatisieren Sie Nachweise, wo immer möglich (Metrikexports, Testprotokolle, SBOM). Messen Sie den Aufwand an tatsächlicher Risikoreduktion, nicht an Seitenzahl.

Wenn Sie Agilität so verstehen – als strukturiertes, evidenzgetriebenes Risikomanagement – dann sind schnelle Iterationen und harte regulatorische Anforderungen kein Widerspruch, sondern gegenseitige Verstärker.