Building an AI risk register people actually use

A risk register is only useful if it changes behaviour. Most do not. Here is the pattern that does.

Risk registers are the most common artefact in any AI Management System, and the least read. Open the register of almost any organisation that is six months into an AI governance program and you will find the same pattern: thirty to forty rows, each with a description, a likelihood and impact score, a generic owner like risk team or AI committee, and a last reviewed date several months in the past. The register exists. It does not change anything.

The reason is structural, not cultural. Most registers are written for auditors, not for the engineers and product managers who actually own the risk. The auditor reads the register once, at the point of audit, and asks whether it covers the right things. The engineer is supposed to read it continuously, and to change their behaviour based on what they find there. These are very different uses, and the register that satisfies the first almost never satisfies the second.

The three properties that change everything

A register that gets used has three qualities. Each row has a named individual owner, not a team. Each row links directly to the system or workflow it concerns, not to a category. And each row carries a next review date that triggers a notification in the channel the owner uses every day, not a quarterly reminder in an inbox they ignore.

These three changes sound minor. They are not. Together they convert the register from a static document into a working surface. Once the register changes the calendar of the people responsible for it, it becomes a working document. Until then it is a filing cabinet.

Name an individual, not a team

Team ownership is the single most common failure mode. A row that says the AI ethics committee owns this risk will never be acted on, because committees do not act, individuals do. The same row, rewritten to say a specific senior engineer or product manager owns this risk, becomes actionable immediately.

Individual ownership has a second benefit. When the named person leaves, or moves to a different team, the register breaks visibly. Their name still appears on rows they no longer own. The visibility forces a quarterly re-assignment exercise, which itself surfaces risks that have become orphaned and need new ownership. A team-owned register breaks silently and stays broken.

There is a common objection: individuals leave, teams persist, so team ownership is more stable. This is exactly backwards. Team ownership is more stable in appearance and less stable in reality. The team continues to exist, but no one inside the team has personal accountability, so no one acts. Individual ownership is less stable in appearance and more stable in reality, because the moments at which it visibly breaks are the moments at which it gets repaired.

Link to the system, not the category

Most registers organise risks by category: bias risks, security risks, supplier risks, model drift risks. This makes them easy to read top down and impossible to use from the engineering side. An engineer working on a specific system needs to know what risks apply to that system, not what risks exist in general.

The fix is to invert the organisation. Each system in the inventory should have a view of the register filtered to risks that apply to it. Each row in the register should link to the specific system or workflow it concerns. The categorical view can still exist for the auditor, but the operational view is system-first. Engineers will read a register that tells them what to watch for in the system they are about to change. They will not read a register that asks them to figure out which abstract category their change falls into.

Trigger reviews in real channels

Quarterly reminders by email do not work. They arrive in an inbox that the recipient already treats as a backlog, they compete with everything else in that inbox, and they require the recipient to open the register in a separate tool. By the time they are acted on, if they ever are, the moment has passed.

Reviews need to be triggered in the channel the owner uses every day. For most engineering organisations, that is Slack or Teams. The trigger should appear in a channel the owner already monitors, should link directly to the row in question, and should require either an update or an explicit acknowledgement that no update is needed. The acknowledgement matters. It produces evidence that the review happened, even when nothing changed.

Implementation is not difficult. A small scheduled job that reads the register, identifies rows whose next review date has passed, and posts a message tagging the owner is a half-day of work. The behavioural change is immediate and durable.

Treat the register as a working document

The register should change between reviews, not just at them. When an engineer discovers a new failure mode, they should be able to add a row in under a minute, from inside the tool they are already using. When a risk is mitigated by a code change, the row should be updated as part of the change, not in a separate workflow. When a supplier discloses a new vulnerability, the relevant rows should be flagged and routed to the owners that day, not at the next quarterly review.

This requires the register to live somewhere editable, with low friction, and with version history. A spreadsheet works. A Notion database works. A dedicated GRC tool can work, but only if it is genuinely easy to write to; many of them are not, and the friction is enough to keep the register stale. Pick the tool that the team will actually update, not the tool that looks most professional in a procurement review.

Use the register to drive design

The highest value of a working register is that it changes the design of new systems. When a team is scoping a new AI feature, they should look at the register and see what risks have been observed in similar systems. They should design around those risks before writing the first line of code. This shifts governance from a post-hoc verification activity to a pre-design input, which is where it generates the most value at the lowest cost.

For this to happen, the register has to be readable by people who did not write it. The descriptions need to be in plain language. The mitigations need to be specific and actionable, not generic statements about implementing controls. A row that says ensure appropriate human oversight is useless. A row that says all outputs above confidence threshold X are auto-applied, all below require reviewer approval, average review latency target 4 hours is useful, because it tells the next team what design pattern actually worked.

What a good register looks like

A good AI risk register is short, specific, and current. It has fewer rows than a bad one, because rows that no longer apply have been retired. Each row names a person, links to a system, has a recent review date, and describes both the risk and the actual mitigation in language an engineer can act on. The register lives where the team works. Reviews are triggered in real channels. New rows are added in minutes, not weeks.

Most importantly, the register is referenced. People talk about it in standups. They link to it in pull request descriptions. They cite specific rows in design documents. When that starts happening, the register has stopped being an artefact and started being part of how the organisation thinks. That is the only state in which it provides any protection at all.