Bevor Ihre Agenten Motoren schalten: Ein CTO‑Sicherheitsnachweis für AI‑to‑IO

Anthropic hat gerade einen Hardware‑Standard vorgestellt, der AI‑Agenten die Steuerung der physischen Welt ermöglicht. Auf diesen Moment haben viele Teams gewartet – „endlich kann unser Lager‑Bot den echten Knopf drücken“. Es ist auch der Moment, in dem sich viele CTOs weh tun werden. Der Fehlermodus hier ist keine kaputte UI; es ist die Palette auf dem Boden, die trockenlaufende Pumpe oder eine Klage.

Wenn Sie Agenten an I/O – Relais, Motoren, Ventile – anschließen wollen, brauchen Sie einen Sicherheitsnachweis, keinen Demo. Dieser Beitrag liefert Ihnen einen Entscheidungsrahmen, um die Grenze zwischen Autonomie und Steuerung zu ziehen, drei unabhängige Interlocks zu verdrahten, Latenzen sauber zu budgetieren, mit einem Zwilling zu testen, bevor Sie Metall berühren, und einen manipulationssicheren Audit‑Trail auszuliefern. Wir bleiben herstellerneutral, benennen aber die Realität: Sie überbrücken moderne Agent‑Stacks (MCP, ROS 2, gRPC) mit alter, aber verlässlicher Anlagentechnik (OPC UA, Modbus/TCP, EtherCAT, Sicherheits‑SPS).

Die rettende Grenze: Agent vs. Steuerung

Die meisten Teams bauen die Architektur falsch, indem sie den Agenten die Anlage direkt „fahren“ lassen. Tun Sie das nicht. Der Agent schlägt vor; eine zertifizierte Steuerung entscheidet. Diese Grenze ist Ihre juristische, betriebliche und moralische Sicherheitslinie.

So sollten Sie sie ziehen:

• Agentenschicht (nicht zertifiziert, adaptiv): Plant Aufgaben und schlägt Intents vor wie „Förderband A 12 Sekunden lang mit 40 % bewegen“ oder „Einlassventil B öffnen, bis der Füllstand 70 % erreicht“. Sie toggelt nie ein GPIO und schreibt keine Coils direkt.
• Befehls‑Hülle (deterministisch, filterbar): Validiert, formt und rate‑limitiert Intents. Denken Sie an einen Kernel für Aktorik: einheitenbewusst, mit Grenzprüfungen, ruckbegrenzt. Kann die Hülle Sicherheit nicht belegen, verweigert sie den Befehl.
• Anlagensteuerung (zertifiziert, echtzeitfähig): Eine SPS/Antrieb/Robotersteuerung betätigt tatsächlich Motoren und Ventile. Sie erzwingt harte Interlocks und Invarianten in Millisekunden‑Zyklen und wechselt bei Kommunikationsverlust in einen sicheren Zustand.

Agenten leben außerhalb der Sicherheitsgrenze. Ihre Steuerung und das Sicherheitssystem leben innerhalb. Das ist die Linie, die Ihre Juristen, Auditoren und Ihr Ops‑Team verteidigen können.

Sicherheitsrestriktionen ausführbar machen

Richtlinien gehören in Code, nicht in ein PDF. Sie brauchen maschinenprüfbare Invarianten im Befehlsweg – bevor überhaupt eine SPS Befehle sieht. Beispiele:

• Wechselseitiger Ausschluss: „Vorwärts‑ und Rückwärts‑Schütze für Motor M dürfen niemals gleichzeitig angesteuert werden.“
• Ratenlimits: „Förderbandgeschwindigkeit um ≤ 10 % pro Sekunde ändern; absolut max. 60 % in Zonen mit Mensch‑Maschine‑Mischbetrieb.“
• Zustands‑Wächter: „Ventil B nicht öffnen, es sei denn Druck P < 1,2 bar und Temperatur T < 40 °C.“
• Energielimits: „TCP‑Geschwindigkeit des Roboters muss ≤ 250 mm/s bleiben, solange Sicherheits‑Scanner Zone 2 belegt ist.“

Repräsentieren Sie die Constraints als domänenspezifischen Regelsatz, der zu Laufzeitprüfungen kompiliert wird. Sie brauchen zum Start keine formalen Methoden; eine sichere Hülle lässt sich mit Zustandsdiagrammen und einigen wenigen Prädikaten durchsetzen. Behandeln Sie sie aber wie eine Steuerung: Property‑Tests schreiben, Diskontinuitäten fuzz‑testen und, wo möglich, Monotonie nachweisen.

