Study on image generation method to support evaluation of automated driving systems. Fine-tuned an image generator on the Zenseact Open Dataset using 100,000 road-scene images annotated with 3D bounding boxes. Demonstrated ability to generate plausible images reflecting scenario specifications and to create images causing detection errors in object detectors. Next steps include quantitatively evaluating validity and realism of generated images and developing methods to automatically identify scenario specifications that degrade object detector performance.

Comments on the structure and content of the draft reference document on artificial intelligence in regulated automotive safety systems. Notes a six-month timeline for adoption by WP.29 in June 2027, with formal submissions due by March 2027. Recommends prioritizing a future-proof repository of information on potential AI-related risks and risk management that can be maintained through standard WP.29 processes. States current regulatory frameworks are sufficient to address unreasonable safety risks from AI use in vehicles. Suggests the document should include introductory explanatory text for non-specialists, clear definitions of technical terms, accessible risk summaries, and a developed risk-management section to support WP.29 regulatory activities.

Presentation proposing an AI Management System (AIMS) as a complementary organizational layer to existing safety, cybersecurity, and software update management systems. AIMS would regulate AI through organizational processes rather than technical requirements, covering data lifecycle, model development, verification and validation, change control, and operational monitoring. The system is technology-neutral, lifecycle-based, and aligned with industry standards including ISO 26262, ISO 21448, and ISO/IEC 42001, avoiding the need for product-specific AI test procedures and re-approval of model updates.

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.

Proposal to modify Annex 1, 1.1.2 to replace the clause beginning ‘and such applications fall within the scope’ with language clarifying that applications fall within the first mode of AI use only where AI is part of the regulated product and directly performs or supports a safety-relevant function, and to add that AI tools used solely for development or assessment fall under section 2.3.3.

Proposal to add working definitions for uncertainty quantification, aleatoric uncertainty, epistemic uncertainty, and uncertainty-aware action at the end of section 1.3 of AI-11-03, Annex 5. These definitions do not replace definitions in applicable standards and support general discussion of uncertainty and its effects on action.