Does listing in Annex III automatically make my AI system high-risk under the EU AI Act?

Not automatically. Article 6(2) creates the presumption that a system falling in an Annex III use case is high-risk, but Article 6(3) allows a provider to conclude that its system does not pose a significant risk of harm to health, safety, or fundamental rights, and therefore is not high-risk. That conclusion is only available where the system meets at least one of four filter conditions, and it is never available where the system performs profiling of natural persons. The derogation is a documented, assessable determination made before placing the system on the market — not a default and not a judgement call recorded after the fact.

Does the profiling carve-out apply to my system?

Article 6(3) states that an AI system referred to in Annex III is always considered high-risk where it performs profiling of natural persons. Profiling carries its GDPR Article 4(4) meaning: automated processing of personal data to evaluate personal aspects of a natural person, in particular to analyse or predict performance at work, economic situation, health, preferences, interests, reliability, behaviour, location, or movements. Scoring, ranking, or segmenting individuals against those dimensions is profiling regardless of what the product calls it, and no filter condition rescues a system that does it.

What documentation does the derogation require?

A provider relying on Article 6(3) must document its assessment before the system is placed on the market or put into service, and must register the system in the EU database under Article 49(2). The assessment has to be provided to national competent authorities on request. Practically, that means a written record identifying the Annex III use case engaged, the specific filter condition relied on, the declared intended purpose, the reasoning connecting them, an explicit finding that no profiling occurs, and the date and owner of the determination.

What happens if a regulator disagrees with a self-declared exemption?

The system is treated as high-risk, and every high-risk obligation the provider skipped becomes an open non-compliance: risk management system, data governance, technical documentation, logging, transparency to deployers, human oversight design, accuracy and robustness, quality management system, and conformity assessment. Market surveillance authorities can require corrective action, withdrawal, or recall. The penalty exposure for non-compliance with high-risk requirements reaches the higher of a percentage of worldwide annual turnover or a fixed ceiling, and a documented but wrong assessment is materially better positioned than no assessment at all.

The Exemption You Have to Document Before You Use It: EU AI Act Article 6(3) and the High-Risk Derogation

Q: What are the four Article 6(3) filter conditions?

A system may fall outside high-risk classification where it is intended to perform a narrow procedural task; where it is intended to improve the result of a previously completed human activity; where it 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; or where it is intended to perform a preparatory task to an assessment relevant to an Annex III use case. Each of these is defined by the intended purpose the provider declares, which means the declaration constrains how the system can then be marketed and deployed.

The Presumption, and the Way Out of It

Article 6(2) is the blunt instrument: an AI system falling within one of the use cases in Annex III is high-risk. Annex III is broad. It reaches employment and worker management, access to essential private and public services, education and vocational training, creditworthiness, biometrics, law enforcement, migration, and administration of justice. A large amount of ordinary B2B software touches at least one of those areas somewhere in its feature set.

Article 6(3) is the release valve. It permits a provider to conclude that a system within an Annex III use case 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 — and therefore is not high-risk. The provision exists because the drafters recognised that a spellchecker inside an applicant tracking system and a résumé-ranking model inside the same product are not the same regulatory object.

What trips companies up is the shape of the exemption. It is not a general proportionality argument, and it is not something counsel can construct after a regulator asks. It is a determination that must satisfy an enumerated condition, be recorded before the system is placed on the market or put into service, and be registered — with the registration itself signalling to authorities that a derogation is being claimed.

The Four Filter Conditions, Read Narrowly

(a) A narrow procedural task

The system performs a defined, bounded step rather than an evaluation. Converting unstructured text into a structured field, deduplicating records, classifying an inbound document by type, routing a ticket to a queue. The tell is whether the output is a fact about the input or a judgement about a person. 'Narrow' does the work here — a task is not narrow because it is one API call; it is narrow because its output space is small and mechanical.

(b) Improving the result of a previously completed human activity

A human already produced the substantive output and the system polishes it. Reformatting, tightening prose, standardising terminology in an assessment a person already wrote. The condition fails the moment the system contributes the substance rather than the finish, and it fails if the 'previously completed' human activity is really a rubber stamp applied to a machine draft.

(c) Detecting decision-making patterns or deviations from prior patterns

The system looks at how decisions were made and flags inconsistency — an audit and quality-assurance posture. This condition carries its own express limit: the system must not be meant to replace or influence the previously completed human assessment without proper human review. A tool that surfaces 'this decision is unusual' to a reviewer can qualify. A tool whose flag functionally reverses the decision does not.

(d) Performing a preparatory task to an assessment

The system readies material for a human assessment relevant to an Annex III use case — assembling a file, extracting the relevant sections, translating a document for review. Preparation is upstream of evaluation. If the preparatory step also orders, scores, or shortlists what the human then sees, it is shaping the assessment and the condition is no longer available.

The Profiling Carve-Out Swallows More Products Than Teams Expect

Article 6(3) closes with an unconditional sentence: a system referred to in Annex III is always high-risk where it performs profiling of natural persons. There is no balancing against the filter conditions. If profiling is present, the analysis is over.

Profiling takes the GDPR Article 4(4) definition — automated processing of personal data to evaluate personal aspects relating to a natural person, in particular to analyse or predict aspects concerning performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location, or movements. That definition is wider than most product teams assume. A lead score is profiling. A churn-risk flag on a named account contact is profiling. An engagement or reliability rating attached to an individual worker is profiling.

