Article 6 provides two routes to high-risk status. Article 6(1) covers AI systems intended to be used as a safety component of a product, or themselves a product, covered by the Union harmonisation legislation listed in Annex I, where the product is required to undergo third-party conformity assessment under that legislation. Article 6(2) covers AI systems referred to in Annex III, subject to the Article 6(3) filter. Both routes turn on intended purpose, and a system should be tested against both routes, in that order, with the reasoning recorded, before any conclusion about high-risk status is drawn.
Why does Article 6 sit at the centre of the Act?
Article 6 decides whether the Chapter III Section 2 requirements, the provider duties in Section 3, the conformity assessment, the declaration of conformity, CE marking and registration duties apply to a system. A wrong classification therefore has consequences in both directions: a high-risk system treated as ordinary escapes controls, documentation and oversight, while an ordinary system treated as high-risk carries unnecessary conformity work and may be delayed or withdrawn. The article is deliberately structured as a test with defined elements, not as a general risk judgement. A team should work through the elements in order, record the evidence for each, and keep the conclusion open where evidence is missing, rather than deciding by analogy with another product.
How does the Article 6(1) product route work?
The product route has two cumulative conditions. First, the AI system must be intended to be used as a safety component of a product, or must itself be a product, covered by the legislation listed in Annex I. Second, the product must be required to undergo a third-party conformity assessment under that legislation. The Omnibus amendments added paragraphs (1a) to (1c), which address systems used solely for non-safety aspects such as user assistance, performance optimisation, service efficiency, automation, convenience or quality control, systems whose failure would endanger health and safety, and products whose third-party assessment is required solely for non-safety risks. Those paragraphs must be read with Article 6(1) in the consolidated text, and the Annex I section covering the product determines how the AI requirements are assessed.
For the broader regulatory framework, see high-risk AI systems.
How does the Article 6(2) Annex III route work?
Article 6(2) provides that, in addition to the systems in paragraph 1, AI systems referred to in Annex III shall be considered high-risk. Annex III lists use cases in eight areas: biometrics, critical infrastructure, education and vocational training, employment and workers management and self-employment, access to essential private and public services and benefits, law enforcement, migration and asylum and border control management, and administration of justice and democratic processes. The route is use-case based: the system must be intended to be used for a listed use case. A general description of a sector is not enough. The specific point in Annex III, its wording, and its conditions must be matched to the intended purpose, and the Article 6(3) filter must then be considered.
In what order should the two routes be tested?
Test the Article 5 prohibition screen first, then Article 6(1), then Article 6(2) with the Article 6(3) filter, then Article 50 and Chapter V separately. Testing Article 6(1) first matters for product teams, because a product conclusion changes the conformity route and the body that assesses it. Testing Article 6(2) second matters for use-case teams, because an Annex III match can be high-risk even where no product legislation is involved. A system can meet both routes, and the record should state both findings separately, because the conformity and registration consequences can differ by route. A system that meets neither route is not high-risk under Article 6, but that conclusion must still be evidenced and the other tiers checked.
What does intended purpose do in Article 6?
Intended purpose is the use for which a system is intended by the provider, including the specific context and conditions of use, as specified in the instructions for use, promotional material, and technical documentation. It is the provider's specified purpose, not the deployer's private hope or the user's improvisation, although a deployer's change of purpose can trigger Article 25. In classification, intended purpose determines which Annex III point is relevant, whether a product function is a safety function, and whether the system is used as described. A vague intended purpose, such as improving decisions in general, cannot be tested against Annex III. The purpose should be stated specifically enough that a reviewer can match it to a point in the annex or explain why no point matches.
Continue with Annex I Section A.
What is not decided by this overview?
This guide explains the routes and the order of testing. It does not classify any particular system, does not decide whether a product is covered by Annex I, and does not decide whether a use case matches Annex III. Those conclusions need the intended purpose, the product and safety analysis, the Annex III point wording, and the Article 6(3) filter evidence, read in the consolidated text. Borderline classifications, where a small change in purpose or context changes the route, should be confirmed with a competent authority or legal adviser, and the classification should be documented before the system is placed on the market or put into service.
Frequently asked questions
Can a system be high-risk through both Article 6 routes?
Yes. A system can be a safety component of an Annex I product and also be intended for a listed Annex III use case. Both findings should be recorded separately, because the conformity route and the evidence needed can differ.
Does a system need to be sold to be classified?
No. Classification is based on intended purpose and the Article 6 tests, and it should be done before placing on the market or putting into service, so that conformity and documentation work can be planned. Own-use systems put into service are also within the analysis.
What if the intended purpose is described very broadly?
A broad description cannot be tested against Annex III or Annex I. The purpose should be specified with its context and conditions, so that a reviewer can match it to a point in the annex or explain why no point matches, and so that a later change of purpose is visible.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗European Commission regulatory framework for AI ↗