Designprinzipien für MVPs in regulierten Umgebungen:

  • Nicht-interferierende Integration: Start im Shadow Mode. Das MVP liest Daten, trifft Entscheidungen, aber greift nicht in Wirkpfade ein. Ergebnisse werden geloggt und mit Ground Truth verglichen.
  • Fail-Closed-Architektur: Jeglicher Ausfall im MVP-Pfad führt automatisch auf den etablierten sicheren Pfad zurück. Kein Single Point of Failure im Neuzugang.
  • Read-Only bis zur Freigabe: Schreibende Zugriffe in operative Systeme sind solange gesperrt, bis Nachweise (Accuracy, Latenz, Robustheit) und Freigaben da sind.
  • Safety Case Inkremente: S0 = Sandbox/Shadow, S1 = Operator Advisory (ohne Automatik), S2 = begrenzte Automatisierung unter Supervisor, S3 = produktiv mit Redundanz. Jedes S-Level hat definierte Evidenzpakete.
  • Datenhoheit als harte Grenze: Kein Transfer sensibler Daten in US-Clouds, keine Abhängigkeit von externen Gateways. Modelltraining/Serving On-Prem oder in souveräner Cloud. Datenverträge: Was rausgeht, ist kryptografisch belegt oder geht nicht.

Konkrete Muster aus der Praxis:

  • Railway Fleet Intelligence: Anomalieerkennung läuft zunächst als Shadow-Prozess an der Telematik, korreliert nur, schreibt nichts zurück. Qualitätsmetriken (Precision/Recall) werden gegen gelabelte Störfälle gerechnet. Erst nach Stabilität über Zeit folgt die Advisory-Stufe in der Leitstelle.
  • Defense Wissenssysteme: LLM-basierte Dokumentenabfragen laufen in einer streng isolierten Umgebung, ohne Internet, mit Retrieval aus kuratierten, klassifizierten Korpora. Responses sind deterministisch (Temperature 0), geloggt, mit Policy-Enforcement und Kill-Switch. Keine US-Cloud, keine Telemetrie nach außen.
  • Manufacturing Visual Inspection: CV-Modelle werden offline mit golden datasets validiert, inferieren dann inline. Bei Unsicherheit geht das System in „Request human“ statt „auto reject“. Thresholds sind konfigurierbar, Änderungen traceable und signed.

5) Architekturen für agile, regulierte KI-Systeme

Wer KI in regulierte Umgebungen bringt, braucht Architekturen, die velocity erlauben und Assurance erzwingen.

  • Drei-Kanal-Assurance-Architektur:
  • Safety-Kanal: Deterministische, formell oder streng getestete Logik (PLC, Safety-Controller, zertifizierbare SW). Darf immer handeln.
  • Advisory-ML-Kanal: ML/LLM führt Analyse durch, schlägt Aktionen vor, beeinflusst den Safety-Kanal nur über klar definierte, geprüfte Schnittstellen und anfangs read-only.
  • Governance/Orchestrierung: Policies, Observability, Audit-Logs, Notfallabschaltung. Hier liegt die „Intelligenz-Umzäunung“.
  • Datenpfad mit Souveränität:
  • Ingestion on-prem, PII/ITAR/klassifizierte Filter früh im Pfad.
  • Data Lake nur innerhalb der kontrollierten Umgebung; Replikation über signierte, genehmigte Kanäle.
  • Trainingspipeline offline/air-gapped möglich; Modell-Artefakte sind signiert, versioniert, mit Herkunftsnachweisen (Datasheets for Datasets/Models).
  • LLM-/ML-Serving unter Aufsicht:
  • Retrieval-Augmented Generation mit kuratierten Indizes. Keine offenen Webzugriffe.
  • Deterministische Modi (Temperature 0), Antwortschemas (JSON-Schema), Whitelisting von Funktionen (Tool Use).
  • Policy-Engine: Was darf das Modell wann? Regeln sind versioniert, getestet, auditierbar.
  • Evaluationsharness: Golden Questions, factual consistency, toxicity/off-policy Checks – alles offline, regelmäßig, mit Drift-Monitoring.
  • Testpyramide erweitert:
  • Unit/Property-based Tests für Kernlogik.
  • Contract-Tests für Schnittstellen.
  • Golden-Master-Tests für ML-Inferenzpfade (Repro über deterministische Seeds/Quantisierungsprofile).
  • Systemtests in simulierten Umgebungen mit echten Datenströmen.
  • Supply-Chain-Sicherheit als Grundarchitektur:
  • Signierte Commits, Repro-Builds, SBOM, Policy für Third-Party-Libs, Isolierung von Runtime-Umgebungen.
  • GitOps für Infrastruktur, deklarative Deployments, Rollback-fähig.
  • Observability als Compliance-Werkzeug:
  • Vollständige Telemetrie zu Inputs/Outputs, Latenzen, Confidence, Policy-Hits, Operator-Overrides.
  • Audit-Trails manipulationssicher (Write-Once oder append-only), korreliert mit Software-Versionen und Model-Hashes.

