Can an AI Agent Control an Industrial Robot Safely? Draw the Boundaries

In brief: An AI agent can propose tasks, explain alarms and assist operators, but its output must never replace deterministic control, safety functions or the machine risk assessment.

Why a fluent answer is not a control signal

A large language model generates the most plausible continuation of its input. The same request can produce different outputs, the response time is not bounded, and a confidently worded answer can be wrong. Robot motion needs the opposite properties: the same input must produce the same, verifiable behaviour within a known time. The question is therefore which decisions an agent may influence, and which mechanism checks every one of them.

Give the agent limited, explicit authority

A defensible role for an agent is to classify a request, choose among pre-approved recipes, draft a parameter set or explain an alarm. Between the agent and the machine sits an authorization layer that is ordinary, testable software: it checks who is asking, whether the operation is on the list of permitted actions, whether every parameter is inside validated bounds, and whether the cell is in a state and operating mode in which the request is allowed. Anything that fails a check is rejected and logged; it is never “interpreted”. The agent proposes; it never writes directly to the robot controller or the PLC.

Keep control and safety deterministic

The PLC and the robot controller keep ownership of sequences, interlocks, motion, timeouts and recovery after a fault, as in a cell with no AI. Safety functions — emergency stop, guard interlocking, speed and space limiting — are implemented in safety-rated hardware and software whose required performance is derived from the risk assessment of the specific application. ISO 10218-2 is the international standard that sets safety requirements for robot applications and robot cells; this article does not reproduce them. No generated text is an input to those functions, and no agent can mute, bypass or reconfigure them. If adding the agent changes how people interact with the cell, the risk assessment has to be reviewed by the people responsible for it; the agent does not shorten that work.

Treat prompts, documents and tools as untrusted input

An agent reads text that nobody on the project wrote: web pages, e-mails, log entries, operator notes. Any of them may carry instructions, by accident or on purpose; this is known as prompt injection. Assume it will happen: keep retrieved content separate from authenticated commands, give the agent as few tools as possible, require a named person to approve every consequential step, and log each proposal together with the decision of the authorization layer. Then test the failure cases before any trial on real equipment: stale sensor values, duplicated commands, malformed targets, network loss, contradictory goals and a person intervening in mid-cycle. For each one, write down the expected rejection or fallback behaviour, not only the successful path.

Checklist before committing budget or scope

• A written list of what the agent may propose and of what it may never do.
• An authorization layer between agent and PLC: identity, list of permitted actions, parameter bounds and state checks.
• Safety functions implemented and validated independently of any AI component.
• Defined behaviour for when the agent is slow, unavailable or wrong: timeouts, fallback and operator authority.
• Injection tests and malformed-command tests, run first in simulation or on a disconnected controller.
• An audit log of proposals, approvals and rejections, with a named owner who reviews it.

What this guide does not establish

This is a planning aid. It is not a test report, a safety validation, a legal opinion or a product certification, and it does not replace the risk assessment of your machine. The NIST AI Risk Management Framework is voluntary guidance, not a machinery safety standard. The architecture and the safety functions of a real cell must be designed and validated by the competent people responsible for it.

Sources and further verification

• ISO — ISO 10218-2:2025, Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells (2025-02; accessed 2026-10-11).
• NIST — AI Risk Management Framework (AI RMF 1.0), Core: Govern, Map, Measure, Manage (2023-01; accessed 2026-10-12).
• OSHA — Robotics: Overview (undated; accessed 2026-10-12).

Next useful step

If you are considering an AI layer on an existing or planned cell, start by writing the list of permitted proposals and the checks behind each one, and bring it, together with your interface list, to the Robotics & Automation page. Projects that start there are scoped and delivered through Eurobots/ReBots, and they begin with feasibility and responsibility boundaries, not with an assumed turnkey installation. The AYXWORKS portfolio shows the engineering background behind these guides.