ISO/PAS 8800 Explained: Safety for Machine Learning in Vehicles

ISO 26262 assumes that behaviour is written down. There are requirements, an architecture, code that implements them, and tests that compare the code with the requirements. A trained model breaks that assumption. Its behaviour sits in parameters that came out of training, and the data decided them. ISO 26262 has no clause that asks what that data must be. ISO 21448 gets closer: its informative Annex D notes that incomplete or biased training data makes a model learn the wrong correlations. Neither standard says what a dataset has to satisfy before you can lean on it for a safety requirement.

That is the gap ISO/PAS 8800 fills.

What ISO/PAS 8800 adds

ISO/PAS 8800:2024, published in December 2024, covers safety-related vehicle systems that use AI, mostly machine learning. Clause 6 makes clear that it is applied together with ISO 26262, not in place of it. Much of its structure looks familiar from the parent standard: deriving AI safety requirements (Clause 9), verification and validation (Clause 12), safety analysis (Clause 13), measures during operation (Clause 14) and an assurance argument (Clause 8).

The part with no counterpart in ISO 26262 is Clause 11, on data. It gives each dataset a lifecycle of its own, with a safety analysis, requirements traced to the AI safety requirements, design, implementation, verification, validation and maintenance. It names data properties that can be insufficient, such as representativeness, independence between datasets and temporality. And it treats the processes and tools that produce the data, labels included, as something to analyse and verify, much as a production process is analysed rather than trusted.

That last point is the one most teams underestimate. A dataset cannot be checked by the model trained on it. If the labels are wrong in a systematic way, the training set and the test set are wrong together, and the test confirms the error.

A worked example: stopped cars under bridges

In this fictional system, a forward radar for emergency braking sees stationary returns all the time: bridge decks, gantries, signs, drain covers, and now and then a car stopped at the end of a queue. A small classifier decides, for each stationary return in the lane, whether it is an obstacle or road structure. Both errors matter. Calling a bridge an obstacle brakes the car hard on an empty road. Calling a stopped car part of the bridge leaves it unbraked.

The team has 900,000 km of recorded motorway driving. Labelling every stationary return by hand is not affordable, so they automate it. A map lists every bridge and gantry, and a rule labels any stationary return inside a bridge zone as structure. Hand labellers review only the returns outside those zones. The rule is fast, cheap and right almost everywhere.

Its one blind spot is the case that matters most. Queues form under and just past bridges, at junctions and lane drops. A stopped car inside a bridge zone is labelled structure by the rule, in the training set and in the test set alike. The classifier learns to treat "under a bridge" as strong evidence for structure, and the test set agrees, because the same rule labelled it. The classifier scores 99.6% on the test set. Its miss rate on stopped vehicles inside bridge zones cannot even be computed against those labels: they contain no stopped vehicles there, so the rate is zero out of zero, and the stratum that matters most has no measurement at all.

How the dataset lifecycle catches it

Nothing in model training or model testing can find this. The error is in the answer key. ISO/PAS 8800 reaches it from the other end. The AI safety requirement says stopped vehicles in the lane are detected below an allocated miss rate, including where the road passes under structures. A dataset requirement traced to it says that labels for stationary returns in bridge zones must be correct for the stopped vehicle class. The dataset safety analysis then asks how the labelling process could break that, and the map rule is the obvious suspect: it is a labelling tool, and verifying the dataset includes verifying the tools that made its labels.

The check itself is ordinary. Relabel an independent sample of 2,000 bridge-zone returns by hand. It finds 46 stopped vehicles the rule had called structure, and the classifier misses 19 of them. The model was always this weak under bridges; the evidence simply could not show it.

The fix is in the data, not the model: change the rule, relabel, retrain, and test against labels that were verified independently of the rule.

A dataset with a specification

ISO 26262 would look at the labelling rule as a software tool and ask about confidence in its use (ISO 26262-8:2018, Clause 11). ISO/PAS 8800 starts one step earlier. It asks which properties the data must have to support each AI safety requirement, writes them down as dataset requirements, and then checks the data, and the way it was made, against them. In that sense a safe dataset is not a large one. It is one whose required properties are specified, traced and verified.

The Safety-Aware Machine Learning (ISO 8800) concept page covers the full picture: the AI safety lifecycle, how AI safety requirements are derived and made verifiable, input-space coverage, robustness and out-of-distribution detection, verification beyond accuracy, runtime monitoring, the assurance argument, how the evidence fits with ISO 26262 and ISO 21448, and the anti-patterns that keep recurring in ML safety work.