ISO/PAS 8800: ISO/PAS 8800 – Tutorial (about 60 minutes)

ISO/PAS 8800 is the international specification that tells the automotive industry how to make safety-related vehicle functions that use artificial intelligence, and in particular machine learning, safe enough to put on public roads. It is used by carmakers, their suppliers and engineering service providers: safety managers, perception and machine-learning engineers, data teams, validation engineers and assessors. After this tutorial you will be able to explain what problem the document solves, how it fits next to functional safety and SOTIF, how its AI safety lifecycle and data lifecycle work, how a safety assurance argument for an AI component is built, and how a real project could apply it from requirements to field monitoring.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current and only edition is ISO/PAS 8800:2024, Road vehicles – Safety and artificial intelligence, edition 1, published by ISO in December 2024 (the ISO catalogue shows it at stage 60.60, "published", dated 2024-12-13). It was prepared by technical committee ISO/TC 22 (road vehicles), subcommittee SC 32 (electrical and electronic components and general system aspects), the same group that maintains ISO 26262 and ISO 21448. It is a Publicly Available Specification (PAS), not yet a full International Standard: ISO uses this deliverable when the market needs guidance quickly, and a PAS must be reviewed within a few years and is then confirmed, turned into another deliverable type such as an International Standard, or withdrawn. The ISO catalogue listed no revision or conversion project for it when this course was checked. National standards bodies republish it; in the United Kingdom, for example, BSI sells it as PD ISO/PAS 8800. The course name carries no year, so this tutorial teaches the 2024 edition. Verified 2026-10-29 against the ISO catalogue entry for ISO/PAS 8800:2024 (project 83303, including its stage history), the BSI/CCAV use-case report and the UL Solutions overview.

Who it is for: engineers, data scientists, test and validation staff, quality and safety professionals, project managers and purchasers who work on vehicle functions that contain a trained model (for example camera-based object detection, driver monitoring, battery state estimation or trajectory prediction) and who are new to ISO/PAS 8800. People who already know ISO 26262 will see where their existing work continues and where new work starts.

Prerequisites: none. A rough idea of how a driver-assistance feature works (sensors, software that interprets them, actuators such as brakes and steering) and what "training a model on data" means will help. Every technical term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why trained models create safety risks that classic automotive safety standards do not fully cover, and which three causes of AI errors ISO/PAS 8800 addresses.
You will be able to define the core vocabulary: AI system, AI component, AI model, AI error, functional insufficiency, triggering condition, input space, AI safety requirement, dataset insufficiency and assurance argument.
You will be able to describe the structure of ISO/PAS 8800:2024, from its context and management clauses to the clauses on requirements, design, data, verification, safety analysis, operation and tools.
You will be able to walk through the reference AI safety lifecycle and the dataset lifecycle, and name the work products each step produces.
You will be able to explain how conformity with ISO/PAS 8800 is assessed and why there is no ISO certificate for it.
You will be able to apply the ideas to a realistic machine-learning perception component.
You will be able to position ISO/PAS 8800 against ISO 26262, ISO 21448, ISO/TS 5083, ISO/IEC TR 5469, ISO/IEC 42001 and UL 4600.

Lesson 1 – Origins, purpose and scope

Why classic safety standards were not enough

Road-vehicle safety engineering for electronics rests on two pillars. The first is ISO 26262, the functional safety standard. It deals with malfunctions: a component fails at random (a capacitor ages, a memory cell flips), or a designer or programmer makes a systematic mistake (a wrong requirement, a software bug). ISO 26262 tells you how to classify the risk of each hazard with an Automotive Safety Integrity Level (ASIL, from A to D), how to design safety mechanisms and how to prove, step by step, that the software does exactly what its specification says.

The second pillar is ISO 21448, known as SOTIF (safety of the intended functionality). It deals with a different danger: a system that has no fault at all, yet behaves unsafely because its specification or its performance is not good enough for some situation in the real world. A camera that cannot see through low sun glare is a classic SOTIF example.

Machine learning puts pressure on both pillars. A neural network is not written line by line by a programmer; its behaviour is learned from data. You cannot read its millions of parameters and check them against a requirement in the way ISO 26262 expects for hand-written code. Its performance depends on how well the training data represents the real world, which is a data problem as much as a software problem. And its behaviour can change sharply for inputs that look almost identical to a human, or for inputs that were rare or absent in the data. Engineers needed answers to questions such as: What does a good safety requirement for a model look like? How much data is enough, and of what kind? How do you test something whose input space is effectively infinite? How do you keep it safe after it leaves the factory?

