Right to Explanation

The controller must provide meaningful information about the logic involved, not just a complex mathematical formula. This requires translating algorithmic decision-making into human-understandable terms.

• Focuses on the rationale and reasoning, not the source code
• Must explain why a specific decision was reached
• Requires bridging the gap between model internals and lay comprehension
• Often fulfilled through counterfactual explanations (e.g., 'You were denied a loan because your debt-to-income ratio exceeded 40%. If it were below 36%, you would have been approved.')

The explanation must convey the significance and the envisaged consequences of the processing for the data subject. This goes beyond the logic to address the real-world impact.

• Must articulate the practical effects of the automated decision
• Includes the severity, scope, and duration of the impact
• Example: 'This credit denial will be reported to credit bureaus, potentially lowering your score by 50-100 points and affecting future loan applications for up to 7 years.'
• Requires a socio-technical assessment, not just a technical one

Explanations must be specific to the individual data subject and the particular decision, not a generic description of the system's overall functionality.

• A generic model card or system overview is insufficient
• Must reference the actual input features that drove the specific outcome
• Requires local interpretability techniques like SHAP or LIME applied to the single inference
• Contrast with ex-ante explanations (before processing) which can be more general

The right is intrinsically linked to the requirement for suitable safeguards under Article 22(3). The explanation itself is a safeguard, but it must be supported by:

• Human intervention capability to contest the decision
• A clear mechanism for the data subject to express their point of view
• The ability to obtain human review of the automated decision
• These safeguards must be real and meaningful, not a rubber-stamp process

The right to explanation exists in tension with the protection of intellectual property and trade secrets. Controllers cannot refuse an explanation solely on grounds of proprietary algorithms.

• Recital 63 states the right is not 'adversely affecting the rights and freedoms of others,' including trade secrets
• However, trade secret claims cannot be used to completely deny an explanation
• Controllers must find a balance, providing sufficient information without revealing the full model architecture
• Model-agnostic explanation techniques are critical for navigating this tension

The right encompasses two temporal dimensions of explanation:

• Ex-Ante (Before Processing): Information provided at the point of data collection about the existence of automated decision-making, the logic involved, and the consequences. Required by Articles 13-15.
• Ex-Post (After Decision): Specific explanations of a particular decision after it has been made. Grounded in Article 22 and Recital 71.
• A robust compliance posture requires both layers of transparency

A game-theoretic approach to model interpretability that assigns each input feature an importance value for a particular prediction. Based on Shapley values from cooperative game theory, SHAP fairly distributes the prediction outcome among the features.

• Mechanism: Computes the marginal contribution of each feature across all possible feature subsets
• Output: A force plot showing which features pushed the prediction higher or lower from the base rate
• Use Case: Explaining why a specific customer received a high churn risk score in a retention model

A technique that approximates any black-box classifier with a locally faithful, interpretable model around a specific prediction. LIME perturbs the input instance, observes prediction changes, and trains a simple surrogate model like a sparse linear model.

• Key Property: Model-agnostic — works on any classifier without accessing its internals
• Output: A weighted list of the most influential features for that single prediction
• Limitation: Local fidelity does not guarantee global understanding of the model's overall behavior

The legal foundation for the Right to Explanation. Article 22 prohibits decisions based solely on automated processing that produce legal effects or similarly significant impacts. When such processing is permitted, the controller must implement safeguards including the right to obtain human intervention and a meaningful explanation of the logic involved.

• Trigger: No meaningful human involvement in the decision loop
• Scope: Credit denials, e-recruiting, and behavioral advertising profiling
• Recital 71: Explicitly mentions the right 'to obtain an explanation of the decision reached'

Structured transparency documents proposed by Google that accompany trained machine learning models. A model card discloses the intended use, evaluation results, ethical considerations, and limitations of a model in a standardized format.

• Sections: Model details, intended use, factors, metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats
• Purpose: Enables downstream users to assess fitness-for-purpose without reverse-engineering the model
• Standard: Increasingly referenced in regulatory guidance as a best practice for transparency documentation

The ability for a data subject to understand and act upon an adverse automated decision to change the outcome. Recourse goes beyond passive explanation to provide actionable pathways for remediation.

• Contrastive Nature: Focuses on what the individual can realistically change
• Feasibility Constraints: Must respect immutable characteristics and causal relationships
• Implementation: Often delivered via counterfactual explanation engines integrated into the decision workflow