Article
AI risk reviews need evidence receipts
AI governance often gets stuck in a comfortable fiction: if a team can assign a maturity score, it must understand its risk. The score feels tidy. It travels well in a steering committee deck. It lets different products appear comparable. But it usually hides the question that matters most: what proof do we have that this control worked on this workflow, under this threshold, recently enough to trust the next decision?
The thesis is simple: AI risk reviews need evidence receipts, not maturity scores.
A receipt is not a policy essay. It is a compact operating artifact that records the risk, the owner, the control, the evidence, the threshold, the last check, the decision and the next review date. It makes governance inspectable without pretending that one number can summarize model behavior, product context, user exposure and operational readiness.
The framing fits the direction of the NIST AI Risk Management Framework, which positions AI risk management around trustworthy design, development, use and evaluation of AI systems. That language matters because evaluation is not a ceremony at the end. It is the evidence trail that lets a product lead, governance operator or incident owner say what changed, what was checked and what decision the organization is willing to defend.
A maturity score is not evidence
A maturity score can be useful as a map of organizational capability. It can show whether a team has a policy, a review forum, documented owners or recurring evaluation. But it is a poor substitute for proof at workflow level.
Consider a customer-support summarization feature. A maturity score may say the team is at level three because it has a risk register, human review and monitoring. That still does not answer practical questions. Which risk is being controlled: privacy leakage, inaccurate escalation, tone drift, or unsafe advice? Who owns the control when support volume spikes? What sample was checked last week? What failure threshold triggers a rollback? Which reviewer accepted the residual risk?
This is the same problem measurement teams face when adoption percentages float without denominators. A number can look objective while leaving the operating base undefined. That is why AI adoption metrics need denominator maps. Risk scores need the same discipline: not a bigger spreadsheet, but a clearer unit of inspection.
The unit should be the AI workflow, not the whole company and not the model in isolation. A workflow has users, inputs, outputs, handoffs, permissions and consequences. It is where the risk becomes concrete enough to test.
What belongs in an AI risk receipt?
An AI risk receipt should fit on one page. If it cannot, the team is probably mixing multiple workflows or avoiding a decision. The point is not to document everything. The point is to preserve the minimum evidence needed to approve, block, limit or revisit a workflow.
A practical receipt has eight fields.
- Risk: the specific failure mode under review, such as unsupported medical advice, confidential data exposure, wrong refund decision, biased ranking or stale source citation.
- Owner: the accountable person, not a department. If the control fails, this person convenes the next action.
- Control: the mechanism that reduces the risk. This might be retrieval limits, human approval, prompt constraints, permission scopes, eval tests, red-team cases, rate limits or post-release monitoring.
- Evidence: the artifact that proves the control was checked. Examples include an eval run, sampled transcripts, test cases, access logs, incident records, reviewer notes or a monitoring query.
- Threshold: the line between acceptable and unacceptable. Without a threshold, evidence becomes decoration.
- Last check: the date and environment of the latest inspection. A launch sandbox result from three months ago is not the same as production evidence from last Friday.
- Decision: approve, approve with limit, pause, rollback, expand or investigate.
- Next review: the date or trigger for reopening the receipt.
This structure is deliberately mundane. It should feel closer to an expense receipt than to a strategy memo. A receipt says: this was bought, by this person, on this date, for this amount. An AI risk receipt says: this risk was reviewed, by this owner, with this control, against this threshold, on this evidence, leading to this decision.
How should a review use the receipt?
The review should start with the receipt, not with a slide about general readiness. The chair can ask four questions in order.
First, is the workflow named tightly enough? “AI in support” is too broad. “Drafting refund explanations before agent approval” is reviewable.
Second, is the risk specific enough to test? “Hallucination” is usually too vague. “Refund explanation cites a policy that does not apply to the customer region” can be sampled, measured and assigned a threshold.
Third, does the evidence match the control? If the control is human approval, the evidence should show approval behavior, not just model quality. If the control is retrieval grounding, the evidence should show source selection and citation correctness. If the control is permission scoping, the evidence should show what the system could and could not access.
Fourth, does the decision follow the threshold? If the threshold says no more than 1 percent of sampled outputs may contain unsupported policy claims, and the latest check found 3 percent, the decision cannot be unrestricted approval. It can be pause, limit, rollback or approve with a documented exception. But the receipt should make the contradiction visible.
This is where evidence receipts connect to security ledgers. A ledger records the controlled surface of a system, while a receipt records whether a risk control on a workflow has recently been proven. The two artifacts should reinforce each other. If the review uncovers a permission issue, it should update the security ledger. If the ledger changes, receipts for affected workflows should be reopened. See the related argument that AI systems need security ledgers, not checklists.
Where teams fake the evidence
The most common failure is not the absence of documentation. It is documentation that looks like evidence but cannot support a decision.
A policy is not evidence that the policy was followed. A demo is not evidence that production traffic is safe. A vendor benchmark is not evidence that your users, data and handoffs are covered. A risk register row is not evidence that a control works. A dashboard without thresholds is not evidence of readiness. A meeting note that says “approved” is not evidence unless it records the basis for approval.
Another common failure is stale evidence. AI workflows change quickly. Prompts change, retrieval corpora change, user behavior changes, models change and downstream processes change. A receipt should not imply permanence. It should expire through a date or trigger: new model version, new user segment, new permission, new jurisdiction, new data source, new incident class or material volume increase.
The receipt also prevents accountability laundering. If no owner is named, the organization has not accepted risk. It has only distributed anxiety. If the owner is a committee, the next incident will produce a transcript instead of a response. Name the person who can convene the fix.
Write one receipt before the next review
Do not start by redesigning the entire governance program. Pick one live AI workflow. Choose the workflow that is important enough to matter but small enough to inspect in an afternoon. Write the receipt with the product lead, the operator closest to the work and the governance owner who will be asked to defend the decision.
If the receipt is easy to fill, the review becomes faster. If it is hard to fill, that is the finding. The team may discover that the threshold was never agreed, the evidence is stale, the owner is unclear or the control does not match the risk. That is not bureaucracy. That is the review doing its job.
Maturity scores can remain useful as background. They can show whether the organization is improving its risk management capability over time. But the decision to launch, expand or continue an AI workflow should rest on a receipt. A score says how grown-up the organization thinks it is. A receipt shows what it can prove today.