EU AI Act Article 86 Right to Explanation 2026: The Deployer Answers

Who Can Ask, and About What

The right sits with the affected person, not the customer

The person entitled to ask is the one the decision was taken about — a rejected applicant, a declined borrower, a flagged student. They are frequently not your customer and have no account, no ticket and no relationship with you. If the only intake channel you operate is a logged-in support form, the people with the right cannot reach it.

It attaches to decisions with legal or similarly significant effects

Employment, credit, education, essential private and public services, and the other high-risk uses listed in the Act's annex. The test is the effect on the person: a decision that changes access to work, money, housing, insurance or a qualification is in; an internal routing decision they never feel is not.

The system has to be in the decision, not merely near it

The right covers decisions taken on the basis of output from a high-risk system. An assistant that drafts a summary a human then ignores is a weaker case than a scoring system whose threshold determines the outcome. The honest way to know which you have is the override rate — a human step that never changes an outcome is not the decision-maker, whatever the process diagram says.

It does not displace the data protection rules it overlaps with

Automated decision-making rights under data protection law run in parallel and have their own thresholds, their own carve-outs and their own regulator. A single request from a rejected applicant can engage both. Answering one and ignoring the other is the common failure, and the two have different deadlines.

Five Things the Answer Has to Contain

The standard is clear and meaningful, judged from the position of the person reading it rather than the person writing it.

The role the system played in the decision

Stated plainly: whether it screened, scored, ranked or recommended, at which stage, and what happened to its output afterwards. This is the element people actually want, and it is the one most often replaced with a sentence saying AI was 'used in the process'.

The main parameters the decision turned on

The categories of input that mattered for this decision and the direction in which they mattered. Not the model weights, and not a generic feature list copied from documentation — the point is that the person can tell what about their own case drove the result.

Information clear enough to contest the outcome

The working test for an explanation is whether the person could use it to identify a mistake. If the answer makes it impossible to say 'that input is wrong about me', it has not done its job, whatever it contains.

The human step, described accurately

Who reviewed it, what they could see, and what they were able to change. Overstating this is the trap: describing a rubber stamp as meaningful review is a statement to a person who may later complain to an authority with the power to ask for the logs.

A route to challenge and a route to complain

Your internal appeal path, and the existence of a complaint route to the national market surveillance authority. A person who cannot find either will find the second one anyway, in a worse mood.

Why Forwarding the Vendor's Documentation Does Not Work

A model card explains the system, not the decision

Vendor documentation describes intended purpose, performance characteristics and known limitations for the system in general. Article 86 asks about one person's case. Forwarding the documentation answers a question nobody asked and reads as evasion.

The record of the individual decision is held by you

Deployers of high-risk systems have to keep the automatically generated logs for a defined minimum period where the logs are under their control. If your integration does not persist inputs, outputs, model version and timestamp per decision, there is no per-case record to explain from, and this is a build gap rather than a legal one.

Explanation is usually not in the contract

Standard AI vendor agreements cover uptime, security and IP. Very few commit to per-decision explainability output, to a support path for explanation requests, or to a response time compatible with yours. That clause has to be negotiated before deployment, because afterwards you have no leverage and a live obligation.

A model update can invalidate old explanations

A decision made eight months ago was made by a version that may no longer exist. Without version pinning in the log, an explanation produced by re-running the current model describes a decision that was never taken. Record the version at decision time and require notice of changes.

Trade secrets limit the depth, not the duty

Protecting intellectual property and commercially confidential information is a legitimate constraint on what can be disclosed. It does not convert the obligation into nothing. The answerable position is a meaningful explanation at the level of inputs, role and effect, with the proprietary internals withheld — and a vendor that will not support even that level is a procurement problem.

Five Things to Build Before the First Request

Open a public channel an affected person can actually reach

A named page, reachable without an account, linked from the decision notice itself. Route it to a monitored queue with an owner, not to a general inbox where it competes with sales mail.

Log every high-risk decision as a retrievable record

Inputs, output, model and version, timestamp, the human reviewer if any, and the final outcome — indexed by something the person can quote, such as an application reference. Retention long enough to cover the period in which requests realistically arrive, which is longer than a support SLA.

Write the template before the first request

