Practice 02 · Artificial intelligence
ISO/IEC TR 5469 · TS 22440 · TS 25223. You cannot review a neural network line by line, and you cannot test your way to confidence one scenario at a time. This is the standards family for arguing that a learned component is safe enough — with evidence the rest of the safety case can actually use.
Scope
This family addresses safety for AI within robotic and autonomous systems: the lifecycle, the evidence and the argument for components whose behaviour is learned from data rather than written as code.
It does not replace anything. It is designed to plug into IEC 61508 and UL 4600/3115 — supplying the component-level evidence they both assume somebody else is producing.
IEC 61508-3 is built on a chain of specification, design, implementation and verification, each reviewable against the one above. For a trained network, the middle of that chain does not exist. There is no line of code implementing "grasp the object correctly given this point cloud"; there is a weight tensor produced by an optimisation process over a dataset. Structural coverage of the inference code tells you almost nothing about whether the function is correct.
UL 4600 is closer, because a safety case already accepts that a function will be imperfect and reasons in terms of claims and evidence. But on its own it treats the AI component as a black box with observed performance — it does not tell you how to build a better box or what evidence is actually worth citing.
The specification moves the argument upstream, to the things that determine model behaviour before any test is ever run:
Where teams get caught. Model performance is usually measured well and documented badly. When an assessor asks which safety function a 0.94 mAP discharges, over which part of the task envelope, with what confidence — the number stops being evidence and becomes a slide.
The standards family
These three documents are not competitors — they are stages of the same effort, maturing at different speeds. We track all three, and we're honest about which are stable and which are still being written.
Describes the properties of AI systems that matter for functional safety, the risks they introduce, and candidate methods to treat them. Vocabulary and structure rather than mandatory requirements — published and stable, and the document most safety cases cite today.
A multi-part follow-on built directly on TR 5469 — defining safety requirements for AI-enabled systems that adapt over time, and how AI verification and validation integrate into the functional-safety lifecycle. Several parts are still approved work items rather than published text.
Guidance and requirements for uncertainty quantification in AI systems — how a model expresses, calibrates and acts on its own confidence. The difference between a perception stack that fails loudly and one that fails silently and confidently.
Lifecycle
Each stage produces evidence the next one depends on. Skip one and the argument has a hole you will find during certification rather than during development.
01 · Allocate
Take the safety functions from IEC 61508 and any task-level performance needs and turn them into requirements a model can be held to: what must be detected, classified or decided, under which conditions, and what happens when confidence is low.
02 · Specify data
Derive the required data distribution from the task envelope, not from whatever happens to be sitting in the training log. Define coverage dimensions, minimum representation for rare but safety-critical cases, and acceptance criteria for the dataset itself.
03 · Develop
Reproducible pipelines, controlled splits, versioned data and weights, documented architecture and hyperparameter decisions — the configuration management story that lets you say exactly which model is running on which robot.
04 · Evaluate
Evaluation stratified by the task and environment dimensions that matter, degradation curves at the edges of the operating envelope, robustness to sensor noise and occlusion, and an explicit list of identified insufficiencies.
05 · Contain
Uncertainty quantification, out-of-distribution detection, plausibility checks against known physical constraints, diverse redundancy, and the defined safety reaction when confidence collapses.
06 · Integrate
Quantisation, pruning and compilation change the function. Determinism, timing and accelerator fault behaviour bring the component back under IEC 61508 — this is where the two branches have to be reconciled, not assumed away.
07 · Operate
In-service performance monitoring, drift detection, incident triage into dataset or architecture changes, and an impact-analysis process for model updates that satisfies both the safety case and any fleet-wide rollout requirements.
08 · Argue
A structured argument from safety function to model evidence, with assumptions, context and an explicit residual risk claim — written so the item-level safety case, and your UL 4600 / UL 3115 evidence, can reference it directly.
Deliverables
We work with your ML team in their tooling, not around it. The output is safety evidence that data scientists recognise and certification bodies accept.
Signals
Connections
This is the newest branch and the one most often run in isolation by a team that doesn't share a vocabulary with the safety organisation. Closing that gap is most of the value.
The hazard and risk analysis is shared. AI safety should not produce its own hazard list — it should take the existing safety functions and ask what threatens them when the fault assumption is removed. Where an AI safety countermeasure is implemented in E/E/PE hardware or software, that implementation goes straight back into the IEC 61508 lifecycle at the right SIL.
AI safety produces the evidence: what was evaluated, on what distribution, with what confidence. UL 4600 and UL 3115 supply the structure that turns that evidence — alongside your IEC 61508 evidence — into an argument a certification body can actually evaluate.
Not "is it accurate" — can you show which safety function each number supports, and what happens on the day it is wrong.