EU AI Act Part 3 – The Article 6(3) Filter: Your Escape Valve Has a Catch

Post 2 of this series walked through the Article 6 classification framework. If that analysis led you to an Annex III use case, you are not necessarily stuck with a high-risk classification. Article 6(3) provides a mechanism, the filter, that allows providers to self-assess their systems as not high risk even when the intended purpose falls within a listed use case.

But the filter is not a simple opt out. The Commission’s draft guidelines impose three constraints that practitioners consistently underestimate, and the mechanism requires documentation that most organizations have not built. This post covers how the filter works, where it breaks, and what you need to do to use it credibly.

Article 6(3) provides that a provider may determine that an Annex III system is not high-risk if the system meets at least one of four conditions:

(a) Narrow procedural task. The system is intended to perform a task that is clearly defined and limited in scope, such as transforming data formats, categorizing incoming documents into predefined categories, or detecting duplicate records. The key is that the system does not evaluate, score, or rank the data it processes. A system that sorts incoming job applications into predefined folder categories based on the role applied for may qualify. A system that categorizes applicants as “strong” or “weak” candidates does not, because that is a value judgment rather than a procedural task.

(b) Improving a previously completed human activity. The system operates after a human has completed their assessment and improves that output, for example by flagging inconsistencies, mapping conclusions to evidence, or checking for errors. The human activity must have been genuinely completed before the AI system is applied. The AI system must not produce a materially different result from the human assessment, change the legal or economic position of the affected persons, or effectively substitute for the human’s judgment. An AI system that provides a “substantially different solution” from what the human produced is not improving a previously completed activity. It is replacing it.

(c) Detecting decision-making patterns or deviations. The system analyzes historical decisions to identify patterns or anomalies, without proposing outcomes on live cases. It may inform a quality assurance review but must not replace or influence the previously completed human assessment without proper human review. “Proper” review means the human considers the system’s output together with all the original evidence, rather than simply rubber stamping the flag. This condition has a more substantive role in the process than (a) or (d), but that substance is tightly constrained.

(d) Preparatory task. The system performs a task that precedes the actual assessment process and has very low potential impact on the assessment that follows. This is distinct from a narrow procedural task under (a), which can occur during the assessment. The preparatory nature requires genuine separation from the decision being made.

1. The Conditions Must Be Interpreted Narrowly

Article 6(3) is an exception from rules designed to protect fundamental rights. The Commission’s draft guidelines are explicit: the conditions must be interpreted narrowly. This is not a technical legal footnote. It is a substantive instruction to authorities reviewing filter self assessments. A filter argument that works only if you read the conditions generously is not a filter argument that will hold up.

The practical implication: when evaluating whether your system qualifies, apply the narrowest reasonable interpretation of the relevant condition. If there is real doubt, there is real risk.

2. Complex Architectures Block the Filter Even When a Condition Is Met

This is the constraint most organizations in agentic AI deployments miss.

Even if an individual component technically meets one of the four filter conditions, it cannot benefit from the filter if it forms part of a complex system where the combined intended purpose or joint outputs materially influence an individual decision within a high risk use case. The guidelines extend this explicitly to “agentic AI systems that coordinate and interact through linked actions.”

The practical implication is that the filter is evaluated at the system level rather than the component level. A preprocessing module that looks like a narrow procedural task in isolation may be part of a pipeline that collectively produces employment decisions. In that context, the filter is unavailable regardless of what the module does on its own.

3. Profiling Is an Absolute Bar

If the system performs profiling of natural persons, meaning automated processing of personal data to evaluate personal aspects such as work performance, economic situation, health, personal preferences, or behavior within the meaning of Article 4(4) of the GDPR, it is always classified as high risk if it falls within an Annex III area. This bar cannot be overcome by any of the four filter conditions. It applies regardless of how narrow or preparatory the system’s role appears to be.

Article 6(4) of the AI Act requires that providers who determine their system is not high risk by using the filter document that assessment before placing the system on the market or putting it into service. This is an active pre market obligation, not an internal reasoning exercise.

What needs to be in that documentation:

• Which filter condition applies and why
• How the system’s intended purpose, as documented, fits within the condition’s requirements under a narrow interpretation
• Why the system is not part of a complex architecture in which the filter is blocked
• Confirmation that the system does not perform profiling of natural persons

The filter and the paper trail are inseparable. You cannot invoke the filter without building the record, and the record needs to be built before market entry. Organizations that have already placed systems on the market without this documentation have a gap to close.

Before investing in a filter argument, run through these questions:

1. Does the system produce outputs that score, rank, evaluate, or categorize individuals in ways that affect decisions about them? If yes, conditions (a) and (d) are likely unavailable.
2. Does the system’s output feed into any subsequent decision making process, however indirectly? If yes, examine the pipeline as a whole before applying the filter to any individual component.
3. Does the system process personal data about individuals to evaluate their characteristics or behavior? If yes, confirm whether this constitutes profiling before proceeding.
4. Would the filter argument require a broad reading of any condition to work? If yes, the filter is fragile.

If the filter survives this test, Part 4 of this series covers how to build the documentation record that makes it defensible.

Next in the series: Part 4 – What This Looks Like in Your Sector

The Paper Trail series is based on the European Commission’s draft guidelines on the classification of high-risk AI systems under Article 6 of Regulation (EU) 2024/1689, published May 19, 2026, for stakeholder consultation. The guidelines are not yet final. Nothing in this series constitutes legal advice.