AI Risk Management

How to Build an AI Risk Register (With a Working Template)

A field-by-field walkthrough of how to build an AI risk register that gets used, including a full template, scoring methodology, and real examples for common AI use cases.

Jasper Claes

May 26, 2026 · 17 min read

AI Risk Management

Ask to see an organization's AI risk register and you'll usually get one of two things: nothing, or a spreadsheet with five rows nobody has opened in six months. This is a field-by-field walkthrough of how to build one that actually gets used, including three fully worked examples and the review process that keeps it alive.

TL;DR

A usable AI risk register needs 9 specific fields per risk — most templates are missing at least three of them, usually the ones that keep it current.
Score likelihood and impact separately (1-5 each), and define impact across legal, safety, financial and reputational dimensions rather than a single number.
Three worked examples in this guide show what a fully completed entry looks like for a hiring tool, a customer support chatbot, and a fraud detection model.
The fields most registers skip — next review date and residual risk sign-off — are exactly what an auditor checks first.
A register without a scheduled review meeting is a document, not a process — the meeting is what actually keeps entries current.

Why Most AI Risk Register Templates Fail

Generic risk register templates are built for infrastructure and security risk — categories like "server downtime" or "unpatched vulnerability" that don't map to how AI systems actually cause harm. For the underlying methodology behind AI-specific risk categories, see our companion guide, AI Risk Management: A Practical Framework. This post focuses specifically on building the register itself.

The Complete Field List, Explained

Field	What goes here
AI system	The specific system this risk applies to — never a blanket organization-wide entry
Risk category	Model drift, training data bias, hallucination, automation bias, third-party risk, security, or regulatory misclassification
Description	A specific, concrete statement of what could go wrong — not a category name repeated
Likelihood (1–5)	How probable this risk materializes, given current controls
Impact (1–5, by dimension)	Scored against the worst of legal, safety, financial and reputational impact
Current controls	What's already in place that reduces likelihood or impact today
Treatment decision	Mitigate, transfer, avoid or accept — with an assigned owner
Residual risk	What remains after treatment, explicitly signed off if accepted
Next review date	A specific date, not 'ongoing' or 'quarterly' without an anchor

Choosing a Scoring Scale

A 1–5 scale for both likelihood and impact is granular enough to differentiate real risks without inviting false precision. Plotting scored risks on a grid makes it immediately visible which ones need the most attention.

Three example risks plotted on a likelihood × impact grid — this is what a register's scores should let you visualize.

Worked Example: Three Real AI Systems, Fully Scored

1. Hiring screening tool — Risk: biased candidate scoring across demographic groups. Likelihood: 4. Impact: 5 (legal + reputational). Current controls: quarterly bias audit. Treatment: mitigate — add human review of all rejections at the top of funnel. Residual risk: medium, accepted by legal. Next review: in 90 days.

2. Customer support chatbot — Risk: hallucinated product information given to customers. Likelihood: 4. Impact: 2 (financial, low-stakes queries only). Current controls: response confidence threshold with escalation to human agent. Treatment: mitigate — expand escalation triggers. Residual risk: low, accepted by product lead. Next review: in 180 days.

3. Fraud detection model — Risk: model drift as fraud patterns evolve faster than retraining cycle. Likelihood: 3. Impact: 3 (financial). Current controls: monthly performance monitoring. Treatment: mitigate — shorten retraining cycle from quarterly to monthly. Residual risk: low-medium, accepted by risk committee. Next review: in 30 days.

Setting Ownership and Review Dates That Stick

Every entry needs exactly one named owner — not a team name. "Platform team" means no individual feels responsible; "Maria, Platform Lead" does. Review dates should be calculated from the last review, not a fixed calendar date everyone forgets, and ideally trigger an automatic reminder rather than relying on someone remembering to check the spreadsheet.

Running a Risk Review Meeting

Start with overdue items — anything past its review date gets addressed first, not last.
Walk through any new or changed AI systems since the last meeting.
Revisit residual risks marked 'accepted' — confirm the acceptance still holds given any new information.
Assign next review dates before the meeting ends — don't leave the register in an ambiguous state.

From Register to Action: Turning Entries Into a Backlog

A risk register that doesn't connect to an actual project backlog just documents problems without fixing them. Each "mitigate" treatment decision should generate a trackable task with the same owner and deadline recorded in the register — otherwise the register and the team's actual work exist in two disconnected systems.

Common Data-Quality Problems

A quick health check for any existing register — the last two rows are what usually go unnoticed.

Risks written as vague categories ('bias risk') instead of specific statements ('scoring bias against candidates over 50')
Owners listed as teams instead of named individuals
No review date, or a review date in the past that was never addressed
Residual risk left blank after a treatment decision was recorded

The Template, Recap

AI system
Risk category
Description
Likelihood (1-5)
Impact (1-5, worst dimension)
Current controls
Treatment decision + owner
Residual risk
Next review date

Primary Sources

NIST — AI Risk Management Framework
EUR-Lex — Regulation (EU) 2024/1689

Where Unorma Fits

A register that doesn't go stale

Unorma’s gap analysis and oversight modules turn this template into a live record with automatic review reminders, instead of a spreadsheet someone has to remember to open. Read the broader methodology in AI Risk Management: A Practical Framework.

Frequently asked questions

What fields does an AI risk register need at minimum?

Nine fields: the AI system, risk category, description, likelihood, impact (by dimension), current controls, treatment decision and owner, residual risk, and next review date.

Should likelihood and impact use the same numeric scale?

Yes, a matching 1-5 scale for both makes them easy to multiply into a comparable severity score, and easy to plot on a matrix to visualize priority at a glance.

Who should own individual entries in the register?

A named individual, not a team — 'the platform team' diffuses responsibility, while a named owner creates clear accountability for treatment and review.

How often should a risk register review meeting happen?

Monthly is common for organizations with several high-risk AI systems; quarterly can work for smaller, lower-risk portfolios — the key is that it's scheduled and recurring, not ad hoc.

What's the most commonly missing field in real-world registers?

Next review date. Without it, a register becomes a one-time snapshot instead of a living record, which is usually the first gap an auditor identifies.

How does a risk register connect to formal frameworks like the EU AI Act or ISO 42001?

The same identify-assess-treat-monitor structure underlies the EU AI Act's Article 9 risk management requirement, ISO 42001's clause 6, and the NIST AI RMF's Map/Measure/Manage functions — one well-built register does most of the underlying work for all three.

Should low-risk AI systems have register entries too?

Yes, but they need far less scrutiny — a lightweight entry with a longer review interval is enough; the goal is complete coverage, not equal depth for every system.

Key terms in this article

About the author

Jasper Claes

Compliance Manager & AI Governance Consultant

Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets.

View full profile

Keep reading