How ISO/PAS 8800 came about

ISO/TC 22/SC 32 approved and registered the project in September 2021, and an international working group, with industry and academic experts from 17 countries, developed it over the following three years. The group chose the PAS format so that industry could start using a common approach quickly while experience with AI safety was still growing. The result, published at the end of 2024, is a long document (about 170 pages) that does not replace ISO 26262 or ISO 21448. Instead, it tailors and extends them for systems that contain AI.

Scope in plain words

ISO/PAS 8800 applies to safety-related systems in series-production road vehicles (mopeds excluded) when one or more of their electrical and electronic systems use AI. Special-purpose vehicles with unique electronic systems, such as vehicles adapted for drivers with disabilities, are outside its scope. The document concentrates on machine learning (ML), the subclass of AI in which a model learns its behaviour from data, and it deliberately avoids prescribing particular techniques such as a specific kind of deep neural network.

Its core purpose is to reduce the risk of unwanted safety-related behaviour at vehicle level caused by errors of AI elements. It names three causes of such errors:

Output insufficiencies (functional insufficiencies) – the model works exactly as trained but its output is not good enough for the situation, for example it misses a pedestrian in a pose it rarely saw in training.
Systematic errors – mistakes made during specification, design, implementation or data handling, such as a pre-processing bug that crops images wrongly, or a labelling rule that is applied inconsistently.
Random hardware errors – faults of the hardware the model runs on, such as a corrupted weight in memory or a failing accelerator chip.

It also covers AI elements outside the vehicle when they influence safety directly or indirectly, for example a cloud service that feeds information to the car, or the off-board systems that collect field data. The development of those external elements themselves is not in scope, although the document can serve as a reference when no domain-specific guidance exists. Finally, it gives no specific guidance for software tools that themselves use AI methods (such as an AI coding assistant); its tools clause is about building confidence in the frameworks and tools used to develop AI.

Figure 1 – The three causes of AI errors and how ISO/PAS 8800 combines functional safety and SOTIF ideas to argue that the remaining risk is acceptable.

The final goal is the familiar one from automotive safety: absence of unreasonable risk. ISO/PAS 8800 does not promise that a model will never be wrong. It asks you to show, with a structured argument and evidence, that the remaining risk from the AI is acceptable within the vehicle-level safety case.

Lesson 2 – Key concepts and vocabulary

ISO/PAS 8800 defines many terms in its terms-and-definitions clause. The explanations below are in our own words and keep to the meaning you need for practical work.

Artificial intelligence (AI) and machine learning (ML) – AI is the broad field of systems that perform tasks associated with intelligence; ML is the part of AI in which behaviour is learned from data rather than programmed rule by rule. ISO/PAS 8800 focuses on ML.
AI model – the trained mathematical structure (for example a neural network with its learned weights) that turns inputs into outputs.
AI component – a component that is, or contains, one or more AI models, often together with conventional pre-processing and post-processing code.
AI system – a system made of one or more AI components and possibly conventional components, for example an object-detection system consisting of image pre-processing, a detector network and a plausibility filter.
AI element – the umbrella word for an AI-based part at any level, such as a whole AI system or one of its AI components, used when a statement applies to all of them.
Encompassing system – the larger vehicle system that contains the AI system and depends on its outputs, such as the complete emergency-braking function with its radar, decision logic and brakes. Many safety measures live here, not inside the model.
AI error – an output of an AI element that deviates from what is correct or required, whatever its cause.
Functional insufficiency – a term inherited from SOTIF: either an insufficiency of specification (the required behaviour is wrong or incomplete) or a performance insufficiency (the element cannot achieve the required behaviour). For models, the most common case is a performance insufficiency that only shows up under certain conditions.
Triggering condition – a specific condition of the situation (low sun, wet road reflections, an unusual vehicle shape) that activates a functional insufficiency and leads to an error.
Input space – the set of inputs the AI system is meant to handle. It is useful to split it into the semantic input space (what the world can contain: road types, weather, objects, usually derived from the operational design domain) and the syntactic input space (what the data looks like: image size, resolution, frame rate, value ranges).
Operational design domain (ODD) – the operating conditions a driving function is designed for, such as road types, speeds, weather and lighting. It is the starting point for the semantic input space.
AI safety requirement – a requirement on an AI element that, when met, helps ensure the safety requirements allocated to it from the encompassing system. Typical topics are performance, robustness and behaviour at the boundaries of the input space.
Safety-related properties of AI – qualities such as robustness (stable outputs when inputs vary within expected limits), generalisation (good performance on situations not seen in training), prediction accuracy, reliability of confidence estimates and absence of harmful bias. They help to formulate requirements and to structure the assurance argument.
Dataset insufficiency – a weakness of a dataset that can lead to violations of AI safety requirements, for example missing classes, wrong labels, unrepresentative sensor characteristics or overlap between training and test data.
Training, validation and test datasets – data used respectively to fit the model, to tune and select it during development, and to verify it independently. Mixing them weakens the evidence.
Distribution shift and out-of-distribution input – a change between the data the model was developed on and the data it meets in use; an out-of-distribution input lies outside what the training data represents.
Assurance argument – a structured line of reasoning, made of claims supported by evidence, that shows why the AI system is acceptably safe in its context. It is often drawn with Goal Structuring Notation (GSN) or a similar notation.
Field monitoring – collecting and analysing data about the AI system's behaviour after release, to find new insufficiencies and confirm that assumptions still hold.

