Practice 03 · Artificial intelligence
You cannot review a neural network line by line, and you cannot test your way to confidence one scenario at a time. ISO/PAS 8800 is the framework for arguing that a learned component is safe enough — with evidence the rest of the safety case can actually use.
Scope
ISO/PAS 8800 addresses safety for AI within road vehicles: 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. ISO/PAS 8800 is designed to plug into ISO 26262 and ISO 21448 — supplying the component-level evidence they both assume somebody else is producing.
ISO 26262 Part 6 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 "pedestrian at 40 metres in rain"; 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.
SOTIF is closer, because it already accepts that the function will be imperfect and reasons statistically about scenarios. But it treats the AI component as a black box with observed performance limits. It tells you the box under-performs; it does not tell you how to build a better box or how to argue that this one is good enough.
The specification moves the argument upstream, to the things that determine model behaviour before any scenario is ever run:
Where teams get caught. Model performance is usually measured well and documented badly. When the assessor asks which safety requirement a 0.94 mAP discharges, and against which subset of the ODD, and with what confidence interval — the number stops being evidence and becomes a slide.
Lifecycle
Each stage produces evidence the next one depends on. Skip one and the argument has a hole you will find during assessment rather than during development.
01 · Allocate
Take the safety goals and the SOTIF-derived performance needs and turn them into requirements a model can be held to: what must be detected, under which conditions, with what performance, and what happens when it is not.
02 · Specify data
Derive the required data distribution from the ODD, not from what happens to be in the fleet log. Define coverage dimensions, minimum representation for rare but safety-critical classes, and the 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 which model is in the vehicle and what it was trained on.
04 · Evaluate
Evaluation stratified by the ODD dimensions that matter, degradation curves at the edges, robustness to perturbation and sensor degradation, and an explicit list of identified model insufficiencies with their operational consequence.
05 · Contain
Uncertainty quantification, out-of-distribution detection, temporal and physical plausibility checks, diverse redundancy, and the defined safety reaction when confidence collapses — the measures that make a wrong output survivable.
06 · Integrate
Quantisation, pruning and compilation change the function. Determinism, timing and accelerator fault behaviour bring the component back under ISO 26262 — 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 R156 software update requirements.
08 · Argue
A structured argument from safety goal to model evidence, with assumptions, context and an explicit residual risk claim — written so the item-level safety case 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 assessors accept.
Signals
Connections
The AI branch is the newest and the one most often run in isolation by a team that does not share a vocabulary with the safety organisation. Closing that gap is most of the value.
Triggering conditions and ODD boundaries are the requirement source for the dataset and the evaluation protocol. Run in the other direction — model first, scenarios later — and you end up optimising a benchmark that nobody's safety goal depends on.
The moment the model is deployed, it is software executing on hardware with random faults, shared memory and a scheduler. Accelerator fault behaviour, freedom from interference and the integrity of the monitoring channel are all classic functional safety questions with an ASIL attached.
Not "is it accurate" — can you show which safety claim each number supports, and what happens on the day it is wrong.