Let’s talk
Wondering how this plays out in your organisation? Get in touch — I answer personally.
Short answer
Whether a given tool is a high-risk AI system is not settled by its name or by how advanced its model is. What settles it is the intended purpose of the system, including a purpose given to it by the organisation itself. Two independent routes lead to high risk — the system as a safety component of a product covered by Annex I, and a use case listed in Annex III. The second route has an exit under the conditions of Article 6(3), but profiling of natural persons closes that exit without exception.
Why this question arises at all
Regulation (EU) 2026/1744 postponed the application of the requirements for high-risk AI systems. Sections 1–3 of Chapter III apply from 2 December 2027 to systems listed in Annex III and from 2 August 2028 to systems covered by Annex I. The postponement also covers the classification rules themselves, because Article 6 belongs to the first section of that chapter. Systems placed on the market or put into service before those dates fall under the Regulation only after a significant change in their design, and systems intended for use by public authorities must achieve compliance by 2 August 2030 (Article 111(2)). It is easy to read these changes as a reason to put the subject off.
What can be postponed is implementing the requirements, not establishing the scope. The requirements of Chapter III range from data quality to conformity assessment, and preparing for them is measured in quarters. Classification therefore determines the budget and the order of work, not a deadline that is about to expire.
One provision of Article 6 was not postponed. Paragraph 5 obliges the European Commission to issue guidelines on the practical implementation of that Article, and the deadline passed on 2 February 2026. The Commission published the draft guidelines on 19 May 2026 and closed the consultation on 23 July 2026. At the beginning of September 2026 the document remains a draft, and the Commission has announced adoption of the final version by the end of 2026. An organisation that classifies its use cases today relies on the wording of the Regulation.
What has to be established before a decision
High-risk AI system — two routes to classification
The first route concerns products. A system becomes a high-risk AI system by this route when two conditions are met at the same time (Article 6(1)). The system must be intended to be used as a safety component of a product covered by the Union harmonisation legislation listed in Annex I, or be such a product itself. The second condition is that this product is required to undergo a third-party conformity assessment under that legislation. Annex I covers toys, lifts and medical devices among other products, so the first route mainly concerns manufacturers. Machinery has been moved to Section B of Annex I, and for AI systems classified as high-risk under Article 6(1) that relate to products covered by that section the Regulation applies only to a narrow extent (Article 2(2)).
The second route concerns use cases. A system listed in Annex III is, as a rule, a high-risk AI system (Article 6(2)). This route does not require any link to a product covered by Annex I. In my assessment this is the route through which most organisations outside manufacturing encounter classification, because Annex III describes mainly use cases rather than industries.
The two routes are checked separately. A manufacturer that builds an AI module into its own products and at the same time uses a tool to assess job candidates faces two independent classification questions.
When a system is not a safety component
Regulation 2026/1744 added three paragraphs to Article 6 that clarify the first route. AI systems used solely for non-safety related aspects listed in the provision do not qualify as safety components (paragraph 1a). The provision lists user assistance and performance optimisation. It also lists service efficiency, automation or convenience and quality control. There is one exception to this exclusion. Where failure or malfunctioning of the system would endanger health and safety, the system remains a safety component (paragraph 1b).
The third new paragraph concerns the conformity assessment procedure. A product that is required to undergo a third-party conformity assessment solely due to risks other than risks to health and safety is not considered to fulfil the condition in point (b) of paragraph 1 (paragraph 1c). The provision gives the example of risks relating to the distribution of radio spectrum or electromagnetic interference that do not affect health and safety. In my assessment the amendment takes out of scope some devices that would otherwise be classified as high-risk solely because of radio testing.
What Annex III describes
Annex III lists eight areas. Three of them mainly concern the activities of public authorities. These are law enforcement (area 6), migration, asylum and border control management (area 7) and the administration of justice and democratic processes (area 8). The remaining five may also concern an ordinary organisation.
In my assessment the area that most often affects organisations is area 4, which covers employment, workers’ management and access to self-employment. It includes tools for the recruitment or selection of candidates, among them tools for placing targeted job advertisements and filtering applications. It also includes tools supporting decisions on the terms of work-related relationships and on the promotion or termination of work-related contractual relationships. Finally, the area covers allocating tasks based on individual behaviour or personal traits or characteristics and monitoring and evaluating the performance and behaviour of workers.
Area 5 covers access to essential services, including the creditworthiness assessment of natural persons and risk assessment and pricing in relation to natural persons in life and health insurance. Area 1 concerns biometrics, area 2 safety components of critical infrastructure and area 3 education and vocational training. The creditworthiness category expressly excludes systems used for detecting financial fraud.
The Annex describes the intended purpose of a system, not a category of tool. The same tool based on a language model stays outside the Annex when it suggests the content of a letter and enters area 4 when it filters candidates’ applications. If the provider did not foresee such a purpose and the system becomes a high-risk AI system because of it, the organisation giving it that purpose becomes its provider (Article 25(1)(c)).
Remember
It is the use case that is classified, not the purchased licence.
When the Article 6(3) derogation really applies
The derogation requires two conditions to be met together. The first is general. The system must not pose a significant risk of harm to the health, safety or fundamental rights of natural persons. The provision adds that this includes not materially influencing the outcome of decision making. The second condition is one of the four situations listed in the provision.
- the system is intended to perform a narrow procedural task;
- the system is intended to improve the result of a previously completed human activity;
- the system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment without proper human review;
- the system is intended to perform a preparatory task to an assessment relevant for the purposes of the use cases listed in Annex III.
Reducing this provision to the list alone leads to misclassification. A tool performing a narrow procedural task remains a high-risk AI system if it nevertheless poses a significant risk of harm.
Profiling rules out the derogation
A system listed in Annex III that performs profiling of natural persons is always a high-risk AI system (Article 6(3), third subparagraph). The Regulation does not create its own definition of profiling. It refers to Article 4(4) GDPR, that is, to automated processing of personal data used to evaluate personal aspects relating to a natural person (Article 3(52)).
This cross-reference has a practical effect. The record of processing activities and the data protection impact assessment often already provide material for answering the question about profiling. However, the record under Article 30 GDPR does not require profiling to be indicated, and an impact assessment is mandatory only for processing likely to result in a high risk (Article 35 GDPR). The absence of an entry therefore does not prove that there is no profiling. Comparing the list of AI use cases with these documents is a starting point, not an answer. A tool that assesses candidates or measures employee performance usually falls within area 4 of Annex III and profiles natural persons at the same time.
Who documents the assessment that a system is not a high-risk AI system
The obligation to document the assessment rests with the provider. A provider that considers an AI system listed in Annex III not to be high-risk documents its assessment before the system is placed on the market or put into service. It is also subject to the registration obligation under Article 49(2) and provides the documentation of the assessment at the request of national competent authorities (Article 6(4)). The deployer has no documentation obligation of its own under this provision.
Even so, I recommend recording your own classification together with its justification. It determines which obligations the organisation will have to fulfil and when preparations should start. Changing the intended purpose of an off-the-shelf tool so that it becomes a high-risk AI system also transfers the provider role to the organisation, together with the obligations under Article 16 (Article 25(1)(c)). This and the two other circumstances in Article 25(1) are covered in When does an organisation using AI become the provider of a system?.
Six questions that structure classification
| Question | What to establish | Where to look |
|---|---|---|
| Is the system a safety component of a product? | the intended purpose of the system and the conformity assessment procedure for the product | Article 6(1) and (1a)–(1c), Annex I |
| Does the use case fall within Annex III? | the intended purpose given by the provider and what the organisation actually uses the tool for | Article 6(2), Annex III |
| Does the derogation apply? | no significant risk of harm and one of the four conditions | Article 6(3), first and second subparagraphs |
| Does the system profile natural persons? | how the system works, with the record of processing activities and the impact assessment as secondary sources | Article 6(3), third subparagraph, in conjunction with Article 3(52) |
| Does our use change the organisation’s role? | the extent of modification and the purpose given to the tool | Article 25(1) |
| When do the requirements actually become binding? | the classification route and the date the system was placed on the market or put into service | Article 113, third paragraph, point (c) and Article 111(2) |
Common mistakes
- Classifying the tool instead of the use case. A single licence may be used in several processes, and each of them is classified separately.
- Reading the derogation as a list of four loopholes. The condition of no significant risk of harm applies regardless of them.
- Overlooking the profiling clause. For systems listed in Annex III it settles classification regardless of any other arguments.
- Assuming that the postponed deadlines take the subject off the agenda. What was postponed is the application of the requirements, not the time needed to prepare.
- Treating the Commission’s draft guidelines as a binding document. Classification is justified by the wording of the Regulation.
- Checking Annex III only. An organisation that builds AI into its own products must also check the first classification route.
- Accepting the provider’s declaration without comparing it with your own use. The declaration describes the intended purpose given by the provider, not how the recipient actually uses the tool.
Conclusions and next steps
Classification is today an analytical task, not an obligation with a deadline. Its outcome, however, determines how much time the organisation really has and what it will spend that time on. The order of work looks the same in most organisations.
- Compile a list of AI use cases, with a description of the process in which the tool operates and the person responsible for its use.
- For each use case, check both classification routes and record the outcome together with its justification.
- Compare the list of use cases with the record of processing activities and establish for each use case whether the system profiles natural persons.
- For use cases listed in Annex III, check whether the Article 6(3) derogation really applies and describe both conditions separately.
- Collect from providers the documents describing the intended purpose of the tool and the limitations on its use.
- Plan preparations for use cases classified as high-risk, taking 2 December 2027 as the reference date for systems listed in Annex III. For systems already in use before that date, check the effect of Article 111(2).
- Include classification in the periodic review, because a change in how a tool is used changes the outcome.
Related materials
- When does an organisation using AI become the provider of a system? — three circumstances in which the obligations of a provider pass together with the role
- What should an AI use register contain? — the list of use cases with which classification begins
- Who is responsible for AI Act transparency obligations? — obligations that apply regardless of the risk level
Sources
- Regulation (EU) 2024/1689 of the European Parliament and of the Council (Artificial Intelligence Act), consolidated text as at July 27, 2026, Article 2(2), Article 3(52), Articles 6, 16 and 25, Article 49(2), Articles 111 and 113 and Annexes I and III — EUR-Lex: eur-lex.europa.eu (accessed September 10, 2026)
- Regulation (EU) 2026/1744 of the European Parliament and of the Council of July 8, 2026 (digital omnibus on AI), Article 1 as regards the amendments to Articles 2, 6, 111 and 113 and Annex I to Regulation (EU) 2024/1689 — EUR-Lex: eur-lex.europa.eu (accessed September 10, 2026)
- Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), Article 4(4), Article 30 and Article 35 — EUR-Lex: eur-lex.europa.eu (accessed September 10, 2026)
- European Commission, draft guidelines on the classification of high-risk AI systems, published May 19, 2026, consultation closed July 23, 2026 — the document remains a draft — European Commission: digital-strategy.ec.europa.eu (accessed September 10, 2026)
- European Commission, targeted consultation on the draft guidelines on the classification of high-risk AI systems — deadline extended to July 23, 2026, adoption of the guidelines announced by the end of 2026 — European Commission: digital-strategy.ec.europa.eu (accessed September 10, 2026)
Find out which AI use cases will require the most work
Classification determines the scope of preparations and which tools need attention now. AI use case review covers compiling the list of use cases, establishing the organisation’s role and classifying each of them with a justification.
This material is general and educational in nature. It is not an individual legal opinion or a recommendation for any specific organisation. The scope of the obligations should be assessed against the situation of the organisation concerned.
Legal status: September 2026.