Konkreter Ablauf für ein MVP in der visuellen Inspektion (Fertigung oder Bahn):
1) Discovery mit Grenzen:

  • ODD definieren: Welche Bauteile, welche Beleuchtung, welche Taktzeit, welche Fehlertypen.

  • Hazard Workshop: Fehlklassifikation und Latenz als Gefährdungen identifizieren, Mitigation via Safety Cage und manuelle Freigabewege.

  • Security & Privacy: Datenfluss on-prem, Pseudonymisierung falls nötig, Zugriff über RBAC, Audit-Logging.

2) Architektur-Schnitt:

  • Edge-Inferenz (C++/Rust + TensorRT/OpenVINO) mit harter Latenzgrenze.

  • Aufnahme-Pipeline mit deterministischer Vorverarbeitung (feste Bildoperatoren, konstante Seeds).

  • Datenablage in einem on-prem Data Lake mit Versionierung (DVC/LakeFS), unveränderlichen Artefakten (Write-Once-Buckets).

  • Steuerung via ICD mit stabilem Schema und Migration-Plan.

3) Pipeline & Evidenz:

  • CI: Unit-/Integrationstests, deterministische Builds, SBOM, SAST/DAST.

  • ML Eval Harness: Fixierte Evaluationssets, Metriken (Precision/Recall pro Defektklasse), Drift-Detektion vorbereitet (z. B. PSI/KL-Divergenz).

  • Traceability: Anforderungen ↔ Tests ↔ Code ↔ Modellversion, automatisch aus Repo generiert.

4) Shadow-Mode Rollout:

  • Read-only Integration, Echtzeit-Performance messen, Advisory mitgeloggt.

  • Wöchentliche Evidence-Drops: Eval-Berichte, Latenzverteilung, Falsch-Positiv/Negativ-Analysen, Aktualisierung Hazard Log.

5) Go-Live mit Safety Cage:

  • Nur unkritische Entscheidungen werden automatisiert; kritische Entscheidungen erfordern Bediener-Quittierung.

  • Fail-Safe: Bei Unsicherheit oder Performance-Degradation automatische Deaktivierung mit klarer HMI-Meldung.

6) Betrieb & Updates:

  • Signierte Update-Pakete, Offline-verteilbar.

  • Canary in einer Linie, dann gestaffelter Rollout.

  • Observability-Metriken: Latenz, GPU/CPU-Budgets, Unsicherheitsquoten, Drift-Indikatoren.

Werkzeug- und Architektur-Muster für Nachweisfähigkeit

Traceability ohne DOORS-Monolith:

  • Anforderungen als versionierte, textuelle Artefakte (z. B. YAML/Asciidoc mit IDs).

  • Referenzen im Code (Annotationen), Tests übernehmen dieselben IDs.

  • CI generiert Trace-Matrizen und markiert Lücken als Build-Fehler.

  • Für formalen Austausch: ReqIF-Exports aus der Textquelle, nicht umgekehrt.

Verifikation & Validierung kontinuierlich:

  • Statische Analyse (z. B. MISRA-konforme Checks bei C/C++), Cyclomatic Complexity-Limits, Duplication-Limits.

  • Coverage zielnormabhängig; wichtige Pfade und Entscheidungslogik werden gezielt abgedeckt; Coverage-Berichte dem Build beigefügt.

  • Unabhängige Reviews: Peer-Review nicht durch Autorenteam; für Safety-relevante Komponenten zusätzlich unabhängige Prüferrolle in CI etabliert (Approval required).

Determinismus & Reproduzierbarkeit:

  • Pinned Toolchains in Container-Images, die selbst versioniert und signiert sind.

  • Einheitliche Build-Orchestrierung (Bazel/Nix) statt individuell konfigurierter IDE-Builds.

  • Artefakt-Provenance: in-toto/SLSA-ähnliche Attestierungen, die Build-Umgebung, Commit und Abhängigkeiten dokumentieren.

ML-spezifische Governance:

  • Dataset- und Model Cards mit klaren Geltungsbereichen, Limitierungen und Trainingsdaten-Charakteristika.

  • Data Lineage: Welche Sensorsessions sind in welchem Trainingslauf gelandet? Welche Label-Qualität? Wer hat freigegeben?

  • Drift-Überwachung als nicht-invasive Telemetrie, on-prem verarbeitet; keinerlei PII verlässt das Netzwerk.

  • Rollback-fähige Modellverteilung mit A/B-/Shadow-Mechanismen und dokumentierter Performance-Grenze.

