What Recital 71 Actually Requires as a Right to Explanation

The claim that the GDPR grants a “right to an explanation” of an automated decision comes almost entirely from one sentence in Recital 71. That sentence is real, and it is not a right. The duties that are enforceable sit elsewhere and ask for something narrower and stranger than most people assume.

What a recital is, legally

Recital 71 of Regulation (EU) 2016/679 says, among other things, that processing of the kind covered by Article 22 should be subject to suitable safeguards, which should include the ability to obtain an explanation of the decision reached. Read as English, that is a right to an explanation. Read as EU law, it is not, because a recital is not an operative provision. Recitals state the reasons for the act and are used to interpret its articles where those articles are ambiguous; they cannot create an obligation that the articles do not contain, and the Court of Justice has said so repeatedly.

The tell is in the drafting history rather than in the text. The word “explanation” appears in the recital and nowhere in Articles 13, 14, 15 or 22. When the same concept appears in a recital but is absent from every article, the ordinary inference is that it was considered and not enacted. That is why the safest way to describe the position is: the GDPR requires transparency about automated decision-making, and the specific obligation is not correctly described as a right to an explanation of an individual outcome.

The three provisions that do bind

The operative text is in three near-identical places, and the near-identical wording is the point: Articles 13(2)(f), 14(2)(g) and 15(1)(h) of the GDPR each require the controller to provide, where automated decision-making within the meaning of Article 22(1) and (4) exists, meaningful information about the logic involved as well as the significance and the envisaged consequences of the processing for the data subject.

Article 13 applies when you collected the data from the person, at the time of collection. Article 14 applies when you did not, within a month or at first communication. Article 15 applies on request, at any time, as part of the access right. The first two are prospective: they describe a system before any decision about this person exists. Only Article 15 can be asked after the fact, and even there the text asks about the logic of the processing rather than about the reasoning behind one outcome.

That distinction survives contact with reality badly, which is exactly why it is worth stating precisely. A rejected applicant wants to know why they were rejected. The provision they can invoke asks the controller to describe how the system works and what it does to people. Those overlap but are not the same document, and an organisation that answers the second question well can still leave the person feeling they were told nothing.

What “the logic involved” turned out to mean

The Court of Justice addressed the wording directly in Case C-203/22, Dun & Bradstreet Austria, decided on 27 February 2025. The referred question was what an applicant is entitled to receive under Article 15(1)(h) when a credit-scoring decision goes against them, and whether trade secrecy lets the controller decline.

The direction of the answer matters more than any single sentence in it. The Court treated “meaningful information about the logic involved” as an obligation to explain the procedure and the principles actually applied in a form the person can understand, rather than as an obligation to hand over the algorithm, the source code or the model itself. Disclosing a formula the reader cannot interpret does not discharge the duty; nor does the existence of a trade secret extinguish it, because the balancing between the applicant’s rights and the controller’s secrets is for the supervisory authority or the court to perform, not for the controller to perform unilaterally and announce as the answer.

The Court’s own case file for C-203/22 is the citation to use; the judgment is short and worth reading in preference to any summary of it, including this one. For an AI system the practical translation is that a description of the input categories, their role, the thresholds or bands applied, and what a different input would have produced is closer to what is being asked for than a model card is.

Why the scope question came first

None of the above engages unless there is a decision within Article 22(1). For years controllers argued there was not: the credit bureau only produces a score, and the bank makes the decision, so nobody in the chain is doing solely automated decision-making with legal or similarly significant effects. The Court closed that gap in Case C-634/21, SCHUFA Holding, decided on 7 December 2023, holding that the automated production of a probability value can itself constitute a decision under Article 22(1) where a third party draws strongly on it in deciding about the person.

That reasoning generalises well beyond credit. A model that scores an applicant, a claim or a transaction, whose output a downstream user follows in the overwhelming majority of cases, is a candidate for being the decision rather than an input to it. Whether that is so on any given facts is unresolved and fact-sensitive, and the boundary is the subject of the definitional question about what counts as solely automated. See the case file for C-634/21.

What to actually produce

Build the disclosure once, as a document, and reuse it across Articles 13, 14 and 15 rather than improvising per request. A version that holds up tends to contain: the categories of input the system uses and where they come from; what the output is and its scale or bands; how the output is used, including whether anything happens without a human in the loop; the consequences for the person at each band; the existence and route of the Article 22(3) safeguards; and a plain statement of the main factors that move the output, expressed as factors rather than as coefficients.

Two failure modes recur. The first is answering with the model’s architecture — a gradient-boosted ensemble over 340 features — which is true, unhelpful, and not the logic in the sense the provision uses the word. The second is answering with a post-hoc attribution output, a SHAP plot or a list of feature weights, as though a numeric attribution were self-explanatory. Attribution methods are approximations of the model’s behaviour, and presenting one as the reason for a decision asserts more than the method supports. If you use one, say what it is and what it approximates.

Where the decision rests on a general-purpose model rather than a scorecard, the honest position is that a faithful account of the logic is genuinely hard to produce, and it is not yet settled how much that difficulty excuses. It is not a defence that the system is opaque; whether the duty can be discharged by describing the prompt, the retrieval sources, the decision rules applied to the output and the review step is being worked out case by case. If you are relying on such a model for a decision with legal or similarly significant effects, the design question and the disclosure question are the same question, and both are cheaper to answer before deployment than after a complaint. The related constraint on when you may run the decision at all is in the Article 22 exemptions.