GDPR Right to Explanation

Articles 13(2)(f), 14(2)(g), and 15(1)(h) require data controllers to provide meaningful information about the logic involved in automated decisions. This is not a right to full algorithmic disclosure or source code. Instead, it mandates a functional explanation of the model's decision-making rationale, including:

• The categories of data used in the decision process
• The relative weight of key features
• The general operation of the model
• Why a specific decision was reached in a given context

This requirement targets comprehensibility for the data subject, not technical exhaustiveness for an engineer.

Article 22(3) mandates that when organizations rely on solely automated processing with legal or similarly significant effects, they must implement suitable safeguards. These explicitly include:

• The right to obtain human intervention on the part of the controller
• The ability for the data subject to express their point of view
• The right to contest the decision

These safeguards transform explanation from a passive disclosure into an active, contestable process. The explanation must be sufficient for a human reviewer to meaningfully evaluate and potentially override the automated outcome.

Articles 13(2)(f) and 14(2)(g) require proactive notification of the existence of automated decision-making and meaningful information about the envisaged consequences of such processing. This is a pre-decision transparency obligation.

Key requirements:

• Data subjects must be informed at the point of data collection
• The notification must describe the type of decisions the system makes
• It must outline the potential effects on the individual
• This applies even when Article 22's prohibition on automated decisions is not triggered

This ensures individuals understand they are interacting with an automated system before any decision is rendered.

Article 15(1)(h) grants data subjects the right to access specific information about automated decision-making upon request. This is an ex-post right exercisable after processing has occurred. The controller must confirm whether automated decision-making is taking place and provide:

• Meaningful information about the logic involved
• The significance of the processing for the data subject
• The envisaged consequences of such processing

This access right is distinct from the proactive notification duties under Articles 13 and 14. It creates an on-demand transparency mechanism that data subjects can invoke at any time.

Recital 71 explicitly states that automated decision-making should be subject to safeguards including 'the right to obtain an explanation of the decision reached after such assessment.' While Recitals are non-binding interpretive guidance, this language has been central to legal scholarship arguing for a self-standing right to explanation.

The Recital clarifies that the explanation must enable the data subject to:

• Understand the decision that has been made
• Challenge the decision effectively
• Receive an explanation that is specific to the individual case

This supports the interpretation that generic system-level descriptions are insufficient; case-specific ex-post explanations are required.

Article 35 requires a Data Protection Impact Assessment (DPIA) for processing that involves systematic and extensive evaluation of personal aspects based on automated processing. The DPIA must document:

• A systematic description of the envisaged processing operations
• An assessment of necessity and proportionality
• The risks to rights and freedoms of data subjects
• The measures envisaged to address those risks, including safeguards

While not a direct explanation to the data subject, the DPIA creates an internal governance artifact that documents the logic, risks, and safeguards of automated systems. This documentation forms the foundation for generating meaningful external explanations.

The specific phrase from Articles 13(2)(f), 14(2)(g), and 15(1)(h) that mandates controllers provide data subjects with 'meaningful information about the logic involved, as well as the significance and the envisaged consequences.'

• Not Source Code: Regulators clarify this does not require disclosing proprietary algorithms or full model weights.
• Functional Explanation: Must convey the rationale of the decision-making process in a way the data subject can understand.
• Weighting of Features: Controllers should explain which categories of personal data were most influential in reaching the specific decision.

While not legally binding law, Recital 71 provides the interpretive context for the Right to Explanation. It states that automated processing should be subject to suitable safeguards, including:

• Specific Information: Providing the data subject with the logic involved.
• Human Intervention: The right to obtain human intervention on the part of the controller.
• Contest the Decision: The ability to express one's point of view and challenge the automated outcome.

This recital bridges the gap between a static transparency report and an interactive, contestable explanation interface.

The technical implementation of the Right to Explanation. Recourse goes beyond passive transparency to provide actionable steps a user can take to change an unfavorable outcome.

• Counterfactual Explanations: 'You were denied a loan because your income was $X. If your income were $Y, you would have been approved.'
• Feasibility Constraints: Recourse suggestions must respect immutable characteristics and real-world actionability.
• Causal Reasoning: Effective recourse requires understanding the causal structure of the decision boundary, not just correlational feature importance.