Skip to Content
Home » Blog » AI » EU AI Act Part 2 – The Classification Audit: A Decision Framework for Article 6
May 18, 2026

EU AI Act Part 2 – The Classification Audit: A Decision Framework for Article 6

EU AI Act Part 2 – The Classification Audit: A Decision Framework for Article 6

Post 1 of this series established why your documentation may have already created high-risk classification exposure without any deliberate choice on your part. This post gives you the tool to find out by providing a step-by-step decision framework for working through the Article 6 classification test.

 

Article 6 operates through two independent pathways. A system can be high risk under Pathway 1 (Article 6(1) and Annex I) regardless of whether it falls under Pathway 2 (Article 6(2) and Annex III), and vice versa. Work through separately for each AI system you are assessing.

Pathway 1: Article 6(1), Products and Safety Components

This pathway applies to AI systems embedded in physical products regulated under EU harmonization legislation, including machinery, medical devices, vehicles, toys, lifts, radio equipment, pressure equipment, and others listed in Annex I of the AI Act. Classification under this pathway requires two cumulative conditions to be satisfied.

 

Step 1: Is the AI system a product covered by Annex I legislation, or a safety component of such a product?

An AI system is the product itself, where it is independently placed on the market, has its own intended purpose, and is directly regulated by one of the Annex I legislative acts. Under the Machinery Regulation (EU) 2023/1230, for example, certain software that is itself machinery-related can be a regulated product.

 

An AI system is a safety component where it is, or is intended to be, part of a regulated product. The AI Act’s definition of “safety component” in Article 3(14) covers two distinct scenarios:

 

  • The safety function scenario: Here, the AI system’s intended purpose, as defined by the provider, is to prevent or mitigate risks to the health and safety of persons or property. Examples include collision detection systems, emergency stop logic, and gas leak monitoring.
  • The failure or malfunction scenario: Even if the system has no safety related intended purpose, its failure or malfunction would endanger the health and safety of persons or property.

This second scenario is the one most product teams miss. It requires a different kind of analysis. Instead of asking, “what is this system designed to do?” you should ask, “what happens to the product’s safety profile if this system stops working correctly?”

 

Practical test for the failure or malfunction scenario: Map the AI system to the product’s hazard profile. Identify every mode in which the AI system could fail, including incorrect outputs, availability loss, performance drift, and latency errors. For each failure mode, ask whether this failure causes the product to enter an unsafe state, keeps it in an unsafe state, or prevents it from remaining in a safe state. If the answer is yes for any failure mode, the system is likely a safety component regardless of its intended purpose.

 

If the answer is no to Step 1 entirely, meaning the system is neither a regulated product nor a safety component of one, stop. Pathway 1 does not apply.

 

Step 2: Is the product required to undergo a third-party conformity assessment?

This is not simply a question of which conformity assessment module the manufacturer chose. The Commission’s draft guidelines clarify that where Union harmonization legislation makes the application of harmonized standards a mandatory precondition for using an internal control only module, such as Module A under the Toys Safety Regulation or Machinery Regulation, the product type is still subject to enhanced regulatory scrutiny for AI Act classification purposes, regardless of which module the individual manufacturer selects.

 

If both Step 1 and Step 2 are satisfied, the AI system is high-risk under Pathway 1.

Pathway 2: Article 6(2), Annex III Use Cases

This pathway applies to stand alone AI systems intended to be used for specific purposes across eight high risk areas. The classification question is whether the system’s documented intended purpose falls within one of the use cases explicitly listed in Annex III.

 

Step 1: Map the intended purpose to the eight Annex III areas

The eight areas are: biometrics; critical infrastructure; education and vocational training; employment and workers’ management; access to essential services and benefits; law enforcement; migration, asylum and border control; and administration of justice and democratic processes.

 

If the system’s intended purpose has no plausible connection to any of these areas, it is not high-risk under Pathway 2.

 

Step 2: Does the intended purpose fall within a specific listed use case?

Within each area, Annex III lists specific use cases. The list is exhaustive. Being in a high-risk area is not sufficient. The intended purpose must match a specific use case.

 

Work from the documented intended purpose, not from what the system technically could do. If the documentation establishes that the system is intended for use in credit scoring, performance evaluation, or biometric identification, to name three examples, it is within scope. If the documentation limits the system to uses that fall outside every listed use case, it is not.

 

Step 3: Does the Article 6(3) filter apply?

Even if the intended purpose falls within a listed use case, the provider may be able to demonstrate that the system does not pose a significant risk of harm and therefore qualifies for exemption. This is the subject of Post 3 in this series. Flag it here as the next question to ask before concluding that the system is definitively high risk under Pathway 2.

What to Do With Your Results

If any path through this framework produces a “possibly high risk” outcome, three things follow:

 

Document your reasoning. Article 6(4) of the AI Act requires providers who conclude their system is not high risk, relying on the filter mechanism, to document that assessment before placing the system on the market. Build the record now while the reasoning is fresh.

 

Revisit your documentation. The classification outcome is only as reliable as the intended purpose documentation you fed into it. If the documentation is inconsistent or ambiguous, fix the documentation before drawing conclusions from it.

 

Run the analysis again after any significant change. Classification is not a one-time exercise. Any substantial change to the system’s functionality or documentation requires a fresh assessment.

 

The framework above tells you whether you have a high-risk system. Part 3 tells you whether you can get out of it.

Next in the series: Post 3 – The Article 6(3) Filter: Your Escape Valve Has a Catch

 

The Paper Trail series is based on the European Commission’s draft guidelines on the classification of high-risk AI systems under Article 6 of Regulation (EU) 2024/1689, published May 19, 2026, for stakeholder consultation. The guidelines are not yet final. Nothing in this series constitutes legal advice.