How to Classify an AI System Under the AI Act

Before classification: is it actually an AI system?

The first question should not be whether the system is high-risk. It should be:

Are we actually dealing with an AI system for the purposes of the AI Act?

Article 3 defines an AI system as a machine-based system designed to operate with varying levels of autonomy, which may display adaptiveness after deployment and, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as:

• predictions
• content
• recommendations
• decisions

that can influence physical or virtual environments.

Not every automation, business rule or conventional software application should therefore be classified automatically as an AI system.

The organisation must examine the system's actual nature. This avoids applying the rest of the regulatory decision tree to tools outside the definition.

First filter: prohibited AI practices

If the tool is an AI system, the next step is to review Article 5.

The AI Act prohibits certain AI practices. This is not a category of “high risk”; it concerns uses that are prohibited when the precise conditions in the Regulation are met.

The check should therefore take place before the high-risk classification analysis continues.

The question is not whether the system merely appears problematic. It is:

Do its intended purpose and manner of use fall precisely within a prohibited AI practice under Article 5?

If they do, the system should not be treated simply as one requiring additional controls. The relevant prohibition must be analysed.

Second route: high-risk systems under Article 6(1)

The AI Act provides a first route for classifying high-risk AI systems.

Two conditions must both be met.

First, the system is intended to be used as a safety component of a product covered by the Union harmonisation legislation listed in Annex I, or is itself such a product.

Second, that product must undergo a third-party conformity assessment before it may be placed on the market or put into service.

The existence of a regulated product alone is not sufficient. Both conditions must be satisfied.

This route is particularly relevant to certain products governed by EU sectoral legislation.

Third route: Annex III systems

The other main high-risk route appears in Article 6(2).

Systems falling within the use cases listed in Annex III may be considered high-risk.

Annex III covers areas including:

• biometrics
• critical infrastructure
• education and vocational training
• employment and worker management
• access to certain essential private and public services and benefits
• law enforcement
• migration, asylum and border control
• administration of justice and democratic processes.

It is not enough for a company merely to operate in one of these sectors. The specific use case must be examined.

Using an AI tool within Human Resources, for example, does not automatically make it high-risk. Its use for recruitment, selection, promotion, allocation of tasks based on personal characteristics or performance assessment must be checked against the relevant Annex III wording.

The intended purpose is decisive.

The Article 6(3) exception

This is one of the points most likely to be misunderstood.

A system within an Annex III use case may not be considered high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision-making.

Article 6(3) identifies circumstances that may support that conclusion, including where a system:

• performs a narrow procedural task
• improves the result of a previously completed human activity
• detects patterns or deviations without replacing or materially influencing a proper human assessment
• performs a preparatory task for an assessment listed in Annex III.

The exception should never be applied automatically. The actual use must be assessed.

Furthermore, a provider concluding under Article 6(3) that an Annex III system is not high-risk must document that assessment before placing the system on the market or putting it into service.

The limit to the exception: profiling

Article 6(3) contains an important limit.

An Annex III system that performs profiling of natural persons is considered high-risk.

The Article 6(3) exception cannot therefore be used to avoid classification where profiling is present in the applicable sense.

This point is especially relevant to systems concerning:

• employment
• access to services
• assessment of people
• individual classification or segmentation.

The organisation should check this expressly.

What if the system is not high-risk?

A conclusion of “not high-risk” does not automatically mean “no obligations”.

Other parts of the AI Act may still apply. The guide to AI Act obligations for business and the overview of the AI Act for business provide the wider context.

There may also be:

• transparency obligations
• AI literacy obligations
• duties arising from the organisation's role as provider or deployer
• requirements under other legislation
• internal governance controls
• risk management
• data protection
• security
• contractual obligations.

A system that is not legally high-risk may still create material business, reputational, operational or human impacts.

Regulatory classification and internal AI risk management are related, but they are not equivalent.

Article 50 transparency obligations

Article 50 establishes specific transparency obligations for certain AI systems.

They may apply, for example, to systems intended to interact directly with people. There are also rules concerning certain AI-generated or manipulated content, emotion-recognition systems, biometric categorisation and certain deepfakes or public-interest content.

These duties do not automatically make the system “high-risk”. They must be analysed separately.

Once a system has been found not to be high-risk, the assessment should therefore continue with another question:

Does any transparency obligation apply?

The organisation’s role also matters

System classification is only one part of the analysis. The organisation's role must also be identified.

The AI Act distinguishes, among others, between:

• provider
• deployer
• importer
• distributor
• authorised representative.

The same technology may create different obligations depending on the role performed by the organisation.

Using a third-party tool is not the same as developing a system and marketing it under the organisation's own name.

The AI inventory should therefore record both the system's classification and the organisation's role. Clear AI governance roles and responsibilities are also needed to assign ownership of the assessment and its review.

