What Belongs in an AI Risk Register? A Board-Level Guide to Assessing AI Risk Before You Deploy
Most boards now field a version of the same question every quarter: are we moving fast enough on AI, and are we exposed if we do? The two halves of that question pull in opposite directions, and without a shared way to talk about exposure, the conversation tends to swing between unfounded optimism and equally unfounded fear. A pilot gets waved through on enthusiasm, or a promising use case gets frozen because nobody can articulate what could actually go wrong.
The instrument that resolves this tension already exists in every well-run organisation. It is the risk register - the plain, unglamorous ledger that lists what could go wrong, how likely it is, how much it would hurt, who owns it, and what is being done about it. The problem is that the AI-specific risks rarely make it onto that ledger, because they fail in ways traditional IT risk frameworks were never designed to anticipate.
This guide sets out what an AI risk register is, why your existing one almost certainly has blind spots, which categories of risk it needs to cover, and how to score and govern the entries so the document drives decisions instead of gathering dust. The aim is a board that can say yes to AI with its eyes open, and no when the evidence warrants it.
Key Takeaways
An AI risk register is a living ledger: it lists each AI risk with its likelihood, impact, named owner and treatment, reviewed on a schedule.
AI fails in ways generic IT risk misses: non-deterministic outputs, data provenance and silent model drift need their own categories.
Scoring must weight reversibility: prioritise risks by blast radius and how hard the damage is to undo, not likelihood alone.
What Is an AI Risk Register?
An AI risk register is a single living document that records every identified AI-related risk alongside its likelihood, its potential impact, the person accountable for it, and the controls being applied to reduce it. It is the same discipline organisations already use for financial, operational and cyber risk, adapted to the specific failure modes that AI systems introduce. Its value is not the document itself but the conversation it forces: naming a risk, assigning an owner, and agreeing a treatment.
Crucially, it is not a one-off compliance artefact produced to satisfy an auditor. A register that is written once and filed is worse than none, because it creates false confidence. The useful version is revisited as systems change, updated when new risks surface, and referenced directly in decisions about whether a given use case is ready to deploy. It sits naturally alongside the structured findings of an AI Data Readiness Audit, which surfaces many of the data-level risks the register then tracks.
Why Isn't Your Existing Risk Register Enough for AI?
Traditional IT risk assumes systems are deterministic: given the same input, they produce the same output, and a tested control stays effective. AI breaks that assumption, which is why a register built for conventional software leaves gaps precisely where AI is most dangerous. A model can give a different answer to the same question tomorrow, degrade silently as the world shifts around it, or behave in ways nobody explicitly programmed.
Three failure modes in particular have no natural home on a generic register. The first is non-determinism and hallucination, where a system produces confident, plausible, wrong output. The second is data provenance, where the risk lives in where the training or grounding data came from and what it was allowed to contain. The third is drift, where a model that passed testing quietly becomes less accurate over months without any code changing. These are not edge cases; they are the defining characteristics of the technology, and they explain why so many pilots stall, a pattern we unpack in why 80% of AI pilots fail.
What Categories of AI Risk Should the Register Cover?
A workable AI risk register organises entries into a small number of categories so nothing important is left implicit, and most organisations can cover their exposure with five. The point of the categories is completeness: they act as a checklist that forces the team to look in each corner rather than only at the risk that happens to be top of mind.
Risk category | Typical exposure | Primary treatment |
Data | Sensitive information exposed to a model, or poor-quality inputs producing poor outputs | Classification, access controls, quality checks |
Model and output | Hallucination, bias, or accuracy drift over time | Human review, evaluation sets, monitoring |
Security | Prompt injection, data exfiltration through a model, or misuse of an agent | Testing, guardrails, least-privilege access |
Compliance and legal | Privacy Act breaches, intellectual property leakage, sector obligations | Legal review, impact assessments, policy |
Operational and vendor | Vendor lock-in, outages, runaway cost, opaque supply chain | Due diligence, exit plans, cost limits |
The security and compliance rows deserve particular attention because they are where AI most often intersects your obligations to customers and regulators, and where the controls depend on getting the underlying architecture right rather than bolting on a policy afterwards.
How Do You Score and Prioritise AI Risks?
Score each risk on likelihood and impact as you would any other, then add a third lens that conventional registers usually omit: reversibility. A risk that is easy to detect and simple to undo deserves less urgency than one whose damage is silent, public or permanent, even when the two share the same likelihood and impact rating. Reversibility is what separates an embarrassing internal error from a reportable breach.
In practice this means weighting the blast radius. A drafting assistant that occasionally produces a clumsy sentence is low-consequence and self-correcting. A model that quietly leaks a customer's personal information into an output that reaches a third party is neither. Prioritising by reversibility keeps the register honest, and it stops the common failure of treating every AI risk as either catastrophic or trivial. The same discipline underpins a credible view of return, which is why scoring should sit alongside the kind of thinking in our board-level framework for measuring AI ROI.
Who Owns the AI Risk Register?
Every entry needs a single named owner who is accountable for its treatment, while the register as a whole belongs to a cross-functional governance forum rather than to IT alone. AI risk spans data, legal, security, operations and the business unit deploying the use case, so parking the whole register in the technology team guarantees that legal and commercial risks go unmanaged. Ownership without authority is theatre; the owner of a risk must be able to pause a deployment.
The most effective structure is a small AI governance group that meets regularly, maintains the register, and has a clear mandate to gate deployments. This is rarely a new committee built from scratch; more often it extends an existing risk or data governance forum. Getting that architecture and its accountability lines right is central to trusted data architecture and governance, and it is what turns a register from a list into a control. The same forum should own related policy, including your AI acceptable use policy.
How Often Should You Review the Register?
Review the register continuously for live systems and formally at least once a quarter, plus at every material change - a new use case, a model upgrade, a vendor switch, or a regulatory shift. AI systems are not static, so a review cadence borrowed from annual audit thinking is far too slow. A model that was accurate at launch can drift below an acceptable threshold within months, and only a regular review catches it before it becomes an incident.
The most valuable move is to wire the register directly into deployment decisions. Before any AI use case goes live, its risks should be on the register, scored, owned and treated to an agreed level. That single gate prevents the most common governance failure, where enthusiasm carries a system into production ahead of the controls. It also strengthens the questions you ask suppliers, which we detail in our guide to AI vendor due diligence.
An AI Risk Register Turns Anxiety Into Governed Decisions
The boards that handle AI well are not the most cautious or the most aggressive; they are the ones that have made their exposure legible. A living register does exactly that. It converts a vague sense that AI is risky into a specific, owned, scored and treated set of entries that anyone in the room can interrogate. That legibility is what lets an organisation move quickly on the use cases that are safe and hold the line on the ones that are not. Build the register, give each risk an owner, gate deployments against it, and review it as often as the technology itself changes. Do that, and AI risk stops being the thing that keeps the board awake and becomes just another category of exposure the organisation manages with confidence.
