Systems integration
Why the AI layer has to sit outside the safety-rated control loop
A machine's safety function runs on a certified, bounded response time. A model's inference time is neither certified nor bounded. Most of what gets called an AI integration challenge on the plant floor is really that mismatch, misdiagnosed as a data or model problem.
Executive summary
3
standards governing a machine's safety-related control system — none written with a model in mind
2
loops a well-integrated AI-assisted machine actually runs, kept deliberately separate
Core conclusions
- A certified safety function has to behave the same way, verifiably, every time — a model's inference time and output are neither fixed nor fully specified in advance.
- IEC 61508, ISO 13849-1 and IEC 62061 all require the safety-related control system to be independently verifiable, which is why the AI has to sit outside it, not inside it.
- The practical fix is architectural, not a better model: hardwired interlocks and E-stops keep the certified boundary; the AI stays supervisory and reaches an actuator only through a rated safety controller.
Ask what is stopping AI from running a piece of machinery and the answer usually comes back as a data problem or a model problem. On the floor it is neither. The machine's safety function and the AI's decision loop are governed by two different engineering disciplines, run on two different timing guarantees, and most integration proposals never draw the boundary between them.
That boundary is the actual challenge. Get it right and an AI layer can sit alongside a machine doing real work. Get it wrong — by letting a model's output reach an actuator directly — and the result cannot be certified, insured, or defended after an incident.
The timing mismatch
A safety-rated control system — the circuit that stops a press, drops a guard, or cuts power to a conveyor — has to respond within a bounded, tested time from the moment a hazard is detected. That response time is part of what gets verified during certification: fixed logic, on fixed hardware, with a known worst case.
Model inference does not offer that. Even a small model returns an answer somewhere in a range, not a guaranteed figure, and the range widens under load, on a cold start, or when the input falls outside what the model has seen before. A control loop built to a certified response time cannot wait on an answer that only ever arrives inside a range.
What the certification actually requires
Three standards cover most machinery in this position, and none of them were written with a model in mind:
- IEC 61508 sets the Safety Integrity Level for the electrical, electronic and programmable systems performing a safety function — verified against defined failure modes, not against 'usually correct'.
- ISO 13849-1 sets the Performance Level for the safety-related parts of a machine's control system, the standard most mechanical guarding and interlock circuits are certified against.
- IEC 62061 covers the same ground as ISO 13849-1 for more complex, programmable safety systems, where the logic is software rather than a hardwired relay.
- All three require the safety function's behaviour to be fully specified and independently testable — a requirement a model, whose output is drawn from a distribution rather than a fixed program, cannot meet on its own.
Where the AI actually belongs
None of this rules AI out of a mechanical system. It rules out one specific placement: inside the certified loop, with its output wired straight to an actuator. Everywhere else — flagging an anomaly, recommending a maintenance window, throttling a feed rate within limits a person already approved — the model does real, valuable work without ever being asked to meet a certification standard it structurally cannot meet.
The practical pattern is two loops, not one. The safety-rated loop stays hardwired: E-stops, interlocks, light curtains, running on logic that was verified once and does not change. The AI runs a separate, advisory loop alongside it, and anything it wants to act on passes through the rated safety controller rather than commanding the machine directly. The controller, not the model, remains the thing that was certified.
The retrofit adds its own constraint
On equipment that predates any of this, there is often no interface for the AI to read state from or request an action through, safety-rated or otherwise — the same gap we cover in retrofitting IoT onto legacy plant equipment. Wiring one in is its own small project, with its own certification and sign-off, before the model ever sees live data. Skipping that step to get a pilot running faster is how a supervisory system quietly ends up with more authority over the machine than anyone signed off on.
What to ask before commissioning it
- Ask the integrator to draw the boundary on paper: which functions stay hardwired and certified, and which run in the advisory layer.
- Confirm the model's output reaches the machine only through a rated safety controller, never through a direct command path.
- Check the response-time budget the certified loop was verified against, and confirm nothing in the new architecture asks it to wait on an inference.
- Where the asset is legacy equipment, treat the interface itself — the sensor, the relay, the wiring — as its own project with its own sign-off, not a detail folded into the AI scope.
That boundary, not the model's accuracy, is what usually decides whether an AI layer on a piece of machinery survives its first safety audit.
