Keep three lines beside an AI-assisted decision
The policy is not the record
Picture a risk lead opening a customer message that was drafted with AI. The message has already gone out. A manager now needs to understand what entered the tool, what was checked before sending, and what can still be found if the case is reviewed later.
The policy may be sensible. It cannot answer the question in front of the team on its own.
NIST's AI Risk Management Framework asks organisations to deal with risk in the design, use, and evaluation of AI systems. The practical test is whether that discipline is visible in an ordinary case, when someone is busy and the work has already moved on.
"A policy tells people what should happen. A case record gives a reviewer something to examine."
Keep three lines beside the work
For an AI-assisted customer note, claims summary, internal recommendation, or credit memo, I would keep a short record with three lines.
Input: The data class, source, and boundary that mattered to the case.
Judgment: What the person checked, changed, or decided before using the output.
Record: Where a second person can find the relevant note, approval, version, or review item.
The record does not need the whole case file. It needs enough context for the next person to understand what happened without guessing from the final output.
The three lines answer different questions. The input line is about the boundary around the information. The judgment line is about the human decision. The record line is about whether a second person can find the trail after the case has moved on.
Putting all three in one sentence is tempting. Keeping them separate is more useful, because a vague line shows the team exactly where the process is unclear.
The storage location deserves the same attention as the wording. A good case note is not much help if it sits in a private chat, a screenshot folder, or an employee's personal workspace. The person reviewing the case later should not need to know who handled it in order to find the record.
That does not mean building a new system for three lines. In many teams, the right home is the existing case record, approval log, or work-management tool. The important thing is that the team has agreed on the home before the first difficult case arrives.
What the three lines can look like
Take a customer message drafted from a claims summary.
Input: A manager used approved case information and removed identifiers that were not needed for the draft.
Judgment: The manager checked the factual basis, rewrote an unsupported sentence, and decided the case did not need a second review.
Record: The final message and the manager's case note sit in the existing claims record.
The wording will change by workflow. What matters is that the record names the real human decision, rather than saying someone was "in the loop" and leaving the reviewer to work out what that meant.
For a credit memo, the judgment line might say that the analyst checked the numbers against the source documents and removed a statement the model could not support. For a customer communication, it might record that a manager rewrote the recommendation and sent the case for another review.
Those are not perfect templates. They are examples of the level of detail a reviewer can use. "Human oversight completed" is not enough, because it describes a principle instead of an action.
The record should stay close to the decision, not become a second report written at the end of the month. A manager completing it while the case is still open can remember what they checked. A manager asked to recreate it later will usually have less to work with.
What this catches early:
When a team starts completing these lines, a few problems usually become visible quickly:
An approved workflow begins to take in more sensitive information than anyone expected.
A human check exists, but disappears once the message or recommendation is sent.
The record lives in a private chat or a personal folder, so no second reviewer can find it.
Staff cannot describe the judgment they are expected to make because the process never made it clear.
Those are useful findings. They point to a change in the work, not another general reminder to "use AI responsibly."
Test it on one ordinary case
Choose a recent piece of work that people recognise: a customer note, a claims summary, a manager briefing, or an internal recommendation. Ask the person who handled it to complete the three lines with a reviewer nearby.
Use the exercise to see what the current process makes easy, what it hides, and where a reviewer would be left without an answer. The aim is not to test whether staff remember policy wording.
If the three lines stay vague, that is the practical issue to fix. A vague input line often means the data boundary is unclear. A vague judgment line usually means the review role has not been designed. A vague record line means the evidence has no agreed home.
Start with five ordinary cases, then look for a pattern. If every case needs a manager to reconstruct the same decision after the fact, the problem is in the workflow, not in the employee who happened to handle the last one.
At the end of the small sample, ask one final question: could another reviewer understand why the output was used without calling the original handler? If the answer is no, the team has found a specific operating gap. It can now decide whether the fix belongs in the tool settings, the review step, the data boundary, or the record itself.
Save the three-line record beside the work. It gives the next reviewer a place to start, and gives the policy a visible connection to what actually happened.
That small record also gives the team something practical to improve. When the same line stays vague across several cases, the gap is no longer theoretical: it is a design problem the owner can fix before the next review.