Article 86: The Right to an Explanation of an AI Decision

Most of the EU AI Act tells you how to build and document an AI system. Article 86 points the other way. It hands the people on the receiving end of your AI a right they can use against you. If your system helped make a decision that significantly affects someone, that person can come back and ask you to explain it. And you have to give them a clear, meaningful answer.

This is a deployer’s obligation, and it is one of the few parts of the Act an ordinary member of the public can invoke directly. A rejected loan applicant, a screened-out job candidate, a student denied a place on a course — any of them can ask the question. Article 86 says you must answer it.

Who owes the explanation, and who can ask

The direction here is the reverse of most of the Act, so it’s worth pinning down first. The right runs against the deployer — the organisation that used the AI system to reach a decision — not the provider who built it.

That matters because deployers often assume their vendor carries this. It doesn’t work that way. If you license a credit-scoring tool and use its output to decline an application, the applicant comes to you for the explanation. The company that wrote the model does not have to answer; you do. The provider’s job, under Article 13, is to give you the information you need to be able to explain the system. The duty to actually face the affected person is yours.

Here is what the Act requires. Article 86(1) gives an affected person the right to obtain from the deployer “clear and meaningful explanations of the role of the AI system in the decision-making procedure and the main elements of the decision taken.”

Two things, then: what part the AI played, and what the decision actually turned on.

Does this apply to you?

Article 86(1) is narrower than it first looks. The right is triggered only when all four of these are true:

1. You are the deployer, and you made a decision about a specific person. Not a general policy — a decision affecting one identifiable individual.
2. The decision was based on the output of a high-risk AI system listed in Annex III — and not one of the critical-infrastructure systems in point 2 of that list. Annex III point 2 covers AI in the management of electricity, water, gas, road traffic, and digital infrastructure, and it’s carved out here, because those systems aren’t making individual decisions about people.
3. The decision produces legal effects, or affects the person in a similarly significant way. Losing a job offer, a loan, a place at a university, or a welfare payment clears this bar. A minor inconvenience does not.
4. The person considers the decision to have an adverse impact on their health, safety, or fundamental rights, and asks you for an explanation. This is a right exercised on request. You are not required to volunteer the explanation to everyone; you are required to give it when an affected person comes asking.

Two carve-outs sit on top. Under Article 86(2), the right does not apply where Union or national law sets out its own exceptions or restrictions. And under Article 86(3), it applies “only to the extent that the right referred to in paragraph 1 is not otherwise provided for under Union law” — which is the Act’s way of saying it won’t duplicate a right you already owe under something else. We’ll come back to what that means for GDPR.

One nuance worth knowing from the recitals. Recital 171 frames the trigger as a decision “based mainly upon” the AI’s output. So a decision where the system’s output was one minor input among many is on weaker ground than one where the output effectively decided the outcome. The closer the AI sits to the actual decision, the more clearly Article 86 bites.

What “a clear and meaningful explanation” actually means

Take Meridian, a German logistics firm that runs about 4,000 job applications a year through an Annex III recruitment-screening tool. A candidate, Lena, applies for a warehouse-operations role, is auto-ranked in the bottom decile, and is rejected without an interview. She asks Meridian why.

A clear and meaningful explanation has to cover the two elements the Act names:

The role of the AI system in the procedure. Lena is entitled to know that an automated screening tool ranked her application, where in the process that happened, and how heavily that ranking weighed in the rejection. “A computer said no” is not an explanation. “Your application was scored and ranked by an automated tool against the role’s criteria, and applications below a set threshold were not progressed to interview” is the beginning of one.

The main elements of the decision. This is the harder part. Lena should learn what actually drove the outcome — the factors the decision turned on, in terms she can understand and, if she wants, challenge. Not the model’s weights or source code, but the substance: which criteria mattered, and broadly how she fell short of them.

Notice what you need on hand to answer this well. You need the system documentation your provider gave you, so you can describe the tool’s role accurately. And you need a record of the specific decision in question — which inputs were used, what the system output, who acted on it — which is exactly what your Article 12 logging is for. An Article 86 request is, in practice, a test of whether your logs and your provider documentation can be turned into a plain-English answer about one person.

