AI Risk Register Template (Free Download)
Five columns, a 5x5 scoring matrix and a named review cadence turn a spreadsheet into a working AI risk register.
An AI risk register is a structured log of every AI-specific risk an organisation has identified, each one scored by likelihood and impact, paired with a mitigation plan and a single named owner. It differs from a general IT or enterprise risk register because it captures hazards unique to AI systems, such as model drift, hallucination, training-data bias, and regulatory non-conformity. The rest of this guide sets out the columns, the scoring method, the review cadence, and a free downloadable template you can populate in an afternoon.
The worked template referenced throughout this guide is available to download as a spreadsheet at https://mickai.co.uk/downloads/ai-risk-register-template.xlsx.
What is an AI risk register and how is it different from a standard risk register?
A standard enterprise risk register tracks generic hazards: project delay, budget overrun, supplier failure, cyber intrusion. An AI risk register sits alongside it but tracks a distinct hazard class that a generic template was never built to capture. AI systems fail in ways that do not map cleanly onto existing risk categories, which is why organisations that try to bolt "AI risk" onto an existing spreadsheet as a single row tend to miss most of what actually goes wrong.
The hazard classes an AI risk register needs to cover include:
- Model drift, where a model's real-world accuracy degrades as the data it sees in production diverges from its training data.
- Hallucination or confabulation, where a model states something false with the same confidence as something true.
- Training-data provenance and bias, where the data a model learned from was unlawfully sourced, poorly labelled, or skewed against a protected group.
- Explainability gaps, where nobody in the organisation can reconstruct why a model produced a specific output.
- Prompt injection, where an attacker embeds instructions in input data that hijack a model's behaviour.
- Data leakage into third-party models, where confidential or personal data is sent to an external model provider and retained or used for further training.
- Over-reliance and automation bias, where staff accept a model's output without independent check, even on high-stakes decisions.
- Third-party and vendor model risk, where the organisation depends on a model it does not own, control, or can fully audit.
- Intellectual property and copyright exposure, where a model's output or training data creates infringement risk.
- Regulatory non-conformity, where an AI system fails to meet an applicable legal obligation.
None of these appear as line items on a conventional register. That is the gap the AI risk register closes.
What are the five core columns and how do you fill them in correctly?
Every AI risk register, however elaborate, is built on five columns. Get these right and the rest of the template is detail.
| Column | What it captures | Common mistake to avoid |
|---|---|---|
| Risk | A single, clearly scoped statement written as cause, then event, then consequence. | Writing a vague category ("AI bias") instead of a specific, testable statement. |
| Impact | The consequence if the risk materialises: financial, safety, legal or regulatory, reputational, operational. Scored on a defined scale. | Scoring impact from gut feel with no defined scale behind the number. |
| Likelihood | The probability of occurrence, ideally backed by evidence: incident history, model-monitoring signal, or an audit finding. | Guessing likelihood with no evidence basis at all. |
| Mitigation | The specific control or controls reducing likelihood and/or impact, marked as preventive, detective, or corrective. | Merging the risk statement and the mitigation into one column so neither can be assessed cleanly. |
| Ownership | One single named accountable individual per risk, not a team or a department. | Leaving ownership blank or assigning it to "IT". |
A well-written risk statement follows cause, event, consequence: "Because the customer-support model was trained on data that under-represents non-native English speakers (cause), it may misclassify a legitimate complaint as spam (event), leading to a missed regulatory deadline and a complaint to the ombudsman (consequence)." That single sentence is scoreable, assignable, and auditable. "AI bias in customer support" is none of those things.
How do you score AI risk likelihood and impact?
Most organisations use a 5 by 5 matrix: likelihood scored 1 to 5, impact scored 1 to 5, multiplied to give a raw score from 1 to 25. Smaller organisations sometimes use a simpler 3 by 3 matrix scoring 1 to 9. Either way, the score is then mapped to a named band so it can be read at a glance and escalated consistently.
| Score range (5x5) | Band | Typical escalation rule |
|---|---|---|
| 1 to 5 | Low | Logged and monitored at team level; no committee reporting required. |
| 6 to 10 | Medium | Reviewed at monthly operational review; mitigation plan required. |
| 11 to 15 | High | Escalated to the AI governance board or risk committee; mitigation plan mandatory with a review date. |
| 16 to 25 | Critical | Escalated immediately, typically to board or senior accountable owner; may trigger a pause on the system pending mitigation. |
The single most commonly missing element in amateur templates is the distinction between inherent risk and residual risk. Inherent risk is the score before any control is applied. Residual risk is the score after the mitigation is in place. A register that only records one number cannot show whether a control actually worked, and cannot demonstrate to an auditor or regulator that the mitigation was effective rather than merely documented. Score both, as two separate columns, every time.
How often should an AI risk register be reviewed?
"Regularly" is not a cadence. A working register needs named review points tied to the AI system lifecycle: design, development, validation, deployment, monitoring, and retirement. Both the NIST AI Risk Management Framework and Article 9 of the EU AI Act treat risk management as continuous across that full lifecycle, not a one-off exercise completed before launch and forgotten.
A concrete cadence that works in practice:
- At intake: a new risk is logged the moment a new AI system or use case enters the organisation, before deployment.
- Monthly: full operational review of open risks, status, and approaching review dates.
- Quarterly: governance-level review at committee or board level, focused on High and Critical risks.
- Ad hoc: triggered immediately by a material model change, a new regulation, a confirmed incident, or a monitoring or drift alert.
A register with no review date column, or one that was populated once at launch and never touched again, is not a functioning control. It is a document that existed once.
What risk categories should the template be pre-populated with?
A blank register is intimidating and slow to populate. Pre-loading a taxonomy of common AI risk categories gives a first-time user a starting point rather than a blank sheet:
- Data: quality, bias, provenance, privacy.
- Model: drift, hallucination, robustness, explainability.
- Security: prompt injection, data leakage, adversarial input, model theft.
- Legal and regulatory: AI Act conformity, UK GDPR and data protection, sector-specific rules, IP and copyright.
- Operational: vendor and third-party dependency, over-reliance and automation bias, business continuity.
- Ethical and societal: fairness, discrimination, misuse, transparency to affected individuals.
Who should own the AI risk register?
Ownership works in two layers. Each individual risk needs exactly one named accountable owner, typically the business or technical lead closest to the system in question, not a team or function. The register as a whole needs a separate owner, usually a named risk or compliance function, or an AI governance board.
This layered model echoes the UK Government AI Playbook, which sets out project-level governance (leads, multidisciplinary teams, security and legal owners), programme-level assurance through an AI review board with a clear escalation route, and departmental oversight held by a senior responsible owner. A register that names "the AI team" as the owner of every risk has, in practice, assigned ownership to nobody.
How does the register fit into the wider AI risk management process?
The register is the living record of a process, not the process itself. That process typically runs: intake and screening of a new AI use case, risk assessment, register entry, mitigation plan and control implementation, monitoring and testing, periodic review, escalation and reporting, then retirement or re-assessment on material change. The NIST AI Risk Management Framework organises the same idea into four functions: Govern (culture, policy, and accountability, which cuts across everything else), Map (identifying and categorising the AI system and its context), Measure (quantitative and qualitative analysis, benchmarking, and monitoring), and Manage (resourcing and prioritising the response). A register with no owner is a Govern failure. A register with no evidence behind its likelihood scores is a Measure failure. Treat gaps in the register as a diagnostic for which part of the wider process needs attention.
How do you score AI risk without a data science team?
Scoring does not require a model-monitoring platform. It requires a specific risk statement, an honest likelihood estimate grounded in whatever evidence exists, and a documented mitigation. A worked example:
| Field | Entry |
|---|---|
| Risk | The customer-facing chatbot gives incorrect financial guidance to a customer, who acts on it and suffers a loss. |
| Category | Model |
| Inherent likelihood | 3 |
| Inherent impact | 4 |
| Inherent score / band | 12 / High |
| Mitigation | Human-in-the-loop review of any answer flagged as high-stakes, guardrail prompts restricting financial advice, and continuous output monitoring for policy breaches. |
| Residual likelihood | 2 |
| Residual impact | 3 |
| Residual score / band | 6 / Medium |
| Owner | Head of Customer Operations |
Nothing in that row required a data scientist. It required a specific statement, an honest score, a real control, and a named person accountable for it.
What common mistakes should you avoid?
- Merging risk and mitigation into one column, so neither can be assessed independently.
- Recording only one risk score instead of separate inherent and residual scores, which hides whether the control actually worked.
- Leaving ownership blank, or assigning it to "IT", which means nobody is actually accountable.
- No review date recorded, so the register cannot demonstrate it is a living document.
- Writing risks as generic categories ("AI bias", "model risk") instead of specific, scoped, cause-to-consequence statements.
- Building the register once and never revisiting it, which is the single most common failure mode auditors report.
What is inside the free AI risk register template?
The download is a working spreadsheet, not a lead magnet dressed as one. It includes a Risk Register sheet with the full column set (risk ID, category, risk statement, affected system, inherent likelihood and impact, an auto-calculated inherent score and band, mitigation and control type, residual likelihood and impact, an auto-calculated residual score and band, owner, status, and next review date), a scoring guide with a printed 5 by 5 matrix and plain-English definitions for each likelihood and impact level, a starter library of pre-written common AI risk statements across all six categories so you are not starting from a blank sheet, a review cadence tracker, and a short instructions sheet with a worked example. Scores calculate automatically from formulas, categories and statuses are constrained by dropdowns, and risk bands are colour-coded, so the file is ready to populate the same day you download it.
For the infrastructure layer that many of these risks trace back to, the architecture is set out at /sovereign-ai, and the film at /film shows the interface in operation.
Frequently asked questions
What is an AI risk register?
It is a log of every AI-specific risk an organisation has identified, scored by likelihood and impact, paired with a mitigation plan and a named owner. It differs from a general risk register by capturing AI-specific hazards such as model drift, hallucination, training-data bias, and regulatory non-conformity.
What should be in an AI risk register template?
At minimum: a unique risk ID, a specific risk statement, a category, a likelihood score, an impact score, an inherent risk score, a mitigation or control description, a residual risk score, a named owner, a status, and a next review date.
How do you score AI risk likelihood and impact?
Most registers use a 5 by 5 matrix, scoring likelihood 1 to 5 and impact 1 to 5, multiplied to give a score from 1 to 25, mapped to bands such as Low, Medium, High, and Critical. Score inherent risk before controls and residual risk after controls as two separate figures.
How often should an AI risk register be reviewed?
Individual risks should be reviewed whenever the underlying AI system changes materially, with a full operational review monthly and a governance-level review quarterly at minimum, in addition to ad hoc review triggered by an incident or a new regulatory requirement.
Who should own risks on an AI risk register?
Each risk needs exactly one named accountable owner, typically the business or technical lead closest to the system, with a separate governance function such as risk, compliance, or an AI review board owning the register as a whole.
Is an AI risk register a legal requirement?
For high-risk AI systems under the EU AI Act, Article 9 requires a continuous risk management system across the AI lifecycle, of which a risk register is the standard practical artefact. Outside that scope it is best practice rather than a strict legal mandate, but auditors, insurers, and enterprise customers increasingly expect to see one.
What is the difference between an AI risk register and the NIST AI RMF?
The NIST AI Risk Management Framework is a four-function framework, Govern, Map, Measure, and Manage, describing the overall process for managing AI risk. The risk register is the practical, living document that records the output of that process, one row per identified risk.
Is the EU AI Act high-risk deadline still 2 August 2026?
No. The Digital Omnibus on AI deferred the stand-alone Annex III high-risk obligations to 2 December 2027, and high-risk AI embedded in regulated products to 2 August 2028. Article 50 transparency obligations largely remain on the original schedule. Treat the deferral as a build window rather than a reprieve, since the underlying risk-management requirements survive the move intact.
Where a sovereign AI substrate fits
Vendor and third-party dependency is a genuine entry in the risk taxonomy above, and it exposes a limit a purely process-based register cannot mitigate on its own. An organisation can score, own, and review a risk such as "we cannot independently verify what our AI vendor did with a given decision", but the register only records that residual exposure; it cannot reduce it. Reducing that specific residual score requires infrastructure, not process: a per-action cryptographic audit trail, deployment the organisation owns and can run offline, and no vendor-side data egress. A sovereign, owned, on-prem and audit-verifiable AI substrate is one credible way to lower that particular residual score, alongside the process controls the register already tracks. Mickai is one such substrate: the architecture, not the paperwork, is what does that work, and the underlying engineering is separately protected by 104 filed UK patent applications and 2,340 claims.