Kann ein KI-Agent einen Roboter sicher steuern? Grenzen, die vor dem Code feststehen müssen

Kurz gesagt: Ein KI-Agent kann Aufgaben vorschlagen, Alarme erklären und Bedienpersonen unterstützen. Seine Ausgabe darf jedoch niemals die deterministische Steuerung, Sicherheitsfunktionen oder die Risikobeurteilung der Maschine ersetzen.

Warum eine flüssige Antwort kein Steuersignal ist

Ein großes Sprachmodell erzeugt eine plausible Fortsetzung seiner Eingabe. Dieselbe Anfrage kann unterschiedliche Ausgaben liefern, die Antwortzeit ist nicht verbindlich begrenzt, und auch eine selbstsicher formulierte Antwort kann falsch sein. Roboterbewegungen benötigen gegenteilige Eigenschaften: Bei gleichen Eingangsbedingungen muss innerhalb einer bekannten Zeit dasselbe überprüfbare Verhalten entstehen. Entscheidend ist deshalb, welche Entscheidungen ein Agent beeinflussen darf — und welcher Mechanismus jede davon prüft.

Dem Agenten begrenzte, ausdrückliche Befugnisse geben

Eine vertretbare Rolle besteht darin, Anfragen einzuordnen, aus vorab freigegebenen Rezepten auszuwählen, einen Parametersatz vorzuschlagen oder einen Alarm zu erklären. Zwischen Agent und Maschine liegt eine Autorisierungsschicht aus gewöhnlicher, prüfbarer Software. Sie kontrolliert, wer die Anfrage stellt, ob die Aktion ausdrücklich erlaubt ist, ob sämtliche Parameter innerhalb validierter Grenzen liegen und ob Zustand sowie Betriebsart der Zelle die Ausführung zulassen. Alles, was eine Prüfung nicht besteht, wird abgewiesen und protokolliert, nicht nachträglich „interpretiert“. Der Agent macht Vorschläge; er schreibt niemals unmittelbar in Robotersteuerung oder SPS.

Steuerung und Sicherheit deterministisch halten

SPS und Robotersteuerung behalten die Verantwortung für Abläufe, Verriegelungen, Bewegungen, Zeitüberwachungen und die Wiederaufnahme nach Störungen — genauso wie in einer Zelle ohne KI. Sicherheitsfunktionen wie Not-Halt, Schutztürverriegelung sowie sichere Geschwindigkeits- und Raumbegrenzung werden mit sicherheitsgerichteter Hard- und Software umgesetzt. Ihr erforderliches Leistungsniveau ergibt sich aus der Risikobeurteilung der konkreten Anwendung. ISO 10218-2 legt internationale Sicherheitsanforderungen an Roboteranwendungen und Roboterzellen fest; dieser Artikel gibt sie nicht wieder. Generierter Text ist kein Eingang dieser Funktionen, und kein Agent darf sie stummschalten, umgehen oder umkonfigurieren. Verändert der Agent die Zusammenarbeit zwischen Menschen und Zelle, müssen die Verantwortlichen die Risikobeurteilung überprüfen. Der Agent verkürzt diese Arbeit nicht.

Prompts, Dokumente und Werkzeuge als nicht vertrauenswürdige Eingaben behandeln

Ein Agent liest Texte, die nicht vom Projektteam stammen: Webseiten, E-Mails, Protokolle oder Bedienernotizen. Jeder dieser Texte kann versehentlich oder absichtlich Anweisungen enthalten; dieses Problem wird als Prompt Injection bezeichnet. Rechnen Sie damit: Trennen Sie abgerufene Inhalte von authentifizierten Befehlen, geben Sie dem Agenten möglichst wenige Werkzeuge und lassen Sie jeden folgenreichen Schritt von einer benannten Person freigeben. Protokollieren Sie jeden Vorschlag zusammen mit der Entscheidung der Autorisierungsschicht. Testen Sie anschließend die Fehlerfälle, bevor ein Versuch an realer Ausrüstung beginnt: veraltete Sensorwerte, doppelte Befehle, fehlerhafte Zielangaben, Netzwerkausfall, widersprüchliche Ziele und einen menschlichen Eingriff während des Zyklus. Halten Sie für jeden Fall die erwartete Ablehnung oder Rückfallreaktion fest, nicht nur den erfolgreichen Ablauf.

Checkliste vor Budget- oder Auftragsfreigabe

• Schriftlich festlegen, was der Agent vorschlagen darf und was er niemals tun darf.
• Zwischen Agent und SPS eine Autorisierungsschicht für Identität, erlaubte Aktionen, Parametergrenzen und Zustandsprüfung vorsehen.
• Sicherheitsfunktionen unabhängig von allen KI-Komponenten umsetzen und validieren.
• Das Verhalten bei langsamen, fehlenden oder falschen Agentenantworten definieren: Zeitgrenzen, Rückfallverfahren und Bedienerbefugnisse.
• Prompt Injection und fehlerhafte Befehle zunächst in der Simulation oder an einer vom Prozess getrennten Steuerung testen.
• Vorschläge, Freigaben und Ablehnungen nachvollziehbar protokollieren; eine verantwortliche Person für die Auswertung benennen.

Was dieser Leitfaden nicht nachweist

Dies ist eine Planungshilfe, kein Prüfbericht, keine Sicherheitsvalidierung, kein Rechtsgutachten und keine Produktzertifizierung. Sie ersetzt nicht die Risikobeurteilung Ihrer Maschine. Das NIST AI Risk Management Framework ist eine freiwillige Orientierung, keine Norm zur Maschinensicherheit. Architektur und Sicherheitsfunktionen einer realen Zelle müssen von den dafür verantwortlichen fachkundigen Personen ausgelegt und validiert werden.

Quellen und weitere Prüfung

• ISO — ISO 10218-2:2025, Robotik — Sicherheitsanforderungen — Teil 2: Industrieroboteranwendungen und Roboterzellen (2025-02; abgerufen am 2026-10-11).
• NIST — AI Risk Management Framework (AI RMF 1.0), Core: Govern, Map, Measure, Manage (2023-01; abgerufen am 2026-10-12).
• OSHA — Robotik: Übersicht (ohne Datum; abgerufen am 2026-10-12).

Der nächste sinnvolle Schritt

Für eine KI-Erweiterung einer vorhandenen oder geplanten Zelle sollten Sie zunächst die erlaubten Vorschläge und die Prüfungen für jeden davon aufschreiben. Diese Liste und die Schnittstellenübersicht bilden die Grundlage für den Einstieg über die Seite Robotik und Automation. Daraus entstehende Projekte werden über Eurobots/ReBots abgegrenzt und umgesetzt. Sie beginnen mit Machbarkeit und klaren Verantwortungsgrenzen, nicht mit einer vorausgesetzten schlüsselfertigen Installation. Das AYXWORKS-Portfolio beschreibt den technischen Hintergrund dieser Leitfäden.