Proposal to consolidate speed and distance requirements under the requirement to adapt driving behaviour to conditions.

Proposal to clarify that ADS Off means the ADS is prevented from performing any activity, and ADS On means the ADS has been requested to perform activity, either an ADS feature is performing the DDT or the system is in ADS Standby, to distinguish ADS Off from ADS Standby and be consistent with off mode definition in UN R171.

Proposal to amend Figure 1 in para. 4.2.2.2.3 to add an (ADS feature) Available box within the ADS Standby box. The (ADS feature) Available state shows that no ADS feature is performing the DDT, however the ADS may be performing some other activity such as determining whether the vehicle is in the ODD. The figure depicts ADS Off, ADS Standby, ADS Feature (A) Active, ADS Feature (B) Active states with transitions for Activation, Deactivation, Switching On, and Switching Off.

The change request seeks to amend the road-safety agent Instructions explanation to indicate that examples regarding road safety agent instructions to the ADS vehicle are territory-based. The revision adds the phrase “which depending on the country of operation” to both the list of example instructions and the statement regarding communication methods, clarifying that instructions from road safety agents vary from country to country.

This change request proposes to amend the explanatory text for para. 6.1.2.11. (UNR)/4.1.2.11. (GTR) by modifying the phrase “the ADS is always responsible for detecting them” to “the ADS is always responsible for detecting and responding to them” and by deleting two “remote intervention” examples of non-ADS strategies. The rationale states that the ADS is responsible for both detection and response to instructions from road safety agents, and that remote intervention examples should be avoided at the current stage as this topic is already under discussion in Phase Two.

Proposal to amend para. 6.1.2.5 (UNR)/4.1.2.5 (GTR) to clarify that the ADS is always responsible for detecting and responding to priority vehicles, and to delete the examples of non-ADS strategies involving remote intervention.

The revised text adds ISO 21448, GB/T 34590 Road vehicles-Functional safety, and GB/T 43267 Road vehicles – Safety of the intended functionality to the original reference standards ISO 26262-2/8:2028 and ISO 9001 2015. GB/T 34590 is an important reference for functional safety in China and ISO 21448 and GB/T 43267 are important references for SOTIF.

Proposal to correct a paragraph number error in para. 5.3.2.15 of the GTR and para. 7.3.2.15 of the UNR by renumbering them as 5.3.2.14 and 7.3.2.14 respectively. The safety concept shall describe the manufacturer’s approach to scenario selection to cover the reasonably foreseeable situations and conditions that the ADS will encounter including how the following aspects are covered, aligned with WP.29/2026/139 (GTR) and WP.29/2026/137 (UNR).

Proposal to delete example “collision” under “Failure to meet the ADS requirements under paragraph 6 of this Regulation” in Annex 1 (GTR) and 3 (UNR) List of reportable occurrences by reporting type. The rationale states that not all collisions involving ADS vehicles constitute failure to meet ADS requirements, as some collisions are not caused by ADS or the ADS vehicle, and some collisions are not avoidable, such as suddenly appearing obstructing road users.

Contribution for the AI literature review.

Contribution for the AI literature review.

Proposal to add text to para. 3.2.4.6 clarifying that uncertainty-related risks may propagate from upstream to downstream AI modules when uncertainty information is inadequately communicated or used, affecting the resulting action, and to add text to Annex 2, item 1.6 clarifying that inadequate communication or use of uncertainty information across AI modules can propagate or amplify uncertainty-related risks and affect the resulting action, even when the upstream estimate is informative.

Proposal to add text to para. 3.2.4.6 clarifying that uncertainty-related risks may propagate from upstream to downstream AI modules when uncertainty information is inadequately communicated or used, affecting the resulting action, and to add text to Annex 2, item 1.6 clarifying that inadequate communication or use of uncertainty information across AI modules can propagate or amplify uncertainty-related risks and affect the resulting action, even when the upstream estimate is informative.

Proposal to append sentences to paragraph 2 addressing uncertainty-related risks propagated from upstream to downstream AI modules and supporting uncertainty-aware action, and to paragraph 3 considering whether uncertainty information remains meaningful when used by downstream AI modules and how it affects the resulting action.

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.

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 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 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 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 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.

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 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.

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 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 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 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 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.