Industrial Automation’s AI Integration Problem: Safety Standards Haven’t Kept Up

The factory floor has changed faster than the standards that govern it. Walk through a modern automotive assembly plant or a large-scale e-commerce fulfillment center and you will find AI-powered vision systems making real-time quality decisions, collaborative robots adjusting grip force based on learned material models, and autonomous mobile robots navigating shared human spaces through inference rather than fixed logic. These systems are deployed, operational, and generating business value.

The standards that were supposed to certify their safety were written before any of this was conceivable.

IEC 62061 — the dominant functional safety standard for machinery — dates to 2005 and was revised in 2021. ISO 10218 parts 1 and 2, which govern industrial robot safety, were last substantively revised in 2011. ISO/TS 15066, which specifically addresses collaborative robot operation and defined the contact force limits that still govern most cobot deployments today, was published in 2016. None of these documents anticipates a system whose behavior is a function of training data, whose failure modes are not enumerable at design time, and whose performance can degrade in unpredictable ways when encountering out-of-distribution inputs.

This is not a paperwork problem. It is a structural problem in how industrial safety certification works, and engineering teams are living inside it right now.

What the Existing Standards Actually Assume

To understand why the gap exists, it helps to understand what IEC 62061 and ISO 10218 actually require at a technical level.

IEC 62061 is a risk-reduction framework. It requires that a safety function be assigned a Safety Integrity Level (SIL 1, 2, or 3), which specifies a target probability of dangerous failure per hour. Achieving a given SIL requires a combination of hardware reliability (quantified via failure rates from databases like IEC 61508-2 or manufacturer data) and systematic capability (demonstrated through development process rigor). The entire architecture is built around the assumption that the system’s behavior is deterministic given its inputs: a safety relay either opens or it does not, a guard door either interlocks or it does not.

ML-based inference systems break this assumption completely. A vision-based presence detection system using a convolutional neural network does not have a calculable dangerous failure rate in the IEC 61508 sense. Its failure mode is not a hardware fault or a software bug in the traditional sense — it is a distributional mismatch between training data and operational environment. You cannot model that with a Markov chain.

ISO 10218 and TS 15066 have a different but related problem. TS 15066 defines four collaboration modes for human-robot interaction: safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting. Speed and separation monitoring, the mode most directly relevant to autonomous mobile robots and modern cobots, requires that the robot know where the human is and maintain a protective separation distance calculated from the system’s stopping time and the human’s maximum approach speed.

Current implementations of that mode increasingly rely on AI-based perception — stereo cameras, time-of-flight sensors, LiDAR point clouds processed through neural networks — to estimate human position. TS 15066 does not address how to validate the reliability of that perception. It specifies the geometry, not the detection confidence. The standard was written expecting the sensor to be a light curtain or a laser scanner with a defined detection capability specified in a product standard. A fine-tuned transformer network processing point cloud data has no equivalent specification.

Where Teams Are Deploying Ahead of Standards

Despite this gap, deployment is proceeding. The business case for AI automation in manufacturing is compelling enough that engineering teams are finding ways to move forward, using a combination of good engineering judgment, supplemental analysis, and tolerance for regulatory ambiguity that would not be comfortable to document explicitly.

The most common patterns:

Treating AI as a non-safety-rated subsystem. A vision system performing automated inspection is classified as a production system rather than a safety function. The safety function — stopping the line if a human enters a danger zone — remains entirely within a conventional, certified safety PLC using traditional sensors. The AI does not touch the safety layer. This works when the application genuinely allows that separation, and it works well. It fails when the whole value proposition of the AI system is to replace or augment the safety-relevant perception.

Using dual-channel architectures with AI in one channel. Some teams are implementing architectures where an AI-based perception system operates in parallel with a validated conventional sensor, and a safety-rated logic unit requires agreement between both channels before clearing a condition. This achieves architectural diversity but does not resolve the diagnostic coverage calculation problem — you cannot formally quantify how well the conventional sensor detects AI failures when AI failures are not modeled.

Assurance cases in lieu of standard compliance. Particularly in jurisdictions with goal-based rather than prescriptive safety frameworks, teams are building structured safety assurance cases using the Goal Structuring Notation (GSN) or Claims-Arguments-Evidence (CAE) format. This approach documents the safety argument explicitly — here is the claim, here is the evidence, here are the assumptions — and submits it to a notified body for evaluation. It is more defensible than ignoring the gap, and it is what aerospace and defense have used for decades when deploying novel system types. It is also significantly more labor-intensive than conforming to an existing standard, and it does not produce the clear regulatory coverage that a harmonized standard does.

What Industry and Standards Bodies Are Actually Doing

Progress is happening, but slowly relative to deployment rates.

ISO/TC 299, the technical committee responsible for robotics standards, is actively revising ISO 10218. The revision has been in progress since approximately 2018 and has faced repeated delays. Current expectations place the revised Part 1 and Part 2 publication in the 2026–2027 timeframe. The revised standard is expected to introduce a new concept — the validated safety function — that creates a pathway for certifying safety functions implemented in non-deterministic or software-intensive systems, but the normative details of what validation must demonstrate are still being debated within the working group.

