6) Einsatz von AI-Komponenten mit Governance

  • Daten- und Modell-Souveränität: Trainings-/Testdaten on-prem, Versionierung, Herkunftskennzeichnung.

  • Reproduzierbare Inferenz: deterministische Pipelines, Dokumentation der Preprocessing-Ketten, definierte Betriebsgrenzen.

  • Observability für AI-Anteile: Eingaben, Ausgaben, Fehlermodi, Drift-Indikatoren – alles auditierbar. Für agentische Komponenten braucht es zusätzlich Richtliniendurchsetzung und Protokollierung von Aktionen.

Technical Ownership: Was es ist – und warum es Produkte rettet

Technical Ownership ist die Verpflichtung, das Produkt technisch als Ganzes zu verantworten, nicht einzelne Komponenten. Rollenbeschreibung, wie sie in sicherheitskritischen Projekten funktioniert:

  • Architekturverantwortung: Setzt die Systemgrenzen, Integrationsmuster, Resilienz- und Sicherheitsmechanismen. Pflegt das Architektur-Entscheidungslog.
  • Non-Functionals als Vertragsgröße: Latenz, Durchsatz, Robustheit, Diagnosefähigkeit, Portierbarkeit, Wartbarkeit – mit messbaren Zielen pro Release-Linie.
  • Compliance-Integration in den Arbeitsfluss: Definition of Done enthält Evidenzkriterien. Keine Freigabe ohne vollständige Artefaktkette.
  • Risikobudget-Verwalter: Priorisiert Risiken und verknüpft sie mit PBIs. Entscheidet bewusst, wofür Zeit und Tests investiert werden.
  • Tooling- und Lieferkettensouveränität: Stellt sicher, dass die Toolchain auditierbar, reproduzierbar, on-prem betreibbar ist.
  • Change Authority: Stuft Änderungen ein, führt Impact-Analysen durch, schützt die Baselines.

Technical Ownership ist unpopulär, weil sie Nein sagt: zu unklaren Änderungen, zu architektonischem Wildwuchs, zu „wir bauen erst später Tests“. Genau deshalb rettet sie Produkte. Ohne sie entsteht lokales Optimum (schnelles Feature), aber globales Versagen (nicht auditierbar, nicht wartbar, nicht sicher).

MVP in sicherheitskritischen Systemen: das „Steel Thread“ mit Sicherheitsgurt

Das übliche MVP („nur das Nötigste, schnell geliefert“) ist in regulierten Domänen oft unbrauchbar: Es zeigt Funktion, aber keine Betriebstauglichkeit unter Safety- und Compliance-Anforderungen. Besser: Ein „Steel-Thread-MVP“, ein dünner, aber echter End-to-End-Faden durch das System – inklusive Sicherheitsgurt und Nachweisführung.

Bausteine eines Steel-Thread-MVP:

  • Minimale, aber echte Ende-zu-Ende-Funktion: Ein realer Betriebsfall, vom Eingangssignal/Sensor bis zur abgesicherten Aktor-/Entscheidungswirkung.

  • Safety/Assurance Seed: Früh definierter Sicherheitsrahmen (Betriebsgrenzen, Degradationsmodi, Fallbacks, Überwachung). Keine „Safety später“-Lüge.

  • Messbare Non-Functionals: Setzen von Zielkorridoren (z. B. Latenz unter Lastklasse X, Erkennungsqualität in Umgebung Y). Tests verifizieren diese Korridore im MVP.

  • Evidenz-Pipeline aktiv: Traceability, Tests, Protokolle, Freigaben – alles läuft von Tag 1.

  • Betriebsartefakte vorhanden: Telemetrie, Logging, Diagnosen, Fernwartung innerhalb des erlaubten Rahmens. Observability ist nicht Kür, sondern Pflicht.

So geplant, ist ein MVP auditierbar, betrieblich wertvoll (ein echter Use Case mit Sicherheitsgurt) und technisch erweiterbar ohne Komplettumbau.

Beispielhafte Umsetzung in 90 Tagen (vereinfachte Roadmap)