Drei Interlocks, unabhängige Pfade

Ein „Wir haben einen Not‑Aus“ reicht nicht. Sie wollen überlappende, diverse Verteidigungen, sodass eine einzige Fehlerklasse Sie nicht ausknocken kann.

1) Policy‑Gate (wer darf was)

• Allowlist statt Prompts: Der Agent darf nur benannte Skills mit typisierten Argumenten aufrufen. Keine freiformatigen Aktuator‑Strings.
• RBAC + Zeitgrenzen: Bestimmte Skills (z. B. „Ätzendes Ventil öffnen“) erfordern erhöhte Rollen und explizite zeitlich befristete Freigabe. Verankern Sie das Vier‑Augen‑Prinzip für Policy‑Änderungen.
• Befehlsbudgets: Pro Schicht oder Rezept die Anzahl risikoreicher Aktuationen und die Einschaltdauer begrenzen. Sie sollten beantworten können: „Wie oft haben wir dieses Ventil in den letzten 24 h geöffnet?“

2) Physics‑Gate (die Hülle)

• Mit Einheiten geprüfte, ruckbegrenzte Befehle: Befehle tragen Einheiten und werden automatisch geformt (z. B. S‑Kurven‑Profile), um Transienten zu vermeiden.
• Invariantprüfungen mit Sensorbestätigung: Die Hülle verweigert die Ausführung, wenn erforderliche Sensoren degradiert, veraltet oder widersprüchlich sind.
• Watchdog + begrenzter Horizont: Agent‑Intents müssen eine klare Endbedingung haben. Wird sie nicht erfüllt, bricht die Hülle ab und fällt in einen bekannten Zustand zurück.

3) Plant‑Gate (Sicherheits‑SPS/Relais)

• Hartverdrahtete Not‑Aus‑Schalter und Sicherheits‑Scanner: Kategorie 3/4‑Schaltkreise gemäß ISO 13849, Öffner‑Verdrahtung und Sicherheitsrelais, die energielos sicher schalten.
• Safe Torque Off (STO): Für Antriebe und Roboter IEC 61800‑5‑2‑Funktionen nutzen, wo verfügbar.
• Unabhängig getakteter Watchdog: Wenn die Steuerung einen Heartbeat (z. B. 100 ms) von der Hülle verpasst, wechselt sie in einen sicheren Zustand – ohne Ausreden.

Diese Pfade sollten, wo praktikabel, technologisch divers sein: Eine LLM‑Policy‑Schicht kann unabhängig von einem SPS‑Firmware‑Bug oder einem verschweißten Sicherheitsrelais ausfallen.

Latenzbudgets, die niemanden verletzen

Aktorik ist keine Chat‑Completion. Machen Sie Zahlen fest – oder liefern Sie nicht aus.

• Geschlossene Regelkreise: 1–5 ms Zyklen für Servobewegungen; 5–20 ms für typische SPS‑Logik. Das ist kein Agenten‑Terrain.
• Logistik im Menschentempo: Förderbänder und Pick‑Lights: 50–200 ms Round‑Trip sind akzeptabel. Ihre Hülle + SPS müssen den gesamten Jitter darunter halten.
• Netzwerkrealitäten: LAN‑OPC‑UA‑Round‑Trips liegen oft bei 5–15 ms; Cross‑Region‑Cloud‑RTTs können 60–120 ms mit dicken Tails haben. Legen Sie niemals sicherheitskritische Entscheidungen über ein WAN.
• Heartbeats und Timeouts: 100 ms Heartbeat von der Hülle zur SPS; 300–500 ms Timeout auf Fail‑Safe. In beide Richtungen loggen.

Faustregel: Hülle und Anlagensteuerung gehören co‑lokal an den Edge. Agenten können im Backoffice oder auf einem nahen Edge‑Knoten laufen, aber die letzten 10 ms Steuerung dürfen nicht über das öffentliche Internet gehen.

„Human in the loop“ ist keine Sicherheitsstrategie

HITL ist eine Governance‑Schicht, kein Regelkreis. Ein Mensch kann nicht zuverlässig im 200‑ms‑Takt bestätigen, dass Befehle keine Druckgrenze verletzen. Nutzen Sie menschliche Prüfung für Policy (z. B. „Rezeptänderung freigeben“) und Intent (z. B. „nach der Schicht einplanen“), nicht um sich per Button‑Mashing zur Sicherheit durchzuklicken.

Testen wie in der Luft‑ und Raumfahrt: SIL, HIL und Zwillinge

Nicht an der echten Anlage lernen. Nutzen Sie:

