An AI risk register is one living table of every risk your AI systems create, each with a cause, a consequence, an owner, scores before and after controls, a treatment decision and a review date. The template below gives the column set, risk categories, scoring bands, a filled example of eight entries and a layout for Excel.
Register or assessment: which one you need
Both, because they do different jobs. A risk assessment for a single AI system is a structured review at a moment in time: it describes one system, classifies it and decides whether its residual risk is acceptable. The register is the organisation’s running ledger. It collects the risks found in every assessment, audit, test and incident, keeps them comparable on one scale, and shows which ones are getting worse.
| Risk assessment | Risk register | |
|---|---|---|
| Scope | One system or use case | Every AI system in the inventory |
| Timing | At intake, before go-live, on material change | Continuous; reviewed quarterly |
| Output | A signed decision on one system | A prioritised list of open risks and actions |
| Owner | The system owner | The AI governance lead, with one owner per row |
| Audience | Approvers at a gate | AI governance committee and enterprise risk |
| Standards hook | ISO/IEC 42001 clause 6.1.2; NIST MAP | ISO/IEC 42001 clause 6.1.3 and 8.3; NIST MANAGE 1.2 to 1.4 |
ISO/IEC 23894:2023 applies the ISO 31000 process of identifying, analysing, evaluating and treating risk to AI, and ISO/IEC 42001 expects the results to be retained as documented information. A register is the usual way to meet both.
The AI risk register template
Columns
| # | Column | What to enter |
|---|---|---|
| 1 | Risk ID | R-01, R-02 and so on; never reuse an ID |
| 2 | AI system | Name and inventory ID |
| 3 | Category | From the category list below |
| 4 | Risk statement | ”Because [cause], [event] may happen, leading to [consequence]“ |
| 5 | Affected parties | Customers, staff, applicants, patients, the public, the organisation |
| 6 | Source | Assessment, test, audit, incident, vendor notice, horizon scan |
| 7 | Inherent likelihood (1 to 5) | Before any controls |
| 8 | Inherent impact (1 to 5) | Before any controls |
| 9 | Inherent score | Likelihood × impact |
| 10 | Existing controls | Only controls that are working today, with evidence |
| 11 | Residual likelihood (1 to 5) | With existing controls |
| 12 | Residual impact (1 to 5) | With existing controls |
| 13 | Residual score and band | Likelihood × impact; low, medium, high or critical |
| 14 | Treatment | Mitigate, transfer, avoid or accept |
| 15 | Actions | What, who, by when |
| 16 | Target score | Expected residual score after the actions |
| 17 | Risk owner | A named person, not a team |
| 18 | Status | Open, in treatment, accepted, closed |
| 19 | Dates | Raised, last reviewed, next review |
| 20 | Links | Assessment, incident, model card, FRIA or DPIA references |
The treatment options are the four that NIST AI RMF lists under MANAGE 1.3. Keep the risk statement to one sentence: a row that needs a paragraph is usually two risks.
Risk categories
Seed the category list from published taxonomies rather than inventing one. NIST AI 600-1, the Generative AI Profile, names twelve risks; the OWASP Top 10 for LLM Applications 2025 covers the application-security side; agentic systems add authority and tool risks.
| Category | Example risk statement |
|---|---|
| Confabulation and accuracy | Because answers are generated without checking sources, the assistant may state a wrong policy limit, leading a customer to rely on it |
| Data privacy and confidentiality | Because retrieval ignores folder permissions, staff may see restricted files |
| Harmful bias | Because training data under-represents older applicants, the screening model may rank them lower |
| Information security | Because the agent reads inbound email, injected instructions may make it forward documents |
| Excessive agency | Because the agent holds write access to the CRM, it may change records outside its task |
| Human-AI configuration | Because reviewers approve nearly all drafts, errors may pass unchecked |
| Information integrity | Because content is generated at scale, unlabelled synthetic text may be published |
| Intellectual property | Because generated code is not licence-checked, copyleft code may enter a product |
| Value chain and supplier | Because the vendor can change the model without notice, behaviour may shift silently |
| Legal and regulatory | Because the system was never classified, a high-risk use may run without Article 26 controls |
| Operational and cost | Because no rate limit is set, a loop may exhaust budget or capacity |
| Environmental | Because large models run for simple tasks, energy use may exceed targets |
Scoring and escalation
Use the same five-point likelihood and impact scales as your assessments, so a score of 12 means the same thing everywhere. The bands in our assessment template work well for a register too: 1 to 4 low, 5 to 9 medium, 10 to 14 high, 15 to 25 critical, with any impact of 5 on health, safety or fundamental rights rated at least high.
| Residual band | Who may accept it | Review frequency | Committee visibility |
|---|---|---|---|
| Low | Risk owner | Annually | Count only |
| Medium | System owner | Half-yearly | Trend in quarterly report |
| High | AI governance committee | Quarterly | Listed individually |
| Critical | Executive sponsor, and only with a dated plan | Monthly | Every meeting until reduced |
AI risk register example
Eight rows from a fictional professional services firm with four AI systems: a document assistant over internal knowledge (S-01), a contract review agent (S-02), a CV screening tool bought from a vendor (S-03) and a code assistant (S-04). Scores are illustrative.
| ID | System | Category | Risk statement (short) | Inh. | Controls in place | Res. | Treatment | Owner | Next review |
|---|---|---|---|---|---|---|---|---|---|
| R-03 | S-01 | Privacy | Retrieval may return restricted HR files | 4×4=16 | Index respects source permissions; nightly permission check | 2×4=8 | Mitigate | Head of knowledge | Jan 2027 |
| R-07 | S-01 | Security | Injected text in a retrieved file may leak a confidential document | 4×4=16 | User-scoped retrieval, no outbound tools, cited sources, injection tests | 2×3=6 | Mitigate, then accept | Head of knowledge | Jan 2027 |
| R-12 | S-02 | Excessive agency | Agent may send a marked-up contract to the counterparty unreviewed | 3×5=15 | Send action held for lawyer approval | 1×5=5 | Mitigate | Legal ops lead | Dec 2026 |
| R-13 | S-02 | Accuracy | Agent may miss a non-standard liability clause | 3×4=12 | Clause checklist; lawyer reads every flagged section | 2×4=8 | Accept with owner sign-off | Legal ops lead | Dec 2026 |
| R-18 | S-03 | Bias | Screening may rank some protected groups lower | 3×5=15 | Vendor test summary only; no own testing yet | 3×5=15 | Avoid automated rejection until own tests pass | HR director | Nov 2026 |
| R-19 | S-03 | Regulatory | Employment use is Annex III high-risk; deployer duties not yet in place | 4×4=16 | Classified; FRIA screening started | 3×4=12 | Mitigate before 2 Dec 2027 | HR director | Nov 2026 |
| R-24 | S-04 | IP | Generated code may carry incompatible licences | 3×3=9 | Licence scanner in CI | 2×3=6 | Mitigate | Head of engineering | Mar 2027 |
| R-25 | S-04 | Supplier | Hosted model changes behaviour without notice | 3×3=9 | None | 3×3=9 | Mitigate: pin version or self-host | Head of engineering | Dec 2026 |
R-18 stays critical because its controls are claims, not evidence, which is why the treatment avoids the risky use instead of accepting it. R-19 shows a regulatory row: once the system is classified as high-risk, the deployer duties of Article 26 and, for public bodies and some private ones, the fundamental rights impact assessment become actions with a date.
Building the register in Excel
Spreadsheets are a reasonable start for up to a few hundred rows. Four sheets keep it maintainable:
- Register: one row per risk with the twenty columns above, frozen header row, filters on.
- Scales: the likelihood and impact definitions, so scorers read the same words.
- Lists: categories, systems, owners, statuses and treatments, used by data validation drop-downs.
- Inventory: system ID, name, tier, system owner; the register looks names up from here.
Adjust the letters to your own layout. Here:
G = inherent likelihood, H = inherent impact,
K = residual likelihood, L = residual impact,
M = residual score, O = "Y" if the impact falls on health,
safety or fundamental rights (the scorer fills it in),
W = next review date.
Inherent score (I2): =G2*H2
Residual score (M2): =K2*L2
Band (N2): =IF(AND(O2="Y",L2=5,M2<10),"High",
IF(M2>=15,"Critical",IF(M2>=10,"High",
IF(M2>=5,"Medium","Low"))))
System owner (Y2): =XLOOKUP(B2,Inventory!A:A,Inventory!D:D)
Overdue flag (Z2): =IF(W2<TODAY(),"Overdue","")Add conditional formatting on the band column and a pivot table by system and band for the quarterly report, and protect the formula columns. The O column exists because no formula can tell on its own whether an impact concerns people’s health or rights; the scorer decides and the band rule does the rest. Move to a GRC tool when several teams edit at once or when auditors ask who changed a score and when.
How to fill it in, and who owns it
The AI governance lead owns the register as a whole: its structure, scales and quarterly report. Each row has one risk owner, usually the system owner, who answers for the score and the actions. Security, privacy and legal add rows from their own reviews, and the incident process adds or re-scores rows when an AI incident is closed.
- Start from the inventory. Every system in the inventory should have at least one row. A system with none has not been looked at.
- Import assessment findings. Copy every risk scored in an assessment into the register under the same ID.
- Review by exception. Committee time goes to high and critical rows, overdue actions and rows whose score moved.
- Close rows deliberately. A risk closes when the system is retired or the cause is removed, not when the action is done.
The editable DOCX of the register, with the column guide and the eight example rows, is part of the AI Governance Template Pack alongside the policy, incident plan, model card, intake form and readiness checklist.
Keeping it current with less effort
A register goes stale when updating it is a separate job. The AI risk management agent proposes new rows from incidents, audit findings and assessments, scores them with the scales you configure and tracks owners and actions, so reviewers confirm entries instead of typing them. For the regulatory column, the AI risk classification agent records the Article 6 and Annex III reasoning per system; the wider AI risk assessment and classification use case shows how the two fit together. If you are not sure the register is your most urgent gap, the AI readiness assessment scores governance against five other areas.
How VDF AI fits
The controls column is only as good as the evidence behind it. VDF AI runs on infrastructure you control, so a row like R-03 can point at retrieval that respects each user’s source permissions, and a row like R-25 can be treated by self-hosting an open-weight model behind VDF AI Router with an approved-model list.
Agent tools are granted per role from an MCP registry, high-impact actions can wait for a person’s approval, and every prompt, retrieval, tool call and response is logged with the user and model version and can stream to your SIEM. That turns “controls in place” from a statement into something an auditor can sample. Scoring, acceptance and the register itself stay with your risk owners.
Sources
- NIST AI 100-1, AI RMF 1.0
- NIST AI 600-1, Generative AI Profile
- ISO/IEC 42001:2023, AI management systems
- ISO/IEC 23894:2023, AI risk management guidance
- ISO 31000:2018, Risk management guidelines
- OWASP Top 10 for LLM Applications 2025
- AI Act, Regulation (EU) 2024/1689, on EUR-Lex
- Digital Omnibus on AI, Regulation (EU) 2026/1744