The Act does not set a deadline for responding, and it does not prescribe a format. Don’t read that as licence to stall. A vague or evasive answer invites a complaint to your national market surveillance authority under Article 85, and complaints are how enforcement tends to start.

How this differs from GDPR’s Article 22

If this all sounds familiar, that’s because GDPR already governs some of the same territory — and the two laws are designed to interlock rather than overlap. Knowing where the line falls saves you from either double-building or assuming you’re already covered.

GDPR’s Article 22 gives people the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects, with safeguards including human intervention, the right to express a view, and the right to contest the outcome. The word that does the limiting is “solely”. If a human was meaningfully involved in the decision, GDPR Article 22 may not apply at all.

That is the gap Article 86 closes. The AI Act right is not limited to solely-automated decisions. It applies to a decision “taken by the deployer on the basis of the output” of the system — which squarely includes the common case where an AI recommends and a human signs off. If your hiring manager glances at the AI’s ranking and approves the rejection in two seconds, you may be outside GDPR Article 22 but firmly inside Article 86.

	GDPR Article 22	AI Act Article 86
Triggered by	Decisions based solely on automated processing	Decisions based on a high-risk AI system’s output, human-in-the-loop included
Scope	Any automated decision with legal/significant effect	Only Annex III high-risk systems (excluding critical infrastructure)
Who you owe	The data subject	The affected person
In force	Now	Tied to the high-risk timeline (see below)

The practical upshot: Article 86 catches the rubber-stamp cases GDPR’s “solely” wording lets through, but only for high-risk Annex III systems. And because of Article 86(3), where GDPR already gives someone an equivalent right, GDPR governs — you don’t owe the same explanation twice under two laws. They’re meant to add up to one coherent duty, not two parallel ones.

When the right starts to bite

Article 86 only matters for Annex III high-risk systems, so its timing tracks theirs. Under the Digital Omnibus — the simplification package provisionally agreed on 7 May 2026, pending formal adoption — the Annex III high-risk obligations now apply from 2 December 2027 rather than 2 August 2026. Treat the right to explanation as part of that package landing on the later date.

This is not yet formally in force. The agreement still needs lawyer-linguist review, a Parliament vote, Council adoption, and publication in the Official Journal. For planning purposes, the December 2027 date is the working baseline.

But don’t file the whole topic under 2027. GDPR’s automated-decision rights already apply. If you already make decisions about people off the back of automated processing, someone can already ask you for meaningful information about the logic involved — and contest the outcome — under GDPR. Article 86 widens and sharpens that right for high-risk AI; it does not create the obligation to explain automated decisions from scratch.

What to do now

You don’t need an Article 86 response process running tomorrow. You do need to make sure that when the high-risk rules land, you can actually answer the question. That readiness is built well before the first request arrives.

1. Find out which of your decisions are in scope. For each high-risk Annex III system you deploy, identify the points where its output feeds a decision that legally or significantly affects an individual. Those are your Article 86 exposure.
2. Get the explanation material from your provider now. The information you’ll need to describe the system’s role should be in the instructions for use your provider owes you under Article 13. If it isn’t there in a form you could hand to an affected person, raise it before you sign.
3. Make sure your logs can reconstruct one decision. An explanation is about a specific person on a specific day. Confirm your Article 12 logging captures the inputs, output, and human action for individual cases — not just aggregate system behaviour.
4. Pre-write the actual answer. Draft a template explanation for each in-scope decision type, in plain language a rejected applicant could understand. A written policy promising that you will explain is not the same as a draft explanation you can send. If you can’t write it now, you won’t be able to write it under time pressure with a complaint pending.
5. Decide who answers. Name the function that owns these requests — usually the same people handling your GDPR data-subject requests, since the two will often arrive together. This sits inside your broader deployer obligations under Article 26.

Article 86 turns your AI from a private system into something you have to justify to the person it acted on. The deployers who’ll handle that comfortably are the ones who can already trace any single decision back to its inputs and put the result in a sentence a non-expert understands. If you can do that, the right to explanation is a request you can fill. If you can’t, it’s the moment your documentation gets read out loud.