Klassische Software lässt sich deterministisch prüfen; KI bringt Daten- und Modellvariabilität. Das ist beherrschbar – mit Strukturen:

  • Daten-Governance on-prem: Datenspeicher, Feature Stores und Trainingsumgebungen sind unternehmenssouverän (keine externe Cloud, DSGVO-konform). Jede Datenquelle ist versioniert und referenzierbar (z. B. DVC, LakeFS).

  • Modell-Lebenszyklus: Trainingskonfigurationen, Code, Hyperparameter, Seeds, Umgebung (Container-Hashes) sind Teil der Evidenz. Lineage vom Rohdatensatz bis zum Modell-Artefakt ist nachweisbar.

  • Akzeptanzkriterien fachlich statt nur ML-metrisch: In der Fertigung sind SPC-Kennzahlen (z. B. Ppk) operational relevant; in Safety-Kontexten definieren wir Fehlertoleranzen, verknüpfen Performance mit Hazard-Auswirkungen und legen Abbruchbedingungen fest.

  • Change-Impact für Daten: Neue Trainingsdaten sind eine Änderung am System. Impact-Analyse, Regressionstests gegen Golden Datasets, Monitoring auf Datendrift im Betrieb.

  • Erklärbarkeit und Monitoring: Feature-Attribution, Fehlerklassifikation, Outlier-Detektion – nicht als Selbstzweck, sondern als Beleg der Wirksamkeit von Safety Envelopes und zur Root-Cause-Analyse.

  • LLMs im Unternehmen: Keine Produktionsgeheimnisse oder personenbezogene Daten in offene APIs. Falls LLMs im Entwicklungsprozess oder als Komponente eingesetzt werden, dann on-premise mit vollständiger Observability und Governance (Prompt-/Antwort-Logs, Richtlinien, Rollenkonzepte, Audit-Trails). Genau hier setzt unsere Plattform Alpi-M an: Observability und Governance für LLM-Agenten in souveränen Umgebungen, integrierbar in bestehende on-prem CI/CD und Evidence-Flows.

Architektur- und Prozessmuster, die in der Praxis tragen

  • Schnittstellen als Hartwährung: Gefrorene, versionierte Verträge zwischen Safety Cage und restlichem System. Contract-Tests laufen in der Pipeline, bevor etwas in einen sicherheitsrelevanten Pfad merge-fähig ist.
  • Determinismus messbar machen: Latenz- und Jitter-Budgets pro Komponente, Worst-Case Execution Time (WCET) Analysen, Lock-Contention-Checks, Heap-Nutzung unterbinden oder strikt begrenzen in High-Criticality-Pfaden.
  • Datenpfade härten: Klare Trennung zwischen qualifizierten und explorativen Pfaden. Explorative ML-Experimente dürfen nie unbeabsichtigt den qualifizierten Pfad berühren. Strikte Artefakt-Namenskonventionen, Signierung, Freigabeprozesse.
  • Security-by-Design ist nicht optional: Threat Modeling (z. B. STRIDE), Härtung (CIS-Benchmarks), Secrets-Management on-prem, Schlüsselmaterial unter HSM, signierte Updates, Secure Boot. SBOM verpflichtend, mit automatisierten Vulnerability Alerts und definierten Remediation SLAs je Kritikalität.
  • Toolchain-Qualifikation pragmatisch: Bewerten Sie, ob ein Tool Fehler einführen kann, die Tests nicht entdecken würden. Qualifizieren Sie selektiv. Dokumentieren Sie Vertrauen (z. B. durch Cross-Checks, Tool-Proven-in-Use, formale Reviews).

Anti-Patterns, die wir regelmäßig sehen – und wie man sie vermeidet

  • „Agile bis zum Audit“: Monate lang Features bauen, dann ein hektisches Dokumentations-Finale. Lösung: Evidence-as-Code, ab Tag 1.
  • „Scrum ersetzt Systemarchitektur“: Wenn der Scheduler die Safety-Risiken managen soll, ist das Kind schon im Brunnen. Lösung: Hazard-driven Architektur vor Sprint-Takt.
  • „KI-Pilot ohne Souveränität“: Public-Cloud-Experiment mit Produktionsdaten, später Unzulässigkeiten. Lösung: von Anfang an on-prem und DSGVO-sicher; Modell-Lifecycle versioniert.
  • „Compliance-Theater“: Formale Dokumente, die nicht zur Realität passen. Auditoren merken das. Lösung: erzeugte Evidenz muss maschinen- und menschenlesbar aus dem Build kommen – keine Word-Artistik.
  • „Product Owner ohne Safety-Accountability“: Features werden priorisiert, aber Safety-Budgets verfehlt. Lösung: Technical Ownership mit klarer Verantwortung für Safety/Security/NFRs.

