Claiming the Article 6(3) Exemption and Documenting the Case

A procurement or architecture review reaches the point where someone says the quiet part out loud. The tool shortlists job applicants, or scores loan files, or flags exam scripts for a second look, but "a person always makes the final call", so surely this is not a high-risk system. The programme that follows a high-risk classification is substantial: a risk management system, data governance evidence, technical documentation, logging, designed human oversight, a conformity assessment and an entry in the EU database. Article 6(3) of the EU AI Act offers a way out of it. That is precisely why it attracts optimistic reasoning.

The derogation is real and it is available. It is also narrower than most first readings assume, it belongs to one party only, and using it creates its own paperwork and its own registration duty. Misclassifying is not a neutral outcome. A system you treated as exempt has no Article 9 risk file, no Article 11 technical documentation and no conformity assessment, so a regulator that disagrees with your classification finds you non-compliant on all of those points at once, not just on the classification itself.

What Article 6(3) actually says

Article 6(2) makes systems falling within Annex III high-risk. Article 6(3) derogates from that where the system 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. That is the first limb, and it is the substantive one.

The second limb is that at least one of four listed conditions must be met. Treat it as a conjunctive test: satisfying a condition does not by itself deliver the exemption if the system still materially influences an outcome that affects people. Many internal assessments invert this, picking a condition first and reasoning backwards to the risk conclusion. That is the wrong order and it shows in the file.

Condition	What it is aimed at	Where the claim usually fails
(a) Narrow procedural task	Bounded, mechanical processing, such as converting unstructured text into structured fields	The task is described narrowly but its output feeds straight into the ranking or score
(b) Improving the result of a previously completed human activity	Tidying, formatting or refining work a person has already finished	The human activity is not genuinely complete before the system runs
(c) Detecting decision-making patterns or deviations from them	Audit and quality-assurance overlays reviewing past decisions	The output is routed back into the live decision as a prompt, replacing or influencing the prior human assessment without proper human review
(d) Performing a preparatory task to an Annex III assessment	Indexing, translating or collating material ahead of the real assessment	The preparation embeds a substantive judgement, such as relevance scoring or shortlisting

There is then an override that decides most cases before the conditions are reached. An Annex III system is always high-risk where it performs profiling of natural persons. Profiling carries its GDPR meaning: automated processing of personal data to evaluate personal aspects, in particular to analyse or predict performance at work, economic situation, health, reliability, behaviour, preferences, location or movements. Most people-facing Annex III use cases involve exactly that. If your system profiles, stop the analysis and classify it as high-risk.

Who this duty falls on

The Article 6(3) assessment is a provider duty. Article 6(4) requires a provider who considers an Annex III system not to be high-risk to document that assessment before the system is placed on the market or put into service, and to produce the documentation to national competent authorities on request. A deployer buying a system does not make this call for the vendor and cannot rely on an undocumented vendor assertion as its own defence.

Three routes turn a deployer into a provider, and all three are common in mid-size organisations. Under Article 25 you become the provider if you put your name or trademark on a high-risk system already on the market; if you make a substantial modification to a high-risk system that remains high-risk; or if you change the intended purpose of a system, including a general-purpose AI system, so that it becomes high-risk. A fourth route is simpler still: if you build the system yourself and put it into service for your own use, you are the provider and the deployer simultaneously, and the Article 6(3) file is yours to write.

Where the internal build sits on top of a vendor foundation model with your own prompts, retrieval layer and scoring logic, assume the provider question is live rather than settled. Record who concluded what, and on what basis.

What a defensible assessment file contains

The Act sets no template. The Commission was required under Article 6(5) to issue guidelines on the practical implementation of Article 6, including examples of high-risk and non-high-risk use cases; confirm what has actually been published and in what form before treating any example as settled. In the meantime, a file that would survive a request should cover:

• The system's identity, version and the exact intended purpose as stated to users, not as described in a sales deck.
• Which Annex III point it engages, stated positively. A file that never names the Annex III heading looks like avoidance.
• An explicit profiling analysis, with a reasoned conclusion that no profiling of natural persons occurs.
• The reasoning on the first limb: who is affected, what harm is conceivable, and why the output does not materially influence the decision.
• Which of conditions (a) to (d) is relied on, and evidence rather than assertion — the actual output schema, where it lands in the workflow, and what the human sees.
• Evidence about the human step: what information the reviewer receives, what discretion they hold, and whether override rates suggest real independent judgement.
• Named accountable owner, date, and the trigger conditions that would force a reassessment (model change, new feature, purpose change, new user group).
• A note of the other law that still applies regardless of the classification outcome.

That last point matters. The exemption removes the high-risk regime only. It does not touch the Article 5 prohibitions, the Article 4 AI literacy duty, the Article 50 transparency duties where they apply, or data protection law. UK organisations should note that automated decision-making rules under UK GDPR were reformed by the Data (Use and Access) Act 2025 with phased commencement, so check the provisions actually in force before relying on any summary of Article 22.

Registration is not optional

The most commonly missed consequence is that claiming the exemption does not remove you from the EU database. Article 49(2) requires a provider relying on Article 6(3) to register itself and the system before placing it on the market or putting it into service. Publicly claiming an exemption is part of the design, and it is why a thin file is a poor idea: you are advertising the claim while holding little to support it.

Article 80 gives market surveillance authorities a dedicated procedure for systems the provider has classified as not high-risk under Article 6(3). If the authority concludes the classification is wrong, it can require corrective action within a deadline and, where relevant, withdrawal or recall. Failure to comply exposes the provider to penalties of up to 3% of global annual turnover for most AI Act obligations, with the 7% ceiling reserved for prohibited practices. Where personal data is involved, a separate GDPR exposure of up to 4% sits alongside it.

The limits of this guidance

This is a structural guide, not advice on your system. Article 6(3) turns on facts — what the model outputs, where that output lands, and what a reviewer can actually do with it — and two systems described identically in a policy document can classify differently. Several inputs remain unsettled: the practical detail of Commission guidance under Article 6(5), the harmonised standards that will shape what adequate evidence looks like, and the application timetable itself, which has been the subject of amendment proposals. Confirm the position in force for your system and date rather than relying on any summary, including this one.

Take specialist legal advice where the system affects employment, credit, education, essential services, law enforcement or migration decisions; where you are relying on a vendor's classification rather than your own; where a modification may have moved you into the provider role; or where the exemption is the difference between deploying and not deploying. In that last case the classification is carrying commercial weight, and a documented external view is worth considerably more than an internal conclusion reached under deadline.