Why the high-risk classification question matters
Almost every conversation a business has about the EU AI Act reduces to a single question: is our system high-risk or not? A high-risk classification brings a risk management system, data governance duties, technical documentation, logging, human oversight, accuracy and cybersecurity requirements, conformity assessment and registration. A system outside the category carries none of that. The gap is the difference between a compliance programme and a paragraph in a policy document.
What many businesses do not realise is that appearing on Annex III — the list of high-risk use cases covering areas such as employment, education, credit and essential services — is not the end of the analysis. Article 6(3) contains a derogation: a system sitting squarely within an Annex III area can still fall outside the high-risk regime if it does not pose a significant risk of harm. That derogation is real, it is used, and it is also the most misunderstood provision in the Regulation. Getting it wrong is not a quiet internal error, because the AI Act contains a dedicated enforcement procedure aimed at precisely this mistake.
What Annex III covers, and who has to ask the question
Annex III lists eight areas: biometrics; critical infrastructure; education and vocational training; employment, workers’ management and access to self-employment; access to essential private and public services and benefits; law enforcement; migration, asylum and border control management; and administration of justice and democratic processes. Several are subdivided. Point 5, on essential services, breaks into four lettered sub-points covering public assistance benefits including healthcare, creditworthiness and credit scoring, life and health insurance pricing, and emergency call classification and dispatch.
The duty to run the analysis falls on the provider — the party that develops a system and places it on the market under its own name or trade mark. That matters for businesses that think of themselves as buyers rather than builders, because a company that puts its own branding on a system, or substantially modifies one, can find itself holding provider obligations it never planned for. If you are genuinely a deployer, the call is not yours to make — but you should be asking your supplier whether it has made one, and on what basis.
How the four conditions in Article 6(3) actually work
The provision has three subparagraphs. The first states the general test: an Annex III system is not 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. The second sets out four conditions and provides that the derogation applies where any of them is fulfilled. The third contains the override discussed below.
A narrow procedural task
The first condition covers a system intended to perform a narrow procedural task. Recital 53 gives the illustration of a system that transforms unstructured data into structured data. A system that reformats or routes information without evaluating anyone is the paradigm case. A system that scores, ranks or prioritises is not, because the moment a system sorts people by desirability it is doing considerably more than procedure.
Improving the result of completed human work
The second condition covers a system intended to improve the result of a previously completed human activity. The sequencing is the whole point: the human work must already be finished, and the AI must operate on its output rather than produce the substance of it. A tool that checks a completed assessment for internal contradictions sits comfortably here. A tool that drafts the assessment a human then signs off does not, because the human activity was not previously completed — it was performed by the machine.
Detecting patterns, and preparing the ground
The third condition covers a system intended to detect decision-making patterns or deviations from prior patterns, and which is not meant to replace or influence the previously completed human assessment without proper human review. Quality assurance and audit tooling most often relies on it, and the qualifier does a great deal of work: if the detection feeds back into the decision without a human genuinely reviewing it, the condition is not satisfied. The fourth covers a system performing a preparatory task to an assessment relevant to the Annex III use cases — indexing, searching, retrieving and linking data. The line between preparation and assessment is thinner than most businesses assume once a preparatory step starts filtering what a decision-maker ever sees.
The profiling override, which closes the door
The third subparagraph provides that, notwithstanding the first subparagraph, an Annex III system shall always be considered high-risk where it performs profiling of natural persons. The word “notwithstanding” overrides the derogation as a whole, not merely the four conditions: a system that profiles is high-risk even if it would otherwise satisfy a condition and poses no significant risk. The AI Act does not supply its own definition — Article 3, point (52), defines profiling by direct reference to Article 4, point (4), of the GDPR, meaning automated processing of personal data to evaluate personal aspects relating to a natural person. That is a broad concept, and most systems in the employment and essential services areas involve profiling by construction, which puts the derogation out of reach before anyone reaches the four conditions.
Documenting the decision, and telling the regulator you made it
Article 6(4) is the provision businesses forget. A provider that considers an Annex III system not to be high-risk must document its assessment before the system is placed on the market, is subject to the registration obligation in Article 49(2), and must provide the documentation to national competent authorities on request. Three duties, and the second surprises people.
Article 49(2) requires the provider, or where applicable the authorised representative, to register themselves and the system in the EU database referred to in Article 71 before it goes to market. The content is set out in Annex VIII, Section B, and the Digital Omnibus trimmed it: points 7 and 9 were deleted, so the database entry now carries less information than the original 2024 text required. Registration itself remains mandatory. What that means in practice is that relying on the derogation is still a positive act of self-identification to regulators, recorded in a Commission-run database — while the fuller reasoning stays in the documentation the provider must hold under Article 6(4) and produce to national competent authorities on request.
One further wrinkle. Article 6(5) required the Commission to provide guidelines on the practical implementation of Article 6 no later than 2 February 2026. Draft guidelines appeared on 19 May 2026 and a consultation ran until 23 July 2026, but none has been adopted. The Digital Omnibus on AI, Regulation (EU) 2026/1744, deferred the Annex III high-risk obligations to 2 December 2027 but did not move the guidance deadline and did not amend Article 6(3), (4) or (5) at all. Businesses assessing their systems today are assessing against a standard the Commission has not finished writing.
Practical example
A Malmö industrial services group with around three hundred employees introduces two AI tools into hiring. The first reads incoming applications and converts free-text CVs into structured fields — education, years of experience, certifications — so recruiters can search them consistently. The second scores each candidate against the role and presents a ranked shortlist.
The first has a strong claim to the narrow procedural task condition: it transforms unstructured data into structured data, the illustration the Regulation itself gives, and it evaluates nobody. The second is a different matter. Ranking candidates by suitability is automated processing of personal data to evaluate personal aspects relating to natural persons, which is profiling within the GDPR definition Article 3(52) imports. The override applies, and the tool is high-risk however narrowly the group would like to describe it. Recruitment sits in Annex III point 4, which in Sweden falls to Post- och telestyrelsen for market surveillance under the interim designations — a point that surprises HR teams who assume anything touching employees belongs to Integritetsskyddsmyndigheten. The group therefore cannot make one classification decision about “our recruitment AI”: it must assess tool by tool.
Common mistakes companies make
The first is treating the derogation as a conclusion rather than an argument. Businesses find a condition that roughly fits, stop reading, and never test whether the system profiles. Because the override sits in the third subparagraph, after the conditions, it is easy to miss on a quick read — and it is the limb that most often decides the answer.
The second is failing to document contemporaneously. An assessment written up after a regulator asks is not compliance with Article 6(4); it is evidence that Article 6(4) was not complied with.
The third is assessing the product rather than the function. The test applies to the AI system and its intended purpose, not to the invoice.
The fourth is assuming a wrong call can be quietly corrected later. Article 80 is a bespoke procedure titled, in terms, for AI systems classified by the provider as not high-risk in application of Annex III. Where a market surveillance authority has sufficient reason to consider that such a system is in fact high-risk, it must evaluate it, and on a finding of high-risk require the provider to bring the system into compliance within a prescribed period. It provides separately for fines both where the provider fails to remediate and where the authority establishes that the system was misclassified in order to circumvent the high-risk requirements.
Recommended actions
Build an inventory at the level of AI systems and their intended purposes, not products or vendors, and map each against the eight Annex III areas and their sub-points. For anything landing in Annex III, run the profiling question first rather than last, because a system that profiles is high-risk and no amount of work on the four conditions will change that. Only where profiling is genuinely absent should you move on to whether a condition is met, and expect that analysis to be finely balanced more often than not.
Where you conclude the derogation applies, write the assessment down before the system goes live, in enough detail that an authority reading it cold can follow the reasoning — which condition you relied on, what the system does and does not do, and why no significant risk arises. Treat the Article 49(2) registration as part of the same workstream, since it makes the decision visible to regulators. And diarise the Commission’s guidelines: when adopted, every borderline assessment made in the meantime will deserve a second look.
Frequently asked questions
If our system meets one of the four conditions, is that the end of the analysis?
Not quite. The derogation applies where any one of the four conditions is fulfilled, but the first subparagraph frames it around not posing a significant risk of harm, and the third makes profiling an absolute bar. The safest position is to be able to explain why no significant risk arises, and to be certain the system does not profile.
Do we have to publish our assessment?
No. Article 6(4) requires you to document it and to provide it to national competent authorities on request. What becomes visible is the Article 49(2) database entry, and the Digital Omnibus reduced what that entry contains by deleting points 7 and 9 of Annex VIII Section B. The registration duty itself is unchanged. The full assessment stays with you until an authority asks for it.
Does the deferral to 2 December 2027 mean we can postpone this analysis?
The Digital Omnibus deferred the obligations, but the classification analysis is what tells you whether you have until 2 December 2027 to build a compliance programme or nothing to build at all. A business that has not classified its systems does not know which position it is in, and cannot plan. The analysis also feeds procurement, customer due diligence and investor questions that are already being asked.
Conclusion
Article 6(3) is a genuine route out of the high-risk regime, and businesses should use it where it honestly applies. But it is a narrow door with a lock on it. The conditions are drafted tightly, the profiling override closes the door on most systems that evaluate people, the assessment must be documented before launch, and the decision must be registered where regulators can see it. Treated seriously, it is valuable compliance work. Treated as a way of making the AI Act go away, it is an invitation to the one enforcement procedure the Regulation wrote for this mistake.
Lawgent helps businesses classify their AI systems under the EU AI Act, document Article 6(3) assessments that hold up to regulatory scrutiny, and register them correctly in the EU database.
