Guide
AI risk register template: fields, examples and upkeep
An AI risk register template with the fields to record, worked example rows for a customer chatbot and a CV screening tool, and how to keep it current.
What should an AI risk register template include?
An AI risk register template needs one row per risk, tied to the AI system it comes from, with the risk described as cause, event and consequence, a likelihood and consequence rating before and after treatment, the controls that treat it, a named owner, the person who accepted the residual risk, and a review date or trigger. The fields below are a complete list you can copy into a spreadsheet or a governance, risk and compliance (GRC) tool, followed by worked rows for two common systems and the routine that keeps the register true as systems change.
An AI risk register template has one row per risk, tied to the AI system it came from, with ratings before and after treatment, the controls, a named owner, who accepted the remaining risk and when the row is next reviewed. The template below is a set of columns, not a form. Copy the columns into whatever holds your risks today. What makes it work is the link from every row back to a specific system and the assessment that found the risk.
The fields to record
| Field | What to record | Example |
|---|---|---|
| Risk ID | A stable identifier that never gets reused. | R-014 |
| Source system | The AI system’s ID in your system register, and the version assessed. | SYS-007, v2.3 |
| Risk title | A short name someone can scan in a report. | Chatbot gives wrong refund terms |
| Description | Cause, event and consequence in one or two plain sentences. | The model answers from an outdated policy page, a customer is told they qualify for a refund they do not, and the complaint escalates. |
| Category | The harm domain. Use a fixed list such as accuracy and reliability, fairness, privacy and data protection, transparency, security and misuse, human oversight, dependence. | Accuracy and reliability |
| Affected parties | Who is harmed if it happens. | Customers, complaints team |
| Source | Where the risk was identified, such as a named risk assessment, an impact assessment, an incident or a review. | Risk assessment RA-007-3 |
| Inherent likelihood | Likelihood before any treatment, on your scale (for example 1 to 5). | 4 |
| Inherent consequence | Consequence before any treatment, on your scale. | 3 |
| Inherent rating | The rating your matrix gives, such as Low, Moderate, High or Critical. | High |
| Existing controls | Controls already operating, by control ID. | C-031 answers grounded in the current policy library |
| Treatment decision | Avoid, reduce, transfer or accept. | Reduce |
| Planned controls | Controls still to put in place, each with an owner and due date. | C-032 refund answers routed to an agent, due 30 Nov |
| Residual rating | The rating after treatment, with one sentence of reasoning. | Moderate. Refund questions no longer get a model-only answer. |
| Risk owner | A named person, not a team. | Head of Customer Operations |
| Residual risk accepted by | Who accepted the residual risk and when. | COO, 14 Oct |
| Status | Open, treating, accepted, closed. | Treating |
| Review trigger | The changes that reopen this row. | New model version, new policy content, complaint volume above threshold |
| Next review date | The calendar backstop. | 14 Jan |
| Framework references | The clauses or outcomes the row supports, if you map to a framework. | ISO/IEC 42001 clause 6.1.3, NIST AI RMF MANAGE 1.3 |
If you want a header row to paste straight into a spreadsheet, use this.
Risk ID,Source system,System version,Risk title,Description,Category,Affected parties,Source,Inherent likelihood,Inherent consequence,Inherent rating,Existing controls,Treatment decision,Planned controls,Residual rating,Residual reasoning,Risk owner,Residual accepted by,Accepted date,Status,Review trigger,Next review date,Framework referencesTwo fields do most of the work. Source system stops the register drifting away from reality, because a row that cannot name its system cannot be re-assessed when that system changes. Residual risk accepted by turns the register from a list into a record of decisions, because an auditor’s first question about a High row is who decided that was acceptable.
Worked example 1: a customer service chatbot
A retailer runs a vendor-hosted large language model chatbot on its website. It answers order, delivery and returns questions from a policy library, and hands over to a human agent on request.
| ID | Risk | Category | Inherent | Treatment | Residual | Owner |
|---|---|---|---|---|---|---|
| R-014 | The chatbot states outdated refund terms and a customer acts on them. | Accuracy and reliability | High | Answers grounded only in the current policy library. Refund and compensation questions routed to a human agent. | Moderate | Head of Customer Operations |
| R-015 | Customers paste card numbers or health details into the chat, and the text is retained in vendor logs. | Privacy and data protection | High | Personal information detected and redacted before the prompt leaves the network. Vendor contract confirms no training on inputs and a fixed retention period. | Low | Privacy Officer |
| R-016 | A crafted message makes the chatbot ignore its instructions and produce offensive or off-brand content. | Security and misuse | Moderate | Prompt injection and toxicity scanning on input and output. Blocked responses logged and reviewed weekly. | Low | Digital Channels Lead |
| R-017 | Customers do not realise they are talking to an AI and rely on it as they would on staff. | Transparency | Moderate | Clear AI disclosure at the start of every chat and a visible route to a person. | Low | Head of Customer Operations |
Review triggers for this system are a new model version from the vendor, a change to the policy library, a new channel such as SMS, and complaint volume tagged to the chatbot passing an agreed threshold.
Worked example 2: a CV screening tool
A recruitment team uses a feature inside its applicant tracking system that scores and ranks applicants against the role description. Recruiters see the ranking and choose who to interview.
| ID | Risk | Category | Inherent | Treatment | Residual | Owner |
|---|---|---|---|---|---|---|
| R-021 | The ranking disadvantages applicants by gender, age or disability through proxies in CV wording or career breaks. | Fairness | Critical | Selection rates compared across groups each quarter. Vendor bias testing report obtained and read. Protected attributes and obvious proxies excluded from scoring. | High | Head of Talent |
| R-022 | Recruiters only read the top of the ranked list, so the score becomes the decision in practice. | Human oversight | High | Recruiters review a fixed sample below the cut-off for every role. Rejections need a recorded reason that is not the score. | Moderate | Head of Talent |
| R-023 | Applicants are not told AI is used and cannot ask for a human review. | Transparency | High | Notice in the job advertisement and privacy notice. A documented route to request human review of a decision. | Low | People and Culture Director |
| R-024 | The vendor retrains the model and the ranking changes without anyone noticing. | Dependence | Moderate | Contract requires notice of material model changes. Score distributions monitored per role family. | Low | HR Systems Manager |
R-021 sits at High after treatment. That is a legitimate outcome, provided someone with the authority to carry it has accepted it on the record with a review date. Recruitment is also an area many jurisdictions treat as high risk. The EU AI Act lists AI used to select or evaluate candidates as high risk, and several US states and cities regulate automated employment decision tools. Check which apply to you before you settle the treatment.
How to keep the register current
A risk register built once in a workshop goes stale the first time a system changes. Four habits keep it true.
- Re-assess on change, not just on the calendar. Each row’s review trigger names the changes that reopen it. A new model version, a new data source, a new user group or a new channel means the source assessment is due again, and the rows it produced are updated from it.
- Add rows from every source, not only assessments. Incidents, near misses, monitoring alerts, vendor notices and staff reports all surface risks. Record each with its source so the trail stays visible.
- Review on a schedule set by the rating. Quarterly for High and Critical rows and annually for Low is a common starting point. Record that the review happened even when nothing changed, because “reviewed, no change” is evidence too.
- Close rows deliberately. When a system is retired or a risk no longer applies, close the row with the reason and the date rather than deleting it. A deleted row is a decision nobody can see.
Report the register upward by rating and trend, not row by row. The board needs to know how many High and Critical risks are open, which are new since last period and which have sat above appetite the longest.
In Australia
The National AI Centre’s Guidance for AI Adoption (AI6, October 2025), published by the Department of Industry, Science and Resources, sets out risk management as essential practice 3, “Measure and manage risks”. It superseded the Voluntary AI Safety Standard. The National AI Centre also publishes an AI register template with the guidance, which catalogues an organisation’s AI tools and systems. The risk rows here sit underneath that system list and add the ratings, treatment and acceptance detail. See the Guidance for AI Adoption framework page.
How Aicura fits
In Aicura the risk rows are not typed by hand. Each risk assessment drafts risk items with a domain, a rating, a written rationale and suggested controls, and those land in Risks and Controls under the system they came from, which is the Source system column above. Your people record a position on each risk, and each control’s status tracks applicable, implemented and tested separately. Publishing the set saves it as a new version, and on Pro it can be copied across to your GRC platform so the enterprise risk register stays in step.
Aicura drafts the ratings and controls. It does not decide that a risk is acceptable or sign anything off. Those calls stay with the owners named in your register. This page is general information, not legal advice.
Sources
- ISO/IEC 23894:2023, Information technology, Artificial intelligence, Guidance on risk management, iso.org
- ISO/IEC 42001:2023, Artificial intelligence management system, including Annex A reference controls, iso.org
- NIST AI Risk Management Framework (AI RMF 1.0) and the Generative AI Profile (NIST AI 600-1), nist.gov
Questions
What is the difference between an AI risk register and an AI system register?
The AI system register lists the AI systems in use, one row per system. The AI risk register lists the risks those systems carry, one row per risk, each pointing back to a system in the system register. One system usually has several risks, so the risk register is the longer of the two.
Should AI risks go in the enterprise risk register?
Material AI risks should roll up to the enterprise risk register, but the detail belongs in a register that can hold the system, version and assessment each risk came from. Keep the per-system rows in the AI risk register and report the aggregated, material ones into enterprise risk.
How often should an AI risk register be reviewed?
Review an AI risk register on change and on a calendar. Re-assess when the system, its model, its data or its use changes, and review every row on a schedule set by its rating, for example quarterly for High and Critical and annually for Low.
Run this work in Aicura
Essentials adds risk assessments, controls, governance policies and guardrail authoring on top of the AI register.