How the terms connect

A useful chain of thought links many of these words. A triggering condition in the world (heavy rain at night) meets a functional insufficiency of the model (poor detection of dark-clothed pedestrians in rain), which produces an AI error (a missed pedestrian). Whether that error becomes a hazard depends on the encompassing system: if a radar channel or a plausibility check catches the problem, the vehicle may still behave safely. ISO/PAS 8800 calls this kind of reasoning a cause-and-effect view of AI errors, and it is the backbone of safety analysis for AI.

A second chain links requirements to data. Safety requirements allocated from the vehicle level are refined into AI safety requirements; those are turned into dataset requirements; the datasets are checked for dataset insufficiencies; and verification evidence is traced back to every requirement. Traceability in both directions is a recurring demand of the document.

Lesson 3 – Structure of the specification

ISO/PAS 8800:2024 has fifteen clauses and eight annexes. The first clauses are the usual front matter, such as scope, normative references, terms and abbreviations. The substance is in clauses 6 to 15, summarised here in our own words:

Clause 6 – AI in the context of road-vehicle safety: how an AI element sits inside a vehicle system, the basic concepts of AI errors and their causes, and how the work relates to ISO 26262 and ISO 21448.
Clause 7 – AI safety management: the organisational side and the reference AI safety lifecycle, including iterative development and the work products the lifecycle produces.
Clause 8 – Assurance arguments for AI systems: how to build a structured argument that the AI system is acceptably safe, and what evidence it needs.
Clause 9 – Deriving AI safety requirements: turning the safety requirements allocated to the AI system into refined, verifiable AI safety requirements, and defining the input space.
Clause 10 – Selecting AI technologies and architectural and development measures: choosing a suitable AI method and the design measures (redundancy, monitors, training techniques) that make the requirements achievable.
Clause 11 – Data-related considerations: the dataset lifecycle, dataset requirements, dataset safety analysis and data-related work products.
Clause 12 – Verification and validation of the AI system: testing AI components and the integrated AI system, and validating that the allocated safety requirements are met in the encompassing system.
Clause 13 – Safety analysis of AI systems: finding the root causes of AI errors, including functional insufficiencies and their triggering conditions as well as faults.
Clause 14 – Measures during operation: field monitoring, handling of newly found insufficiencies, and safe updating after release.
Clause 15 – Confidence in AI frameworks and software tools: making sure that the development frameworks, libraries and tools used to build and test the AI do not introduce undetected errors.

The annexes give background material and examples that help you interpret and apply the clauses.

Figure 2 – How clauses 6 to 15 group into foundations, a development V-model and post-release and supporting topics, with analysis and field findings feeding back into requirements and tool confidence supporting the data work.

Requirements, objectives and work products

Each technical clause follows a pattern that ISO 26262 users will recognise. It states objectives (what the phase must achieve), requirements and recommendations (normally phrased with "shall" for mandatory items and "should" for recommended ones) and work products (the documents, data or software that prove the phase was done). For example, the requirements phase produces an input space definition, the refined AI safety requirements and a record of known insufficiencies with the parts of the input space they affect; the data clause produces a defined dataset lifecycle and evidence for the outputs of each of its phases, such as dataset requirements and dataset safety analysis records.

Relationship with ISO 26262 inside the document

