• Kommunikationsgrenzen als Verträge
  • Schmaler, versionierter API-Schnitt. Strikte Validierung, Rate-Limits, Zeitbudgets.
  • Einseitige Informationsflüsse, wenn möglich. Bei bidirektionalen Kanälen: explizite Gatekeeper mit Watchdogs.
  • On-Prem und Air-Gap bedenken
  • Offline-fähige Updates, signierte Pakete, lokale Artefakt-Repositories.
  • Keine Abhängigkeit von fremden Clouds. Wenn Cloud-Funktionalität nötig ist: Bridge über Datendiode bzw. gepufferte, asynchrone Synchronisation, mit klaren Failure-Modes.
  • Determinismus erzwingen, wo er zählt
  • Verzicht auf nicht-deterministische Patterns im Core (z. B. unbounded Queues, unkontrollierte Nebenläufigkeit).
  • Zeitgetriggerte statt ereignisgetriebene Abläufe, wenn Timing essenziell ist.

Diese Partitionierung macht Innovation möglich, ohne jeden Sprint durch eine vollständige Sicherheitsanalyse zu zerren. Der Safety Core bleibt stabil; das Innovation Layer iteriert unter harten Verträgen.

CI/CD ohne Internet: Versiegelte Lieferkette

„Ship fast“ kollidiert oft mit Air Gap. Lösung ist nicht, Compliance zu lockern, sondern die Lieferkette technisch zu schließen:

  • Reproduzierbare Builds
  • Pinned Toolchains, hermetische Builds, Content-Addressability.
  • Build-Provenance speichert: Eingangsartefakte, Compiler-Versionen, Flags, Prüfsummen.
  • Signaturkette
  • Entwickler signieren Commits.
  • Build-System signiert Artefakte.
  • Freigaben signieren Releases. Überprüfung erfolgt sowohl im Test- als auch im Zielsystem.
  • Offline-Registries und Artefakt-Repos
  • Container-Images, Bibliotheken, SBOMs in internen, geprüften Repos.
  • Keine Laufzeit-Zugriffe auf externe Paketquellen.
  • Testen im Zwiebelschalenmodell
  • Auf Entwicklerrechnern: schnelle Unit-/Contract-Tests.
  • In CI: Integrations- und Systemtests in Simulationen/Digital Twins.
  • Hardware-in-the-Loop für reale Grenzen (Timing, IO, Sensorik).
  • Vor-Ort-Deployments nur mit „Release Gates“: Checklisten, Unterschriften, Rollback-Pläne.
  • Observability-by-Design
  • Logs, Metriken und Events sind spezifizierte Schnittstellen, nicht Nachgedanken.
  • Safe-State-Monitoring: Wenn Telemetrie Lücken hat, degradieren wir konservativ.

MVP neu gedacht: Minimal Verifiable Product

Ein MVP, das „nur so halb“ funktioniert, ist in sicherheitskritischen Umgebungen wertlos. Wir ersetzen Viable durch Verifiable: Ein MVP muss die kleinste in sich sichere Funktionseinheit sein, die man objektiv prüfen kann. Das beinhaltet:

  • Safety Envelope
  • Definition, welche Zustände zulässig sind und wie das System in einen sicheren Zustand übergeht.
  • Hard Limits und Watchdogs bereits im MVP, nicht „später“.
  • Degradationspfade
  • Wenn Teilfunktionen scheitern: definierte, getestete Degradationsmodi statt „Undefined Behavior“.
  • Explizite Kill-Switches
  • Operative Möglichkeit, neue Pfade sofort abzuschalten, ohne den Safety Core zu beeinträchtigen.
  • Simulation-first Nachweise
  • Bevor reale Anlagen berührt werden: Nachweis in Digital Twins mit belastbaren Szenarien, Lasten und Fault-Injection.
  • Evidenz-Minimum
  • Anforderungs- und Traceability-Basis, Teststrategie, Betriebs- und Rollback-Konzepte, Risikoanalyse mit dokumentierten Gegenmaßnahmen.

Ein guter Test für MVP-Reife: Können Sie einem Auditor in einer Stunde demonstrieren, welche Anforderungen abgedeckt sind, welche Tests wo laufen, wie Sie versagen und wie Sie sicher degradieren? Wenn nicht, ist es ein Prototyp, kein MVP.

Sprint-Mechanik mit Auditoren im Kopf

