An AI risk register is the artefact a regulator, an internal auditor, and your own compliance team will all ask for first. Most teams writing one for the first time get stuck on the same question — what does a single, properly-shaped entry actually look like? This piece walks through the fields an entry should contain, scores a worked example for an employee-facing tool, and maps the result to NIST AI RMF and ISO 42001 so the entry holds up under review.
An AI risk register is a structured list of every AI system your organisation uses or builds, with the likelihood and impact of each risk, the mitigation in place, and a named owner accountable for review. The NIST AI Risk Management Framework names this artefact directly under the GOVERN and MAP functions; the EU AI Act Article 9 makes it mandatory for high-risk systems. Responsible AI Studio (RAIS) generates jurisdiction-aware risk registers via the AI Risk Register tool across 14 jurisdictions, pre-populated with the sector-specific risks our regulatory data layer tracks.
Qualified review still required. Outputs are AI-generated starting-point documents — not a substitute for qualified legal or compliance advice.
What an AI risk register entry should contain (the 15 fields)
The minimum set of fields an AI risk register entry needs splits into three groups: identification, risk scoring, and accountability — plus a small set of AI-specific fields a generic operational risk register does not capture.
| Group | Field |
|---|---|
| Identification | System name |
| Identification | Vendor |
| Identification | Use case |
| Identification | EU AI Act risk category |
| Risk scoring | Likelihood (1–5) |
| Risk scoring | Impact (1–5) |
| Risk scoring | Mitigation |
| Risk scoring | Residual risk |
| Accountability | Owner |
| Accountability | Last reviewed |
| Accountability | Next review |
| AI-specific | Underlying model and version |
| AI-specific | Training-data provenance flag |
| AI-specific | Hallucination / error-feedback signal |
| AI-specific | Prompt-injection control status |
The four AI-specific fields are the ones that distinguish an AI risk register from a generic operational register. Underlying model and version matters because vendor abstractions change underneath you — a tool labelled the same in March may sit on a different model in July. Training-data provenance matters because customer or employee data flowing into model training is the GDPR Article 28 boundary. Hallucination signal gives the next-review meeting something concrete to look at. Prompt-injection control status documents whether the input-handling controls have been tested.
A worked entry: ChatGPT Business tier for HR drafting
The clearest way to learn the format is to fill one in. Here is a single entry for ChatGPT Business tier used by HR for drafting tasks — the most common employee-facing AI use case in 2026.
- System name: ChatGPT Business (HR drafting use)
- Vendor: OpenAI
- Use case: First-draft job descriptions, internal comms, meeting summaries — HR only, customer-facing output prohibited
- EU AI Act risk category: Limited-risk (general-purpose AI under Articles 53 and 55, not Annex III high-risk because no automated employment decision)
- Likelihood (1–5): 4 — multiple HR users daily; high frequency of exposure
- Impact (1–5): 3 — confidentiality exposure risk if personal data is pasted; reputational rather than safety
- Inherent risk score: 12 (4 × 3)
- Mitigation: Mandatory training before access; admin-console-enforced prohibited-prompts list; sample audit of 5% of conversations; quarterly review by HR Director with Data Protection Officer
- Residual risk (1–5): 2 — meaningful reduction from training plus audit; not zero
- Owner: HR Director (business owner) — DPO (compliance reviewer) — Head of IT (technical owner)
- Last reviewed: 2026-06-01
- Next review: 2026-09-01
- Underlying model and version: GPT-4o (model family at time of entry — re-check at every review)
- Training-data provenance flag: OpenAI DPA in place; data not used to train default models per ChatGPT Business terms
- Hallucination signal: Two incidents logged in past quarter — one factual error in a draft email, caught at review
- Prompt-injection control status: Tested 2026-05 — admin console prevents system-prompt override
A fully-shaped entry takes 20 minutes to write the first time and 5 minutes to refresh. The pattern travels: every subsequent entry follows the same shape.
Scoring on a 5×5 matrix
The 5×5 likelihood-by-impact matrix is the established convention because it scales without becoming unreadable. Likelihood runs from 1 (very rare, less than once a year) to 5 (continuous, daily exposure). Impact runs from 1 (negligible — a corrected internal note) to 5 (material — regulatory enforcement, customer harm, reportable breach). Multiplying the two yields the inherent risk score from 1 to 25.
The mitigation reduces the residual risk by lowering likelihood, impact, or both. A 4×3 inherent score of 12 might fall to 2×2 residual of 4 after access controls, training, and a sample audit. Anything still scoring 12 or above after mitigation needs escalation to the risk committee rather than a calendar reminder. The matrix is a triage tool, not a finished verdict.
Mapping the entry to NIST AI RMF and ISO 42001
The fields above map cleanly onto two frameworks the entry will be measured against. NIST AI RMF MAP function sub-category MAP-2.1 (context characterisation) covers identification fields; MEASURE-2.7 (security and resilience) covers the prompt-injection control status. ISO/IEC 42001:2023 clause 8.3 (operational planning and control) covers the mitigation field; clause 9.1 (performance evaluation) covers the hallucination signal and review cadence. The crosswalk is what turns the register into an audit artefact — a single entry now answers questions from both frameworks at once. The deeper walk-through is in mapping risk register fields to NIST AI RMF and ISO 42001.
The EU AI Act Article 9 makes the risk management system mandatory for high-risk AI; the register is how you evidence the system exists.
How a policy breach becomes a risk source
The risk register and the ChatGPT employee use policy are paired artefacts. The policy says what is permitted; the register tracks what happens when the permitted use creates risk and — more sharply — when the policy itself is breached. A breach is a risk source: an employee pastes confidential data into a sanctioned tier, or uses a prohibited tier, and the consequence lands in the register as an incident-driven entry update. The link between policy and register is what closes the audit loop. Without it, the policy looks aspirational; with it, the policy reads as operational. The upstream context is the employee AI guidelines rollout guide; for the contract layer on the vendor behind the registered tool, see assess the vendor behind the tool you are registering.
FAQ
Q1. What is an AI risk register? An AI risk register is a structured table of every AI system your organisation uses or builds, with the risk type, likelihood, impact, mitigation, owner, and review date for each. The NIST AI Risk Management Framework MAP function and the EU AI Act Article 9 both expect it.
Q2. Do SMBs need an AI risk register? Yes if you use any high-risk AI system as defined by the EU AI Act Annex III (recruitment, credit scoring, biometric ID, employee monitoring, and several other categories). For lower-risk uses, a single-page register is enough.
Q3. What fields should an AI risk register have? The minimum set: system name, vendor, use case, risk category under the EU AI Act, likelihood (1–5), impact (1–5), residual risk, mitigation, owner, last reviewed, next review. Responsible AI Studio (RAIS) generates a 15-field template tailored to your jurisdiction and industry.
Q4. How is an AI risk register different from a general risk register? An AI risk register tracks risks that are specific to AI systems — model drift, training-data bias, hallucination, prompt injection, vendor lock-in, regulatory misclassification — that a general operational risk register would not capture. It sits alongside the general register, not inside it.
A well-formed register entry takes longer to learn than to write — but once one is shaped, the rest of the register follows the same pattern. RAIS tools amplify your in-house expertise — the field structure, the framework crosswalks, and the sector-specific risk taxonomies — so the work that takes weeks of policy-team time lands in hours, with qualified review still required at the end.
Generate a jurisdiction-aware AI risk register → /tools/ai-risk-register
Qualified review still required. Outputs are AI-generated starting-point documents — not a substitute for qualified legal or compliance advice.