Woche 1–2: Rahmensetzung

  • Betriebsfall auswählen, der repräsentativ ist und echten Wert im Feld hat.

  • Sicherheits-/Risikorahmen definieren: Betriebsgrenzen, Fallback, Überwachung, erste Gefährdungsanalyse light.

  • Architekturfirst: Systemgrenzen, Datendurchfluss, Synchronisations- und Fehlerszenarien, Schnittstellen, on-prem Betriebsrahmen.

  • Tooling-Baseline aufsetzen: on-prem Git/CI, Artefakt-Repository, Testinfrastruktur, evidenzerzeugende Pipeline.

Woche 3–4: Steel Thread skizzieren

  • Minimale Sensorik/Aktorik-Anbindung, Kommunikationspfad, Datenpersistenz.

  • Messpunkte für Non-Functionals definieren, Testharness aufbauen.

  • Traceability-Backbone aktivieren: IDs, Verknüpfungen, Pull-Request-Checks.

Woche 5–8: End-to-End-Inkrement

  • Funktionale Kernlogik (oder erstes ML-Modell) integrieren, mit deterministischen Pre-/Postprocessing-Ketten.

  • Safety-Mechanismen implementieren (Monitoring, Grenzwerte, Degradationsmodus).

  • HIL/SIL/Simulation: definierte Szenarien als Pipeline-Stufen, Artefakte archivieren.

  • Erste Betriebsfahrten/Sim-Läufe mit Telemetrie, Logging, Anomaly-Flags. Risiken gezielt abbauen (Leistung, Stabilität).

Woche 9–10: Härtung und Evidenzkonsolidierung

  • Abdeckungsziele erreichen, Nicht-Funktionales validieren, Grenzfälle testen.

  • SBOM, Build-Reproduktion, Konfigurationsbaselines fixieren.

  • Betriebsprozesse skizzieren: Deployment-Playbook, Recovery, Diagnose.

Woche 11–12: Review, Freigabe, Plan für nächste Inkremente

  • Audit-Ready-Review: Stichproben durch die Artefaktkette, Gaps schließen.

  • Nächster Risikoschwerpunkt definieren (z. B. Datenqualität unter anderen Umgebungen, robuste Zeitbasis, Redundanz).

  • Entscheid vorantreiben: Was bleibt im Scope on-prem, welche Komponenten dürfen in isolierte Umgebungen, wie bleiben Schnittstellen strikt?

Werkzeuge und Governance – was in der Praxis trägt

  • Artefaktorientiertes Arbeiten: Anforderungen, Tests, Ergebnisse, Freigaben sind erstklassige Objekte mit Versionen und Links. Dateien im Wiki reichen nicht.
  • Pull-Request-Policies: Keine Zusammenführung ohne aktualisierte Trace-Links, Testevidenzen, Risiko-Update.
  • Testpriorisierung: Safety-relevante Pfade zuerst stabil, Non-Functionals durchgehend messen, UI/„nice-to-have“ später.
  • Observability by Design: Protokollierung, Metriken, verankerte Diagnose-Schnittstellen. Ohne Sichtbarkeit keine Sicherheit.
  • Datenethik und Zugriff: Klare Datenklassifizierung, kontrollierte Zugriffe, pseudonymisierte Entwicklungsdatensätze, getrennte Produktionsdaten. Alles on-prem beherrschbar.
  • Vendor-Neutralität: Kritische Komponenten austauschbar halten (Schnittstellenverträge, Adapter), damit Lieferkettenschocks nicht produktionskritisch werden.

Anti-Pattern: Woran man gescheiterte Agilität erkennt

  • Dokumentation als nachträgliches Sammeln: Wenn „Evidenzen“ erst am Releaseende entstehen, kommen sie zu spät und sind lückenhaft.
  • Tooling als Fremdbestimmung: Wenn zentrale Build-/Test-/Datenpfade nur via externem Cloud-Dienst funktionieren und offline nicht, ist Souveränität Illusion.
  • Feature getrieben, risikoignorant: Kein sichtbarer Risk-Burndown, nur Velocity. Spätere Überraschungen sind eingebaut.
  • Architektur-Erosion: „Wir refactoren später“ als Dauermantra. In Wirklichkeit wächst die Zinslast.
  • Unklare Rolle: Niemand kann erklären, wer endgültig über Non-Functionals, Risiko und Baselines entscheidet. Das Produkt hat keinen technischen Besitzer.

Technical Ownership in Aktion: ein Tagesablauf