Most AI risk registers are inventories, not decision tools. Here is how to build one that supports board oversight and stands up to regulatory scrutiny.
ai-embed Insights · 3 November 2026
Many organisations now have an AI risk register. Far fewer have one that anyone senior reads, challenges or acts upon. The typical artefact is a spreadsheet assembled by a working group, listing dozens of generic risks such as bias, hallucination, data leakage and model drift, each scored red, amber or green by someone who has never seen the system in production. It satisfies a governance checkbox. It does not help a board decide whether to fund, pause or retire a use case, and it will not help much when a regulator asks how a specific system was assessed.
The problem is rarely effort. It is design. A register built as an inventory of worries behaves differently from one built as a decision tool. The first grows indefinitely and informs nobody. The second is deliberately narrow, tied to named systems and owners, and structured around the questions that boards and supervisors actually ask. What follows is a practical approach to building the second kind.
The most common structural mistake is organising the register around abstract risk themes. Themes are useful for taxonomy, but they cannot be owned, tested or closed. A board member cannot meaningfully ask who is accountable for "bias". They can ask who is accountable for the credit pre-screening model, and what happens if it performs worse for a particular customer group.
Build the register at the level of the AI system or use case. Each entry should name the business process it supports, the decision it influences or automates, the people affected, the data it relies on, whether it is built in-house or supplied by a third party, and a single accountable executive. This requires an AI inventory underneath it, and many organisations discover at this point that they do not have a reliable one. Shadow usage, embedded AI features in procured software and employee use of public tools all need a route into the inventory, otherwise the register describes only the systems you already knew about.
Within each entry, express risks as specific scenarios with a cause, an event and a consequence. "The model may be inaccurate" is a category. "The claims triage model under-prioritises complex cases after a change in claim mix, delaying settlement and creating conduct exposure" is a scenario that can be measured, mitigated and owned. Keep scenarios few per system. Five well-understood ones are worth more than thirty generic ones.
Scores are where registers lose credibility. If likelihood and impact are assigned by instinct, two reviewers will rate the same risk differently, and a regulator will reasonably ask what the numbers mean. Define your scales in terms the organisation already uses for other risks, such as financial thresholds, customer harm, regulatory consequence and operational disruption, so that AI risk can be compared with the rest of the enterprise risk profile rather than sitting in a separate world.
Record inherent risk, the controls in place, and residual risk, and be specific about which controls are doing the work. A control should be something that can be evidenced: a pre-deployment validation, a human review step with defined authority to override, monitoring with an alert threshold, a contractual audit right with a supplier. Where a control is planned rather than operating, say so. Boards are much better served by an honest statement that residual risk is high until a control goes live than by a green rating that assumes it already has.
Then connect the register to risk appetite. The board should have stated, in plain language, where it will and will not accept AI-related risk, for example around fully automated decisions affecting customers or employees. Each entry can then be positioned against that appetite, and breaches become escalation triggers rather than discussion points. Without this link, the register reports exposure but never prompts a decision.
For organisations operating in or into the EU, the EU AI Act (Regulation (EU) 2024/1689) shapes what the register must capture. It takes a risk-based approach, with prohibited practices, obligations for high-risk systems, and transparency requirements for certain others. Its provisions apply in stages, and the timing of some high-risk obligations has been the subject of ongoing legislative discussion, so confirm current application dates with legal counsel rather than hard-coding them into your process. What you can do now is add fields to each entry recording the system's likely classification under the Act, your role as provider or deployer, and the evidence supporting that judgement.
The register is also a natural home for obligations that sit alongside the AI Act. Where personal data is processed, the UK and EU GDPR requirements around data protection impact assessments and automated decision-making will apply, and financial services firms will need to map entries to existing operational resilience and third-party risk expectations. Linking each AI entry to those assessments, rather than duplicating them, keeps the register light and reduces the chance of contradictory records.
Voluntary frameworks can help structure the work. ISO/IEC 42001 provides a management system standard for AI, and the NIST AI Risk Management Framework offers a widely used vocabulary of govern, map, measure and manage. Neither replaces a legal assessment, but both give you a recognised basis for explaining your method to a supervisor.
Boards do not need the full register. They need a short, stable view: the systems that carry the highest residual risk, any that sit outside appetite, material changes since the last meeting, incidents and near misses, and decisions required. Keep the detailed register one level down, owned by risk and the first line, with clear thresholds for what gets escalated.
A register is only as useful as its freshness. Trigger reviews on events, not just calendars: a model change, a new data source, a supplier update, a change in use, a significant incident or a shift in the regulatory position. Assign review dates and owners, and track overdue actions visibly. Record decisions as well as risks, including when the organisation chose to accept a risk and why, because that audit trail is precisely what supervisors look for.
A risk register earns its place when it changes a decision. If yours has never led a board to delay a launch, fund a control or retire a system, it is documentation, not governance. Narrow it to named systems, make every score defensible, tie it to stated appetite, and give directors a page they can act on.