• Software‑in‑the‑Loop (SIL): SPS‑Logik, Hüllen‑Code und Agentenpläne gegen ein Anlagenmodell simulieren. Für Robotik: ROS 2 + Gazebo oder Webots; für SPS: Herstellersimulatoren (PLCSIM, CODESYS) oder ein gemockter OPC‑UA‑Server.
• Hardware‑in‑the‑Loop (HIL): Echte Steuerungen über I/O‑Emulatoren an eine simulierte Anlage verkabeln. Watchdogs, STO und Not‑Ketten validieren. Nachweisen, dass das System sicher in den Zustand fällt, wenn Sie Kabel ziehen.
• Digitale Zwillinge mit Fault‑Injection: Szenarien wie „Ventil klemmt“ oder „Sensor driftet“ skripten. „Sensor stale > 200 ms“ als erstklassigen Fehler behandeln, nicht als Randfall.

Machen Sie das Exit‑Kriterium explizit: „Kein Befehl erreicht einen realen Aktor, bevor nicht SIL‑Tests 95 % des erreichbaren Zustandsraums abdecken und HIL‑Tests alle Kategorie‑A‑Gefährdungen.“

SIL, nicht Vibes: Welchen Standard peilen Sie an?

Wenn Sie in regulierten Branchen arbeiten, sprechen Ihre Auditoren IEC 61508/61511 (Prozess), ISO 13849 (Maschinen) oder UL 4600 (Autonomie). Sie müssen den Agenten nicht zertifizieren, aber Sie müssen Ihre Hülle und die Anlagen‑Gates auf die geforderten Safety Integrity Levels (SIL) bzw. Performance Levels (PL) abbilden.

• Ziele im kontinuierlichen Modus (IEC 61508 PFHd): SIL 1: 1e‑6–1e‑5 gefährliche Ausfälle/Stunde; SIL 2: 1e‑7–1e‑6; SIL 3: 1e‑8–1e‑7. Die meisten Brownfield‑Logistik‑Szenarien zielen für spezifische Sicherheitsfunktionen auf SIL 1–2.
• Diagnostik zählt: Sie heben PL/SIL nicht nur mit stärkerer Hardware an, sondern mit besserer Diagnosedeckung und Testintervallen. Die Selbsttests Ihrer Hülle zählen.
• Den Sicherheitsnachweis dokumentieren: Gefährdungsanalyse (HAZOP/STPA), Safety‑Requirements‑Allokation, Verifikationsmatrix und Evidenz. Bauchgefühl besteht keine Audits.

Befehlsverträge: Intents, Acks und gemessene Effekte

Jede Aktuation sollte vom Intent bis zum gemessenen Effekt mit expliziten Acks nachvollziehbar sein:

1. Intent erstellt: Agent schlägt Actuate(ConveyorA, speed=0.4, duration=12s) vor
2. Hülle akzeptiert/verweigert: Validiert, in sicheres Profil geformt oder mit Begründung abgelehnt
3. Steuerungs‑Ack: SPS akzeptiert oder verweigert; Code‑Pfad loggen
4. Telemetrie‑Abschluss: Sensoren bestätigen den gewünschten Zustand (z. B. Drehzahlsensor ~0,4 innerhalb Toleranz). Wird er in T Sekunden nicht erreicht, Incident auslösen und in den sicheren Zustand zurückrollen

Befehle, die nicht zu einem messbaren, rechtzeitigen Effekt führen, sind nicht „fertig“. Sie sind Anomalien und fließen in Ihre MTTR‑ und Incident‑Metriken ein.

Audit, mit dem Sie vor Gericht bestehen

Wenn etwas schiefgeht, streiten Sie nicht mit einem Ingenieur; Sie streiten mit einem Versicherer oder einem Regulator. Ihre Logs müssen manipulationssicher und vollständig sein:

• Append‑only‑Speicher: WORM‑Buckets oder ein Merkle‑verkettetes Log pro Edge‑Knoten. Hash‑Snapshots alle N Minuten in ein separates System schreiben.
• Hochaufgelöste Telemetrie: 50–100 Hz Erfassung relevanter Sensoren/Aktoren während aktiver Aufträge. Im Idle gröber, um Kosten zu steuern.
• Reproduzierbarkeit: Aus einem Log‑Segment lässt sich die Entscheidung der Hülle, der SPS‑Programmpfad und der resultierende Anlagenzustand rekonstruieren.
• Attribution: Agent‑ und Hülle‑Binärdateien signieren, Modellversion/Weights‑Hash, Skill‑Katalog‑Version und SPS‑Firmware‑Prüfsumme für jeden Lauf aufzeichnen.

