An insurer's renewal questionnaire asks for it in one line: "Please provide your AI risk register." A managing partner opens the shared drive, searches, and finds an AI policy, a couple of vendor brochures, and an email thread from a committee meeting. No register. The thing everyone assumed existed does not, at least not as a document anyone could hand over.
This is the most common gap I see, and it is not a knowledge gap. Firms know AI carries risk. They have written policies saying so. What they have not built is the artifact that records those risks in a form a regulator or an insurer can read: what the risk is, how likely it is, who owns it, and what is being done about it, kept current.
A policy says the firm takes AI risk seriously. A risk register proves it, because it shows the risks named, scored, assigned, and reviewed. When the SRA or your PI insurer asks, the policy is not the answer. The register is.
A risk register is not a risk assessment, or a policy
Three documents get confused here, and the confusion is why firms think they have a register when they do not.
A policy is a statement of intent. It says what the firm will and will not do with AI. It is written once and points forward.
A risk assessment is an analysis. It examines a tool or a project at a point in time and concludes how risky it is. It is a snapshot, and once done, it is done.
A risk register is a living record. It holds every identified risk as a standing entry, with a score, an owner, a set of controls, and a review date, and it changes as risks are added, mitigated, and re-scored. It is the only one of the three that answers the question "what are your AI risks and what is happening about them, right now."
The distinction matters because SRA Rule 2.5 does not ask you to assess risk once or to intend to manage it. It asks you to "identify, monitor and manage all material risks." Three verbs, all continuous. A policy covers none of them. A one-off assessment covers the first. Only a maintained register covers all three, which is why it is the artifact the rule effectively demands. We drew the wider line between a document and a working control in why an AI policy is not AI governance; the register is where that line is sharpest.
The anatomy of a single register entry
A register is only as good as its entries, and an entry is only defensible if it carries the fields that let someone act on it. Strip out any of these and the entry becomes a note rather than a record.
| Field | What it captures |
|---|---|
| Risk ID | A stable reference so the risk can be tracked and cited |
| Description | The specific risk, in plain terms, not a category label |
| Category | Which of the risk types it belongs to (the six below) |
| Likelihood | How probable it is, on a consistent scale |
| Impact | How serious the consequences would be, on the same scale |
| Inherent score | Likelihood and impact combined, before controls |
| Controls / mitigation | What is actually being done to reduce it |
| Owner | The named person accountable for managing it |
| Residual score | The risk that remains after the controls are applied |
| Review date | When it was last reviewed, and when it is next due |
| Status | Open, mitigated, accepted, escalated |
Here is one entry, worked through, so the shape is concrete rather than abstract:
AI-04. Fabricated legal authority reaches a client. Category: accuracy. Likelihood: medium. Impact: high. Inherent score: high. Controls: mandatory citation verification against primary sources before any AI-assisted output leaves the firm; verification logged per matter. Owner: Head of Knowledge. Residual score: low. Last reviewed 12 June 2026, next review 12 September 2026. Status: open, controls operating.
Read that and you can see the difference from a policy line. It does not say "we mitigate hallucination risk." It says which risk, how bad, what is being done, who is accountable, what remains, and when it was last looked at. That is an entry the SRA can test and your insurer can price.
The six AI risk categories a firm should record
A register that lists three vague risks is as weak as no register at all. AI introduces risk to a law firm across six distinct areas, and a defensible register has entries in each.
- Accuracy and hallucination. AI fabricates a case, a citation, or a clause, and it reaches a client or a court. The controls are verification against primary sources and a human check before release.
- Confidentiality and data protection. Client data enters an ungoverned tool, or is retained or reused by a vendor. This category overlaps with your data-protection obligations, including the DPIA triage that decides whether a tool needs a full assessment before use.
- Competence and over-reliance. A fee earner accepts AI output without the scrutiny it needs, or uses a tool beyond their understanding of its limits. The control is supervision and training, owned in the practice areas, not just centrally.
- Regulatory and compliance. AI use breaches an SRA obligation, or triggers duties under the EU AI Act for firms with EU exposure, or misses a required assessment. The register is where these are tracked against the specific rule.
- Vendor and supply chain. A third-party model changes, a sub-processor is added, a data processing agreement is missing a term, or a supplier fails. This is where your Article 28 processor reviews feed the register.
- Security and data sovereignty. Where the data is hosted, who can access it, whether it is used to train a model, and how a breach would be handled. For firms where hosting location is decisive, this is the category that drives the self-hosting question.
Six categories, at least one live entry in each, is the difference between a register that looks complete and one that is.
Who owns each risk
An entry with no owner is not managed, it is merely noticed. The register only works if each risk has a named person accountable for it, and in a firm that ownership maps onto roles that already exist.
- The COLP owns the regulatory and compliance risks, because those are the firm's SRA obligations, and Rule 2.5 sits within the COLP's remit. We set out that remit in the COLP's responsibilities for AI.
- The DPO owns confidentiality and data-protection risks, where the entry connects to DSARs, DPIAs, and processor agreements.
- Practice and supervising partners own competence and over-reliance risks in their teams, because that is where the supervision actually happens.
- The managing partner or board owns the register as a whole and signs off the firm-wide material risks, because Rule 2.5 is a firm obligation, not a delegated task.
The point is not to invent new roles. It is to attach each AI risk to the person already accountable for that kind of risk, so the register has real owners rather than a single overwhelmed administrator listed against everything.
Defensible or decorative: what Rule 2.5 actually tests
Two firms can have a register that looks identical on the page. What separates the defensible one from the decorative one is not the columns. It is whether it is alive.
The test an inspector or insurer applies is not "do you have a register." It is "is this register maintained." They look at the review dates. If every entry was last reviewed on the day the register was created and never since, it is a snapshot wearing a register's clothing, and it fails the "monitor" in Rule 2.5. They look at whether the status ever changes, whether risks have been added since launch, whether an incident that clearly happened shows up as an entry. A register that has not moved is evidence that nothing is being monitored, which is worse than admitting you have not started.
Field note: The fastest way to tell a real register from a decorative one is to sort it by "last reviewed" date. If everything shares one date, it was built for a questionnaire and abandoned. If the dates are staggered and recent, it is being worked. Regulators and insurers do this sort in their heads within seconds of opening the file.
A defensible register also links to evidence. When an entry says a control is operating, a maintained register can point to the proof: the verification logs, the training records, the incident that was caught. Controls asserted without evidence are the decorative version. Controls tied to records are the defensible one.
From a spreadsheet to a system
Most firms build their first register in a spreadsheet, and there is nothing wrong with that as a start. The trouble is what happens next. A spreadsheet register is only as current as the last time someone remembered to open it. Owners change roles and the entry does not follow. An incident occurs and never gets logged because logging it was a separate manual step nobody did. Six months on, the review dates are stale, and the register has quietly become the decorative kind.
The fix is to stop treating the register as a document to update and start treating it as an output of the work. When AI activity is governed in the layer where it runs, the register fills itself: incidents are logged as they happen, controls are tied to behaviour the system actually enforces, and review dates are driven rather than remembered. The register stops being a thing someone has to maintain and becomes a thing that is maintained by the operation of the controls it describes.
That is what the AI Governance and Audit Agent produces: a risk register that stays current because the governance is where the AI runs, not in a spreadsheet beside it, and rolls up into the same SRA-ready audit report an inspection would ask for. It sits inside the wider governance approach we lay out in the AI governance framework for law firms, and it is the document that most directly answers the AI questions now landing in PI insurance renewals.
LegalAI Space builds AI agents for legal teams with a governance layer that makes every output verifiable, compliant, and audit-ready. Sign up for early access or book a pilot call with Founder Daman Kaur.
FAQ
What is an AI risk register? It is a living record of the risks your firm's use of AI creates, held as standing entries. Each entry names a specific risk, scores its likelihood and impact, records the controls in place, assigns a named owner, notes the residual risk, and carries a review date. Unlike a policy or a one-off assessment, it is maintained over time and is the document a regulator or insurer will ask to see.
Does the SRA require an AI risk register? Not by that name. SRA Rule 2.5 requires firms to identify, monitor and manage all material risks. For a firm using AI, a maintained risk register is the practical way to demonstrate all three, which is why it functions as a required artifact even though no rule names it explicitly.
How is a risk register different from a DPIA? A DPIA is a focused assessment of a specific processing activity's data-protection risks, done under Article 35 of the UK GDPR when the processing is likely to be high risk. A risk register is broader and ongoing: it holds all material AI risks across the firm, of which data protection is one category. A DPIA can feed an entry into the register, but it does not replace it.
Who owns the AI risk register? The register as a whole is typically owned by the managing partner or board, because Rule 2.5 is a firm-wide obligation. Individual entries are owned by the role already accountable for that risk type: the COLP for regulatory risks, the DPO for data-protection risks, and supervising partners for competence and over-reliance in their teams.
How often should an AI risk register be reviewed? Frequently enough that the review dates never all share one value. High-scoring risks warrant more frequent review than low ones, and any new tool, incident, or regulatory change should prompt an update. A register whose entries have not moved since it was created reads as unmonitored, which fails the "monitor" limb of Rule 2.5.
Can we just use a spreadsheet? As a starting point, yes. The risk is that a spreadsheet is only as current as the last manual update, so entries go stale, owners drift, and incidents go unlogged. The register stays defensible when it is maintained as a by-product of governed AI work rather than as a document someone has to remember to open.
Sources
-
SRA Code of Conduct for Firms, Rule 2.5. Requires firms to "identify, monitor and manage all material risks" to their business, including those arising from connected practices. The continuous nature of these obligations is why a maintained risk register, rather than a one-off assessment, is the instrument that demonstrates compliance.
-
SRA, Standards and Regulations. The SRA governs AI use through existing obligations, including the management of material risks, rather than a standalone AI rulebook.
-
ICO, Data protection impact assessments. DPIAs assess the data-protection risks of specific high-risk processing under Article 35 of the UK GDPR and can feed individual entries into a firm's wider risk register.
-
EU AI Act, Regulation (EU) 2024/1689, Article 9. Requires a risk management system to be established, implemented, documented and maintained across the lifecycle of high-risk AI systems, relevant for firms with EU exposure and a useful reference point for the structure of AI risk management generally.