Services
IEC 61508, the emerging AI-safety family and UL's certification standards are not three competing rulebooks. They are three views of the same question — can this robot hurt someone, and how do we know? Here is what each one covers, where the boundaries sit, and why the boundaries are the dangerous part.
Start here
The fastest way to know which framework applies is to ask what has to be true for a person to be harmed. The three answers below are mutually exclusive as causes — and jointly exhaustive as an argument.
Something in the electrical, electronic or programmable electronic safety-related system breaks or was built wrong — a random hardware fault, a systematic design fault, a software defect — and the resulting malfunction leads to a hazard.
The system is faulted. Remove the fault and the hazard disappears.
Nothing is broken. Every actuator responds correctly. The AI-enabled function is simply not reliable enough for the situation it meets, or it cannot say how confident it is when it should.
The system is fault-free. You cannot debug your way out; you have to improve the model, its data, or the way its uncertainty is used downstream.
The robot may genuinely be safe. But safety that lives in engineers' heads and passing test logs is not a certifiable argument — and a customer, insurer or certification body cannot act on a claim it cannot audit.
The system may be safe and fault-free, but the evidence is not organised into a case anyone outside the engineering team can evaluate.
Side by side
Print this and put it on the wall. Most cross-team arguments about "whose finding is this?" are resolved by the second row.
| Dimension | IEC 61508 Functional safety | TR 5469 · TS 22440 · TS 25223 AI safety | UL 4600 · UL 3115 Autonomy certification |
|---|---|---|---|
| Question answered | Does the safety-related control system fail dangerously? | Is the AI-enabled function trustworthy even when nothing fails? | Can the safety of the whole product be shown, not just claimed? |
| Cause of the hazard | Random hardware faults and systematic faults in hardware and software of the E/E/PE safety-related system | Data-driven, adaptive or non-deterministic behaviour of an AI/ML component used in or around a safety function | Absence of a structured, auditable argument connecting design, evidence and residual risk |
| System state | Faulted | Fault-free, but the learned behaviour may be miscalibrated or out of distribution | May be safe in practice — but unproven |
| Risk classification | SIL 1–4, derived from severity, exposure, avoidance and demand rate | AI-specific risk factors — robustness, explainability, adaptability — assessed against the allocated safety requirement | Not a classification scheme: an evaluation of the completeness and rigour of the safety case itself |
| Core technique | Safety functions, diagnostic coverage, hardware fault tolerance, systematic capability, safety management | AI-specific hazard and risk analysis, safety-requirement derivation for adaptive systems, model evaluation, uncertainty quantification | Goal-structured safety cases (UL 4600), and mapped safety criteria for AI-embedded and digital AI products (UL 3115) |
| Central evidence | SIL achieved vs SIL required, PFD/PFH figures, proof-test intervals | Documented AI risk treatment, calibrated confidence bounds, evaluation against the intended operational envelope | A complete, itemised safety case with explicit assumptions, plus a certification or investigation result |
| Typical failure it catches | A safety-rated stop function fails to trigger because a diagnostic test interval was set too long | A grasp-classification model is confidently wrong on an object shape it never saw in training | A robot passes every component test yet nobody can state the accepted residual risk |
| Primary artefact | Functional safety assessment report, SIL verification, safety manual | AI safety case addendum, model and dataset documentation, uncertainty and monitoring concept | The safety case document itself (UL 4600), and the AI-product certification record (UL 3115) |
| When it applies | Any E/E/PE safety-related control system — the default reference where no sector-specific derivative exists | Any robot with a machine-learned component contributing to safety-relevant behaviour | Any autonomous or AI-based product that needs to demonstrate — not just claim — its safety |
Scroll the table horizontally on narrow screens.
Why it matters
Each one was written because the previous one had run out of road. The sequence tells you exactly what each framework is blind to.
2010
IEC 61508 second edition — the generic functional safety baseline
2024
ISO/IEC TR 5469 published — AI functional safety guidance
2025
UL 3115 published — certification for AI-based products
Functional safety rests on a quiet assumption: that the correct behaviour of the system is fully specified, and the job of the safety lifecycle is to make the electronics deliver it reliably. For a safety-rated e-stop circuit or a fixed collision-avoidance interlock, that assumption holds — the logic is short, the inputs are bounded, and "correct" is unambiguous and testable line by line.
A robot that has to decide whether a shape on the floor is a pallet or a person breaks the assumption in exactly the way an automated vehicle does. The hard part is no longer delivering specified behaviour — it is knowing what the specified behaviour should be when the input space is effectively unbounded. IEC 61508 has no clause for a function that was implemented perfectly and is still wrong.
ISO/IEC TR 5469, published in 2024, was the first document to describe — at guidance level — the properties of AI systems that matter for functional safety, the risks they introduce, and candidate methods to treat them. It set the vocabulary rather than mandatory requirements.
ISO/IEC TS 22440 is the normative follow-on: a multi-part technical specification building directly on TR 5469, defining safety requirements for AI-enabled systems that adapt over time and how to integrate AI verification into the functional-safety lifecycle. Several parts are still in development at the time of writing — this is a standards family being written in real time, and we track it as it moves rather than waiting for a finished edition to start the conversation.
ISO/IEC TS 25223 narrows in on the single hardest sub-problem: how does a system know when it doesn't know? Uncertainty quantification is what separates a perception stack that fails loudly from one that fails silently and confidently.
The practical consequence. Under IEC 61508 you reduce risk with diagnostics and redundancy. Under the AI-safety family you reduce risk by improving the model, calibrating its confidence, or limiting what it is allowed to decide unsupervised. These are different engineering programmes with different budgets and different people in the room.
UL 4600 was written deliberately technology-agnostic: a safety case built from claims, arguments and evidence that applies as well to a delivery robot or an AMR fleet as it does to a self-driving car. It does not tell you how to build the robot — it tells you how to show that what you built is safe enough, and what is still open.
UL 3115, published in October 2025, is narrower and newer: an outline for the safety of AI-based products specifically, covering both AI-embedded products — autonomous robots among them — and pure digital AI products. It complements hardware and electrical safety rules rather than replacing them, and maps its criteria onto ISO, IEC and NIST frameworks so evidence built for one recognises the other.
None of this is optional once you want to sell or deploy. The EU's Machinery Regulation (EU) 2023/1230, applicable from January 2027, replaces the old Machinery Directive with an explicitly widened scope that names autonomous mobile machinery, AI-based safety systems, industrial robots and cobots. ISO 3691-4 and ANSI/RIA R15.08 set the acceptance bar for AGVs and industrial mobile robots in Europe and the US respectively.
None of these bodies receive three standards. They receive one argument. If your evidence is organised by standard rather than by hazard, you will spend the weeks before a customer audit or a certification submission re-organising it under pressure.
The ecosystem
There is only ever one hazard list. The standards do not partition the robot — they partition the causes. That single idea is what makes an integrated safety argument possible.
Each safety function gets a SIL. Diagnostics, redundancy and architectural measures reduce the probability that a fault produces the hazard.
The same safety functions are re-examined assuming zero faults. Model evaluation, calibrated uncertainty and monitoring bound the AI-related risk.
Where branches A and B produce evidence, this branch supplies the structure that turns evidence into a claim a certification body can evaluate.
The seams
In our experience the findings that hurt most are never inside one standard. They sit exactly on the boundary, where each team assumes the other one owns it.
Seam 01
A safety function is verified to SIL 2 against a requirement that quietly assumed the AI's classification would be reliable. Functional safety confirms the implementation; nobody confirms the AI's actual behaviour under that assumption.
Fix: derive AI safety requirements from the same hazard analysis and safety functions, in the same requirement baseline — not a parallel document set.
Seam 02
A model's evaluation report sits in a data-science folder while the safety case simply states "the AI was tested" — without saying what, how much, or against which acceptance criterion.
Fix: treat every model evaluation result as first-class safety-case evidence, traced explicitly to the claim it supports.
Seam 03
The safety case cites a hardware fault-tolerance figure that was never actually verified at the SIL claimed — the case looks complete on paper while the underlying functional safety verification is still open.
Fix: never close a safety-case item against evidence that hasn't itself been independently verified.
Practice areas
Each practice can be engaged on its own. All of them are written to land in the same safety case.
01 / Functional safety
Safety-related control system architecture, SIL determination, hardware fault metrics, systematic capability, and the functional safety case for the E/E/PE parts of a robotic or autonomous system.
02 / Artificial intelligence
AI risk analysis, safety requirements for adaptive and learned behaviour, model evaluation and calibrated uncertainty — from ISO/IEC TR 5469 guidance through to the emerging TS 22440 and TS 25223 specifications.
03 / Autonomy & certification
Safety-case-based evaluation of autonomous products and certification of AI-based products, mapped to the evidence a customer, insurer or certification body will actually accept.
Cross-cutting
The integration itself is a deliverable. These engagements are what turn three conformant workstreams into one argument.
Most teams we meet are strong in functional safety, competent in AI evaluation, and have never written the certification argument down. Let's find out which is which.