• Safety-/Compliance-Envelope
  • Vor dem MVP wird festgelegt, was das System niemals darf (unverhandelbare Grenzen) und was es nur mit Freigabe darf.
  • Beispiele für Envelope-Regeln: Keine Schreibzugriffe auf Steuergeräte; keine externen Netzwerkverbindungen außer zu Whitelist-Endpunkten; maximaler Ressourcenverbrauch; Not-Aus-Pfade.
  • Technische Konsequenz: Policy-Enforcement auf Host- und Applikationsebene, strikt gekapselte Toolzugriffe, „Safe Defaults“.
  • Assurance-MVP
  • Der MVP liefert Artefakte, die zeigen, dass die Kette Anforderung → Design → Implementierung → Test → Betrieb konsistent ist – wenn auch minimal.
  • Minimal-Set an Artefakten: Systemkontextdiagramm, 3–5 ADRs zu Kernentscheidungen, Risiko-/Bedrohungsnotizen zu Top-5-Gefährdungen mit implementierten Controls, automatisierte Tests mit reproduzierbaren Ergebnissen, Betriebs-Runbook (erste Version), Evidenz-Index mit Querverweisen.

Dieser Zuschnitt vermeidet die Falle, technische Schulden in Audit-Schulden zu verwandeln.

5. Architektur- und Deploymentmuster für ML/LLM unter Souveränitätsvorgaben

Souveränität ermöglicht Intelligenz – nicht umgekehrt. Der Betrieb entscheidet, was baubar ist. Daraus folgen konkrete Muster:

  • Daten- und Modell-Souveränität
  • On-prem Storage für Rohdaten, Feature-Stores und Modelle; keine Abhängigkeit von Public-Cloud-Diensten für Training/Inferenz, sofern Datenklassifikation/Vertragslage das nahelegt.
  • Dataset- und Modellversionierung als erste Bürger: D, F, M werden wie Code behandelt (Branches, Tags, Reviews).
  • Modell-Registry mit Promotion-Stufen (Dev → Shadow → Restricted → General) und dokumentierten Annahmen/Limitierungen.
  • Reproduzierbare Umgebungen
  • Containerisierte Trainings- und Build-Pipelines mit pinbaren Abhängigkeiten; deterministische Seeds; Hardwareprofile versioniert.
  • Signierte Artefakte, Build-Provenance, unveränderliche Artefakt-Repositories im Zielnetz.
  • Observability und Governance by Design
  • Telemetrie auf vier Ebenen: Infrastruktur (CPU/GPU/Netz), Dienst (Latenzen, Fehler), Funktion (Domänenmetriken), ML/LLM (Daten-/Feature-/Drift-Metriken, Prompt-/Tool-Nutzung).
  • Policy- und Audit-Layer: Wer darf welches Modell wohin deployen? Welche Datenquellen sind zulässig? Welche Tools dürfen LLM-Agenten aufrufen?
  • Für LLM-Agenten: White-Listing von Tools, deterministische Prompt-Templates, Retrieval nur gegen freigegebene, versionierte Wissensbasen, Ausführungs-Sandboxing, Human-in-the-Loop für kritische Aktionen.
  • Netzwerk- und Deploy-Topologien
  • Air-gapped oder semi-gapped: Artefaktexport aus Buildnetz via geprüftem Transfer; Import in Betriebsnetz mit Inhaltsprüfung.
  • Edge-Deployments für geringe Latenz; Zentrale für Training/Auswertung; Asynchrone Synchronisation mit Signaturen.
  • Test- und Evaluationsstrategie
  • Golden Datasets und Szenarien; Metrikschwellen als Vertragsbestandteil vor Deploy; Wirkbetrieb erst nach Shadow-Erfolg.
  • Drift- und Regredienstests automatisieren; jede Promotion-Stufe hat definierte zusätzliche Anforderungen.

Diese Prinzipien sind technologieagnostisch; sie rahmen die konkrete Umsetzung mit Python/C++/K8s/… so, dass Auditierbarkeit und Betriebssicherheit nicht Opfer kurzfristiger Effizienz werden.

