8 April 2026
AI Risk Register: What It Is and How to Build One
Every business using AI needs a risk register. Here's what to include, how to structure it, and why it matters for compliance.
Sam Hawkins
Syntra Automate
If someone asked you today to list every AI system your organisation uses, the risks each one carries, and the controls you have in place — could you do it?
For most businesses, the honest answer is no. And that is precisely the gap an AI risk register fills.
An AI risk register is a structured record of all AI systems in your organisation, the risks they present, and the measures you have taken to manage those risks. It is not a theoretical governance exercise. It is a practical tool that regulators, auditors, and increasingly procurement teams expect to see.
Why you need one
The EU AI Act requires it. Regulation (EU) 2024/1689 requires providers and deployers of high-risk AI systems to establish and maintain risk management systems. Article 9 mandates a risk management system that identifies and analyses known and reasonably foreseeable risks, estimates and evaluates those risks, and adopts appropriate management measures. A risk register is the practical tool that underpins this requirement. High-risk obligations apply from 2 August 2026, with fines reaching EUR 35 million or 7% of worldwide annual turnover.
ISO 42001 expects it. ISO/IEC 42001, the international AI management system standard published in December 2023, requires organisations to identify AI-related risks and opportunities and plan actions to address them. A risk register is the standard way to evidence this.
Regulators will ask for it. When a UK regulator — whether the ICO investigating a data protection concern, the FCA reviewing an algorithmic trading system, or a sector regulator responding to a complaint — asks about your AI governance, one of the first things they will want to see is evidence that you have identified and are managing your AI risks. A risk register provides that evidence.
Your board needs it. Directors cannot fulfil their oversight responsibilities without a clear view of the organisation's AI risk landscape. A risk register feeds directly into board-level AI risk reporting.
What an AI risk register looks like
An AI risk register does not need to be complicated. For most businesses, a well-structured spreadsheet will do. What matters is that it captures the right information consistently.
Here are the fields you should include for each AI system:
System name. The name of the AI tool, platform, or system. Be specific — "ChatGPT Enterprise" rather than just "AI chatbot."
Provider/vendor. Who supplies the system? This is critical for supplier risk management.
System owner. The named individual within your organisation who is accountable for this system. Every system must have an owner. Without ownership, governance is theoretical.
Department(s) using it. Which teams use this system? AI tools often span multiple departments.
Purpose and use case. What is the system used for? Be precise: "Screening inbound CVs and ranking candidates by suitability" is useful. "HR purposes" is not.
EU AI Act risk tier. Is this system classified as unacceptable, high, limited, or minimal risk? For high-risk systems, note the specific Annex III category.
Data sensitivity. What types of data does the system process? Personal data, special category data, confidential business data, publicly available data? Note the sensitivity level.
Decision impact. Does this system influence or make decisions about individuals? If so, what kind? Employment decisions, credit decisions, customer outcomes? The higher the impact on individuals, the greater the risk and the stronger the controls needed.
Key risks identified. List the principal risks: data leakage, bias, inaccuracy, lack of transparency, regulatory non-compliance, business continuity dependency, intellectual property concerns.
Controls in place. What mitigations are currently active? Human oversight, data input restrictions, access controls, output verification processes, contractual protections with the supplier, DPIAs completed.
Residual risk rating. After controls, what is the remaining risk? Use a simple scale — high, medium, low — that your organisation can apply consistently.
DPIA status. Has a Data Protection Impact Assessment been completed? Required under the UK GDPR where processing is likely to result in high risk to individuals.
Review date. When is this entry next due for review? No risk register entry should be left indefinitely without reassessment.
Notes and actions. Space for any outstanding actions, planned improvements, or contextual information.
How to populate it
If you have already conducted an AI usage audit — surveying employees, reviewing IT assets, checking SaaS subscriptions, and scanning for shadow AI — you have the raw material to populate your risk register. Each AI system identified during the audit becomes an entry.
For each entry, work through the fields above systematically. You will need input from:
The system owner — for purpose, use case, and operational details
IT or information security — for technical controls, data flows, and security posture
Legal or compliance — for regulatory classification, DPIA requirements, and contractual review
Data protection — for data sensitivity assessment and UK GDPR compliance
If you have not yet conducted an AI audit, start there. A risk register built on incomplete information gives a false sense of security.
How to maintain it
An AI risk register is a living document. It is only useful if it is kept current.
Quarterly reviews. At minimum, review the entire register every quarter. Check that risk ratings are still accurate, controls are still in place, and no new risks have emerged. Align this with your board reporting cycle so the register feeds directly into governance.
Triggered reviews. Certain events should trigger an immediate review of relevant entries:
- A new AI system is adopted or an existing one is significantly changed
- A supplier changes its terms of service, data processing practices, or pricing model
- A regulatory change affects your obligations (new guidance from the ICO, updates to the EU AI Act's implementing measures)
- An AI-related incident occurs — a data breach, a biased output, an inaccurate decision
- A new business activity brings your AI systems into contact with EU data subjects or markets
New entries. Every new AI system must be added to the register before it is deployed. Build this into your procurement and change management processes. No AI tool should enter the organisation without a risk register entry.
Archiving. When you decommission an AI system, do not delete the entry. Archive it with a note on when and why it was retired. Regulators may ask about past AI usage, and a clean archive demonstrates mature governance.
Common mistakes
Treating it as a one-off. A risk register completed once and never updated is worse than useless — it creates the illusion of governance without the substance. If your register is dated twelve months ago and nothing has changed, a regulator will see that for what it is.
Not including third-party tools. Most businesses do not build their own AI. They use AI embedded in SaaS platforms, productivity tools, and vendor systems. These tools carry the same risks — data processing, decision impact, supplier dependency — and must be on the register.
No ownership assigned. If a risk register entry has no named owner, nobody is accountable for managing that risk. Every entry needs a specific individual — not a team, not a department, but a person — who is responsible for ensuring the controls are in place and the entry is reviewed.
Overly complex risk ratings. A five-by-five risk matrix with likelihood and impact scores may work for enterprise risk management, but for most organisations a simple high/medium/low rating applied consistently is more practical and more likely to be used.
Confusing the register with the assessment. The risk register records the summary of your risk position. It is not a substitute for the detailed risk assessments, DPIAs, and technical reviews that inform it. Those documents should exist separately and be referenced from the register.
Ignoring minimal-risk systems. While your governance effort should concentrate on high-risk systems, minimal-risk tools still belong on the register. They may be low risk today, but a change in use case, data inputs, or decision context could change that. The register ensures you have visibility.
Linking the risk register to your governance framework
The AI risk register does not exist in isolation. It is a component of your broader AI governance framework and should connect to:
Your AI usage policy — which sets the rules that the register helps enforce
Your board AI risk report — which draws on the register for its risk summary
Your DPIA records — which provide the detailed data protection analysis for high-risk systems
Your supplier review process — which informs the supplier-related fields in the register
Your incident response plan — which should reference the register when AI incidents occur
Together, these form an integrated governance system that regulators, auditors, and certification bodies expect to see.
The bottom line
An AI risk register is not bureaucracy for its own sake. It is the practical tool that gives you visibility over your AI risks, evidence of your governance, and a foundation for regulatory compliance.
It does not need to be complex. A well-maintained spreadsheet with the right fields, clear ownership, and regular reviews will serve most businesses well.
The key is to start — and to keep it current. A living risk register is one of the clearest signals of governance maturity. A dusty one is a liability.