What is an AI risk register?
Global AI regulation
An AI risk register is a living record that logs an organisation's material AI risks, the controls used to address them, who owns each risk, what evidence supports the rating, and when the risk must be reviewed. It helps teams manage AI risk over time, rather than treating governance as a one-off exercise. In practice, it connects assessment, approval, monitoring, incident handling, audit and regulatory documentation.
What this means
An AI risk register is not the same thing as an AI risk, an AI inventory, or a full AI governance framework. It is the running record that shows which risks have been identified for a particular AI system or use case, how serious they are, what controls are in place, what still remains, and who must take action.
A good register is updated through the AI lifecycle. It usually starts when a use case is proposed or procured, absorbs findings from impact assessments, testing and supplier due diligence, and stays live after deployment as logs, incidents, audits, user feedback and system changes reveal new issues.
Few laws require a document with exactly the title "AI risk register". Even so, multiple laws, standards and regulator guides require documented risk management, review, traceability and senior accountability. That is why the AI risk register has become a practical governance artefact across sectors and jurisdictions.
Why it matters
AI governance usually fails in the gaps between teams and over time. A privacy team may flag a concern, a product team may add a control, procurement may rely on vendor promises, and an approval group may sign off a launch, but without a shared record those actions do not stay connected. The register creates continuity. It shows what was identified, what was done, what still needs work, and who is accountable if risk remains too high.
This matters in regulation because many AI duties are not one-time checks. They are ongoing duties to document, monitor, update, log, reassess and escalate. A register helps an organisation turn broad governance principles into evidence that can be reviewed by management, buyers, auditors, regulators and, where relevant, public authorities. It also helps leaders decide whether an AI use should proceed, proceed with conditions, pause, or be retired.
How it works
It records risk in context
A useful AI risk register does not just list generic labels such as "bias", "privacy" or "security". Each entry should be tied to a named AI system or use case, its intended purpose, the people or processes affected, and the scenario that creates concern. Context matters because the same technical component can create very different governance issues depending on whether it is used for internal drafting, customer triage, fraud detection, recruitment, medical support or public service delivery.
For procured or embedded AI, the context should also include the supplier relationship, the version or model being used, important data dependencies, and any assumptions built into contracts or documentation. This is especially important where a deployer did not build the model itself but is still responsible for relying on it in a controlled way.
It links risk ratings to controls and evidence
Once a risk is identified, the register should show how it is assessed and what is being done about it. Most organisations use some form of severity and likelihood scale, often translated into priority bands or tolerance levels. The exact scoring method matters less than consistency and reviewability.
Each entry should also point to the control set attached to that risk. Depending on the system, controls might include testing, access restrictions, human review, monitoring rules, procurement clauses, data quality checks, logging, incident escalation, retraining conditions, or decommissioning triggers. The register is strongest when it links these controls to evidence, such as a DPIA, an AI impact assessment, test reports, supplier documents, internal approvals, incident records or logs. It should also show residual risk, meaning the level that remains after those controls are applied.
It assigns ownership and decision rights
A register only works if each material risk has a named owner with authority to act. That usually means a business, product or operational owner for the risk itself, plus control owners for the mitigations attached to it. Review authority often sits with privacy, security, legal, model risk, procurement or AI governance functions, depending on the issue.
This matters because AI governance often breaks when the team that detects the risk is not the team that can change the system or stop the deployment. The register should therefore show who can remediate, who can accept residual risk within tolerance, who must escalate beyond tolerance, and who signs off launches or major changes. Senior sign-off is particularly important where risks cannot be fully removed and require an informed management decision.
It sits between inventory, controls and approval
An AI use-case inventory, an approval workflow, a control library and an AI management system all do different jobs. The inventory tells you what AI exists and where it is being used. The control library lists standard safeguards the organisation can apply. The approval workflow records whether a use or change may proceed. The AI management system is the broader set of policies, responsibilities, review cycles and continual improvement processes.
The risk register connects these artefacts. It shows which controls are actually attached to which risk, whether approval conditions are still open, whether a particular use remains inside the organisation's risk appetite, and whether new evidence has changed the picture. In that sense, it is the operational bridge between policy and practice.
It stays live across the AI lifecycle
An AI risk register should start early and survive deployment. Good trigger points include intake, procurement, pre-deployment testing, launch approval, major retraining, fine-tuning, new data sources, new user groups, vendor updates, incidents, audit findings, complaints and retirement. Closed risks should be marked with date and reason, not silently removed.
This lifecycle point is central to modern AI governance. The EU AI Act treats risk management for high-risk AI as a documented, continuous and iterative process linked to technical documentation, logging and post-market monitoring. In UK data protection practice, the ICO expects risks identified for AI systems using personal data to be documented, signed off and tracked through an appropriate corporate risk register. In the US federal context, OMB requires inventories, AI impact assessments and ongoing review for rights-impacting and safety-impacting AI. A live register is one practical way to keep these moving parts joined up.
It helps translate law and standards into daily governance
The register is useful partly because legal and standards documents often describe duties in separate pieces. One instrument may require documented risk management. Another may require technical documentation, logs, post-market monitoring, testing, human oversight or management accountability. Standards may emphasise governance, role clarity, review cycles, risk tolerance and continual improvement. A register gives teams one place to pull those threads together for a specific system or use case.
That is why the mechanism travels well across jurisdictions. NIST's AI RMF is voluntary, but it encourages documented risk management, role definition, inventories, risk tolerance, monitoring and review. ISO/IEC 42001 is also a voluntary management system standard, but it pushes organisations toward a structured and continually improved way of governing AI-related risks. Even where a regulator does not prescribe a register by name, the underlying governance logic strongly supports one.
It creates evidence for assurance and audit
A well-run AI risk register is not just a management aid. It is also an assurance artefact. It lets an internal audit team, a regulator, a board committee, a public body, or a major customer see whether the organisation knew about a particular risk, linked it to controls, assigned responsibility, reviewed new evidence and revisited the decision after change.
This does not mean the register replaces the underlying proof. Test reports, impact assessments, logs, contracts, incident analyses and technical documents still do the heavy lifting. But the register acts as the index that shows where the proof sits and how the organisation turned that proof into a managed decision.
Examples
Current example, UK government internal deployment: the Cabinet Office's "Hidden AI Risks Toolkit" describes how the team behind the generative AI tool Assist identified more than 100 hypothetical risks during rollout, then used a published risk register template to catalogue, triage and reduce them to 33 priority risks across six categories. That is a strong illustration of a register being used as a working governance tool for prioritisation and ongoing review, not as a final appendix produced at the end.
Current regulatory example, EU high-risk AI: the EU AI Act requires providers of high-risk AI systems to run a documented risk management system across the full lifecycle, keep technical documentation up to date, enable logging, maintain quality management documentation and establish documented post-market monitoring. In practice, an AI risk register is a sensible way to keep those linked duties coherent for a specific system, especially when modifications, deployer feedback or incidents change the risk picture.
Current regulatory example, US federal agency use: OMB M-24-10 requires agencies to inventory AI use cases and, for rights-impacting or safety-impacting AI, complete an AI impact assessment, update it through the lifecycle, and stop using the AI if minimum risk management practices are not met. For an agency governance team, the register is the operational record that can connect the inventory entry, the impact assessment, the named owner, the planned mitigations, the review cycle and any stop-use decision.
Common misunderstandings
A common mistake is to treat the register as the same thing as an AI inventory. It is not. The inventory tells you what AI exists and where it is used. The register tells you what could go wrong in that use, what controls are in place, and whether management is still content to proceed.
Another mistake is to think a DPIA or AI impact assessment does the same job. Those assessments are deeper reviews at a point in time. The register is the live record that carries identified issues forward into monitoring, approvals, version changes and audit.
It is also wrong to assume only model builders need one. Buyers, deployers and organisations relying on third-party AI still face governance, privacy, security, operational and sector-specific duties. If you use the system, rely on the output, or integrate it into your process, you still need a controlled way to record and review risk.
Some teams think vendor assurance means the risk can stay off the register. That is risky thinking. Supplier documentation is evidence, not a substitute for your own record of intended use, local controls, review triggers and acceptance decision.
A final misunderstanding is that the register is finished once the system is approved. AI systems change, their context changes, and the evidence around them changes. A static register usually signals static governance.
Risks and boundaries
An AI risk register has clear limits. It does not prove that a control works. A green status entry is weak if the underlying test record, audit evidence or vendor assurance is poor. It also should not become a dumping ground for every imaginable fear. If entries are too generic, unowned or disconnected from real decisions, the register quickly loses value.
It is also not a substitute for the wider artefacts governance requires. You may still need technical documentation, logs, incident records, impact assessments, supplier due diligence, data protection records, contract terms, sector-specific approvals and internal audit evidence. The register should point to these records, not replace them.
Legal status also varies. NIST AI RMF and ISO/IEC 42001 are voluntary standards, not statutes. ICO guidance explains how existing UK data protection law applies where AI systems process personal data. OMB M-24-10 binds US federal agencies, not private firms. The EU AI Act creates binding documented risk management duties for certain systems, but it does not impose a universal global obligation for every organisation to maintain a document with the exact label "AI risk register". The practical lesson is simple: the label may vary, but the need for structured, reviewable AI risk recording is now hard to avoid.
What to do next
Name the AI systems, uses and changes that must trigger a register entry, and connect that rule to intake, procurement and change management.
Use one clear schema for entries: system or use case, risk statement, affected people or processes, rating, controls, owner, evidence, residual risk, status and next review date.
Give a named senior body authority to accept, escalate, pause or retire AI uses that exceed tolerance, rather than leaving difficult calls with technical teams alone.
Require every material entry to link to supporting artefacts, especially impact assessments, DPIAs, test records, supplier documents, logs, incident reports and approval decisions.
Review the register when systems are retrained, fine-tuned, repurposed, exposed to new data, connected to new vendors, or used in new contexts, not just on an annual timetable.
Keep it proportionate. A low-stakes internal drafting tool does not need the same depth as AI used in employment, credit, healthcare, law enforcement or public service delivery.
FAQs
Is an AI risk register a legal requirement?
Usually not by that exact name. Few regimes prescribe the label itself, but many require the underlying discipline, such as documented risk management, impact assessment, senior accountability, logging, monitoring or technical documentation.
What should every AI risk register entry contain?
At minimum, a specific system or use case, a clear risk statement in context, a rating method, attached controls, a named owner, supporting evidence, residual risk, current status and a review date.
Who should own the register?
Day-to-day administration may sit with a governance, risk or compliance function, but each material risk still needs an operational or business owner with authority to act. Senior review should sit with the body that can approve, condition, pause or stop use.
Is it the same as a DPIA or AI impact assessment?
No. A DPIA or AI impact assessment is a structured analysis at a moment in time. The register is the continuing record that tracks identified risks after the assessment is complete.
Do we need one for third-party AI tools?
Yes. Supplier AI can create local risk even if you did not build the model. Your register should record the intended use, supplier assumptions, contractual controls, review triggers and evidence you relied on.
How often should an AI risk register be reviewed?
At intake, before deployment, after significant change, after incidents or complaints, after major vendor updates, and on a regular periodic cycle. The right cadence depends on the stakes and how quickly the system changes.
Can a small team start with a spreadsheet?
Yes. A spreadsheet can be enough at first if fields are clear, ownership is real, evidence is linked and review discipline is maintained. As the number of systems, regulators and reviewers grows, many teams move to a more structured governance or risk platform.