ISO/PAS 8800 leans on ISO 26262 rather than repeating it. For malfunctions of AI elements it tailors selected clauses of ISO 26262 Parts 4 (system level), 6 (software level) and 8 (supporting processes). Risks from random hardware faults and from classic systematic faults in the execution platform and conventional software are still handled by fulfilling ISO 26262. Where testing methods are needed for AI components, it points back to established techniques of ISO 26262 Part 6, such as requirements analysis, equivalence classes, boundary values and error guessing, and adds AI-specific ones. Likewise, functional insufficiencies are handled by extending the SOTIF ideas of ISO 21448 to the level of AI components. A team that has no ISO 26262 or ISO 21448 process will find ISO/PAS 8800 hard to apply on its own.

Lesson 4 – How it works in practice: the AI safety lifecycle

The big picture

ISO/PAS 8800 describes a reference AI safety lifecycle. It starts where vehicle-level safety work hands over to the AI system: a set of safety requirements allocated to that system, plus a description of its context. It then runs through an AI-specific V-model (requirements, design, data, implementation and training, verification, integration, validation) and continues into operation. The lifecycle is explicitly iterative: findings in later phases routinely send the team back to refine requirements, collect more data or change the architecture.

Figure 3 – The reference AI safety lifecycle as an iterative flow, from allocated safety requirements to field monitoring, with the main feedback loops.

Step 1 – Understand the context and the allocated requirements

The AI system never stands alone. Before refining anything, the team describes the encompassing system, its architecture and the role the AI system plays in it. Vehicle-level analyses carried out under ISO 26262 (hazard analysis and risk assessment) and ISO 21448 (identification of hazards from insufficiencies and misuse) produce safety requirements, and some of them are allocated to the AI system. Such an allocated requirement is usually expressed in system terms: for example, a required rate of correct detections of a given object class within a certain distance, or a limit on false alarms per hour of driving.

Step 2 – Define the input space and refine AI safety requirements

Next the team defines the input space. The semantic part comes from the ODD: which roads, objects, weather and lighting the system must handle. The syntactic part comes from the sensor chain: format, resolution, frame rate, value ranges. Both are refined in increments as the team learns which features of the environment actually affect the model.

The allocated requirements are then refined into AI safety requirements that a model developer can design and test against. Typically this means requirements on performance (a measurable quality level), on robustness (that performance holds across defined variations such as rain levels or glare angles), and on behaviour near the edge of the input space (for example that the component reports low confidence or signals "outside domain"). Each refined requirement must trace either to an allocated safety requirement, an assumption or a critical scenario, or to a known root cause of insufficiency. The team must also justify why the refined set is sufficient. Two situations must be reported back to the encompassing-system team: when the AI system cannot fully meet its AI safety requirements, and when it meets them only in part of the input space. That escalation allows the system level to add measures such as restricting the ODD or adding a second sensor channel.

Step 3 – Choose technologies and architectural and development measures

Here the team justifies the choice of AI technology (for example a particular detector family) and decides on measures. Architectural measures are design features: redundant or diverse channels, plausibility checks, out-of-distribution or uncertainty monitors, safe fallback behaviour, input-quality checks that reject unusable images. Development measures are things done while building the model: data augmentation, careful training procedures, model selection rules, regularisation, documented hyperparameter choices. The effectiveness of the combination must be supported by an argument. The team also compares the development environment with the target execution environment (for example a GPU in the lab versus a quantised model on an automotive chip) and handles differences that could affect safety.

Step 4 – Run the dataset lifecycle

Data deserves its own lesson-level attention, and ISO/PAS 8800 gives it a full clause. The essentials are covered in the next section of this lesson.

Step 5 – Train, implement and verify

AI components that contain models are trained on the training dataset and evaluated on the validation dataset, and the team records its design decisions and their rationale (many teams keep a development log for this). Verification then shows that components and the integrated AI system conform to the AI safety requirements and that there is no unintended functionality. Test cases need explicit pass and fail criteria and must cover the requirements over the specified input space. Components that can be tested alone are tested alone; then they are integrated step by step until the whole AI system is verified against its architectural design.

Step 6 – Validate in the encompassing system

Validation answers a different question from verification: not "did we build the AI system to its requirements?" but "with this AI system inside the vehicle function, are the safety requirements that were allocated to it really achieved?" Validation uses the integrated vehicle function, simulation and real-world driving, and it is where hidden assumptions about the environment are most likely to break.

Step 7 – Safety analysis throughout