How to classify an AI system step by step

A practical method can follow this sequence:

Step 1. Confirm that it is an AI system

Check whether it falls within the Article 3 definition. If it does not, document that conclusion and do not continue applying the AI Act classification tree as though it did.

Step 2. Review Article 5

Check whether the intended purpose or manner of use falls within a prohibited practice. If it does, analyse the relevant prohibition.

Step 3. Review Article 6(1)

Ask:

• is the system a safety component of an Annex I product, or such a product itself?
• must that product undergo third-party conformity assessment?

If both conditions are met, the system is high-risk.

Step 4. Review Article 6(2) and Annex III

Check whether the precise use case appears in Annex III. Do not classify by sector alone; assess intended purpose and context.

Step 5. Check Article 6(3)

If the system falls within Annex III, determine whether any condition supporting a conclusion that it is not high-risk genuinely applies.

Step 6. Check for profiling

Where the Annex III system performs profiling of natural persons, apply the limit in Article 6(3).

Step 7. Review Article 50

Even where the system is not high-risk, check for applicable transparency obligations.

Step 8. Identify the role

Determine whether the organisation acts as provider, deployer, importer, distributor or another operator.

Step 9. Document the decision

Record:

• system
• intended purpose
• use case
• articles assessed
• annexes reviewed
• conclusion
• owner
• evidence
• date
• next review.

The classification should remain explainable months later without relying on one person's memory.

Practical example: candidate selection system

Consider an AI system used to analyse CVs and recommend candidates to a recruitment team.

Is it an AI system?

First, check whether it meets the Article 3 definition.

Is there a prohibited practice?

Review Article 5 against the precise functionality.

Does Article 6(1) apply?

This type of system would not ordinarily follow the Annex I regulated-product route.

Does it fall within Annex III?

Annex III covers certain systems intended for recruitment and selection. The case therefore requires assessment as a potentially high-risk AI system.

Can Article 6(3) apply?

Only where its conditions are genuinely met and the system neither poses a significant risk nor materially influences the outcome in the terms set by the Regulation.

Does it perform profiling?

If it profiles natural persons in the relevant context, this directly affects whether the exception can be used.

The analysis should not be reduced to “it is an HR tool, therefore it is high-risk”. It should explain the function the system actually performs.

An AI impact assessment may then complement the classification by examining consequences for affected people.

What evidence should be retained

The classification assessment should leave sufficient evidence, including:

• system name and version
• provider
• intended purpose
• process and users
• the organisation's role
• assessment of the AI system definition
• Article 5 review
• Article 6(1) review
• Annex III review
• Article 6(3) analysis
• profiling analysis
• Article 50 review
• conclusion
• responsible person
• date
• evidence used.

There is no need to produce dozens of pages for every tool, but the conclusion must be traceable and integrated into AI governance.

When classification should be reviewed

Classification should not be treated as permanent.

It should be reviewed when there is a change to:

• intended purpose
• context of use
• model
• provider
• functionality
• data
• affected population
• level of autonomy
• the organisation's role
• the regulatory framework.

It should also be revisited when new information emerges about actual system performance.

A system initially used for a preparatory task may later become directly integrated into a decision. That change may alter its classification.

Common mistakes

Classifying by the tool's name

The commercial name does not determine classification. Intended purpose and actual use do.

Assuming everything related to employment is automatically high-risk

The specific Annex III use case must be checked.

Skipping Article 6(3)

Falling within Annex III does not mean the exception analysis should be ignored.

Applying Article 6(3) without documenting it

Where the provider must document the conclusion, that evidence must exist.

Forgetting profiling

Profiling may directly change the outcome of the Article 6(3) analysis.

Treating “not high-risk” as “no obligations”

Transparency duties and other requirements may still apply.

Confusing internal risk with legal classification

An organisation may consider a system materially risky internally even where it is not legally a high-risk AI system.

Failing to review classification

A change in intended purpose may turn an apparently simple use into a different regulatory case.

Classification is not a label: it is a justified decision

A sound classification should not end with a cell saying “high-risk” or “not high-risk”.

It should allow the organisation to reconstruct why it reached that conclusion: which system was assessed, its intended purpose, the relevant article and annex, any exception considered, the organisation's role and the obligations remaining afterwards.

When that reasoning is documented, classification stops being an opinion and becomes a traceable governance decision. ISO/IEC 42001 can help integrate that decision into a wider AI management system.

References

• Regulation (EU) 2024/1689 — AI Act.
• Article 3 — definition of an AI system.
• Article 5 — prohibited AI practices.
• Article 6 — classification of high-risk AI systems.
• Annex I — Union harmonisation legislation.
• Annex III — certain high-risk AI systems.
• Article 50 — transparency obligations.