IEC SC 65A, which owns IEC 61508 and IEC 62061, has been slower. There are published technical reports exploring AI and functional safety (IEC TR 5469 was published in 2024, addressing functional safety and the safety of AI systems) but these are informative, not normative. They describe the problem more than they solve it.

On the coalition side, the A3 Association (Association for Advancing Automation) has been active in coordinating industry positions and funding research into ML safety metrics that could eventually feed into normative requirements. The Manufacturing Leadership Council has published position papers. SICK, Pilz, and Rockwell Automation have each published their own technical white papers on AI safety in industrial contexts — useful engineering guidance, but not standards.

The EU Machinery Regulation (2023/1230), which replaced the old Machinery Directive and takes full effect in January 2027, explicitly acknowledges AI-controlled machinery as a category requiring attention and references the AI Act. But the practical implication — how a CE marking assessment is conducted for an AI-based collaborative robot — has not been worked out in harmonized standards. Notified bodies are developing their own internal approaches, which means the assessment your system receives will depend on which notified body you use.

The honest summary: the machinery safety standards landscape will not have coherent, normative guidance for ML-based safety functions before 2028 at the earliest. Engineering teams deploying AI automation today are doing so in a gap that will remain open for at least two to three years.

How Engineering Teams Are Managing Requirements and Safety Arguments Now

Given that the standards will not rescue you on schedule, the question becomes operational: how do you build a defensible safety case for an AI-integrated system today?

The teams doing this well share several practices.

Explicit hazard analysis that accounts for AI-specific failure modes. Traditional HAZOP and FMEA are necessary but not sufficient. ML systems require supplemental analysis — at minimum, an evaluation of what happens when the system encounters out-of-distribution inputs, what the distributional characteristics of the training data are relative to the operational environment, and what monitoring is in place to detect degradation. Some teams are adopting STPA (System-Theoretic Process Analysis), originally developed at MIT for complex sociotechnical systems, because it does not require enumerable failure modes and can capture emergent behaviors that FMEA misses.

Requirements traceability that reaches into the AI subsystem. This is where many teams are struggling most visibly. Conventional requirements management handles AI systems poorly because the behavior of the AI is not fully specified by requirements — it is also a function of the training process and the data. A safety requirement that says “the presence detection system shall detect a human in zone A with probability ≥ 0.999” cannot be verified the same way as a requirement on a light curtain response time. The evidence for that requirement is a combination of testing, simulation, operational monitoring, and engineering judgment, and all of that evidence needs to be traceable back to the requirement.

Tools built around document-based requirements management — where requirements live in a Word file or a static database — break down here because the traceability links are not live. When a model is retrained, or when operational monitoring reveals a distributional shift, there is no mechanism to propagate that information through the safety case automatically.

This is one of the practical problems that graph-based requirements management tools are better positioned to solve. Flow Engineering, for instance, represents requirements, evidence, and system architecture as connected nodes in a live model rather than as sections in a document. When an AI subsystem’s validation evidence changes — because the model was updated or because monitoring data flagged a performance change — the impact on connected safety claims is visible immediately rather than requiring a manual audit. For teams building GSN-based assurance cases, that kind of live connectivity between evidence and claims is the difference between a defensible safety case and a document that goes stale within weeks of being approved. Flow Engineering’s focus on hardware and systems teams rather than general software development also means its data model maps reasonably well to the IEC 62061 / ISO 10218 context, without requiring teams to force-fit their safety architecture into a framework designed for something else.

Operational monitoring as a safety argument element. Because pre-deployment validation cannot fully characterize ML behavior, the safety case increasingly needs to include a monitoring commitment: here is how we will detect degradation, here is what triggers a review or a system halt, here is how updates are controlled and re-validated. This is borrowed from aviation (the Permit to Fly model, where initial deployment carries operational limitations that are lifted as confidence accumulates) and pharmaceutical (post-market surveillance requirements). It does not map cleanly onto machinery safety traditions, but it is increasingly what notified bodies in Europe are asking for when they encounter AI-based safety claims.

The Honest Assessment

AI-powered automation is delivering real value in industrial environments, and deployment will continue regardless of the standards gap. The technology business case is too strong, and competitive pressure among manufacturers is too intense, for engineering teams to wait for ISO to catch up.

That does not mean the risk is being ignored. The better teams are doing serious engineering work — supplemental hazard analysis, structured assurance cases, operational monitoring programs — to manage safety arguments in the absence of normative guidance. The worse teams are making optimistic classification decisions to keep AI out of the formal safety layer, and hoping that the classification holds under scrutiny.

The standards bodies are moving. ISO 10218’s revision and whatever IEC 62061 eventually adds for AI will matter enormously when they arrive. But the 2026 factory floor will not wait for the 2028 standard, and the gap between them is where engineering rigor and tooling quality determine whether deployed AI systems are actually safe or merely deployed.

For engineering teams in this position, the practical priorities are: build your safety case in a form that survives model updates, treat monitoring as a safety requirement not an afterthought, and maintain traceability from your safety claims to your validation evidence in a system that stays live as the system evolves. The certification framework will eventually arrive. The safety argument needs to exist now.