Brownfield‑Integration ohne Illusionen

Ihre Anlage spricht vermutlich OPC UA, Modbus/TCP, Profinet, EtherNet/IP oder EtherCAT. Ihr Agent‑Stack spricht vermutlich gRPC oder ROS 2 (DDS). Erzwingen Sie keine Neuverkabelung, nur um „modern“ zu sein.

• Brücken, nicht neuschreiben: Ein dünnes, testbares Gateway bauen, das typisierte Intents in Steuerungsaufrufe übersetzt. Verantwortung auf Serialisierung, Zeitsynchronisation und Retries begrenzen.
• Taktdisziplin: PTP oder mindestens NTP mit Monitoring einsetzen; Ihre Hülle und SPS sollten sich auf wenige Millisekunden einigen.
• Graceful Degradation: Bei Netzwerktrennung führt die Steuerung das letzte sichere Rezept weiter aus oder geht in sicheren Leerlauf. Der Agent hat kein Vetorecht.

Organisation: Neugier von Steuerung trennen

Conways Gesetz ist ein Sicherheitsrisiko. Wenn dasselbe Team, das Prompts feinjustiert, auch anlagenseitigen Code ausrollen kann, liefern Sie einen Demo in Produktion. Setzen Sie Grenzen:

• Safety Owner: Eine klar verantwortliche Person für Hülle und Anlagen‑Gates. Behandeln Sie die Rolle wie „SRE für Physik“.
• Change Control: Vier‑Augen‑Prinzip für Änderungen an Sicherheitsrichtlinien; Produktions‑Simulatoren für Trockenläufe; jede Änderung bekommt ein Hazard‑Diff.
• Red‑Team‑Drills: Vierteljährliche Übungen, in denen Sie Netzwerklinks kappen, Sensoren fehlinjizieren und schlechte Intents einspeisen. Erkenn‑ und Erholzeiten messen.

Wenn Sie schnell Domänenexpertise brauchen, können Nearshore‑Mechatronik‑Teams wirklich etwas bewegen. Brazil allein bringt jedes Jahr Tausende Regelungs‑ und Elektroingenieure hervor und hat dank seiner Fertigungsbasis einen tiefen Pool an SPS‑Integratoren. Mit 6–8 Stunden Überlappung kann ein Nearshore‑Team aus Brazil OPC‑UA‑Gateways verdrahten, die Invariantenbibliothek Ihrer Hülle bauen und HIL‑Testrigs 20–30 % günstiger als US‑onshore liefern – ohne Zeitzonen‑Schmerz.

Kaufen vs. bauen: Wo der Hebel ist

Bauen Sie die Hülle; kaufen Sie den Rest, wo es Sinn macht.

• Kaufen: Sicherheits‑SPS/‑relais und Antriebe mit STO; Lichtvorhänge/Scanner; Feldbus‑Adapter; hersteller‑unterstützte OPC‑UA‑Server; sichere Remote‑Access‑Gateways.
• Bauen: Domänenspezifische Befehls‑Hülle mit Invarianten; Simulationsmodelle und HIL‑Harnesses; Policy‑Gate und Audit‑Pipeline; typisierter Skill‑Katalog mit Signaturen.
• Wiederverwenden: ROS 2 als Robotik‑Middleware; OPC UA für Informationsmodelle; protobuf/gRPC für Skill‑Definitionen; bestehende Anlagenprogramme mit erprobter Logik.

Ein pragmatischer 90‑Tage‑Plan

Tage 0–30: Grenze ziehen und simulieren

• Aktoren und Gefährdungen inventarisieren; eine einseitige Hazard‑Zusammenfassung (Top‑10‑Fehlermodi) schreiben.
• 10–20 Invarianten als Code in einer Hüllen‑Stub definieren; an einen Simulator anbinden (Gazebo/Webots/PLCSIM/gemocktes OPC UA).
• Append‑only‑Logging mit Modell/Versions‑Attestierung aufsetzen.
• Edge‑Platzierung entscheiden; einen Industrial PC mit Dual‑NICs und PTP‑Zeitsync bereitstellen.

Tage 31–60: Echte Steuerungen und Interlocks verdrahten

• Integration mit einer echten SPS auf dem Prüfstand (HIL). Watchdogs und STO‑Verhalten durch Kabelziehen nachweisen.
• Policy‑Gate implementieren: Allowlist‑Skills, RBAC, zeitlich befristete Freigaben.
• 20–30 SIL‑Tests und 10 HIL‑Fault‑Injection‑Szenarien schreiben. Produktionshardware weiterhin nicht anfassen.

