Commission Guidelines on High-Risk AI: How the Article 6(3) Filter Works

The European Commission published its draft Commission guidelines on the classification of high-risk AI systems under Article 6 of the AI Act on 19 May 2026. 148 pages, open for stakeholder consultation until 23 June 2026. For anyone working on AI governance or compliance, this is the most important interpretative document since the AI Act itself entered into force.

The guidelines finally answer a question many organisations have been grappling with: when exactly does my AI system qualify as high-risk, and what happens if it falls within Annex III but in practice poses no significant risk? This article covers the structure of the document, the Article 6(3) filter with all four conditions, and the three pitfalls the Commission explicitly addresses.

The Two Paths to High-Risk

The AI Act has two fundamentally different routes to high-risk classification. The guidelines draw that distinction sharply.

Path 1: Article 6(1) and Annex I. An AI system is high-risk when it is used as a safety component of a product, or is itself a product, falling under EU harmonisation legislation listed in Annex I and requiring a third-party conformity assessment. Think machinery, medical devices, toys, lifts, radio equipment. For this path, compliance runs not only through the AI Act but in parallel through existing sectoral safety regimes.

Path 2: Article 6(2) and Annex III. This covers stand-alone AI systems whose intended purpose falls within one of eight explicitly enumerated use areas. This list is exhaustive. The Commission can only add use cases via delegated acts, and only when the conditions of Article 7(1) AI Act are met. That makes classification predictable for the market and prevents regulatory scope creep.

The Article 6(3) filter, the focus of this article, applies only to Path 2. For systems falling under Annex I, no escape from high-risk classification is possible.

The Eight Annex III Domains

The guidelines structure Path 2 along the eight domains in which the legislator identified significant risks to health, safety or fundamental rights. Each domain has its own chapter with use-case examples of what does and does not qualify as high-risk.

For each use case within each domain, the guidelines provide concrete examples of AI systems that do and do not qualify as high-risk. This is new. Until now, organisations had to interpret on their own whether their system fell within an Annex III use case. From now on, there is a reference framework.

For a broader explanation of the high-risk concept and the obligations that follow, see our earlier article on high-risk AI systems under the AI Act.

The Article 6(3) Filter: Where the Action Really Is

Not every Annex III system is automatically high-risk. Article 6(3) AI Act allows providers to take their system out of high-risk if one of four alternative conditions is met. The Commission calls this the filter mechanism.

The guidelines devote two extensive sections to this filter, with over twenty pages of interpretation and examples. That is not coincidence. The filter is where most practical disputes will arise, and the Commission wants to lock down the boundaries precisely.

Condition (a): Narrow Procedural Task

An AI system can be filtered out of high-risk if it performs a "narrow procedural task". These are tasks that categorise, reformat, structure or deduplicate data without making a value judgement about content.

Example that falls within the filter: A system that scans submitted visa applications, converts scanned documents into indexed text, automatically files items into fixed folders such as "identity documents", "travel itinerary" and "supporting evidence", and marks exact duplicates.

Example that does NOT fall within the filter: The same system, but now it ranks documents or labels material as "useful" or "less useful" for human review. At that point you introduce a value judgement that influences the assessment. No longer a narrow procedural task, so no filter, so high-risk.

The difference lies in a fundamental separation: structuring input is not the same as evaluating input.

Condition (b): Improves the Result of a Previously Completed Human Activity

The second path is an AI system that improves the result of a previously completed human activity. Three cumulative elements must be present: a human activity occurred, that activity led to a result, and the AI system refines that result.

The critical limitation sits in the word "improve". The Commission makes clear this is not the same as "review" or "revise". An improvement must not change the outcome, the rights, or the legal or economic position of the people affected.

Filter applies: A system that polishes final human-drafted text linguistically, flags errors or contradictions in completed work, or maps conclusions to evidentiary records to improve traceability.

Filter does not apply: A system that checks a decision, plan or design made by a human and proposes a substantively different solution. That is review, not improvement.

Condition (c): Detect Decision-Making Patterns or Deviations

The third path covers systems that detect decision-making patterns or deviations from prior patterns, without replacing or influencing the human assessment, and without proper human review.

This is the broadest of the four conditions. The guidelines allow a more substantive role for the system here, but under three constraints. The human assessment must be completed, the system may only perform ex-post comparisons (it cannot infer criteria for a new assessment), and the output must be validated through proper human review.

Example: A system that analyses past eligibility assessments completed by public administrators in order to detect decision-making patterns or deviations, for quality assurance and reporting purposes. The system does not propose outcomes on live cases and does not evaluate individual staff members. That may fall within the filter.

Condition (d): Preparatory Task