Safety analysis is not a single step; it runs alongside the whole lifecycle. Its job is to find potential AI errors, their root causes and triggering conditions, and the measures that prevent or mitigate them. Teams combine classic techniques adapted to AI (fault tree analysis, failure mode and effects analysis, hazard and operability studies, system-theoretic process analysis) with AI-specific analyses of insufficiencies and of datasets. Results feed new requirements, new data needs and new architectural measures.

Step 8 – Release, operate and keep learning

Because complete verification of a trained model is impossible, ISO/PAS 8800 puts weight on measures during operation. Before release, the team defines AI safety requirements that support field monitoring: what the system must log, which signals indicate trouble (for example frequent low-confidence outputs or out-of-distribution alarms), and how that information returns to development. After release, field data is analysed for new insufficiencies; when one is found, the lifecycle loops back to requirements, data and design. Any updated model goes through the same verification, regression testing and argument update as the original, under change management.

The dataset lifecycle

ISO/PAS 8800 treats datasets as safety-relevant work products in their own right, with their own lifecycle that mirrors the model's V-model. The team must define this lifecycle, make it support iteration (because requirements change and field findings arrive), and include gathering, creation, safety analysis, verification, validation, management and maintenance of the data.

Dataset requirements are derived from the AI safety requirements and must stay traceable to them. Practitioners often organise them around a few quality dimensions:

Relevance and representativeness – the data reflects the real sensors, mounting positions and operating environment of the target vehicle.
Accuracy of labels – annotations (classes, bounding boxes, segmentation masks) are correct and consistent, with clear labelling guidelines and checks.
Completeness and coverage – all relevant combinations of environmental features from the robustness requirements are present in sufficient quantity.
Balance – rare but safety-critical classes are not swamped by common ones in development data.
Independence – verification data is kept separate from development data and ideally prepared by people not involved in training.

Dataset safety analysis asks, for each step, what could go wrong with the data and how it could break an AI safety requirement: a missing class, a labelling team that interprets a rule differently, a collection campaign that only covered summer, synthetic data that looks unrealistic, or test images leaking into training. Each potential insufficiency gets a countermeasure that prevents or mitigates it. The evidence produced along the way (data specifications, analysis records, coverage reports, version manifests) becomes part of the assurance argument.

Roles and organisation

ISO/PAS 8800 builds on the safety management ideas of ISO 26262: a safety plan that includes AI-specific activities, clear responsibilities, competence management, a safety culture and independent confirmation. In practice new roles appear next to the familiar safety manager, such as a data steward responsible for dataset lifecycle evidence and an ML lead responsible for model development logs. AI-specific competence (statistics, ML testing, data quality) must be planned, because classic functional safety training does not cover it.

Lesson 5 – Assessment, conformity and the assurance argument

Is there an ISO/PAS 8800 certificate?

No, not from ISO. ISO writes standards and specifications; it does not certify anyone against them. ISO/PAS 8800 also does not define a certification scheme, accreditation rules or certificate levels. Conformity is claimed by the organisation that develops the system, and it is checked in the ways the automotive industry already uses for safety:

Internal confirmation measures carried over from ISO 26262 thinking: confirmation reviews of key work products, audits of the process and an independent safety assessment of whether the safety argument is convincing.
Customer assessments: carmakers increasingly ask suppliers of AI-based components to show that their process follows ISO/PAS 8800 and to deliver the relevant work products, often written into the development interface agreement.
Third-party services: testing, inspection and certification companies offer training, gap analyses, process assessments and product assessments against ISO/PAS 8800, sometimes combined with ISO 26262 or ISO 21448. Any certificate they issue follows their own scheme; it is not an ISO certificate and its meaning depends on what was assessed.
Regulators and type-approval authorities: they look at the overall safety evidence for automated or assisted driving features. A reference to ISO/PAS 8800 can strengthen that evidence, but the specification is not itself a legal requirement.

What an assessor actually looks at

Because ISO/PAS 8800 sets objectives more than detailed numeric thresholds, assessment focuses on whether the evidence convincingly supports the safety claim. Typical questions are:

Are the AI safety requirements traceable to the allocated safety requirements, and is their sufficiency justified?
Is the input space defined well enough to know where the requirements apply, and are known limitations reported to the system level?
Are dataset requirements derived from the AI safety requirements, and is there evidence of dataset safety analysis, label quality checks and separation of datasets?
Do verification results show that requirements are met across the defined variations, not just on an average metric?
Do safety analyses identify triggering conditions and root causes, and are mitigations in place at component or system level?
Is there a working plan for field monitoring and for safe model updates?
Are the frameworks and tools that could corrupt the result under control?