Review nicht nur für Features, sondern für Evidenz. Das Sprint Review bekommt drei Slots:

  • Funktionale Demo gegen Akzeptanzkriterien.

  • Evidenz-Review: Traceability, Testresultate, ADRs, SBOM-Updates.

  • Betriebsprobe: Logs/Alarme im Zielbetrieb simulieren, Rollback im Trockentraining.

Die Retrospektive bewertet nicht nur Velocity, sondern:

  • Wie viel Verification Debt wurde aufgebaut/abgebaut?

  • Kamen wir ins Risiko-Budget? Wenn ja, warum?

  • Wo klemmt die Lieferkette (Tooling, Air Gap, Sigchain)?

Kennzahlen, die helfen:

  • Evidence Burndown: Offene Nachweis-Items über die Zeit.

  • Change Impact Durchlaufzeit: Von kritischer Anforderung bis freigegebenem, belegtem Release.

  • Mean Time to Safety Regression Detection: Zeit von Fehler-Einführung bis Alarm im CI/HIL.

AI/ML im regulierten Kontext: Modelle sind Artefakte mit Nachweisbedarf

Wenn ML-Modelle Teil des Produkts sind:

  • Daten- und Modellversionierung

  • Datasets, Feature-Pipelines, Modelle sind erstklassige Artefakte mit IDs, Checksummen und Provenance.

  • Nichtdeterminismus kontrollieren

  • Fixierte Seeds für Reproduzierbarkeit in Tests.

  • Runtime-Monitore begrenzen Ausgaben (Confidence-Gates, Sanity Checks). Bei Unsicherheit: Fallback.

  • Shadow-Mode-Einführung

  • Modelle zunächst „im Schatten“ mitloggen, Entscheidungen nicht steuern, Performance messen.

  • Drift- und Szenarioabdeckung

  • Gezielte Tests auf kritische Szenarien, kontinuierliches Monitoring auf Drift.

  • Mensch im Loop, wo nötig

  • Bei nicht verifizierbaren Auswirkungen bleibt der Mensch Gatekeeper.

Für komplexere KI-Agenten im industriellen Umfeld gilt zusätzlich: Transparenz über Kettenentscheidungen und Eingabedaten ist Pflicht. Plattformen für Observability und Governance helfen, Entscheidungen nachvollziehbar zu machen und Freigaben zu steuern. Entscheidend ist: On-Prem, souverän, auditierbar – keine Blackboxes, keine Fremd-Cloud-Abhängigkeiten.

Konkrete Muster aus Projekten

Defense: Command-and-Control-Zusatzmodule

  • Safety Core unberührt: Kernfunktionen in gehärteter, deterministischer Domäne.

  • Zusatzmodule im Innovation Layer: Datenfusion, Visualisierung.

  • Updates über signierte Offline-Pakete; Akzeptanztests im HIL-Lab, danach gestaffelte Ausbringung.

Railway: Flottenintelligenz

  • Fahrzeugseitig: Minimalinvasiver Client mit strikt definiertem Puffer und Upload-Takt.

  • Zentrale: On-Prem Analytics-Cluster, versionierte Auswertungen, reproduzierbare Pipelines.

  • Shadow-Analysen parallel zu bestehenden Verfahren, erst später operative Umschaltung.

Aviation-Training: Cloud-nahe, aber souverän

  • Trennung Trainingsdatenbank (On-Prem oder EU-Cloud) und Simulation Engine.

  • Feature-Freigaben nur mit Telemetrie-Checks und sofortigem Rollback-Pfad.

  • Performance- und Konsistenz-Gates in CI, bevor Kundensysteme berührt werden.

Organisatorische Arbeitsvereinbarungen

  • Architektur-Gremien sind klein, schnell und dokumentieren Entscheidungen in ADRs. Kein Elfenbeinturm, sondern wöchentliche 30-Minuten-Slots mit Technical Owner, Lead Devs, Safety/Compliance.
  • Jede Quellcode-Änderung referenziert eine Anforderung und/oder ein Risiko. Kein „Drive-by“-Code.
  • Pairing bei sicherheitskritischen Pfaden: Vier-Augen-Prinzip technisch im Code Review verankert, nicht nur als Policy.
  • Tooling ist Teil des Produkts: CI, Scanner, Simulationsumgebungen werden versioniert, signiert, auditiert.
  • Zulieferer sind integrierte Teilnehmer: Vertragswerke mit Update-Takten, SBOM-Pflichten, Schnittstellen-Freeze-Zeiten.