Tage 61–90: Pilot in einer abgesperrten Zelle

• Bereitstellung in einer einzelnen, abgegrenzten Zelle mit harten Not‑Aus und Sicherheits‑Scannern.
• Überwachte Schichten fahren, in denen Agenten Intents vorschlagen; die Hülle führt unter strikten Budgets aus.
• 2–4 Wochen Logs sammeln, Invarianten tunen und einen Sicherheitsnachweis v1 für den Pilotumfang veröffentlichen.

Was der Schritt von Anthropic tatsächlich ändert

Der „Hardware‑Standard für Agenten“ von Anthropic ist ein positives Signal: Das Ökosystem erkennt den Bedarf an einer gemeinsamen Control‑Plane zwischen AI und I/O an. Nutzen Sie das – aber verwässern Sie Ihre Grenzen nicht. Eine standardisierte Skill‑API oder ein GPIO‑Hub ersetzt weder Ihre Hülle, noch Ihre Interlocks, noch Ihren Audit‑Trail. Im Gegenteil: Es erleichtert Ihre Arbeit, weil Sie Ihre Ingenieursleistung auf den Sicherheitsnachweis statt auf Treiber‑Kleinarbeit fokussieren können.

Ausfälle, die Sie vermeiden können

• Der optimistische Watchdog: Ein Startup ließ die SPS annehmen, die Hülle sei am Leben, solange man ihr nichts Gegenteiliges sagte; ein abgestürzter Prozess ließ eine Pumpe weiterlaufen. Drehen Sie das um: Standardmäßig sicher bei verpassten Heartbeats.
• Die unsichtbare Restriktion: Ein Team „wusste“, dass zwei Ventile nicht gemeinsam geöffnet werden dürfen, kodierte es aber nie; ein Agent „optimierte“ die Taktzeit und mischte Reagenzien. Wenn es wichtig ist, ist es eine Invariante.
• Der Cloud‑Reflex: Ein Logistik‑Bot hing von einem Cross‑Region‑Planfreigabeschritt ab; ein 40‑sekündiger Ausfall stoppte eine Linie und verwirrte Bediener. Halten Sie Sicherheit und kurzfristige Entscheidungen lokal.

Der langweilige Weg ist der schnelle

CTOs geraten in Schwierigkeiten, wenn sie neuartige Steuerungen jagen, wo langweilige Steuerung – mit echter Sicherheitsingenieurkunst – schneller ausgeliefert hätte und die Anlage am Laufen gehalten hätte. Ihr Agent muss kein Virtuose von Modbus‑Coils sein. Er muss ein guter Bürger sein, der klare Intents vorschlägt, Ablehnungen gelassen akzeptiert und das Harte – Echtzeit‑Sicherheit – den Systemen überlässt, die dafür gebaut sind.

Die wichtigsten Punkte

• Eine harte Grenze ziehen: Agenten schlagen Intents vor; zertifizierte Steuerungen führen innerhalb einer codierten Sicherheits‑Hülle aus.
• Drei unabhängige Interlocks implementieren: Policy‑Gate, Physics‑Gate (Hülle) und Plant‑Gate (SPS/Not‑Aus/STO).
• Latenzen realistisch budgetieren: Hülle und Steuerungen am Edge halten; niemals Sicherheitsentscheidungen über ein WAN legen.
• Testen, bevor Metall berührt wird: SIL für Logikabdeckung, HIL für echte Watchdogs/Interlocks und Zwillinge mit Fault‑Injection.
• Sicherheitsrestriktionen ausführbar machen: Invarianten (wechselseitiger Ausschluss, Ratenlimits, Zustands‑Wächter) kodieren und nicht verifizierbare Befehle verweigern.
• Einen belastbaren Audit‑Trail liefern: Append‑only‑Logs, hochfrequente Telemetrie während Jobs, vollständige Attribution von Modellen und Firmware.
• Für Sicherheit organisieren: Getrennte Teams für Agenten und Anlagensteuerung; Vier‑Augen‑Prinzip für Policy‑Änderungen; Red‑Teaming Ihrer Physik.
• Die Hülle bauen, die Sicherheitshardware kaufen und zu Brownfield‑Standards wie OPC UA und ROS 2 brücken.
• Nearshore‑Mechatronik‑Teams in Brazil können OPC‑UA‑Gateways, Invarianten und HIL‑Rigs mit 6–8 Stunden Überlappung 20–30 % günstiger als US‑onshore liefern.