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