How is an AI risk register different from a normal corporate risk register?

The structure is the same: identify, score, own, review. The categories and the failure modes are different. A corporate register may not capture model hallucination, vendor model-training rights, prompt injection or shadow AI use by staff. The AI risk register makes those AI-specific exposures visible alongside the data, vendor and reputational risks they generate. In larger organisations the AI register often becomes a feeder into the main corporate register, with high-scoring AI items promoted to board-level reporting.

How often should we review the register?

Quarterly at minimum. High-scoring risks, anything sitting at 17 or above, deserve a monthly check. Any AI incident, however minor, should trigger an immediate review of the relevant entry. New tools and use cases must generate an entry before they go into production. The point of these rules is to keep the document live; a register reviewed once a year is essentially a snapshot, and the regulatory and tooling landscape moves faster than that.

Can we just use our existing GRC platform for this?

Yes, if it lets you record the seven fields and assign a named individual owner. The platform does not matter; the discipline does. Many organisations start with a simple spreadsheet and only move to a GRC tool once the register has more than thirty entries and is feeding board reporting cycles. Beware platforms that encourage forty-column entries and elaborate workflows; the failure mode of AI risk registers is over-engineering, not under-engineering.

Who should own the AI risk register?

A named individual at senior level, not IT or the AI team alone. In a UK SME this is often the COO, the CFO or the operations director, supported by the DPO and a nominated AI lead. In a council it sits with the senior officer responsible for digital or transformation. The owner does not need to be an AI specialist; they need authority to enforce the rule that no new AI tool goes live without a register entry, and they need to be the person who is called when something goes wrong.

What is a realistic first version of the register?

Six entries, drawn directly from the minimum viable register: one per active AI tool covering data handling, one for vendor dependency and continuity, one for staff capability and over-reliance, one for UK GDPR obligations, one for any public-facing AI output, and a named owner with a quarterly review date. That is enough to start governing. Most organisations grow from six to twenty entries within the first year as the AI inventory becomes more honest and shadow-AI use surfaces.

Governance & Strategy · for leaders & councils

AI Risk Register: A Simple Structure Leaders Can Maintain

An AI risk register is a live document that records the specific AI risks your organisation is carrying right now, who owns each one, what controls are in place and what triggers an escalation. Most registers die within three months because they are built to satisfy a process rather than to manage risk. The structure that works uses six risk categories, seven fields per entry and a named individual owner, reviewed at least quarterly. Six well-maintained entries beat forty that nobody updates.

What an AI risk register is, and what it is not

A risk register is a live document that records specific risks from your AI activity, who is responsible for each one, what controls are in place and what triggers an escalation.

It is not a policy document. It does not explain your ethics position, your acceptable use principles or your vendor selection criteria. Those live elsewhere. The register records the actual risks you are carrying right now in the tools you are actually using. Keep the two things separate; conflating them produces documents that are too broad to act on and too vague to audit. Most AI risk registers die within three months because they were built to satisfy a process, not to manage risk. Registers with forty-three columns, colour-coded probability matrices and no named owner do not survive contact with a real organisation.

Six risk categories for AI

Group every entry under one of six categories. They cover the full range of AI-specific exposure without creating unnecessary complexity. You do not need a separate register for each category; one document, six labels. If a risk sits across two categories, pick the dominant one and note the secondary in the description field.

Data risk: personal data, training data quality, data sovereignty, DSAR exposure.
Model risk: hallucination, bias, output accuracy, model drift over time.
Vendor risk: dependency, lock-in, contractual gaps, third-party security posture.
Operational risk: process failure, staff capability gaps, over-reliance on automation.
Legal and compliance risk: UK GDPR, ICO obligations, sector regulations, IP ownership.
Reputational risk: public-facing AI errors, deepfakes, client trust, media exposure.

The seven fields every entry needs

Strip the register back to seven fields. Anything beyond this becomes a burden rather than a tool.

Field	What to record
Risk ID	Sequential reference. AI-001, AI-002. Simple and permanent.
Description	One plain-English sentence. Describe the specific harm that could occur, not a vague category.
Category	One of the six above: Data, Model, Vendor, Operational, Legal/Compliance, Reputational.
Score (L × I)	Likelihood 1–5 multiplied by Impact 1–5. A score of 1–9 is low, 10–16 is medium, 17–25 is high.
Current controls	What is in place right now. Be honest — "none" is a valid and useful answer.
Owner	A named individual, not a team or department. If nobody will own it, escalate it to the board immediately.
Review date	Quarterly at minimum. High-scoring risks should be reviewed monthly.

The optional eighth field: escalation trigger

Add an escalation trigger to each high-scoring entry. The trigger defines the specific condition that moves a risk from monitored to incident. For example: "Triggers escalation if more than two staff report AI output errors in the same week."

Without a trigger, risks sit in the register indefinitely without action. The board sees the same red row at every meeting and stops paying attention. With a trigger, the register tells you what has actually changed since last quarter and what now needs intervention.

What to put in it first

Start with the AI tools your organisation is actively using, not the tools you think you might adopt in future. Speculative risks clutter the register and dilute attention from the real ones. Five practical checks generate the first ten to fifteen entries.

List every AI tool currently in use across the business, including tools staff are using without formal approval.
For each tool, identify what data it processes and who in the organisation has access.
Check whether each vendor's terms allow your data to be used for model training.
Identify which business-critical processes would fail if the tool became unavailable tomorrow.
Note any tools where no contract exists, no DPA has been signed or no security assessment has been completed.

Keeping it alive

A register that is not maintained is worse than no register because it creates false assurance. Set three rules from the outset.

First, every new AI tool or use case must generate at least one register entry before it goes into production; the procurement or approval step has to include this explicitly. Second, any AI incident, however minor, triggers a review of the relevant entry. Third, ownership of the register sits with a named person at senior level, not with IT or the AI team alone. Watch for the failure pattern where every owner is listed as a team. "IT Department" cannot be called at 9pm when something goes wrong; neither can "Operations". Name a person and make sure they know they are named.

The minimum viable risk register

If your organisation is at the start of its AI governance journey, six entries are the floor before any AI deployment at scale. It is not comprehensive governance, but it is a live document with owners and dates, which puts you ahead of most UK SMEs and many councils.

One entry per active AI tool covering data handling risk.
One entry covering vendor dependency and continuity.
One entry covering staff capability and over-reliance.
One entry covering UK GDPR obligations and ICO notification thresholds.
One entry for any public-facing AI output, including chatbots and automated communications.
A named register owner and a scheduled quarterly review date.

Connecting it to your wider governance

The risk register does not stand alone. It feeds into your AI governance policy, your incident response process and your board reporting cycle. High-scoring risks should appear on board-level risk dashboards. Incident closures should update the register within five working days.

If you do not yet have an AI governance policy or an AI incident response process, build those in parallel. The register without governance context is a list. With governance context, it becomes a management tool.

Take the next step

Want help applying this to your organisation? Use the resource below or book a 30 minute strategy call with Simon — no pitch, just practical advice.

Frequently asked questions

Related resources

Governance & Strategy

Find Out Where AI Can Save or Generate Money in Your Organisation

Book a free 30-minute call with Simon. Bring a real problem — staff time, governance worry, vendor proposal, failing pilot — and leave with a concrete first step you can take next week.

07973 210 895