Ein Wort zu Agenten: LLM-Agenten sind in regulierten Umgebungen nur in eng ummauerten Gärten sinnvoll. Observability- und Governance-Layer (z. B. agentenspezifische Protokolle, Circuit-Breaker, Tool-Whitelists, Prompt-/Response-Logging, Replay) sind keine Kür, sondern Zulassungsvoraussetzung – unabhängig vom genutzten Modell.

6) Liefermechanik: Iteration und Nachweis zusammen denken

  • Kadenz-Dualität:
  • 2-Wochen-Entwicklungsiterationen mit klaren Deliverables (inkl. Evidenz).
  • 6- bis 8-Wochen-Compliance-Inkremente, in denen Artefakt-Freeze, End-to-End-Nachweis und formale Reviews stattfinden.
  • Artefakt-Freeze vor Gateways: Feature-Entwicklung pausiert kurz vor Audits/Meilensteinen. Fokus auf Stabilisierung, Nachweise, Build-of-Record. Danach Branch-Cut.
  • Kontinuierliche Zertifizierungs-Evidenz:
  • Pipelines generieren Standards-Artefakte automatisch: Traceability-Matrizen, Testreports, Coverage, SBOM, Signaturen, Review-Logs.
  • Kein „Doku-Sprint“, sondern „Doku per Build“.
  • Change Control integriert:
  • Jede Änderung referenziert Hazard/Anforderung/ADR.
  • Impact-Analyse ist ein Pull-Request-Check, ergänzt durch unabhängige Prüfer für sicherheitsrelevante Änderungen.
  • Toolchain On-Prem, auditierbar:
  • Quellcode, Artefakte, Runner, Artefakt-Registry, Model-Registry – alles innerhalb der Souveränitätsgrenzen.
  • Kein verstecktes Telemetrie-Abfließen in fremde Clouds.

7) Was wir konkret tun, wenn wir ein reguliertes KI-Produkt starten

Die ersten 90 Tage sind entscheidend. Ein pragmatischer Ablauf, der sich bewährt:

  • Tag 0–10: Scope klären, Hazard-Landkarte erstellen, Sicherheits-/Souveränitätsziele festlegen. Compliance-Matrix aufsetzen (welche Normen, welche Artefakte, welche Gremien).
  • Tag 10–20: Technical Ownership mandatieren. NFR-Budgets definieren (Latenz, Speicher, Verfügbarkeit, Datenflussgrenzen). ICDs für die ersten Integrationspunkte entwerfen.
  • Tag 20–30: Evidence-Tooling minimal lauffähig: Git, CI/CD on-prem, Artefakt-Store, Test-Runner, SBOM-Generator, Signierung, einfache Traceability (z. B. Anforderungen in Git, Verlinkung in PR-Templates).
  • Tag 30–45: MVP-S0 planen: Shadow-Integration, Fail-Closed, read-only. Evaluationsharness definieren (Metriken, Golden Sets, Drift-Checks). Datenverträge festziehen.
  • Tag 45–60: First Increment bauen, ICD/Contract-Tests stabilisieren, Observability anschließen. ADRs zu den kritischen Architekturentscheidungen finalisieren.
  • Tag 60–75: Systemtests in der Zielumgebung, Performance-/Robustheitstests. Erste Evidenzpakete erzeugen, interne Pre-Audits.
  • Tag 75–90: MVP-S0 live im Shadow, Monitoring aktiv, Feedbackloop mit Operatoren. Planung für S1 (Operator Advisory) inkl. zusätzlicher Nachweise.

8) Trade-offs, die man bewusst eingehen sollte