The assurance argument

The assurance argument is where all of this comes together. It is a structured set of claims, each supported by sub-claims or evidence, with explicit reasoning about why the evidence is enough. A top claim such as "the pedestrian detector is acceptably safe within the defined ODD as part of the braking function" is broken down into claims about requirements, data, model performance, residual insufficiencies and operation. Evidence comes from the work products of every phase. ISO/PAS 8800 expects the argument to address the AI-specific uncertainty honestly: where evidence is statistical, the argument should say how confident it is and what assumptions it relies on.

Figure 5 – A simplified assurance argument: one top claim, two groups of supporting claims and the kinds of evidence that back each of them.

A good argument also records what is not claimed. If the detector meets its robustness requirement only up to a certain fog density, the argument says so, and the encompassing system must handle denser fog, for example by reducing speed or handing over to the driver. Honest limits are a strength in assessment, not a weakness.

Lesson 6 – Worked example: a pedestrian detector for urban emergency braking

This example is invented for teaching and simplified; the numbers illustrate the method and are not values from the specification.

The organisation and the feature

Northbridge Mobility is a tier-1 supplier. A carmaker has asked it to supply the camera-based perception for an urban automatic emergency braking (AEB) feature. A neural network detects pedestrians and cyclists in images from a front windscreen camera; a radar provides a second, independent channel; a decision unit fuses both and commands the brakes. The carmaker owns the vehicle-level safety case under ISO 26262 and ISO 21448 and requires Northbridge to follow ISO/PAS 8800 for the ML part.

1. Context and allocated requirements

The carmaker's hazard analysis identifies two main hazards: failing to brake for a pedestrian, and braking hard when nothing is there (which can cause rear-end collisions). Its SOTIF analysis adds triggering conditions such as low sun, night rain and partially hidden pedestrians. From this, two safety requirements are allocated to the camera perception system: a minimum rate of correct pedestrian detections per frame within 40 metres in the ODD, and a maximum rate of false pedestrian detections per hour of driving. The ODD is urban roads up to 60 km/h, day and night, dry or wet, excluding snow.

2. Input space and AI safety requirements

Northbridge writes a semantic input space from the ODD: road layouts, pedestrian appearance (adults, children, wheelchair users, people pushing prams), clothing colours, occlusion levels, lighting conditions, rain intensity and glare angle. The syntactic input space is the camera's output: resolution, frame rate, dynamic range and the pre-processing that normalises brightness.

The team refines the allocated requirements into AI safety requirements. A performance requirement sets a target on recall and precision for pedestrians within 40 metres, evaluated with a localisation tolerance agreed with the decision unit team. A robustness requirement states that this target must hold across each defined level of rain, glare and occlusion, not just on average. A boundary requirement says the component must output a "degraded" flag when image quality falls below defined limits. Each requirement traces to the allocated requirements or to the triggering conditions from SOTIF analysis, and a short justification explains why meeting them achieves the allocated targets given the frame rate and the decision unit's logic.

3. Architecture and development measures

The team selects a well-established single-stage detector family and justifies it with published results and its own pilot tests. Architectural measures include an input-quality check that rejects frames with severe blur or saturation; an out-of-distribution monitor that flags unusual images; temporal tracking that requires a pedestrian to be confirmed over several frames before a full braking request; and fusion with radar so that one channel can confirm or veto the other. Development measures include transfer learning from a pre-trained network, targeted augmentation for rain and glare, and a written model selection rule that prefers the model with the best trade-off between missed and false detections, not the best single score. Because the final model runs quantised on an automotive system-on-chip, the team plans tests that compare outputs of the lab model and the deployed model.

4. Data

The data lead writes dataset requirements: images must come from the same camera type and mounting height as the production vehicle; labels must enclose the whole visible pedestrian, with a rule for partially hidden people; every combination of lighting, rain and occlusion level in the robustness requirement must have at least a minimum number of samples; children and wheelchair users must be present in sufficient numbers; verification data must be collected on routes and dates separate from training data and labelled by a separate team.

The dataset safety analysis finds three problems. First, night-time rain images with children are scarce. Second, two labelling teams treated cyclists walking beside their bikes differently. Third, the first collection campaign used a pre-production camera with a different lens. Countermeasures follow: a targeted night-rain collection campaign plus carefully reviewed synthetic augmentation; a unified labelling guideline with a re-labelling pass and random audits; and either re-collection with the production camera or evidence that the lens difference does not change performance. All datasets are versioned, and each model version records exactly which dataset versions it used.