A structured answer covering the five elements above, in plain language, at reading level, in the language of the decision notice. Written under time pressure by whoever is available, the first response becomes the precedent for every one after it.

Set an internal clock and record it

The Act does not hand you a single number the way data protection law does, so pick a defensible one and meet it consistently. Log receipt and response dates: a pattern of prompt, complete answers is the strongest thing you can show an authority, and it is also the cheapest to produce.

Close the loop into the system

Explanation requests are the highest-quality defect signal a high-risk deployment produces. If three people in a month can point at the same wrong input, that is a data quality bug and a monitoring duty in one. Route the content of the requests back to the system owner, not just the responses back out.

Questions Deployers Ask

Is this the same as the GDPR right not to be subject to automated decisions?

They overlap and they are not the same, which means a single request can trigger both and neither answer satisfies the other. The data protection right is framed around decisions based solely on automated processing producing legal or similarly significant effects, with its own exceptions and its own supervisory authority; the AI Act right is framed around decisions taken on the basis of output from a high-risk system and reaches situations where a human was involved but the system's output drove the outcome. The practical consequence for a deployer is organisational: one intake, one record, and a response that covers both framings, because a person who receives a competent explanation rarely cares which instrument produced it. Keep the deadlines separate internally — data protection law gives you a specific clock and the AI Act does not, so the shorter one governs your process.

Our vendor says the model is proprietary. What can we actually disclose?

Enough for the person to understand what happened to them and to identify an error, which is a different thing from enough to reconstruct the model. Protecting intellectual property and commercially confidential information is a recognised limit on disclosure and it bites on internals — weights, architecture, feature engineering, thresholds where disclosure would enable gaming. It does not reach the categories of input used, the role the output played in the decision, or the effect a factor had in this case. The negotiation point is upstream: require the vendor, before deployment, to supply a per-decision explanation artefact suitable for disclosure to an affected person, and to support you when a request arrives. A vendor unwilling to commit to that is telling you its product cannot be deployed for high-risk decisions in Europe, which is information worth having during procurement rather than after.

We are outside the EU. Does this reach us?

Potentially, and the trigger is where the output is used rather than where you are incorporated. The Act reaches deployers established outside the Union where the output produced by the system is used within it, and the high-risk annex covers exactly the decisions that cross borders easily — recruitment for a role in an EU member state, credit for an EU resident, admission to an EU programme. A US company screening applicants for its Dublin office is the standard example. Two consequences follow. First, the obligations attach to a slice of your traffic, which means you need to be able to identify that slice rather than apply everything everywhere. Second, an explanation request will arrive in a language and on a channel your support function may not be set up for, so the intake decision has to be made before the volume does it for you.

Does a human in the loop remove the obligation?

No, and treating it as though it does is the most expensive mistake available here. The right concerns decisions taken on the basis of output from a high-risk system, which includes decisions a human formally signs. What human involvement does change is the content of the explanation: you now have to describe the review accurately, including what the reviewer saw and what they could change. That description is checkable. If your logs show a reviewer approving hundreds of recommendations a day with no overrides, an authority reading that alongside your explanation letters will conclude the human step is decorative, and you will have said otherwise in writing to affected people. Measure the override rate before you describe the safeguard, and if it is effectively zero, fix the process rather than the wording.

What happens if we simply do not answer?

The immediate consequence is not a fine; it is a complaint. Affected persons can complain to the national market surveillance authority, and an authority that opens a file asks for the things you were supposed to have anyway — the logs, the human oversight arrangements, the deployer documentation, the record of requests and responses. An organisation that answered promptly and imperfectly is in a substantially better position than one that answered nothing, because the first has a record and the second has an absence that looks identical to non-compliance across every other obligation. The secondary consequence is private: silence pushes a person who wanted an explanation toward a lawyer or a regulator, and in employment and credit contexts those channels carry their own national liabilities that are considerably older and better established than the AI Act.

The Rejection-Letter Test

Take the last automated rejection your organisation sent to someone in the EU. Read it as the recipient. Is there anything on it that tells them a system was involved, and anything that tells them where to ask why?

If not, the obligation is not dormant — it is unreachable, which is a different and worse position. The first person who finds the answer will find it at a market surveillance authority, and the file they open starts with the logs you were already required to keep.

The Applicant Can Ask You Why. Article 86 Puts That Question on the Deployer.