What the Digital Omnibus on AI Means for Road Infrastructure Management and Operation
Artificial intelligence is increasingly being integrated into transport infrastructure to support functions like traffic management, road-condition monitoring, and safety analysis. EU-funded research and innovation projects play an important role in testing how such technologies can be developed and applied in real-world environments. For instance, the iDriving project combines AI, Digital Twins, real-time monitoring, predictive maintenance and vehicle-to-infrastructure communication to detect hazards, support maintenance and deliver timely warnings. These functions make the project a useful practical lens through which to examine an important legal question under the EU Artificial Intelligence Act: when does an AI system become a ‘safety component’, and when does that make it high-risk? This distinction matters as the AI Act specifically identifies AI systems used as safety components in the management or operation of road traffic as potentially high-risk, meaning stricter legal requirements and safeguards. But what exactly counts as a ‘safety component’?
The answer has become more precise following the adoption of Regulation (EU) 2026/1744, the Digital Omnibus on AI, which amended the Artificial Intelligence Act (Regulation (EU) 2024/1689) and recently entered into force.
Why the concept matters
The AI Act follows a risk-based approach. Most AI systems are not classified as high-risk merely because they use sophisticated technology or operate in an important sector. High-risk status is attached to defined situations in Article 6 of the AI Act. Two routes are particularly relevant to smart mobility.
The first route, under Article 6(1), concerns an AI system that is itself a product, or is intended to be used as a safety component of a product, covered by the Union harmonisation legislation listed in Annex I. A second cumulative condition must also be satisfied: the product or AI system must be required to undergo a third-party conformity assessment before being placed on the market or put into service.
The second route, under Article 6(2), covers the use cases listed in Annex III. Of direct relevance to smart mobility, Annex III includes AI systems intended to be used as safety components in the management and operation of road traffic where failure or malfunction may put at risk the life and health of persons. This is a separate route from the regulated-product route. An AI system may therefore require assessment under Annex III even when it is not embedded in a vehicle or another Annex I product.
The Digital Omnibus on AI: what changed?
The Digital Omnibus on AI amended the AI Act to simplify its implementation, provide greater legal certainty and reduce unnecessary compliance burdens, while preserving its risk-based approach and fundamental safety objectives. One of the issues addressed concerned the meaning of a ‘safety component’, which is particularly important because an AI system may be classified as high-risk where it performs a safety function in a regulated product or is itself such a product. The amendment therefore refined the relevant conditions to distinguish AI systems whose failure could genuinely endanger health, safety or property from tools that merely provide supplementary information and do not independently perform an essential safety function.
The original wording of Article 3(14) of the AI Act treated a component as a safety component where it fulfilled a safety function or where its failure or malfunction endangered health and safety. The Digital Omnibus on AI refines that definition in Article 1(4)(a). The amended approach requires two elements to be considered: the component must be intended by the provider to fulfil a safety function, meaning its intended purpose is to prevent or mitigate risks to the health and safety of persons or property, and its failure or malfunction must be capable of endangering them. In practical terms, a connection with safety is not enough. The provider’s intended purpose must be to prevent or mitigate a safety risk, and the component must be important enough that its own failure or malfunction could create or aggravate danger. Systems used only for comfort, convenience, performance optimisation, ordinary automation or non-safety-related quality control would not qualify merely because they are deployed in a safety-sensitive environment.
This clarification supports a more proportionate classification. A road-data dashboard, for example, does not become a safety component simply because a road authority uses it. By contrast, an AI function that identifies a dangerous obstruction and directly triggers or controls a warning on which road users rely may perform a genuine safety function. Even then, Article 6(1) requires the additional link to an Annex I product and a mandatory third-party conformity assessment.
What does this mean for iDriving?
iDriving develops an integrated solution for urban and secondary roads. According to the project’s official solution description, its main building blocks include real-time visual inspection, behaviour and weather analysis, defect detection, intelligent maintenance, AI-based warning mechanisms and a Digital Twin capable of anticipating road conditions and events. These functions should not be classified as one undivided AI system. Each component must be assessed according to its intended purpose, technical integration, operational role and failure consequences.
The amended timeline does not remove the need to prepare
The Digital Omnibus also postpones the application of the high-risk framework. According to the Commission’s current implementation information, the rules for Annex III systems apply from 2 December 2027, while the rules for AI systems covered through the regulated-product route under Article 6(1) apply from 2 August 2028. These later dates provide additional preparation time, but they do not convert a high-risk system into a low-risk one or displace sector-specific product-safety law.
For projects such as iDriving, the useful response is not to classify the entire architecture prematurely. It is to build a component-level inventory, preserve evidence about intended purpose and safeguards, and reassess classification as the technology moves from research and pilots towards operational deployment.
Authors: Defne Halil and Stefani Velkova, Law and Internet Foundation (LIF), iDriving partner.