How to Explain an AI Decision to the Person Affected

The hard part is not getting the system to run. The hard part is telling the person why it acted, when you can feel their hope tighten into anger. If I want accountability, I have to give them more than a shrug wrapped in technical words. I have to give them a path they can use.

1) Start with a plain notice of AI use

I write the first line like I am asking for trust, not asking for patience. I say the decision involved an AI system, in plain language the person can repeat to someone else. This helps because secrecy breeds the worst conclusion, even when the outcome was correct. First step: add a short “AI was used” statement to the top of the decision letter, and make it specific enough to matter.

2) Name the decision purpose, not just the result

I tell them what the decision was trying to do, and what question the AI was answering. “Approve,” “deny,” “rank,” or “select” is not enough. A purpose sentence helps because it shapes what they should challenge, and it prevents the explanation from becoming a mystery box. First step: write one sentence that begins with “The system was used to decide whether…” and end it with the same wording you used internally for the outcome.

3) Give important factors with the right level of meaning

I pick a short set of factors that truly influenced the outcome and I explain them as factors, not as a machine log. I resist the temptation to list everything the model touched. Too much detail turns into noise, and noise feels like evasion. First step: choose three to five factors that a reasonable person would recognize as relevant, then add one sentence per factor that connects it to the purpose.

4) State what data was used, and where it came from

I separate “data used” from “model design,” because the person can’t challenge model math. I describe the data category and source in human terms, like form answers, prior records, or third-party data. This helps because errors often come from inputs, not from the model’s style. First step: include a data-source line that names the input types and indicates whether the person supplied it or a system supplied it.

5) Admit uncertainty where it matters, not where it sounds nice

I do not pretend the output is a fact when it is a judgment under uncertainty. I say there are limits, such as missing data, proxy signals, or data that may not transfer well to the person’s situation. This helps because certainty without honesty pushes the person toward disbelief. First step: add one short uncertainty sentence that answers “What could be wrong about this decision?” without blaming the person.

6) Explain human review as a real control, not a trophy

I say who checked the decision, when human review happens, and what the human can change. If the human only rubber-stamps, I say so in plain terms. If the human can override, I describe what triggers override and what standards the reviewer should apply. This helps because accountability is not a label, it is a mechanism. First step: write a “Human review” section with two lines: “What is reviewed” and “What can be changed.”

7) Offer correction and appeal as steps with deadlines and access

I make correction and challenge usable, even if the person is upset and wants to move fast. I explain what they can correct, how they submit it, what information they should include, and what timeline applies. This helps because the gap between “you can appeal” and “here’s how” is where people give up. First step: include a simple checklist of next actions, and add a contact or intake method the person can actually access.

8) Reframe the explanation toward what the person can test

I try to write as if the person is deciding whether to fight, not whether to understand. I connect the explanation to the most realistic challenge points: an input that may be wrong, a factor that was misread, or a rule that was applied incorrectly. I do not sell an illusion that the model “understood them,” because that would be unfair and often false. First step: end the explanation by stating one or two things the person can provide or dispute that could change the result.

9) Use the “same person” logic to avoid overpromising

I do not imply that every explanation will fit every audience, and I do not promise the same depth for every case. I aim for consistency in what categories of information are included, even if the level of detail varies by impact. This helps because it sets correct expectations, and it reduces the risk that a later review finds the explanation was incomplete for the stakes involved. First step: define a small set of mandatory explanation fields, then document when you can expand them.

10) Keep the tone steady: accountable, not defensive

I can feel the urge to defend the work, especially when it is technical and I have to translate it under pressure. But my job in the explanation is not to win an argument. My job is to show what was done, what it relied on, what could be wrong, and how the person can challenge it. This helps because defensiveness makes the process feel rigged, even when it is not. First step: do a “defense edit” by removing every sentence that justifies the organization and keeping only sentences that support the person’s next move.

A good explanation is not a performance. It is a tool the person can use to question the decision without guessing what to ask. After the Demo, the person still has to live with the outcome, so the explanation has to leave them with one realistic path to change the result, or at least to test whether it should change.