The practical failure mode is a system that sits comfortably in filter condition (a) for its core function and then quietly profiles at the edges — a document classifier that also assigns a confidence-weighted "applicant strength" hint, or a routing engine that learns which agents handle which customers and scores the customers. The edge feature is the one that decides classification for the whole system.

The intended purpose is a commitment, not a description

Every filter condition is framed around what the system is intended to do. That intended purpose is what the provider declares in its instructions for use and its documentation. Declaring a narrow procedural purpose to secure the derogation and then marketing the same system as a decision-support or ranking capability is the cleanest way to lose it — sales collateral, product pages, and onboarding material are all evidence of intended purpose, and they are public.

What the Documentation Has to Contain

The obligation is timing-sensitive. The assessment must be documented before the system is placed on the market or put into service, and the system must be registered in the EU database under Article 49(2). Authorities can request the assessment, and a provider who produces one dated after the inquiry has answered a different question than the one asked.

1. Name the Annex III use case you are in

The derogation only exists relative to a listed use case. A memo that argues the system is outside Annex III entirely is a different analysis and does not create an Article 6(3) record. Identify the point of contact with the list first, then argue the filter.

2. Identify the single filter condition relied on

Pick one and defend it. Assessments that gesture at three conditions simultaneously read as an argument searching for a hook, and each condition has different failure modes a reviewer will test separately.

3. State the declared intended purpose verbatim

Quote the intended purpose exactly as it appears in the instructions for use, and confirm the product's public positioning matches it. Any divergence between the two is the first thing an authority will find.

4. Make an express no-profiling finding

Enumerate every output the system produces about an identifiable person and state, for each, why it is not an evaluation of personal aspects. Silence on profiling reads as an issue that was never considered rather than one that was cleared.

5. Record who decided, when, and on what version

Tie the determination to a model and product version. Systems change; a derogation assessed against a rules-based v1 says nothing about the learned-ranking v3 that shipped eight months later, and the version pin is what tells you when to reassess.

6. Register under Article 49(2) and keep it current

Registration is not incidental paperwork. It is the mechanism by which the claim becomes visible to market surveillance authorities, and an unregistered derogation is a compliance gap independent of whether the underlying reasoning was right.

Why Deployers Should Read the Provider's Assessment

A company buying an AI system inherits the consequences of the vendor's classification without controlling it. If the vendor claimed a derogation and the claim fails, the deployer has been operating a high-risk system without the deployer-side obligations — human oversight assignment, input data relevance, monitoring, log retention, and in some cases a fundamental rights impact assessment.

This makes the Article 6(3) assessment a reasonable procurement artifact to request alongside a DPA. A vendor that can hand over a dated, version-pinned assessment has done the work. A vendor that responds with "we're not high-risk" and nothing else has told you exactly how much diligence exists behind the answer — and deployers who use a system outside the vendor's declared intended purpose can find themselves treated as the provider under Article 25.

Frequently Asked Questions

We're a US company with EU customers. Does any of this reach us?

Yes, where you place an AI system on the EU market or put it into service in the EU, and also where the output produced by the system is used in the EU. Establishment is not the trigger. A US SaaS product sold to an EU employer, or whose output is acted on by an EU deployer, is inside scope and generally needs an authorised representative in addition to the classification analysis.

Our AI only makes a recommendation — a human always decides. Isn't that enough?

Not on its own. The statute contemplates systems that do not materially influence the outcome of decision-making, and a recommendation that is followed nearly all the time is influencing the outcome. The relevant evidence is override rates and whether reviewers ever select against the recommendation, not the org chart. Condition (c) makes this explicit by requiring proper human review rather than nominal review.

Does the derogation remove every AI Act obligation?

No. It removes the high-risk obligations in Chapter III. The transparency duties in Article 50 still apply where relevant — disclosing that a person is interacting with an AI system, marking synthetic content in a machine-readable format, disclosing deepfakes and certain AI-generated public-interest text. The AI literacy obligation and the prohibitions in Article 5 apply regardless of risk classification.

Can we rely on a derogation for a general-purpose model we build on top of?

The classification question is about your system and its intended purpose, not about the base model. Building on a general-purpose model does not import that model provider's posture, and it does not shield you: you are the provider of the system you place on the market. The base model provider carries its own GPAI obligations separately.

How often should we revisit the assessment?

On any substantial modification, on any change to declared intended purpose, and on a fixed calendar cadence regardless — annual is a defensible baseline. The most common way a valid derogation becomes invalid is incremental product work: a ranking heuristic added to a classifier, a score surfaced in a UI, a preparatory tool that starts shortlisting. Tie reassessment to your release process rather than to a legal review cycle.

An Undocumented Exemption Is Not an Exemption

The substantive question — is this system genuinely low-risk — is one most teams can answer honestly in an afternoon. The procedural question is where the exposure accumulates, because a company that is factually correct about its risk profile and has no dated, registered assessment is in a worse position than one that wrote a careful memo and got a close call slightly wrong.

Write the assessment before launch, pin it to a version, name the one condition you rely on, and say out loud that the system does not profile. That artifact is cheap now and expensive to reconstruct later.