6. Teammechanik: Wie sieht das im Sprint aus?

Ein funktionierendes Sprint- oder Kanban-Setup unterscheidet nicht nur „Dev“ und „Test“, sondern mappt Arbeit auf Wert- und Evidenzflüsse:

  • Zwei Backlogs, eine Wahrheit
  • Product Backlog führt die Wert-Hypothesen.
  • Assurance Backlog führt die dazugehörigen Evidenzaufgaben. Beide werden zusammen geplant; ein Item ist nur dann fertig, wenn beide Aspekte nach DoD+ erfüllt sind.
  • Engineering Kanban mit WIP-Limits
  • WIP-Limits halten das System stabil. Besonders kritisch: Integrations- und Testspalten nicht überladen.
  • Eine eigene „Integration/Shadow“-Spalte verhindert, dass halbgare Inkremente sich nach „Done“ ausgeben.
  • Rollen und Verantwortlichkeiten
  • Technical Owner kuratiert Guardrails, ADRs, Schnittstellenverträge, Observability-Standards; entscheidet bei Zielkonflikten.
  • QA/Assurance mit klarer Eigentümerschaft für Evidenzkonsistenz; nicht Gatekeeper erst am Ende, sondern Coach und Reviewer im Fluss.
  • Product arbeitet mit Engineering Hypothesen und Messkriterien aus, nicht Featurelisten.
  • Reviews, die Substanz haben
  • Sprint Review hat zwei gleichwertige Teile: „User Value Review“ und „Assurance Review“. Im zweiten Teil wird gezeigt, wie Nachweise entstanden sind, welche Metriken gemessen wurden, wo noch Lücken sind.
  • Retrospektiven adressieren technische Schulden und Evidenzschulden explizit.
  • Artefakt-Checklisten pro Inkrement
  • ADR aktualisiert? Trace Links gesetzt? Logs/Metriken im Monitoring sichtbar? Sicherheits-/Safety-Kontrollen verifiziert? Deploy-Rollbacks getestet? Daten-/Modellartefakte versioniert und signiert?

Diese Praxis ist am Anfang gewöhnungsbedürftig, verhindert aber die teuren Kurven vor Gate 3.

7. Trade-offs offen benennen

Agile Produktentwicklung in regulierten Umfeldern bedeutet bewusste Kompromisse:

  • Cloud-Komfort vs. Souveränität: Public-Cloud-Dienste beschleunigen – solange Datenlage und Abhängigkeiten vertretbar sind. On-prem bedeutet mehr Eigenverantwortung für Betrieb, aber Kontrolle und Auditierbarkeit. Für viele Industrien ist letzteres nicht verhandelbar.

  • Performance vs. Determinismus: Höchste Performance verlangt aggressive Optimierung; Auditierbarkeit verlangt Reproduzierbarkeit. Wir setzen früh deterministische Pipelines auf und akzeptieren initiale Performanceverluste – optimieren dann gezielt unter Kontrolle.

  • Feature-Fülle vs. Betriebsstabilität: Weniger Features, dafür robuste Deploy-/Rollback-Mechanik, saubere Logs, stabile Schnittstellen – das gewinnt auf Dauer.

  • Modellgüte vs. Testbarkeit: „Schnell höherer Score“ gegen „Beobachtbarkeit, Fairness, Robustheit, OOD-Verhalten“. In sicherheitskritischen Kontexten ist erklärbare Robustheit wichtiger als ein paar Prozentpunkte an Metrikgewinn ohne Begründbarkeit.

  • Lieferantenabhängigkeit vs. Time-to-Market: Proprietäre SDKs beschleunigen; Abhängigkeiten verteuern spätere Zertifizierungen und Langzeitbetrieb. Wir wählen bewusst Schnittstellen und Komponenten, die eingefroren und langfristig gepflegt werden können.

8. Beispielhafter Inkrement-Schnitt: Zustandsüberwachung einer Flotte