Registering an Annex III System You Judged Not High-Risk

The message usually comes from product, not from legal. A team has built something on top of a general-purpose model — a tool that ranks inbound job applications against a role, or that pre-sorts which claims an assessor should open first — and someone has already reached a conclusion. "It only ranks. A human still decides." You are being asked to confirm a view rather than form one, and the go-live date is already in a plan.

If the system sits anywhere in Annex III of the EU AI Act, that conclusion does not close the file. Article 6(3) allows certain Annex III systems to fall outside high-risk classification. Article 6(4) then attaches two duties to that outcome: the provider must document its assessment before the system is placed on the market or put into service, and the provider becomes subject to the registration obligation in Article 49(2). Deciding a system is not high-risk produces a database entry with your organisation's name on it and a file you must be able to hand to a regulator on request. It is a different door, not an exit.

What Article 6(3) actually requires

The derogation is not a general proportionality judgement. It has two limbs and one override, and they have to be worked through in that order.

First, the system must 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. Second, at least one of four conditions must be satisfied. Then the override: notwithstanding everything above, an Annex III system that performs profiling of natural persons is always high-risk. Profiling carries its data protection meaning — automated processing of personal data to evaluate personal aspects relating to an individual, such as performance at work, economic situation, health, reliability or behaviour. In practice that override disposes of a large share of candidate cases before the four conditions are reached at all.

Condition in Article 6(3)	What it is for	Where the claim usually fails
Narrow procedural task	Mechanical steps such as classifying documents into categories or detecting duplicates	The task is described narrowly but the output is the substantive input to the decision
Improving the result of a previously completed human activity	Tidying, formatting or refining work a person has already done	The human activity is not genuinely prior or genuinely complete — the model drafts first
Detecting decision-making patterns or deviations from prior patterns	Consistency checking across past human decisions	The condition itself excludes replacing or influencing the prior human assessment without proper human review
Performing a preparatory task to a relevant assessment	Gathering, translating or structuring material ahead of an assessment	The "preparation" is a ranking or score that determines what the assessor ever sees

Who is responsible, and it is not who most teams assume

The registration duty in Article 49(2) falls on the provider. Not the deployer, not a reseller, not the DPO. A provider is the entity that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trade mark. Putting into service includes supplying a system for your own use.

That last point catches in-house builds. If your organisation assembles an Annex III-adjacent tool on a third-party model and deploys it internally under its own name, it is the provider and the deployer of the same system. The documentation duty and the registration duty are yours, and there is no vendor to route them to. Two further routes under Article 25 turn a deployer into a provider: putting your own name or trade mark on a high-risk system already on the market, and modifying the intended purpose of a system that was not high-risk so that it becomes high-risk. The second bites a year after go-live, when a pilot for one team is quietly extended to a decision it was never assessed for.

Keep this map separate from your data protection map. Being the controller does not make you the provider; being a processor does not make you the deployer. The two regimes allocate duties on different criteria, and one organisation can comfortably be controller and deployer, or processor and provider. Note also that the deployer registration in Article 49(3) is narrower than it looks — it is directed at public authorities, Union institutions, bodies, offices and agencies, and entities acting on their behalf.

What the assessment file has to contain

The Act requires the provider to document the assessment and to produce that documentation to national competent authorities on request. It does not prescribe a template. What an authority will look for is whether the reasoning was genuinely done, at the right time, by someone accountable. A file that stands up usually records:

• The Annex III point the system falls within, identified precisely — you cannot claim a derogation from a classification you have not made
• The intended purpose as it appears in the instructions for use or the contract, not the marketing description
• Which single condition in Article 6(3) is relied on; leaning on all four loosely is a reliable sign the analysis was not done
• The significant-risk limb addressed separately, covering health, safety and fundamental rights
• An explicit finding on profiling, with the definition applied to the actual data and outputs
• If human review is load-bearing: who reviews, what they see, whether they can realistically depart from the output, and how often they do
• The system version the assessment covers, and the change-control trigger that forces a re-run
• Who signed it, when, and which body accepted it — dated before the placing on the market or putting into service
• Where the file is held and who can produce it within a working day

What actually goes into the EU database

The registration is not the file. Annex VIII sets out a short, specific field set for this route: provider identity and contact details; anyone submitting on the provider's behalf; the authorised representative where applicable; the system's trade name and an unambiguous reference; the intended purpose; which condition or conditions in Article 6(3) are relied on; a short summary of the grounds for the not-high-risk conclusion; and the Member States where the system is or has been placed on the market, put into service or made available.

Two things follow. The summary of grounds is published — for most Annex III areas the database is publicly accessible, so the entry is a standing, searchable statement of your legal position that claimants, journalists and competitors can read. For systems in the biometrics, law enforcement, and migration, asylum and border control points of Annex III, registration goes into a secure non-public section instead. Article 49 also carves critical infrastructure out of at least one registration route; check the exact wording against your own system rather than assuming it reads across.

The database is set up and maintained by the Commission under Article 71. The practical mechanics — the submission interface, identity checks, how free-text summaries are handled, what happens when an entry needs correcting — depend on the Commission's implementation and may change. Verify the current process at the point of filing rather than designing a workflow around assumptions.

Where this goes wrong

Human review that cannot actually depart from the output

Several of the conditions, and the "not materially influencing the outcome" test, depend on the human step being real. If reviewers see a score rather than the underlying material, have minutes per case, and have no route to escalate a disagreement, the claim is hard to sustain. Measure your own override rate before you rely on it; do not assert it.

Profiling arriving through the back door

A shortlisting tool scored against a model of previous successful hires is evaluating personal aspects relating to performance at work. Once that is true, the four conditions are irrelevant — the system is high-risk.

The assessment dated after go-live

Article 6(4) requires the documentation before placing on the market or putting into service. A file dated afterwards evidences the breach rather than the compliance.

Both parties assuming the other registered

The vendor treats you as the provider because you configured it; you treat the vendor as the provider because they built it. Nobody registers. Settle it in the contract, in the same clause that allocates the Article 25 triggers.

Limits, and when to take advice

Several inputs to this analysis are not settled. The Commission is required to issue guidelines on the practical implementation of Article 6, with a list of practical examples of high-risk and non-high-risk use cases; check their current status, because where they exist they are a far better guide than internal reasoning. Harmonised standards supporting the high-risk regime are still maturing. The application date of the Annex III high-risk obligations has itself been the subject of proposed amendment, so confirm the date in force for your system rather than relying on a figure in a slide deck. If you are a UK organisation deploying only in the UK, the AI Act does not apply — but it does reach you if you place a system on the Union market or the output is used in the Union, and the UK analysis under data protection law, including the reformed rules on solely automated decision-making, is a separate exercise with its own commencement timetable. Get specialist advice where the stakes justify it. A market surveillance authority can evaluate a system you classified as not high-risk under Article 6(3), and can require corrective action if it disagrees. Operating a system that should have been treated as high-risk sits in the penalty tier of up to 3% of total worldwide annual turnover, or a fixed euro maximum, whichever is higher — for SMEs and start-ups, whichever is lower. A separate and lower tier applies to supplying incorrect, incomplete or misleading information to national competent authorities, which is what an over-optimistic database summary risks becoming. And where the same tool processes personal data, an unsound automated decision-making or DPIA analysis is a data protection exposure of up to 4% of global annual turnover in its own right. Zen AI Governance can help you build and test the assessment; the classification decision itself, and its consequences, remain the provider's.