Before You Read On
An AI risk register is one table that lists each risk an AI system creates, how likely and how severe it is, who owns it, what you are doing about it and when it is next reviewed. The template below has 18 fields, each mapped to a NIST AI RMF function, and is sized for a team without a dedicated risk department.
- Cost: a register costs owner time, not software; a governed table or a spreadsheet both work at the start.
- Effort: expect two to four hours per AI system to fill the first rows, then 30 minutes a month to review them.
- Risk: a register nobody reviews is worse than none, because it records risks you knew about and ignored.
- Fit: start it the day the first AI system touches customer data, a consequential decision or an agent with tool access.
NIST released the AI Risk Management Framework 1.0 on 26 January 2023 as a voluntary structure organised into four functions: Govern, Map, Measure and Manage. It tells you what a risk process should achieve. It does not hand you a spreadsheet.
The register is where the framework becomes something you can open on a Monday. In the RMF Core, MANAGE 1.3 asks that responses to high-priority risks be “developed, planned, and documented,” with options that include mitigating, transferring, avoiding or accepting. Documented where? For most mid-market teams, nowhere in particular.
The usual result is a slide in a quarterly deck, disconnected from the lakehouse where the AI systems actually read their data, and rewritten from memory each time. The template below replaces it with fields you can copy, a scoring scale you can defend and a review rhythm small enough that it actually happens.
How Is a Risk Register Different From an AI Inventory?
The inventory lists systems. The register lists risks. GOVERN 1.6 asks for “mechanisms to inventory AI systems,” and that inventory gives every system an ID, an owner and a purpose. The register then holds several rows per system: one for each way that system can hurt a customer, an employee or the business.
Keep them as two tables joined on the system ID. Our AI governance framework describes the inventory and the eight controls around it; this article is only the register that sits next to it. If you skip the inventory, the register has no spine, and risks attach to whatever someone happened to remember.
Which Fields Belong in an AI Risk Register?
Copy these 18 fields as columns. The RMF mapping is ours, built from the subcategory text on the NIST AI Resource Center; NIST does not publish a register format.
| # | Field | What to enter | Allowed values | RMF function and subcategory |
|---|---|---|---|---|
| 1 | Risk ID | Stable unique ID | AIR-0001 onward | GOVERN 1.4 |
| 2 | System ID | Link to the inventory row | Inventory key | GOVERN 1.6 |
| 3 | Risk title | One line, written as cause and effect | Free text, under 15 words | MAP 1.1 |
| 4 | Risk category | The kind of harm | Accuracy, privacy, security, fairness, third party, legal, operational | MAP 1.1 |
| 5 | Who is affected | The people who bear the harm | Customers, employees, applicants, the business, the public | MAP 5.1 |
| 6 | Source of the risk | Model, data, third-party component or human use | Model, data, vendor, process, user | MAP 4.1 |
| 7 | Likelihood | How often it is expected to occur | 1 to 5 | MAP 5.1 |
| 8 | Impact | How bad it is when it occurs | 1 to 5 | MAP 5.1 |
| 9 | Inherent score | Likelihood times impact, before controls | 1 to 25 | MANAGE 1.2 |
| 10 | Existing controls | Controls already running, by name | Free text with control IDs | MANAGE 1.3 |
| 11 | Metric and threshold | How you will know the risk is materializing | Metric name plus limit | MEASURE 1.1 |
| 12 | Response | What you decided to do | Mitigate, transfer, avoid, accept | MANAGE 1.3 |
| 13 | Action and due date | The next concrete action | Action text plus date | MANAGE 1.3 |
| 14 | Residual score | Likelihood times impact, after controls | 1 to 25 | MANAGE 1.4 |
| 15 | Risk owner | A named role, never a committee | Role and group | GOVERN 2.1 |
| 16 | Shut-off path | How the system is disabled if the risk hits | Steps plus the role that runs them | MANAGE 2.4 |
| 17 | Status | Where the risk stands | Open, in treatment, accepted, closed | MEASURE 3.1 |
| 18 | Last and next review | Dates of the last and next review | Two dates | GOVERN 1.5 |
Two fields do most of the work. Field 11 turns a worry into something you can watch: “answers cite a retired price list” becomes “share of sampled answers citing a document older than 90 days, limit 2%.” Field 16 forces the question MANAGE 2.4 asks, whether you can supersede, disengage or deactivate a system, before you need the answer.
How Do You Score Likelihood and Impact Without Arguing for an Hour?
MAP 5.1 asks that the likelihood and magnitude of each impact be identified and documented, and MANAGE 1.2 asks that treatment be prioritized on impact, likelihood and available resources. A shared scale is what stops scoring from turning into a debate about adjectives.
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Not expected in the next year | Internal inconvenience, fixed the same day |
| 2 | Could happen once a year | Rework for one team, no customer sees it |
| 3 | Could happen once a quarter | A customer sees a wrong answer or delay |
| 4 | Could happen monthly | Wrong decision about a person, a data exposure or a contract breach |
| 5 | Already happening or weekly | Regulatory notice, material financial loss or harm to many people |
Multiply the two. Treat 15 to 25 as high, 8 to 12 as medium and 1 to 6 as low, and write those bands into your policy so the next person scores the same way. Anchor the impact scale to your own business before you adopt it: a wrong answer to a customer is a 3 for a retailer and a 4 for a lender.
What Does a Completed Row Look Like?
Here is an illustrative row for a customer-support assistant that answers from a retrieval index over product documents. It is a composite pattern, not a client record.
| Field | Example entry |
|---|---|
| Risk title | Stale documents in the index cause wrong pricing answers to customers |
| Category and source | Accuracy; data |
| Likelihood, impact, inherent score | 3, 3, 9 (medium) |
| Existing controls | Nightly index refresh from the gold product table |
| Metric and threshold | Share of sampled answers citing a document older than 90 days; limit 2% |
| Response and action | Mitigate: add a freshness check that blocks the refresh if the gold table is late, due in two weeks |
| Residual score | 2, 3, 6 (low) |
| Owner | Head of customer operations |
| Shut-off path | Disable the serving endpoint; route chats to the human queue; platform on-call runs it |
| Next review | Monthly while in treatment |
Who Owns the Register, and How Often Is It Reviewed?
GOVERN 1.5 asks that periodic review be planned and roles defined, “including determining the frequency of periodic review.” So write the frequency down. A mid-market version looks like this.
| Role | What they own | Cadence |
|---|---|---|
| AI risk owner (executive) | The register as a whole, risk acceptance for high scores | Monthly review, 45 minutes |
| Risk owner per row | Score, response, actions and metric for that risk | High: monthly. Medium: quarterly. Low: twice a year |
| Data platform lead | Metric feeds, lineage and the shut-off path | Before each monthly review |
| Security lead | Privacy, security and third-party rows | Quarterly, plus after any incident |
| Counsel | Legal category rows and accepted risks with legal exposure | Quarterly |
Add three event triggers on top of the calendar: a new AI system enters the inventory, a model or vendor changes, or an incident occurs. Each one opens a review of that system’s rows within a week.
Why Do AI Risk Registers Go Stale?
- Risks are written as topics, not causes. “Hallucination” is not a risk you can treat. “The model answers from documents the index should have dropped” is. Our post on why AI pilots fail shows how often the root cause turns out to be data, not the model.
- No metric means no signal. Without field 11, the only way a risk changes score is when someone remembers it. Then the score never moves until an incident moves it for you.
- The committee owns everything. A row owned by “the AI council” is owned by nobody. One role per row, and that role’s name goes on the action.
- Accepted risks are never revisited. Acceptance is a decision with a date, not a status forever. Put every accepted risk on the quarterly agenda.
- The register drifts from the inventory. A retired system keeps its open rows, and a new agent never gets any. Joining the two tables on system ID and flagging mismatches fixes this mechanically.
Should the Register Live in a Spreadsheet or a Lakehouse Table?
Start in a spreadsheet if that is what gets it filled this week. The lakehouse version can wait a month. Move it into a Delta table in your governed lakehouse once you have more than a handful of systems, for three reasons.
First, field 11 becomes live. A scheduled job reads the metric from the gold tables or serving logs and writes the current value next to the threshold, so a breach shows up before the meeting. Second, field 6 gets evidence: Unity Catalog captures column-level lineage automatically for queries run on Databricks, so a data-sourced risk can point at the exact upstream tables. Third, changes to the register itself are recorded. The audit log system table is in Public Preview with a 365-day default retention; copy what you need into your own table, as our audit log retention guide explains, if you must keep records longer.
That last point matters when a regulator asks what you knew and when. Colorado’s SB 26-189, effective 1 January 2027, requires developers and deployers of covered automated decision systems to keep records needed to demonstrate compliance for at least three years. A register with dated reviews is one of those records, though not the only one. If you want help standing up the register, the inventory and the metric feeds together, our AI governance and compliance work starts there. This article is general information, not legal advice; your counsel or a qualified assessor makes the compliance call.
What Should the Register’s First Month Look Like?
- Days 1 to 5: confirm the AI inventory exists and is current. Name the executive AI risk owner and agree the scoring bands.
- Days 6 to 12: run a 60-minute session per AI system with its business owner and the data platform lead. Fill fields 1 to 10 for every risk you can name. Aim for three to eight rows per system.
- Days 13 to 20: pick the high-scoring rows and add fields 11 to 16: a metric with a threshold, a response, a dated action and a shut-off path someone has actually walked through.
- Days 21 to 25: wire the first two metrics to live data and move the register into a governed table if you have more than five systems.
- Days 26 to 30: hold the first monthly review. Accept, treat or close every high row, record the decision and set the next review date.
Frequently Asked Questions (FAQs)
What is an AI risk register?
It is a structured list of the risks your AI systems create, with likelihood, impact, owner, response and review dates for each. It sits alongside an AI system inventory and is the working record of how you manage AI risk.
Does the NIST AI RMF require a risk register?
No. The AI RMF is voluntary and does not prescribe a format. Several subcategories, including MAP 5.1, MANAGE 1.2, MANAGE 1.3 and MANAGE 1.4, ask for risks, priorities, responses and residual risk to be documented, and a register is the simplest place to do that.
How often should an AI risk register be reviewed?
Set the frequency by score: monthly for high risks, quarterly for medium and twice a year for low. Also review a system’s rows whenever its model, vendor or data source changes, or after an incident.
Who should own the AI risk register?
One executive owns the register as a whole and approves accepting high risks. Each row has its own owner, usually the business leader whose process the AI system supports, not the data team that built it.
What is the difference between inherent and residual risk?
Inherent risk is the score before any controls. Residual risk is the score after the controls you actually run. MANAGE 1.4 asks that negative residual risks be documented, so record both.
Can we reuse our enterprise risk register for AI?
You can roll the high AI risks up into it, but keep a separate AI register underneath. AI risks need fields an enterprise register rarely has, such as the data source, the measurement metric and the shut-off path.