EU AI Act Article 6(3): When Annex III AI Systems Escape High-Risk Status

Overview: The Filter Inside the High-Risk Classification

Annex III of the EU AI Act lists the use-case areas that make an AI system high-risk, but the legislator recognised that a use-case list is a blunt instrument. A tool that merely converts documents to a structured format inside a recruitment platform touches the employment area without deciding anyone's career. Article 6(3) — added late in the legislative negotiations — is the safety valve: an AI system referred to in Annex III shall not be considered 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. This derogation is one of the most commercially significant provisions in the entire regulation, and also one of the most dangerous to misuse, because misclassification carries enforcement and penalty exposure.

The Four Qualifying Conditions

Article 6(3) does not leave significant risk to free interpretation. The derogation applies where one or more of the following conditions is fulfilled:

• (a) The AI system is intended to perform a narrow procedural task — for example transforming unstructured data into structured data, classifying incoming documents into categories, or detecting duplicates among applications
• (b) The AI system is intended to improve the result of a previously completed human activity — for example a tool that polishes the language of a decision already drafted by a human
• (c) The AI 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 — for example a tool flagging that a grading decision deviates from an examiner's established pattern
• (d) The AI system is intended to perform a preparatory task to an assessment relevant for the purposes of the Annex III use cases — for example file indexing, search, or initial information extraction feeding a human-led evaluation

The conditions share a logic: in each, the human assessment remains the decision, and the AI's contribution is mechanical, retrospective or preparatory. The moment a system scores, ranks, recommends or filters in a way that shapes who gets the job, the loan or the benefit, the derogation collapses.

The Absolute Limit: Profiling

The second subparagraph of Article 6(3) draws a hard line: notwithstanding the four conditions, an AI system referred to in Annex III shall always be considered high-risk where it performs profiling of natural persons. Profiling carries its GDPR meaning — automated processing of personal data to evaluate personal aspects such as work performance, economic situation, health, preferences, reliability, behaviour, location or movements. This single sentence eliminates the derogation for most scoring systems: credit scores, recruitment rankings, recidivism assessments and benefits risk flags all evaluate personal aspects of individuals. In practice, the derogation lives mainly in the plumbing of high-risk domains — document handling, data preparation, quality checking — not in the decision logic.

Documentation, Registration and the Burden of Proof

Using the derogation is a regulated act, not a private judgment. Article 6(4) requires a provider who considers that an Annex III system is not high-risk to document its assessment before placing the system on the market or putting it into service. The provider must also register the system in the EU database under Article 49(2) — a registration specifically for systems claimed under the derogation — and provide the assessment documentation to national competent authorities upon request. The structure is deliberate: the claim is visible to regulators, contestable and auditable.

Article 80 gives the enforcement teeth. Where a market surveillance authority has sufficient reason to consider that a provider has misclassified a system, it evaluates the classification and can require the provider to bring the system into full high-risk compliance within a set period. Misclassification done to circumvent the requirements exposes the provider to fines under Article 99, and supplying incorrect, incomplete or misleading information to authorities is itself sanctionable with fines up to 7.5 million euros or 1 percent of worldwide turnover.

Commission Guidelines and Future Adjustment

Recognising that the four conditions will generate boundary disputes, Article 6(5) directed the Commission to provide guidelines specifying the practical implementation of the classification rules, complete with a comprehensive list of practical examples of high-risk and non-high-risk use cases, by February 2, 2026. Article 6(6) and 6(7) empower the Commission to adopt delegated acts amending the conditions — adding new ones where evidence shows systems slipping through without justification, or modifying conditions shown to be unnecessary, but only where doing so does not lower the overall level of protection. Compliance teams should track these instruments closely: a derogation analysis written in 2025 may need revisiting as guidance and delegated acts accumulate.

Who Should Care and How to Use the Derogation Properly

The derogation matters most to software vendors whose products sit inside Annex III workflows without making decisions: document automation in HR suites, data extraction in lending operations, translation layers in public administration, deduplication in case management. For these providers the derogation is the difference between a documentation exercise and full conformity assessment. It also matters to deployers, who should demand the registered derogation assessment from vendors instead of accepting bare assertions that a tool is not high-risk.

A disciplined derogation analysis has four parts. First, define the intended purpose precisely and honestly — the analysis is only as good as the purpose statement, and marketing claims that exceed it will be held against the provider. Second, map the system's output into the deployer's decision process and show, concretely, why it cannot materially influence outcomes. Third, test the profiling question explicitly: does any component evaluate personal aspects of natural persons? Fourth, record the conclusion in a dated assessment, register the system, and set a review trigger for any feature change that moves the system closer to the decision.

Concrete Examples

Example one: a vendor sells an AI module that reads incoming job applications and extracts education and employment history into database fields, without scoring candidates. Narrow procedural and preparatory — a strong derogation candidate, provided no ranking or filtering creeps in.

Example two: a bank uses a model that flags loan officer decisions deviating from the officer's own historical pattern, for quality review by a supervisor. Condition (c) territory — pattern deviation detection with human review.

Example three: an HR platform claims its candidate-matching engine is merely preparatory because a recruiter clicks the final button. The engine ranks candidates by predicted fit — that is profiling and materially influences outcomes. The derogation is unavailable, whatever the user interface suggests.

Action Before August 2, 2026

Providers intending to rely on Article 6(3) should complete and document assessments now, register systems once the database registration for derogated systems is open to them, and align the assessment with the Commission guidelines. Deployers should inventory vendor claims and collect the underlying assessments. Both sides should remember the asymmetry of risk: a wrong high-risk classification costs unnecessary compliance effort, but a wrong derogation claim costs enforcement action, forced remediation under Article 80, possible fines and the unwinding of product commitments to customers. When the analysis is genuinely close, building to the high-risk requirements is usually the cheaper path over a product's life — and it converts directly into trust evidence that enterprise customers in Annex III sectors increasingly demand.

How Deployers Should Handle Vendor Derogation Claims

Deployers inherit real risk from vendor classification decisions, so a vendor's statement that a tool is not high-risk deserves structured scrutiny. Ask for three things: the documented Article 6(4) assessment with its date and the intended purpose it analysed; confirmation of the Article 49(2) registration; and a contractual commitment that the vendor will notify the deployer of feature changes affecting classification. Then verify the assessment against your own use. The derogation analysis is anchored to intended purpose — if your organisation uses the tool beyond that purpose, for instance feeding a document-classification module's output directly into automated candidate rejection, the derogation may not protect your deployment, and under Article 25 purpose-exceeding use can make you the provider of a new high-risk system. Procurement teams in Annex III sectors are increasingly adding a classification annex to AI contracts recording the agreed purpose, the classification conclusion and the change-notification duty. That single page prevents most of the disputes that will otherwise surface during a market surveillance inquiry, when provider and deployer discover they have been assuming different answers to the same question.

This article is for informational purposes only and does not constitute legal advice. Regulatory requirements change frequently — verify current rules with official sources. Built by Sawai Gyoseishoshi Office, Hiroshima, Japan.