Beispielhafte Umsetzungsvignette aus Projekten

  • Bahn: Fleet-Intelligence-System
  • Problem: Zustandsdiagnose und Vorhersage von Ausfällen mit heterogenen Fahrzeugdaten, Offline-Zeiten, strengen IT-Security-Vorgaben.
  • Ansatz: Edge-Connectoren mit gepufferten, signierten Telemetriestreams; on-prem Data Lake, Feature Store, Models im Shadow Mode; ODD-Begrenzung auf nicht-sicherheitskritische Subsysteme; Evidence-Pipeline mit Trace von Anforderung über Datenmerkmal bis Inferenzlog.
  • Ergebnis: Iterative Ausweitung der ODD, keine Beeinflussung von Safety-of-Life-Funktionen, Auditierbarkeit der Daten- und Modellpfade.
  • Fertigung: Visuelle Inspektion
  • Problem: Ersetzen manueller Sichtprüfungen, ohne Falsch-Negative in sicherheitsrelevanter Stückliste.
  • Ansatz: Simplex-Schema: KI identifiziert Defekte, konservativer Heuristik-Checker garantiert, dass potenzielle Defekte nie unentdeckt bleiben; SPC-basierte Akzeptanzkriterien; Freigabe in CRL-Stufen von Shadow bis Teilautomatisierung; Daten-Drift-Monitoring mit automatischer Rückstufung bei Metrikverletzung.
  • Ergebnis: Produktivnutzen früh (Fehlteile-Heatmaps, Taktoptimierung), Sicherheitsgarantien intakt.
  • Defense: Sichere, skalierbare Softwareplattform
  • Problem: Air-gapped Deployments, proprietäre Funkprotokolle, strikte Supply-Chain-Kontrollen.
  • Ansatz: Reproduzierbare Builds, signierte Artefakte, SBOM-Prüfung, deterministische Runtime-Profile; LLM-Unterstützung für Entwickler nur on-prem mit Alpi-M Governance; ADR-getriebene Architekturentscheidungen.
  • Ergebnis: Kurze Integrationszyklen trotz Air-Gap, Audits bestehen auf Knopfdruck.

Schritt-für-Schritt-Einstieg in „Agil mit Struktur“

1) Standards klären, Compliance-Matrix bauen

  • Welche Normen gelten? Welche Level (SIL/DAL)? Welche Tool- und Evidence-Anforderungen?

  • Map auf Artefakte, Pipelines, Quality Gates. Definieren Sie eine Evidence-Ordnerstruktur und Zugriffspolitiken.

2) Requirements-Backbone und Traceability aufsetzen

  • Req-IDs, semantische Struktur, bidirektionale Trace von Hazard über Systemanforderungen, Architektur, Code, Tests, Testläufe.

  • Automatisierte Checks in der CI, die fehlende Traces blocken.

3) Hazard-driven Architektur und Safety Patterns wählen

  • Safety Envelopes definieren, Monitore/Simplex planen, Partitionierung, Echtzeit- und Speicherbudgets festlegen.

  • Schnittstellenverträge einfrieren, Contract-Tests bauen.

4) Evidence-as-Code CI/CD und Security-Härtung etablieren

  • Coverage, Static Analysis, SBOM, Signierung, Repro-Builds, Audit-Paket-Generator.

  • On-prem Runner, Air-Gap-Strategien, Artefaktprovenienz.

5) MVP-Strategie für KI-Komponenten definieren

  • ODD, CRL-Stufen, Shadow/Advisory, Golden Datasets, Drift-Monitoring, Rückstufungskriterien.

  • Daten- und Modell-Lineage in die Evidence-Pipeline integrieren.

6) Technical Ownership besetzen und befähigen

  • Klare Verantwortlichkeit, Stop-the-line, ADR-Prozess, Schnittstellen-Governance.

  • Eskalationspfade vereinbaren, wenn Safety- oder Evidence-Budgets reißen.

Ressourcen- und Souveränitätsaspekt