Direkt gesagt: Ein KI-Modell ist nicht produktionsreif, weil ein Endpunkt einen Score liefert. Es ist erst dann produktionsreif, wenn das Werk Modell und Container, Datensatz und Feature-Schema, Sensorkalibrierung und Prozessfenster hinter der Entscheidung eindeutig belegen kann – und ein getestetes, kompatibles Vorgängerpaket wiederherstellen kann. Modellsteckbrief und Rollback-Bundle gehören deshalb zu einem Release-Objekt.
Eine Modellversion ist für eine Produktionsentscheidung zu klein
Eine semantische Version oder Modellregister-ID kennzeichnet ein Artefakt, nicht dessen Entscheidungskontext. Ein Vibrationsklassifikator kann unverändert bleiben, während ein Sensor getauscht, ein Kalibrierkoeffizient geändert, ein PLC-Mapping angepasst oder eine Feature-Pipeline zeitlich anders rundet. Das Modell heißt noch gleich; seine Inputs bedeuten nicht mehr dasselbe.
Der Musteransatz für industrielle KI-Datenverträge ist die vorgelagerte Kontrolle: Er definiert, was ein Signal bedeutet. Der Steckbrief verknüpft diesen Vertrag, das freigegebene ausführbare Artefakt und die Betriebsgrenzen zu Evidenz, die Operator, Lieferant und Incident Review später nachvollziehen können.
Die IDTA-Spezifikation AI Model Nameplate ist hilfreich, weil sie ein interoperables AAS-Teilmodell für KI-Modellinformationen definiert. Sie strukturiert Inputs, Outputs, Trainingsergebnisse, Plots, Details, Datensätze und typspezifische Informationen. Sie ist jedoch eine Dokumentationsstruktur, kein Releasesystem: Unveränderbare Artefaktverweise, Freigabelogik und Runtime-Checks müssen Sie zusätzlich bauen.
Das Release-Dossier: Evidenz zusammenbinden, die sonst auseinanderläuft
Erstellen Sie für jedes freigabefähige Modell ein unveränderbares Release-Dossier. Legen Sie es in einem Evidenz-Repository ab, stellen Sie eine lesbare Ansicht über AAS/Steckbrief bereit und schreiben Sie seine ID in jedes Inferenzereignis und jede Operator-Empfehlung.
Identität und Executable — Modell-Digest, Container-Digest, Runtime- und Dependency-SBOM, signierter Image-Speicherort, Source-Revision und Build-Provenienz. Ein Tag wie latest ist keine Identität.
Daten und Features — Snapshots oder unveränderbare Manifeste von Trainings- und Evaluierungsdaten, Feature-Schema-Version, Transformationen, Einheiten, Missing-Value-Regel, Quality-Code-Mapping und Kompatibilitätsbereich des Datenvertrags.
Werkskontext — Asset-Klasse, freigegebene Linien oder Zellen, Sensorseriennummern sowie Kalibrierzertifikate oder Hashes, Firmware-/Konfigurationsepoche, Prozessfenster, Samplingrate, Annahmen zur Zeitquelle und ausgeschlossene Betriebszustände.
Leistung und Autorität — Version der eingefrorenen Eval-Suite, Segment-Schwellen, Umgang mit Unsicherheit, Alert-/Aktionsklasse, technischer Owner, Prozess-Owner, Freigeber, Ablauf- bzw. Review-Zeitpunkt und Evidenzverweise.
Rollback-Ziel — Vorgänger-Dossier-ID, kompatibler Container und Pipeline-/Konfigurations-Digest, Ergebnis des Datenvertrags-Kompatibilitätstests, Rücksetz-Anleitung, Health Check, Owner und dokumentiertes Drill-Ergebnis.
Industrieller Release-Flow: von Offline-Evidenz zum begrenzten Betrieb
Verwenden Sie einen gegateten Pfad statt eines einzelnen Deploy-Buttons. Das Diagramm ist bewusst konservativ:
Offline-Bundle → reproduzierbare Evaluation → Shadow Inference → begrenzter Pilot → freigegebener Betrieb → kontinuierliche Evidenz → Rollback oder erneuter Release.
1. Offline-Bundle: Dossier bauen und signieren; Modell gegen eingefrorene Daten und werksrepräsentative Segmente prüfen. Ein guter Gesamtscore reicht nicht, wenn ein sicherheitsrelevanter Betriebszustand zu wenig abgedeckt ist.
2. Shadow Inference: Den exakten Release parallel zum bestehenden Prozess ausführen, ohne Befugnis für Arbeitsaufträge oder Eingriffe. Inputs, Outputs, Latenz, Missingness und Abweichungen gegen den Referenzprozess messen. Shadow Mode findet Integrationsfehler, die Offline-Tests nicht erkennen.
3. Begrenzter Pilot: Release auf benannte Assets, ein erklärtes Prozessfenster, eine niedrigkritische Aktionsklasse und namentliche Freigeber einschränken. Feature Flags und Rate Limits gehören in die Deployment-Kontrolle, nicht in einen Prompt oder ein Dashboard-Setting.
4. Freigegebener Betrieb: Erst nach unterschriebenem Evidenz-Gate fördern. Das operative Ereignis trägt die Dossier-ID, damit ein Incident später nicht aus Logs und Erinnerung rekonstruiert werden muss.
5. Rollback: Das vollständige kompatible Bundle schalten, nicht nur Modellgewichte. Pipeline-/Konfigurationskompatibilität bestätigen, Health Check ausführen und Grund, Auslöser sowie Evidenzreferenz erfassen.
Entscheidungstabelle: fördern, halten oder zurücksetzen
| Entscheidung | Mindestevidenz | Befugnis | Aktion |
|---|---|---|---|
| Offline zu Shadow fördern | signiertes Dossier; Schwellen der Frozen Suite erfüllt; Feature-Vertrag kompatibel | Modell-Owner + Prozess-Owner | read-only Shadow starten |
| Shadow zu Pilot fördern | Input-Parität gemessen; Abweichung und Latenz innerhalb der Grenzen; Kalibrierung/Konfiguration verifiziert | Prozess-Owner + OT Engineering | benannte Assets und begrenzte Aktionsklasse aktivieren |
| Pilot fortsetzen | keine Schwellenverletzung; Operator-Feedback und Evidenzlinks vollständig | Service-Owner | Feature Flag und tägliche Prüfung beibehalten |
| Halten | fehlende Kalibrierung, unbekannte Schemaänderung, abgelaufene Freigabe oder unvollständige Segmentevidenz | Release Manager | Förderung sperren; untersuchen |
| Rollback | Verletzung von Safety-/Prozessfenster, relevante Qualitätsregression, Runtime-Inkompatibilität oder ungültige Evidenz | vorab berechtigte Incident-Rolle | kompatibles Vorgängerbundle wiederherstellen; Incident-Evidenz sichern |
Fehlermodi, die ein Steckbrief sichtbar macht
1. Gewichte werden zurückgesetzt, die Feature-Pipeline bleibt neu. Das alte Modell erhält eine geänderte Spaltenreihenfolge oder Skalierung und versagt unauffällig. Gegenmaßnahme: Der Rollback-Pointer löst Modell, Container, Feature-Schema und Konfiguration als ein kompatibilitätsgetestetes Bundle auf.
2. Ein Sensor wird nach dem Pilot kalibriert. Der Dienst erhält Werte innerhalb eines Zahlenbereichs, aber nicht mehr in der validierten Messbeziehung. Gegenmaßnahme: Sensoridentität und Kalibrierevidenz binden; Inferenz blockieren oder abwerten, wenn sich die erklärte Kalibrierepoche ändert.
3. Shadow Mode wirkt gesund, weil nur die Gesamtgenauigkeit betrachtet wird. Ein seltener, teurer Maschinenzustand regressiert. Gegenmaßnahme: Leistung nach Asset-Klasse, Betriebszustand und Datenqualität segmentieren; Untergrenzen pro Segment statt eines Mittelwerts definieren.
4. Ein Lieferant aktualisiert einen Container unter einem veränderlichen Tag. Die Runtime ändert sich ohne Modellrelease. Gegenmaßnahme: Nur Content Digests und signierte Förderung zulassen; alarmieren, wenn ein laufender Digest im Dossier fehlt.
5. Ein Notfall-Rollback stellt Gewichte wieder her, aber keinen kompatiblen Parser oder Feature Store. Gegenmaßnahme: Drill muss Artefaktabruf, Konfigurationswiederherstellung, Health Checks und einen beobachteten sicheren Degradationsmodus umfassen.
Risikomanagement braucht Traceability, nicht Papier
Das NIST AI Risk Management Framework beschreibt vertrauenswürdiges KI-Risikomanagement als Lebenszyklusaufgabe. Für Engineering-Teams macht das Dossier die Funktionen Govern, Map, Measure und Manage konkret: Owner und Freigabekriterien zuordnen; Modell in Werks- und Datenkontext abbilden; gemessene Schwellen festhalten; und eine definierte Reaktion durchsetzen, wenn Bedingungen nicht mehr erfüllt sind.
In OT darf ein Fördermechanismus nicht zum Steuermechanismus werden. CISAs Prinzipien für sichere KI-Integration in OT betonen Sicherheits-, Security- und Zuverlässigkeitsrisiken. Behalten Sie daher die Trennung aus der OT-Sicherheits- und Safety-Grenze: Ein Modell darf beobachten, klassifizieren und empfehlen; ein separat entwickelter und autorisierter Pfad überschreitet die Grenze zur Steuerung.
Was das nicht löst
Ein Modellsteckbrief beweist weder Safety noch Genauigkeit oder Rechtskonformität. Er ersetzt keine Gefährdungsanalyse, funktionale Sicherheit, Lieferantenverträge, Cybersecurity-Prüfung oder menschliche Betriebsanweisung. Er macht Evidenz und Annahmen prüfbar – eine notwendige Grundlage, bevor diese Disziplinen entscheiden können. Ob ein konkreter Einsatz regulatorische Pflichten auslöst, hängt von Rolle, Use Case und Jurisdiktion ab; lassen Sie diese Einordnung rechtlich prüfen. Die Engineering-Empfehlung ist enger: Release-Evidenz und Rollback unabhängig von der rechtlichen Einordnung testbar machen.
Mit einer reversiblen Entscheidung beginnen
Wählen Sie einen Use Case, bei dem KI eine Maintenance-Priorität oder Qualitätsprüfung empfiehlt, aber keinen Aktor direkt ansteuert. Bauen Sie ein Dossier, führen Sie einen Shadow-Vergleich durch, definieren Sie einen begrenzten Pilot und üben Sie einen Rollback, bevor Sie auf ein werksweites Register skalieren. Wenn Sie eine unabhängige Prüfung benötigen, unterstütze ich Sie mit einem Workshop für Modellrelease und OT-Evidenz, der Dossier, Gates und Rollback-Drill in eine umsetzbare Architektur überführt.
Quellen
IDTA 02060-1-0: Artificial Intelligence Model Nameplate
NIST: AI Risk Management Framework
CISA: Principles for the Secure Integration of AI in Operational Technology
