The IWG on AI reports on its meetings held since July 2026 and activities including compilation of literature on regulated automotive safety systems using AI, creation of terms and definitions, listing of AI use cases, and work on an AI reference document (latest draft AI-11-03). An AI reference document is scheduled for submission as a formal working document to the June 2027 WP.29 session. Small drafting groups are creating proposed updates for introduction, section 2, and section 4 based on AI-11-03 as baseline.

Document addresses outstanding issues in Section 4 of the Management of AI Risks in Automotive, including whether X+ model or other relevant models are cited or referenced, and whether human oversight and system controllability should be added as a new entry under para. 4.2.10. These issues will be discussed at the 13th IWG meeting on 14 December.

Initial proposal for the main contents of Section 4 on AI Risk Management.

Agenda for an online Small Drafting Group meeting to draft Section 4 of the UN/WP.29 IWG on AI Reference Document. The meeting covers welcome and opening remarks, review of previously-identified concerns, drafting of Section 4.1 addressing common concept approach and descriptive approach, and drafting of Section 4.2 addressing common concepts of AI risk management practices including risk-informed lifecycle approaches, intended purpose and operational assumptions, established sectoral engineering practices, traceability and documentation, data as a safety-relevant engineering artefact, confidence through multiple sources of evidence, organizational capacity and governance, continuous monitoring and improvement, and assurance arguments.

Draft working document describing nine common concepts for managing AI risks in automotive regulated products: risk-informed lifecycle approaches, intended purpose and operational assumptions, building upon established sectoral engineering practices, traceability and documentation, data as a safety-relevant engineering artefact, confidence through multiple sources of evidence, organizational capacity and governance, continuous monitoring and improvement, and assurance arguments. The document presumes that existing regulations and established automotive safety engineering practices remain applicable where AI is part of a regulated product, and management of AI risks builds upon those regulations and practices.

Proposal to conduct safety analysis based on vehicle and system architecture to identify and decompose data and model-related safety requirements, and delete the requirement for maintenance or reassessment of assumptions as the system or environment changes.

Proposal to add principles and stages of risk-driven lifecycle approach to para. 4.2.1.1, replacing ‘risk informed lifecycle approaches explanation’ with ‘Risk-driven lifecycle approach explanation’ and adding explicit reference to principles of risk-driven lifecycle approach and stages of risk-driven lifecycle approach.

Change request to revise the driving function name from ‘Acceleration Control Pedal Error’ to ‘Acceleration Control for Pedal Error’ in Section 1.2.4, based on UNECE guidance that the original term is not a correct driving function name.

Proposal to add illustrative real-world application examples under Automated Driving Systems in Annex 1, items 1.2.4 and 1.3, covering low-speed unmanned delivery and sanitation vehicles in closed or semi-open areas and urban non-motorized lanes, robotaxi operation on urban roads, and autonomously-operated vehicles deployed within mining sites, ports and industrial parks.

Proposal to add to illustrative practices in para. 4.2.6.3 a reference to scenario coverage assessment based on ISO 34502 and test case generation based on ISO 34505 as sources of evidence for AI system assurance, and to add ISO 34501-34505 to Annex 4 A standards list.

Proposal to add a new risk item addressing compromised or unavailable infrastructure-sourced inputs in para. 3.2.9.5, add a corresponding extended description in Annex 2 (item 6.5), add a new table row in Annex 3, and add the term ‘Roadside Perception’ to Annex 5. AI systems that rely on roadside perception, map data, or remotely-delivered data may encounter communication outages, latency, or maliciously-altered incoming data, resulting in perception gaps or erroneous decisions.

Proposal to introduce the nine data-related safety properties defined in ISO/PAS 8800:2024 (Accuracy, Completeness, Correctness, Independence of datasets, Integrity, Representativeness, Temporality, Traceability and Verifiability) as a common verification thread across rows 4.1–4.5 in Annex 3 and Section 4.2.5, add an anchoring practice for row 4.4 (Distribution Shift) requiring periodic monitoring and reassessment of data–model drift with re-evaluation of the safety argument where drift is detected, and list digital watermarking and AI-based automated audit as candidate illustrative practices.

Proposal to insert new section 4.2.10 defining human oversight and system controllability as complementary dimensions addressing the human-machine interaction layer and engineering design layer. The concept establishes that human oversight refers to the ability of natural persons to monitor, understand, intervene in, and override AI system outputs affecting safety, while system controllability refers to the ability of external agents to influence AI system behavior to prevent harm. For driving automation functions, human oversight and fallback vary with automation level as defined in SAE J3016 / ISO/SAE 22736. For non-driving safety functions, controllability may be achieved through audible or visual warnings, output degradation, or fail-safe behavior. System-level controllability measures include dedicated safety monitors, redundant model architectures, and structured fallback or fail-safe degradation strategies.

Proposal to insert an introductory paragraph before para. 4.2.1 to establish that the depth and rigor of applying common AI risk management concepts should be commensurate with the safety risk level of the specific AI application, with risk levels informed by ISO 26262 ASIL classification and ISO 21448 SOTIF risk assessment, as well as the degree of AI system autonomy and adaptability, and to elevate the proportionality principle from a sub-point within para. 4.2.1.1 to a framing principle for the entire Section 4.2.

Proposal to insert new sections 2.3.7 and 2.3.8 to clarify the classification criteria and boundaries of the three modes of AI use and provide representative examples illustrating their practical application, establishing that classification should be based on the role and purpose of AI in specific activities rather than assigning a fixed mode to a particular model or process, and that the same AI-related model, system, artefact or process may correspond to different modes at different stages or when used for different purposes.

Add one NB note beneath the “AI Safety” definition in Annex 5, Section 1.1, item 4, clarifying that the definition uses “safety” in the functional-safety sense and that hazards affecting AI-based safety functions may be initiated by malicious actions or arise from personal data processing, and that assurance of AI systems interacts with cybersecurity and data-privacy requirements such as UN R155 and ISO/SAE 21434.

Proposal to modify para. 4.2.5.2 to replace ‘management of changes in data and operational distributions’ with ‘management of changes in data and process assurance’. Where a closed-loop data chain is applied to vehicle AI systems safety development activities, evidence of safety assurance capability of the complete closed-loop data chain shall be provided, including safety assurance descriptions for data collection, data processing, and data annotation processes. Where data training is used as an improvement measure for functional insufficiency, relevant analysis shall be conducted and the rationality of the data shall be justified to ensure the improved system meets system-level safety-related requirements.

Proposal to insert a sentence in para. 2.2.1 clarifying that decision trees can be learned from data and not all are manually specified rule systems, and to modify para. 2.2.5 to state that Generative AI models can use different architectures, with some being Transformer-based and potentially foundation or general-purpose AI models.

Proposal to modify the definition of concept drift in para. 3.2.9.2 and Annex 2, para. 6.2 to clarify that concept drift arises when changes alter the relationship between inputs and target outputs, and that a change in input distribution alone does not necessarily imply a change in this relationship.

Proposal to modify the definition of Validation Data to replace ‘a final’ with ‘candidate’ and append clarification that it is used for model selection or tuning while independent test data used for final performance reporting are not used for model selection or tuning, and add a definition of Test Data as data used to evaluate the final selected model and not used for fitting, model selection or tuning, with a note on dataset separation to avoid leakage between sets.