5. Training, verification and validation

Many candidate models are trained. Candidates are compared on the internal test split, and those that meet the performance and robustness requirements are shortlisted; the final choice is recorded in the development log with its rationale. Verification uses the independent verification dataset, which deliberately contains more extreme cases than real traffic would. Results are broken down per condition, so a weakness in glare at low sun angles cannot hide behind a good average. Robustness testing increases perturbations such as simulated haze until performance drops below the requirement, which shows where the safe limit lies.

The verification report shows that the detector meets the requirements everywhere except at the most extreme glare angle, where recall falls below target. This is reported to the carmaker as a known limitation within part of the input space. The carmaker's system team adds a measure: when the camera's glare indicator is active, the AEB relies more heavily on radar and the warning to the driver comes earlier. Validation on the integrated vehicle, including closed-track tests with pedestrian dummies and many hours of urban driving, confirms the allocated safety requirements at system level.

6. Safety analysis

The team runs a cause-and-effect analysis from each hazardous output (missed pedestrian, phantom pedestrian, wrong position) back to possible causes: insufficient data for a condition, label errors, poor generalisation to new clothing styles, quantisation effects, a pre-processing bug, a memory fault. For random hardware faults on the chip, the ISO 26262 hardware analysis and safety mechanisms apply. For each cause, the analysis records the existing measure or a new one, and new triggering conditions found here are added to the robustness requirements and dataset requirements.

7. Assurance argument, operation and tools

The assurance argument links the top claim to sub-claims and evidence as in Figure 5, and it states the glare limitation and how the system handles it. Before release, Northbridge and the carmaker agree on field monitoring: the vehicle logs anonymised snapshots when the out-of-distribution monitor fires, when the camera and radar disagree strongly, or when the driver brakes hard and the AEB did not react. The data is reviewed monthly. When new insufficiencies appear (for example, a new type of electric scooter that is poorly detected), the lifecycle loops back: new data, retraining, full regression verification, an updated argument and a controlled over-the-air update.

Finally, the team builds confidence in its tools: the training framework and its libraries are pinned to known versions; the labelling tool's export is checked against a reference set; the evaluation scripts that compute metrics are reviewed and tested, because a bug there could make a weak model look strong. That covers the intent of the tools clause without pretending that every open-source library can be proven correct.

Lesson 7 – Relationship to other standards and frameworks

ISO/PAS 8800 is one piece of a growing set of documents on vehicle safety and AI. Knowing the neighbours helps you decide which document answers which question.

Document	Main question it answers	How it relates to ISO/PAS 8800
ISO 26262 (Road vehicles – Functional safety, 2018 edition)	How to avoid unreasonable risk from malfunctions of electrical and electronic systems (random hardware faults and systematic faults).	Foundation. ISO/PAS 8800 keeps ISO 26262 for hardware and classic software faults and tailors its lifecycle ideas to AI elements.
ISO 21448 (SOTIF, 2022 edition)	How to handle hazards from specification and performance insufficiencies and from foreseeable misuse, without faults.	Foundation. ISO/PAS 8800 extends SOTIF concepts (insufficiencies, triggering conditions) down to AI components and their data.
ISO/TS 5083:2025 (Safety for automated driving systems)	How to design, verify, validate and argue the safety of a level 3 or 4 automated driving system as a whole.	Higher level. ISO/TS 5083 covers the complete driving system and its safety case; ISO/PAS 8800 covers the AI elements inside it.
ISO/IEC TR 5469:2024 (AI – Functional safety and AI systems)	Cross-industry guidance on using AI in safety-related functions and on its risks.	Generic background report, not automotive-specific and not a requirements document; ISO/PAS 8800 is the road-vehicle specification.
ISO/IEC 42001:2023 (AI management systems)	How an organisation governs AI responsibly through a certifiable management system.	Organisation level. It covers governance, ethics and risk in general; it does not give vehicle safety engineering methods.
UL 4600 (Evaluation of autonomous products)	What a safety case for an autonomous product must contain to be assessed.	Complementary. Strong on safety-case content and assessment; ISO/PAS 8800 gives the AI-specific engineering lifecycle.
ISO/SAE 21434 (Cybersecurity engineering)	How to manage cybersecurity risk over the vehicle lifecycle.	Neighbour. Deliberate attacks on AI (for example adversarial inputs) need security analysis; ISO/PAS 8800 focuses on safety.