GenAI/LLM in regulierten Umgebungen:

  • Kein Internetzugriff aus dem Produktivsystem. On-Prem-LLM, abgeschottete RAG-Quellen mit geprüften Dokumenten.

  • Prompt- und Output-Logging für Nachvollziehbarkeit, PI-Filter, Policy-Checks vor Auslieferung der Antwort.

  • Agenten dürfen keine sicherheitskritischen Aktionen ohne deterministische Guardrails auslösen.

  • Für operative KI-Agenten ist Observability zentral: Auditierbare Entscheidungen, reproduzierbare Agentenläufe, strenge Rechteverwaltung. Genau hier braucht es spezialisierte Plattformen für Observability und Governance, die on-prem laufen und DSGVO-konform arbeiten.

Planung und Kadenzen: Spikes mit Nachweis, Gateways ohne Big-Design-Upfront

Dual-Track Discovery/Delivery:

  • Discovery-Spikes sind timeboxed, liefern aber harte Ergebnisse: Architektur-ADR, aktualisiertes Risiko, Prototyp mit Messwerten, Entscheidungsgrundlage “go/stop”.

  • Keine “Proof-of-Concepts” ohne definierte Kill-Kriterien und Lernziele.

Leichte, wiederkehrende Gateways:

  • Safety-Review: Auswirkungen auf Hazard Log, Mitigation-Status, Testabdeckung.

  • Architektur-Review: NFR-Budgets, Schnittstellenstabilität, Performance-Headroom.

  • Security/Privacy-Review: Neue Datenflüsse, Bedrohungen, DPIA-Änderungen.

  • Diese Gateways sind in Sprints eingebettet; Entscheidungen werden dokumentiert (ADRs) und Artefakte landen automatisiert im Build-Output.

Metriken, die in regulierten Umgebungen zählen

Vermeiden Sie Vanity-Metriken. Stattdessen messen wir:

  • Evidence Accrual Rate: Wieviel prüffähige Evidenz entsteht pro Sprint (Tests, Berichte, Trace-Links)?

  • Time-to-Explain: Zeit, um eine Anforderung bis zur Testevidenz lückenlos zu erklären.

  • Reproduzierbarkeitsquote: Anteil der Builds, die bit-identisch reproduzierbar sind.

  • Drift-Detection Time: Zeit bis zur Erkennung signifikanter Daten-/Modell-Drifts im Betrieb.

  • Audit Findings per Release: Anzahl und Schwere offener Abweichungen.

  • Risk Burndown: Abbau von Risiken im Hazard Backlog, nicht nur Story Points.

  • MTTR unter Sicherheitsauflagen: Wiederherstellungszeit mit dokumentierten, sicheren Verfahren.

Deployment-Modelle: On-Prem by default, Air-Gap fähig

Datenhoheit und Betriebssicherheit verlangen:

  • Air-Gapped-Option: Updates als signierte, paketierte Bundles, Offline-Verification, kontrollierte Wartungsfenster.

  • Rollende Zertifizierungsfenster: Funktionsgruppen werden in “Zertifikats-Slices” zusammengefasst, um Änderungen gezielt einzuschränken.

  • Konfigurations-Governance: Zwei-Personen-Freigaben, versionierte Konfigurationen, Two-Phase-Commit für sicherheitskritische Parameter.

  • Observability on-prem: Metrik- und Log-Pipelines ohne externe Abhängigkeiten, Retention-Policies, manipulationssichere Audit-Logs.

Kurzbeispiele aus der Praxis (anonymisiert)

Defense: Sensorfusion in einer taktischen Umgebung

  • Forderung: Deterministische Latenz < X ms, kein Cloud-Zugriff, reproduzierbare Builds auf definierter Hardware.

  • Vorgehen: Edge-Optimierung in C++ mit festen Speicherprofilen; Shadow-Integration im Teststand; Safety Cage verhindert Aktorbefehle außerhalb definierter Parameter.

  • Ergebnis: Jede Sprintlieferung brachte Feature plus Evidenzpaket (Trace, Test, SBOM), was die spätere formale Abnahme beschleunigte.