Two Routes to High Risk
Regulation (EU) 2026/1744 makes the EU AI Act’s two high-risk application dates depend on two different classification pathways. This chapter focuses on the legal relationship behind each pathway: a listed high-risk use under Article 6(2) and Annex III, or an AI system connected to a regulated product and its safety function under Article 6(1) and Annex I. Understanding that distinction lets a reader assign the 2027 or 2028 date for the right reason, rather than treating every regulated product or sensitive use as the same kind of “high risk.”
Two legal tests, not one risk label
The first route is use-based. Article 6(2) and Annex III identify areas in which an AI system can be classified as high-risk because of what it is used to do. The Commission’s political-agreement announcement named biometrics, critical infrastructure, education, employment, migration, asylum, and border control as examples. Those examples are useful orientation, but they are not a substitute for checking the final Annex III text and the system’s actual function.
A system used in employment illustrates the point. Its timing question is not answered merely by saying that it uses machine learning or that it influences a workplace. The relevant inquiry is whether its use fits the applicable Annex III category and whether the provisions being considered are the Chapter III, Sections 1 to 3 requirements that the amended Article 113 places on 2 December 2027 for this route. A label such as “employment AI” narrows the inquiry; it does not finish it. The intended purpose, the decision or activity supported, the actor’s role, and the relevant provision still matter.
The second route is product-based. Article 6(1) concerns an AI system that is a safety component of a product covered by the Union harmonisation legislation listed in Annex I. In ordinary language, the system is not high-risk simply because it is installed inside a regulated object. The legal relationship turns on whether the AI performs a safety function and how the product legislation handles conformity assessment. The Commission used lifts and toys as examples of products whose integrated AI systems could fall into this product-related group, but the examples do not remove the need for the legal test.
The two routes can be thought of as different questions:
- Use route: Is the AI system being used in a listed high-risk area?
- Product route: Is the AI system a safety component of an Annex I product, with a safety function connected to health, safety, or property?
They are not simply “software” and “hardware.” A software system can be high-risk through its use. An AI component can be high-risk through its relationship to a product. The same system may also need to be checked against more than one relevant rule. The classification pathway determines which application date and compliance interface deserve attention; it does not turn the rest of the AI Act off.
The use-based route is easiest to misunderstand when a system has a general capability but a narrow deployment. A model that can rank text is not classified solely because it can be used in many settings. The relevant question is what the provider places on the market or what the deployer uses it for, and whether that use matches a listed category. An employment-screening tool and a writing assistant may share similar technical components while occupying different legal situations. Conversely, a single product can be configured for several uses, which means the operator cannot rely on the least demanding configuration if the system is also supplied or used for a listed high-risk purpose.
The product route has a different source of risk. Imagine two AI functions in the same machine. One recommends a maintenance schedule to a technician; the other controls a protective mechanism whose failure could expose a person to harm. The surrounding machine is the same, but the safety-component analysis turns on the function and the failure consequence of the AI function. The first example is not automatically outside every other AI rule, and the second is not automatically resolved merely by calling it “embedded software.” The point is that classification follows the relationship between function, product, and harm.
The routes can also overlap. A product-related system may be used in a setting that appears in Annex III, or a system may support more than one activity over its lifecycle. In that situation, the operator should not treat the two dates as competing choices. The final act specifically addresses a system that is both covered by Annex I and within an Annex III category: the relevant product-law conformity procedure remains the governing assessment route. The existence of overlap therefore increases the need for coordination; it does not create an invitation to choose the easier calendar.
Safety component means a safety function
The Digital Omnibus narrows and clarifies the concept that does most of the work in the product route. A safety component is a component of a product or AI system that fulfils a safety function, or whose failure or malfunctioning endangers the health and safety of people or property. The amended definition explains a safety function as an intended purpose determined by the provider: preventing or mitigating risks to health and safety.
That intended-purpose test excludes systems used solely for user assistance, performance optimisation, service efficiency, automation, convenience, or non-safety aspects of quality control. An AI feature that helps a user navigate a machine, improves its energy efficiency, or predicts maintenance needs is not automatically a safety component merely because the machine itself is regulated. The fact of integration is evidence about context, not a conclusive classification.
There is an important limiting condition. An AI system cannot escape the safety-component concept merely because its provider describes its function as convenience or optimisation if its failure or malfunctioning would endanger health and safety. The amended Article 6 provisions preserve that result. The legal test therefore has both a positive and a negative side: identify the intended safety function, then test the actual consequence of failure. A provider’s description matters, but it is not the only relevant fact.
This clarification changes the shape of compliance. Before asking which documents or assessment body are needed, an operator must determine what the AI is supposed to prevent or mitigate and what would happen if it failed. A recommendation engine inside a lift may be incidental. An AI controller that prevents the lift from operating in an unsafe condition is much closer to the safety-component question. The example does not classify every lift controller; it shows why the function and failure path matter more than the product label alone.
The two routes and their timing can be represented as parallel checks rather than a single funnel:
The “if both routes apply” branch matters because classification and conformity assessment are related but not identical. The act says that where a high-risk AI system is covered by Annex I product legislation and also falls within an Annex III category, the provider follows the relevant product-law conformity procedure. That rule prevents an operator from choosing whichever route appears administratively easier while ignoring the product regime that governs the system.
Sectoral coordination can limit duplication without lowering protection
The Digital Omnibus creates a conditional way to coordinate the AI Act with other Union legislation. For Article 6(1) systems connected to Annex I Section A legislation, new Article 2(13) allows the application of specific requirements or obligations in Articles 9 to 15 and 17 to 25 to be limited where the sectoral legislation provides an equivalent or higher level of protection for health, safety, or fundamental rights. A second condition is equally important: the limitation must not reduce the overall level of protection provided by the AI Act.
This is not a standing permission for a manufacturer to decide that product law is “close enough.” The Commission must use delegated acts to specify the systems concerned, the requirements that may be limited, the conditions, and the scope of the limitation. The regulation sets 2 August 2027 as the deadline by which those delegated acts are to be adopted. Until the relevant instrument identifies a case and its boundaries, the existence of a similar sectoral requirement does not by itself establish that an AI Act obligation has vanished.
The logic is one of equivalence, not substitution. If a product regime already demands controls that protect against the same relevant risk at an equal or higher level, duplicating a second set of paperwork may add cost without adding protection. But if the product regime addresses a different risk, covers a narrower stage of the system’s lifecycle, or leaves a rights issue untouched, the AI Act requirement may still do work. The legal benefit of coordination depends on comparing functions and protection levels, not on comparing the names of two regulations.
In practice, that comparison has three parts. First, identify the AI-specific risk the requirement addresses: for example, unreliable performance, poor robustness, inadequate transparency, or a failure to manage risk across the system’s lifecycle. Second, identify the product-law control that is supposed to address it and the point at which that control operates. Third, ask whether the protection is genuinely equivalent or higher, rather than merely related in subject matter. A product safety test and an AI data-quality requirement may both be called “safety measures,” but that shared label does not establish equivalence. One may test a physical failure mode while the other concerns biased or unreliable outputs.
The third part is why the limitation mechanism is placed in a delegated-act process instead of left to informal interpretation. A provider needs to know not only that another law exists, but also that the Commission has identified the specific system, requirement, condition, and scope for which duplication can be limited. Until then, an operator can use existing risk and quality systems to organize work where the AI Act permits integration, but should not treat internal integration as proof that a legal obligation has been removed. Simplification of the compliance pathway and elimination of the underlying duty are different outcomes.
Machinery shows how that interface is being redesigned. The act moves Regulation (EU) 2023/1230 on machinery from Section A to Section B of Annex I. The stated sectoral approach is that machinery law should incorporate essential health-and-safety requirements for relevant AI systems, while the AI Act’s direct application to those systems is limited to the provisions specified in Article 2(2). The Commission must adopt delegated acts adding relevant health-and-safety requirements to the machinery regulation, and those acts are to apply by 2 August 2028. Until machinery-specific AI standards or common specifications are referenced or adopted, the machinery framework can rely on relevant AI Act standards or common specifications where the conditions for a presumption of conformity are met.
Moving machinery to the sectoral route therefore changes the interface and timing, not the underlying safety objective. It can make one regime carry more of the detailed product work, but it also creates a dependency on delegated acts, standards, and the cooperation of the authorities that supervise machinery. For a machinery provider, “the AI Act is delayed” is an incomplete conclusion. The better question is which machinery rule is carrying which AI requirement, and whether the supporting legal and technical instrument exists.
Conformity assessment follows the product relationship
The act also clarifies how a provider should navigate conformity assessment for Section A products. The relevant product-law conformity procedure remains the route, while the AI Act’s Chapter III Section 2 requirements form part of that assessment. The Digital Omnibus creates a single-application and unified-assessment option for conformity-assessment bodies that are being designated under both the AI Act and relevant Union harmonisation legislation. A body already designated under product legislation can use the existing designation materials to support and accelerate its AI Act designation, where the conditions are met.
This reduces duplicated institutional work without making competence irrelevant. The assessment body still has to satisfy the requirements applicable to the AI Act and the product legislation, and its designation must cover the types of AI systems it assesses. The act also provides a temporary bridge for certain notified bodies already designated under product legislation: for 18 months from 27 July 2026, they may assess the AI requirements under specified conditions while applying for designation under the AI Act by 28 January 2028. That is a transition for assessment capacity, not a permanent relaxation of the standard.
Nor does high-risk classification automatically force a manufacturer into a third-party assessment. If the relevant product legislation allows a manufacturer to rely on harmonised standards without a notified body, the AI Act classification alone does not remove that option. The manufacturer may use it only if the harmonised standards, or applicable common specifications, also cover all the AI Act requirements in the relevant section. The product regime’s own choice of assessment procedure remains decisive within the conditions the final regulation sets.
The result is a more disciplined division of questions. Classification asks why the system is high-risk. Sectoral coordination asks whether another legal instrument already supplies equivalent or stronger protection. Conformity assessment asks which procedure the product law permits and how the AI requirements are incorporated. A third-party body may be required, or it may not be, depending on that combined analysis. Collapsing the three questions into “regulated product equals notified body” would recreate the confusion the Digital Omnibus is trying to remove.
The 2027/2028 split is now easier to read. The 2027 date is attached to the use-based high-risk route. The 2028 date is attached to the product-and-safety-component route. In the second route, product law may carry more of the assessment, but only through conditions designed to preserve protection and supported by later instruments. The next implementation problem follows directly from this architecture: once the route is known, what standards, authorities, testing arrangements, and guidance make the promised simplification usable in practice?