Kernaussage: Halten Sie KI aus dem direkten Safety- und Steuerungspfad heraus. In Operational Technology (OT) darf ein KI-System beobachten, klassifizieren, priorisieren und Empfehlungen erzeugen. Es darf jedoch keinen uneingeschränkten Weg zu SPS, Safety Instrumented System (SIS) oder Aktor erhalten. Platzieren Sie die Inferenz hinter einer OT-DMZ, beschränken Sie Identitäten auf einen klaren Zweck und lassen Sie nur eine benannte Person oder eine separat entwickelte Safety-Funktion die Grenze zur Steuerung überschreiten.
Das bedeutet nicht, dass KI in der Industrie keinen Nutzen hat. Es ist die Voraussetzung dafür, dass ein Modellfehler, Prompt Injection, ein Cloud-Ausfall oder ein kompromittiertes Konto nicht unmittelbar einen physischen Befehl auslösen kann. Die gemeinsame OT-KI-Leitlinie von CISA behandelt Integration ausdrücklich als Safety-, Security- und Zuverlässigkeitsaufgabe; NIST SP 800-82 Rev. 3 beschreibt die besonderen Leistungs-, Zuverlässigkeits- und Safety-Anforderungen von OT.
Drei Ebenen statt einer unklaren Integration
Trennen Sie Evidenz, Inferenz und Steuerung. Diese Trennung muss technisch wirksam sein: mit getrennten Netzpfaden, Identitäten, Protokollen, Logs und Ausfallverhalten; nicht nur als drei Namen für dasselbe Servicekonto.
Referenzarchitektur: Zonen und Conduits
1. Beobachtungsebene — Passive Collector lesen Historian-Repliken, OPC-UA-Endpunkte mit Leserechten oder freigegebene Telemetrie-Broker. Jeder Wert erhält Quell-Asset, Zeitstempel, Qualitätsflag, technische Einheit und Konfidenz. Eine schreibfähige OT-Identität ist nicht vorhanden.
2. Inferenzebene — Ein KI-Service in der Enterprise-Zone oder ein gehärteter Werksservice erhält über die OT-DMZ nur minimierte, allow-gelistete Datenprodukte. Er liefert Empfehlung, Evidenzreferenzen, Konfidenz sowie Modell- und Release-ID zurück. Steuerungsendpunkte kann er nicht auflösen.
3. Safety-/Steuerungsebene — SPS, SIS und Aktoren verbleiben in ihrer geschützten Zone. Ein Approval Gateway übersetzt eine angenommene Empfehlung in einen begrenzten Arbeitsauftrag oder eine separat validierte Aktion. Safety-Interlocks wirken weiter, auch wenn KI, Netz oder Gateway ausfallen.
Das entspricht der Logik der Predictive-Maintenance-Architektur: Diagnosen beruhen zunächst auf kontrollierter Evidenz, nicht auf Prozessänderungen. Für Incident-Workflows ergänzt diese Grenze freigegebene Remediation, statt sie zu ersetzen.
Entscheidungstabelle: Autoritätsgrenze festlegen
| Anwendungsfall | Zulässige KI-Rolle | OT-Übergang | Erforderliche Kontrolle |
|---|---|---|---|
| Zustandsanomalie | priorisieren und erklären | keiner | Lesepfad; Untersuchung durch Bedienpersonal |
| Wartungsplanung | Arbeitsauftrag vorschlagen | nur CMMS | Freigabe durch Planung; Asset- und Evidenzverweis |
| Sollwertoptimierung | innerhalb der Hülle beraten | kein direkter SPS-/SIS-Write | Engineering-Freigabe; unabhängige harte Grenzen |
| Begrenzte geschlossene Aktion | erst nach Safety Case und Validierung | dediziertes enges Gateway | feste Allow-List, Rate Limit, unabhängiger Interlock, Rollback |
| Notabschaltung | keine KI-Autorität | niemals über KI | zertifizierte Safety-Funktion und etablierte Betriebsanweisung |
Die Details, die aus dem Diagramm ein Kontrollsystem machen
Setzen Sie zwischen Enterprise-/Inferenzdiensten und Steuerungszonen eine OT-DMZ. Behandeln Sie jeden Conduit als expliziten Vertrag: Quelle, Ziel, Protokoll, Richtung, Datenfelder, Aufbewahrung und Owner. Eine pauschale Firewall-Regel für „KI-Integration“ ist keine angemessene Kontrolle. NIST ist hier relevant, weil OT-Systeme physische Prozesse beeinflussen und Randbedingungen haben, die gewöhnliche Enterprise-Anwendungen nicht besitzen.
Vergeben Sie dem Inferenzservice eine Workload-Identität mit Leserechten ausschließlich für freigegebene Datenprodukte. Nutzen Sie diese Identität weder für Collector noch für Engineering-Workstations oder das Approval Gateway. Rotieren Sie Zugangsdaten, protokollieren Sie Token-Nutzung und verweigern Sie standardmäßig. Auch die Tool-Konfiguration eines Modells ist eine Autorisierungsfläche: Ein LLM darf kein Schreib-Tool finden, nur weil es den Namen eines Assets kennt.
Das Approval Gateway ist ein Policy-Enforcement-Point, keine Chat-Bestätigung. Es prüft Asset, erlaubte Aktion, Betriebsgrenze, Rolle der freigebenden Person, gegebenenfalls Vier-Augen-Prinzip, Ablaufzeit, Rate Limit und vollständige Evidenz. Der Standardpfad sollte ein Arbeitsauftrag sein. Wo begrenzte Automatisierung vertretbar ist, darf die Schnittstelle nur vordefinierte Befehle zulassen; natürlichsprachige Ausgabe darf niemals als Steuerungsbefehl interpretiert werden.
Ausfallmodi, die Sie entwerfen und testen müssen
Modellhalluzination oder falsche Korrelation: Die Empfehlung nennt eine falsche Ursache. Gegenmaßnahme: Quelle und Unsicherheit anzeigen, Prüfung durch Bedienpersonal verlangen, Quote falscher Empfehlungen je Asset-Klasse messen.
Prompt Injection oder manipulierte Betriebsdaten: Nicht vertrauenswürdiger Text versucht, Empfehlung oder Tool-Nutzung zu verändern. Gegenmaßnahme: abgerufene Inhalte als Daten isolieren, Tool-Autorität von der Inferenz trennen und strukturierte Allow-List-Eingaben verwenden.
Überprivilegierte Identität: Ein für Telemetrie vorgesehenes Konto kann auf einen Controller schreiben. Gegenmaßnahme: Identitäten je Ebene trennen, Least Privilege auf Protokoll- und Netzebene durchsetzen und verweigerte Writes testen.
Inferenz- oder Netzausfall: Eine Cloud-Abhängigkeit verzögert eine Entscheidung. Gegenmaßnahme: manuelle Betriebsanweisungen, lokale Alarme und deterministische Safety-Funktionen erhalten; der Ausfall muss in einen bekannten sicheren Workflow führen.
Schleichende Automatisierung: Aus einer Empfehlung wird durch Ausnahmen ein direkter Befehl. Gegenmaßnahme: Autoritätsmatrix versionieren, jede neue Aktionsklasse freigeben lassen und Rollback-Übungen durchführen.
Für Retrieval-spezifische Risiken behandeln Sie Dokumente und externe Signale nicht als Instruktionen. Das Muster beschreibt der Beitrag abgerufene Dokumente als nicht vertrauenswürdige Daten.
Reifegradmodell: erst Evidenz, dann Autorität
Stufe 0 ist Offline-Analyse mit historischen, anonymisierten oder replizierten Daten. Stufe 1 ist Shadow Inference: Empfehlungen werden geloggt, aber nicht angezeigt. Stufe 2 ist Beratung: Eine Person sieht Evidenz, Konfidenz und Handlungsvorschlag. Stufe 3 ist freigabegebundene Ausführung über ein enges Gateway. Stufe 4 ist gegebenenfalls begrenzte Automatisierung in einer separat entwickelten Betriebshülle mit unabhängigen Interlocks. Für jede Hochstufung brauchen Sie gemessenen Nutzen und eine dokumentierte Ausfallreaktion, nicht nur eine überzeugende Demo.
Was dieser Ansatz nicht löst
Segmentierung und Freigaben begründen weder funktionale Safety Compliance, noch zertifizieren sie ein KI-Modell oder bestimmen rechtliche Pflichten. Safety Case, sektorale Vorgaben, Maschinenrecht, Verträge und lokale Betriebsanweisungen gehören zu den verantwortlichen Engineering- und Rechtsfunktionen. Das BSI betont, dass die gemeinsame Leitlinie KI nutzen will, ohne Verfügbarkeit, Security oder funktionale Sicherheit zu gefährden, und Rollen, kontinuierliches Testen, Monitoring sowie erweiterte Incident-Response-/Safety-Prozesse fordert. Die BSI-Mitteilung zur gemeinsamen Leitlinie ist ein sinnvoller deutscher Einstieg, ersetzt diese Prüfung aber nicht.
Praktischer Start für einen Architekturworkshop
Zeichnen Sie einen konkreten Use Case vom Sensor bis zum Aktor auf. Erfassen Sie jeden Datenfluss, jede Identität, jedes Protokoll, jede Zone, jedes Modellrelease, jede menschliche Entscheidung und jeden möglichen Schreibpfad. Prüfen Sie danach nachweisbar, dass eine KI-Identität weder SPS noch SIS ansteuern kann und dass Bedienpersonal auch bei ausgefallener Inferenz sicher arbeiten kann. Daraus entsteht ein priorisierter Kontroll-Backlog, bevor Beschaffung oder Pilotierung ausgeweitet werden.
Quellen
CISA et al., Principles for the Secure Integration of AI in OT
NIST, SP 800-82 Rev. 3: Guide to OT Security
BSI, Künstliche Intelligenz sicher in Industriesteuerungen integrieren
