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.
Proposal to complete the requirements regarding the use of cap–holder systems in the case of light source modules in a lamp.