How does the right to explanation work?

The right to explanation generally means a person can ask for understandable information about an automated decision that affects them. Organisations should be able to describe the logic, main factors, and available review route in plain language. The practical challenge is making explanations accurate without exposing sensitive model details or enabling abuse.

What the right to explanation is trying to achieve

The right to explanation is mainly about transparency and contestability. Affected people should be able to understand, at a useful level, why an automated decision was made and what they can do next if it seems wrong. That means the explanation has to be meaningful to a non-specialist, not just technically correct.

In practice, the best explanations describe the main inputs, the decision logic at a high level, and the route to human review or appeal. For a deeper policy and privacy context around automated decisions and personal data, see AI and Privacy Guide.

What organisations usually have to provide

A workable explanation normally covers three things: what information mattered, how that information influenced the outcome, and where the person can challenge or correct the result. The goal is to make the decision intelligible without exposing sensitive model internals, trade secrets, or information that would help someone game the system.

That distinction matters because many automated systems use scores, rules, or model outputs that can be explained in plain language even when the exact weights, prompts, or thresholds should not be disclosed. For practitioners building controls around access, disclosure, and auditability, NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST SP 800-63 Digital Identity Guidelines are useful reference points.

Why explanations are hard to get right in real systems

The practical difficulty is balancing clarity, confidentiality, and robustness. If an explanation is too vague, it is useless to the person affected. If it is too detailed, it can leak sensitive model logic, expose protected data, or reveal enough about the decision process for abuse or manipulation.

This is especially tricky when the system is probabilistic, uses multiple models, or relies on ranking rather than a single deterministic rule. The explanation must be honest about uncertainty and about the fact that some automated systems support a recommendation rather than make a fully final decision. That is why governance, audit trails, and response handling matter alongside the explanation itself.

Risk and Threat Considerations

Right-to-explanation obligations create a real disclosure risk if organisations overshare model internals, training signals, or sensitive business rules. They also create a manipulation risk if explanations become so specific that they help users, fraudsters, or adversaries reverse-engineer thresholds, evade detection, or tailor inputs to trigger a better outcome.

Failure mechanism: The organisation gives either an over-simplified explanation that cannot support review, or an over-detailed explanation that reveals sensitive logic, private data, or exploitable decision features.

Impact: People lose trust in the process, disputes become harder to resolve, and the system may become easier to game, especially where the decision influences access, eligibility, risk scoring, or moderation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	Supports reviewable automated decisions and traceable decision outcomes.
	AC-6 — Least Privilege	Limits who can see sensitive model details while preserving needed review access.
Recommendation — Log decision inputs and outcomes so reviewers can reconstruct why the automated result occurred. Restrict sensitive model and decision-detail access to authorised reviewers only.
GDPR	Article 22 — Automated individual decision-making, including profiling	Directly governs meaningful information and human review for automated decisions affecting people.
	Articles 13-15 — Information to be provided to the data subject and right of access	Supports understandable disclosure about the logic and effects of automated processing.
Recommendation — Provide meaningful information and a human review route for affected individuals. Explain the logic and main consequences of automated processing in plain language.
ISO/IEC 27001:2022	A.5.15 — Access control	Supports controlled disclosure of sensitive decision logic and supporting evidence.
Recommendation — Limit access to sensitive decision artefacts while enabling authorised review.

Practitioner Guidance

What to verify: Test the explanation against a real challenge scenario, not just a compliance checklist. A good explanation should let a reviewer trace the decision from the stated inputs to the stated outcome and identify what could be corrected or appealed.

Decision rule: If you cannot explain the decision without revealing sensitive model behaviour, shift to a layered explanation, give the affected person the high-level reasons and review path, and keep the technical detail for authorised reviewers and audit teams.

Practitioner takeaway: The right to explanation works best when organisations treat it as a contestability control, not a disclosure dump, and design the explanation so it is understandable, reviewable, and safe to reveal.