The fourth path is for AI systems performing a preparatory task to an assessment. "Preparatory" means: prior to the actual assessment process. Think indexing, searching, processing and linking data without the system itself reaching a conclusion.

The difference with condition (a) is subtle. A narrow procedural task can occur during the assessment process, as long as it is clearly defined and limited in scope. A preparatory task by definition occurs before the assessment process. In practice both conditions can apply simultaneously to the same system.

Three Pitfalls Every Provider Needs to Know

The Commission devotes separate subsections to the ways providers can wrongly conclude that their system falls within the filter. Three themes stand out.

Pitfall 1: Profiling Always Excludes the Filter

If an Annex III system performs profiling within the meaning of Article 4(4) GDPR, Article 3(4) Directive 2016/680 or Article 3(5) Regulation 2018/1725, it is always high-risk. No filter possible. Full stop.

This is a hard rule. A system that uses automated processing of personal data to evaluate, analyse or predict certain personal aspects of a natural person falls within profiling. Even if it looks narrow procedural in architecture, it remains high-risk once it crosses that threshold.

In practice this means that a correct GDPR classification of the data processing must precede the AI Act classification. For the interaction between both regimes, our DPIA vs FRIA comparison is a good starting point.

Pitfall 2: Anti-Circumvention for Modular Architecture

The Commission explicitly anticipates the creative tricks that will emerge in compliance practice. Splitting a high-risk function into separate modules, where each module individually would fall within a filter condition, does not help. If the modules together serve a high-risk use case, the whole is assessed as one system.

The same applies to complex and agentic AI systems. For interconnected systems where multiple AI components together produce an outcome in an Annex III use case, the combined intended purpose counts. Not the individual modules.

Pitfall 3: Self-Assessment Is Not Self-Certification

A provider who believes the filter applies performs a self-assessment. But self-assessment is no free pass. The guidelines impose three obligations.

First, the provider must document the assessment with reasoning why one of the four conditions is met. Then the system must be registered in the EU database with its filter status. After that, a monitoring obligation applies: if the intended purpose or actual use changes, the provider must reassess.

Market surveillance authorities are entitled to review the filter status. In case of doubt or evidence of incorrect classification, they can require the provider to treat the system as high-risk after all. The fines under Article 99 AI Act then apply.

What This Means for Providers and Deployers

For providers, the practical impact is concrete. From the publication of the final version, and certainly from 2 August 2027, every Annex III classification must be defensible by reference to these guidelines. A claim that "our system is not high-risk" without justification in terms of filter conditions is no longer sufficient.

Practically:

• Document per AI system whether it falls within an Annex III use case
• If yes: justify whether one of the four Article 6(3) filter conditions applies
• When in doubt: treat the system as high-risk
• If filter is claimed: explicitly check whether profiling is involved
• Register the filter status in the EU database
• Monitor for changes in intended purpose or use

For deployers, what changes most is vendor due diligence. Don't just ask for the high-risk classification, ask for the underlying Article 6(3) analysis. Which condition is invoked? Why no profiling? Why is the input merely structural and not evaluative? Who performed this assessment and when?

A vendor that cannot answer these questions transfers the reclassification risk to the deployer. Strong vendor assurance surfaces this before the contract is signed.

The Dutch Context

For Dutch organisations these guidelines arrive at an important moment. The Implementation Act for the AI Regulation is in public consultation until 1 June 2026. That sets up the Dutch supervisory architecture. Sectoral regulators such as AFM, DNB, AP, IGJ and the Dutch Labour Authority will soon be able to test the filter status of AI systems within their own domains.

For organisations using AI in recruitment, credit assessment, fraud detection or public services, this is doubly relevant. The Annex III use cases overlap directly with the domains of these regulators. An incorrect filter classification becomes not only an AI Act risk, but also a sectoral compliance risk.

For the timeline and transitional rules, including the impact of the Digital Omnibus agreement, see the overview of AI Act deadlines 2026, 2027 and 2028.

Next Steps

Consultation closes on 23 June 2026. Anyone wanting to provide substantive input can do so through the Commission's Have Your Say platform. For most organisations the more relevant action right now is to put their own AI portfolio against this interpretative lens.

Conclusion

The draft Commission guidelines are not yet final interpretation, but they provide the clearest indication so far of how the Commission wants Article 6 applied. The message is consistent: high-risk classification is the rule, the filter is the exception, and the exception is read narrowly.

For organisations with serious AI portfolios in any of the eight Annex III domains, this is the moment to put internal classifications under scrutiny. Those with their Article 6(3) analysis in order can demonstrate to market surveillance not only that the choice is defensible, but that it is documented. Those who wait until 2 August 2027 will do so under time pressure, with less room for diligence.