How to build an AI risk register that survives an audit | Insights

When something goes wrong with an AI system, or when an enterprise client's counsel sends the due-diligence questionnaire, the first request is always the same: show me your risk register. Organisations that have one answer in a day. Organisations that do not begin a scramble that costs more than the register ever would have.

This article is the method: how to produce a register that is genuinely useful for running AI, and that holds up when someone hostile reads it.

First, what a register is not

A list of technologies is not a risk register. Neither is a list of worries. "The AI might be wrong" and "reputational risk" cannot be scored, treated or monitored, because they name an anxiety, not an event. Every usable row has three parts:

An event, caused by something, leading to a consequence for someone.

Compare: "The support chatbot commits the company to refund terms it invents, because its output is unconstrained, leading to binding customer claims." That can be scored, classified, treated and checked. Write every row to that standard and half the audit is already passed.

Find the risks with a search grid, not a brainstorm

Unstructured workshops produce three obvious risks and a false sense of completeness. Work through six classes instead, one at a time: bias (systematic unfairness toward groups), robustness (the system failing at its job, including quietly), privacy (personal data flowing where it should not), security (deliberate attack, including prompt injection), misuse (legitimate users doing unintended things, including overreliance), and systemic and third-party (risk imported from outside: vendor model changes made without notice, concentration on one provider, upstream training data you cannot inspect, and your vendor's own vendors; for organisations that buy rather than build, the largest and least examined class).

Two rules make the grid work. Every class gets asked about every system, and an empty class requires a written reason. "We found no security risks" is usually a finding about the search, not the system.

Who is in the room matters as much as the grid: the system's business owner, someone technical, someone who can speak for the people the system affects, someone with legal or data protection sight, and someone explicitly licensed to be awkward. The affected voice is the seat most often skipped, and it is where the bias and misuse findings come from.

Score with anchors, and take the maximum

Unanchored scoring is opinion in a grid: two assessors score the same risk 2 and 5 and both feel right. The fix is written anchors for every point on the scale, so scores are reproducible.

Severity deserves special care. Score it on four dimensions (harm to people, legal, financial, reputational) and take the highest, never the average. A risk scoring people 4, legal 3, financial 1, reputational 2 is a severity-4 risk. The average, 2.5, would bury serious harm to individuals under low financial impact, which is precisely the arithmetic regulators exist to punish.

Then hold two judgements apart. Your internal score says how worried you are. The legal classification (under the EU AI Act, a lookup by use case, not a score) says what the law thinks the system is. A CV-screening tool is legally high-risk however well controlled you believe it to be, and an internal knowledge assistant can be legally minimal while carrying your single largest confidentiality exposure. Record both, per row, and never let one answer the other's question.

Treat honestly

Every above-appetite risk gets one of four responses: treat, tolerate, transfer or terminate. Three honesty rules separate real treatment from decoration:

Every treated risk carries at least one detective control, something that would tell you the preventive controls have failed. Prevention without detection is hope.
Residual scores drop when controls are implemented and evidenced, not when they are planned. A register whose residuals all land conveniently just below the appetite line has been reverse-engineered, and auditors recognise the shape.
Tolerance is accepted by someone senior enough to own it, with an expiry date. Transfer (insurance, indemnities) moves money, not accountability: the harm to affected people and to your reputation stays yours.

Keep it alive

A register's value is measured at its second review, not its first draft. Give it a heartbeat (quarterly review for high-tier systems, annual for the rest) and a set of interrupts: vendor model updates, scope creep, incidents, monitoring thresholds firing, regulatory change. Wire the interrupts into processes that already run, such as change management and procurement, so they fire without anyone remembering the register exists.

Then watch the movement. A register where nothing has changed for two quarters while the organisation kept adopting AI is not stable; it is dead. Movement (new rows, closed rows, residuals shifting) is the health signal, and its absence is what a good auditor checks first.

The failure modes to design against

The audit-eve register: every review date clustered in the week before the audit. Version history gives it away.
The hundred-row register: everything anyone ever said, never triaged. Ten live rows beat a hundred dead ones.
The private spreadsheet: a register is a governance record; it needs a shared home, access control and version history.