Souveränität ist eine Architekturentscheidung, keine Compliance-Formalie. Wer seine Build- und Datenpfade nicht kontrolliert, kann sie nicht auditieren. Elemente, die wir standardmäßig verankern:

  • On-Prem und Air-Gap-fähig: Quellcode, CI/CD, Container-Registry, Artefakt-Repository, ML-Featurestores, Vektorindizes – alles lokal betreibbar. Spiegelmechanismen für externe Abhängigkeiten mit Freigabeworkflows.

  • Reproduzierbare, hermetische Builds: pinned Dependencies, Containerized Toolchains, deterministische Compiler-Flags, Build-Caching auf Artefakt-Servern, Signaturen (z. B. Sigstore/Cosign) und Provenance-Metadaten.

  • Lieferkettensicherheit: Quell- und Binär-Scanning, SBOM-Erzeugung pro Artefakt, Policy-Gates (nur signierte, geprüfte Artefakte dürfen in produktionsnahe Umgebungen).

  • Daten-Governance: Klassifizierung, Zugriff über Attribute-Based Access Control, Verschlüsselung in Ruhe und Transport, Pseudonymisierung/Maskierung in Testumgebungen, Audit-Trails für Datenzugriffe.

  • Observability by design: Technische Telemetrie (Logs, Metriken, Traces) plus Governance-Telemetrie (Wer hat wann welches Modell/diese Prompt-Version freigegeben? Welche Anforderungen deckt dieser Testlauf?) – mit strikter Trennung zwischen Entwicklungs- und Betriebsdomänen.

MVP neu gedacht: Minimum Valuable & Provable

Der klassische MVP-Begriff (“so wenig wie möglich, so früh wie möglich”) führt in sicherheitskritischen Kontexten in die Irre. Wir verwenden MVP bewusst als Minimum Valuable & Provable:

  • Valuable: Erzeugt echte Wertinformation – z. B. validiert einen kritischen Architekturpfad, liefert Nutzen in einem klar begrenzten Einsatzbereich oder reduziert ein Top-Risiko.

  • Provable: Es existieren hinreichende Nachweise für das spezifizierte Einsatzprofil, inklusive klarer Fallbacks und Safe-State-Definitionen.

Gestaltungsprinzipien für MVP in sicherheitskritischen Systemen:

  • Begrenztes Operational Design Domain (ODD): Der Einsatzbereich wird eng definiert und technisch erzwungen (z. B. nur bestimmte Fahrzeugtypen/Umgebungen).

  • Shadow Mode vor Active Mode: Das System läuft mit, trifft aber keine Steuerungsentscheidungen, während Performance, Robustheit und Fehlklassifikationen gemessen werden.

  • Feature-Gating: Kritische Pfade unterliegen expliziten Freigabeschaltern; Rückrollen ist geplant und geübt.

  • Safe-State und Kill-Switch: Technisch implementiert, nicht nur dokumentiert; regelmäßig getestet.

  • Stufentests: Bench → Software-in-the-Loop → Hardware-in-the-Loop → kontrollierter Feldversuch → gestaffelte Flotteneinführung.

  • Evidenzmetriken: Nicht nur Mittelwerte; Konfidenzintervalle, Verteilungsschwänze, OOD/Drift-Indikatoren, Worst-Case-Latenz, deterministische Bounds.

  • Für ML: Versionierte Datasets und Labels, Daten- und Modelldrift-Monitore, Fairness/Robustheitsprüfungen, interpretierbare Fehleranalysen.

  • Für LLM/Agenten: Gesperrte Tool-Whitelists, deterministische Decoding-Settings für kritische Pfade, adversariale Tests (Prompt-Injection, Halluzinationen), Offline-Evaluationssuites, verpflichtende Refusal-Policies.

Fallbeispiel: Visuelle Inspektion in der Fertigung – von PoC zu auditierbarer Produktion

Ausgangslage: In einer Fertigungslinie sollen visuelle Montagefehler erkannt werden. Daten dürfen das Werk nicht verlassen. Das System muss erklärbar sein, Updates müssen nachvollziehbar und rückrollbar sein, der Linienbetrieb darf nicht beeinträchtigt werden.

Architektur und Arbeitsweise:

  • Datenerfassung on-prem: Kamerastreams werden segmentiert, annotiert und in einem lokalen Data Lake abgelegt. Datenschemata und Label-Guidelines sind versioniert; jede Aufnahme trägt Metadaten (Charge, Linie, Lichtsetup).

  • MLOps on-prem: Git für Code, DVC für Datenversionierung, ein lokales MLflow für Experimente und Modellartefakte, Container-Registry on-prem. Kein externer Cloud-Dienst.

  • Pipeline-Gates: Data-Quality-Checks (z. B. Verteilung pro Klasse), Trainingsreproduzierbarkeit (Seeds, Env), auswertbare Performanzmetriken pro Bauteiltyp und Lichtbedingung, SBOM/Scan für inferenzrelevante Laufzeitumgebungen.

  • Integration: Das Inferenzmodul läuft in einem isolierten Edge-Container mit festen Ressourcenlimits und Watchdog. Ergebnisse werden inklusive Unsicherheitswerten und Heatmaps bereitgestellt; bei Unsicherheit überschreitet das System nie die manuelle Endkontrolle.

  • MVP-Phase: Shadow Mode mit A/B-Auswertung gegen manuelle Befunde; definierte Abnahmekriterien je Bauteiltyp, dokumentiertes Fehlertoleranzfenster und ein “no degrade”-Ziel (das System darf die Linie nicht verlangsamen).

  • Assurance-Backlog: Jede Iteration beinhaltet Aktualisierung der Datenkarte (welche Populationen sind abgedeckt?), Drift-Reports, verlinkte Testkampagnen (synthetisch und real), Änderungseinträge im Hazard Log (z. B. neues Glanzverhalten durch Lackwechsel).

  • Freigabe: Monatliche Baselines mit Evidenzpaketen. Rollout in produktive Linien erst nach Erfüllung der ODD-Kriterien und Schulung der Bediener – inkl. dokumentierter Rückfallprozeduren.

Das Ergebnis: Entwicklungs- und Betriebszyklen bleiben agil (2-Wochen-Sprints), während die Compliance in monatlichen Baselines mitwächst. Keine Schlussdoku-Hölle, keine bösen Überraschungen im Audit.

Assurance als Produkt: Der lebende Nachweisbaum

Regulatoren und interne Freigabegremien sind Stakeholder. Sie brauchen keine Showcases, sondern strukturierte Argumente mit Evidenz. Statt Word-Dokumentfarmen setzen wir auf einen lebenden Assurance Case:

  • Zielstrukturierung: Explizite Claims (z. B. “Funktion X ist im ODD Y sicher”), Argumentationsketten, verlinkte Evidenzen. Änderungen erzeugen Delta-Reports.

  • Evidence Map: Für jede Anforderung zeigt eine Karte, welche Tests in welcher Umgebung sie belegen, mit Referenzen auf Logs und Artefakte.

  • Witnessing-Planung: Tests, die ein Witness sehen muss, sind früh identifiziert; zugehörige Daten und Setups sind reproduzierbar.

Kommunikationstipp: Bringen Sie Auditoren früh an das Produkt, nicht erst an den Papierberg. Eine halbstündige Demo der Traceability- und Pipeline-Gates schafft mehr Vertrauen als zehn Seiten Prozessdiagramme.

Häufige Stolperfallen – und wie man sie umgeht