Putting the pieces together

A practical way to think about the stack is from the outside in. Laws and type-approval regulations set the obligations. ISO/TS 5083 or UL 4600 frame the safety case for an automated driving system. ISO 26262 and ISO 21448 give the vehicle-level hazard analysis and the basic safety processes for faults and insufficiencies. ISO/PAS 8800 then takes the safety requirements allocated to an AI system and shows how to meet them with a model, data and evidence. ISO/IEC 42001 sits beside all of this at the organisation level, and ISO/SAE 21434 handles attackers. Using only one of these documents usually leaves a gap: for example, a team that applies ISO/PAS 8800 without a SOTIF analysis at vehicle level will not know which triggering conditions matter.

Another related document is ISO 34503, which gives a structure for describing an operational design domain; teams often use it to write the semantic input space. Domain-neutral AI quality standards (for example on data quality or AI risk management) can supply useful techniques, but they do not replace the automotive-specific requirements.

Common pitfalls and best practices

Pitfalls

Treating a single accuracy number as proof of safety. An excellent average score can hide a dangerous weakness in one condition, such as glare or children in rain. Requirements and results need to be broken down over the input space.
Using ISO/PAS 8800 as a replacement for ISO 26262 and ISO 21448. It extends them; without vehicle-level hazard analysis and SOTIF work there are no well-founded allocated requirements to start from.
Letting test data leak into training. Re-using verification images for tuning, or splitting video frames from the same clip across training and test sets, inflates results and destroys the independence of the evidence.
Collecting data without dataset requirements. Large, unplanned datasets often lack exactly the rare, safety-critical cases; quantity does not replace traced requirements and coverage analysis.
Hiding limitations. Not reporting that a requirement is only met in part of the input space prevents the system level from adding mitigation and later undermines trust in the whole argument.
Stopping at release. Without field monitoring and a controlled update process, new insufficiencies and distribution shift go unnoticed.
Ignoring the tool chain. An unchecked evaluation script or a silent change in a framework version can invalidate results.

Best practices

Start from the encompassing system. Agree allocated safety requirements, assumptions and escalation paths with the system team before training anything.
Write requirements for robustness and boundaries, not only for performance. Define the variations the model must withstand and what it must signal when it is out of its depth.
Manage datasets like safety-relevant code. Version them, trace them to requirements, analyse them for insufficiencies, keep verification data independent.
Combine model and architecture measures. Monitors, plausibility checks, temporal filtering and diverse sensors reduce the risk from errors that training alone cannot remove.
Build the assurance argument early and keep it live. Sketch the claims at the start so every activity knows which evidence it must produce, and update it with every iteration.
Plan field monitoring before release. Define triggers, data flows, review cadence and retraining governance as part of the design.
Invest in competence. Mix functional safety, SOTIF and ML expertise in reviews; each group catches errors the others miss.

Summary and key takeaways

ISO/PAS 8800:2024 is the first-edition ISO Publicly Available Specification on safety and AI in road vehicles, prepared by ISO/TC 22/SC 32 and focused on machine learning.
It addresses AI errors from three causes: functional insufficiencies, systematic errors and random hardware errors, and it aims at the absence of unreasonable risk rather than perfect models.
It extends ISO 26262 and ISO 21448 instead of replacing them, so vehicle-level hazard analysis and SOTIF work remain essential inputs.
Its reference AI safety lifecycle runs from allocated safety requirements through input space definition, refined AI safety requirements, design, data, training, verification and validation into operation, and it is iterative by design.
Datasets have their own lifecycle with requirements, safety analysis and evidence; data quality is a safety topic, not just a performance topic.
A structured assurance argument ties evidence from all phases together and states limitations openly.
There is no ISO certificate; conformity is shown through confirmation measures, customer assessments and optional third-party assessments under their own schemes.
Field monitoring and controlled updates are part of safety, because a trained model can never be completely verified before release.

Reflection questions

Pick an AI-based function in a vehicle you know (for example traffic-sign recognition or driver drowsiness detection). Which of the three causes of AI errors would worry you most, and why?
How would you describe the semantic and syntactic input space for that function, and which environmental features would you include in a robustness requirement?
Your verification shows that a model meets its requirements except in heavy fog. Which people would you inform, and what measures could the encompassing system take?
Think of a dataset your team uses today. Which dataset insufficiencies could exist in it, and how would you find them?
Sketch the top three levels of an assurance argument for your function. Which claim do you currently have the weakest evidence for?