A customer receives a message saying that their account has been restricted after an automated risk review. The message lists three factors and says the system is highly accurate. It does not identify which transactions caused concern, whether the restriction is temporary, or how to correct a mistake. The customer has received information about a decision, but little help responding to it.
Useful transparency begins with the questions a person faces at that moment. What happened? What information was used? What can be checked or corrected? Who can review the outcome? Explainable AI can contribute to answering these questions, but a model explanation is only one part of the communication and service process. The aim is an accurate understanding of the decision and its limits, with a practical route forward.
Explain the Decision People Experience
A model might produce a risk score while application rules determine whether that score triggers a warning, a request for evidence, or an account restriction. Staff may then add a further judgment. Telling a customer which inputs contributed to the score leaves the final outcome unexplained if the policy and human roles remain invisible.
Describe the relevant stages in ordinary language. In an illustrative account-review process, automated analysis might identify unusual activity, a policy might require a temporary hold, and a specialist might decide whether the hold remains. The customer needs an accurate account of which stages actually occurred in their case. Avoid describing a human review when the only human involvement was designing the policy months earlier.
State the consequence clearly, including its scope and current status. A restriction on one transaction is different from a closed account. If further information is needed before a decision, say so. The notice should distinguish a provisional assessment from a final outcome and should identify any time-sensitive action the person needs to take.
The business guide to explainable AI considers how to specify these requirements before selecting a system. Here the concern is how the information reaches someone who must understand and respond to a particular outcome.
Give Reasons That Connect With Checkable Facts
A technical variable such as “activity deviation score” is not a useful customer-facing reason without context. It may summarise several transactions, a comparison period, and a calculation the recipient has never encountered. Translating it into a sentence requires understanding what the variable represents and ensuring that the translation remains accurate.
Where appropriate, connect the explanation to relevant records. A person might need to know that an address differs between two records or that a recent payment is missing from the information used. Show enough detail to identify the issue while protecting other people’s data and legitimate security information. Disclosure requirements and restrictions depend on the particular service and legal context.
Distinguish a factual input from an inference. “The record shows a payment overdue on this date” is different from “the system estimated elevated payment risk.” A customer may be able to correct the former directly. The latter may require a review of whether the inference and the resulting action are appropriate. Combining them into a single authoritative statement makes challenge harder.
Do not present attribution scores as percentages of responsibility unless that interpretation is justified. A chart can describe contributions to a model output under a particular method without establishing why the business action was appropriate. The article on investigating explanations develops that distinction for reviewers examining the evidence behind a claim.
Structure the Information Around the Next Step
A layered explanation can let people begin with the outcome and then inspect the details they need. The first view should contain the decision, its principal reasons, the relevant consequence, and the available response. Further detail can include source records, descriptions of the assessment process, and contact or review information.
Layering should not bury essential qualifications. If the result is based on an incomplete record, that fact belongs near the outcome. If a review deadline applies, it should not appear only in an expandable technical note. The structure should reduce navigation effort without reducing access to information that could change the person’s response.
Test the language with likely recipients. Ask them what they think happened, which facts they would check, and what they would do next. This reveals whether a familiar word such as “reviewed” is being interpreted as a specialist examination when the organisation meant an automated assessment. Clear typography cannot repair a misleading term, but it can make a well-written explanation easier to use.
Describe Limits Without Making the User Guess
An explanation should identify limitations that matter for the case. An unavailable source, an estimated value, or a recent change in circumstances may affect how the result should be interpreted. A general disclaimer that AI can make mistakes does not tell the recipient whether any such limitation applies here.
Do not attach an unexplained confidence percentage to create reassurance. A numerical score needs a defined meaning and appropriate evaluation. Even a well-calibrated probability cannot determine whether the policy response is proportionate. If uncertainty changes the available route, explain that route: supply a missing document, obtain a specialist assessment, or wait for a verified record.
Avoid turning a model counterfactual into a promise. An analysis might show that changing a recorded value would change the output of a fixed model under specified conditions. It does not automatically establish that a person can make that change, that other circumstances will stay fixed, or that a future application will use the same rules. Guidance should distinguish correcting present information from proposing future steps.
Explanations also need boundaries around their scope. An account notice should not imply that the organisation has evaluated every aspect of the customer’s circumstances when it has only checked a limited set of records. Honest limits help recipients decide what additional information may be relevant.
Make Review Work Beyond the Notice
A contact link is useful only if it reaches a process capable of addressing the issue. Establish who receives corrections, who can review the decision, what evidence they can access, and how the result returns to the customer. The organisation should also know how to handle an urgent consequence while review is pending.
The reviewer needs authority to act on new information. Running the same unchanged model again may reproduce the same outcome without examining the complaint. A meaningful process can assess factual errors, missing context, policy application, and other relevant grounds for challenge. The appropriate review depends on the decision and applicable obligations.
Keep a record of what the person was told. If the explanation changes after a correction, distinguish the original outcome from the reviewed outcome and explain the relevant difference. This avoids leaving customers and staff with conflicting notices that appear to describe the same event.
The AI interface ergonomics article considers the staff side of this process. Reviewers need accessible sources and manageable workloads if the organisation expects them to examine disputes carefully. Customer-facing clarity and internal operational support need to develop together.
Evaluate Understanding and Appropriate Reliance
A more persuasive explanation can increase confidence without improving judgment. Satisfaction and trust ratings therefore provide incomplete evidence of success. Evaluation should ask whether people understand the outcome, can identify a relevant error, and can use the available correction or review route.
Use representative scenarios, including correct decisions, incorrect records, and cases where additional evidence should change the outcome. Observe what participants do rather than relying only on whether they say the explanation was clear. A person may rate a notice highly while misunderstanding that the account restriction has already taken effect.
Check accessibility across languages, reading needs, assistive technology, and devices. Do not depend on colour alone to distinguish status, or require a desktop dashboard to reach essential information. Provide an alternative route where a digital process would exclude affected users. The necessary support will vary, but it should be treated as part of the service requirement.
After release, monitor the reasons people request help, how long corrections take, and whether reviewed cases reveal repeated data or policy problems. A high complaint volume can signal unclear notices, underlying errors, or both. These are hypotheses to investigate rather than reasons to optimise for fewer complaints by making the route harder to find.
Keep Transparency Connected to Accountability
Legal duties require a context-specific assessment. For example, the CJEU’s account of C-203/22 addresses meaningful information about the actual procedure and principles used in automated credit assessment under the GDPR. The explanation must support understanding and challenge. It does not establish that any technical explanation automatically satisfies every disclosure obligation.
Operationally, keep explanation content connected to the deployed process. Changes to the model, inputs, thresholds, or review policy can change what a notice should say. Include customer-facing explanations in release review, alongside tests confirming that the reasons refer to the relevant case and version.
Transparency becomes useful when it helps a person understand an outcome and obtain a reasoned response to a legitimate question. It should also help the organisation discover and correct failures. That requires an explanation people can use, evidence staff can inspect, and a review process with enough authority to make a difference.
