A generative AI risk register is a controlled list of the ways a generative AI system can fail or be abused in production, each paired with the control that contains it, the system that enforces that control, and the person accountable for it. It is a governance artefact, not a threat list.
Most enterprise AI risk documents stop at naming risks. A register that stops there changes nothing, because a risk with no named control and no named owner is a statement of concern. What follows is the register structure we use, the twelve risk classes it covers, and the three properties that separate a register that governs from a document that reassures.
Build a Practical AI Risk Register
Identify, assess, and prioritize the risks associated with enterprise generative AI use cases, from data exposure and model reliability to security and governance.
What a risk register has to contain to be useful
A register entry is only operable when it carries five fields. Risk class, containing control, enforcing system, owner role, and evidence of enforcement.
The fifth is the one most registers omit and the one an auditor asks for first. “We require human approval for high-impact actions” is a policy. “Approval is enforced by the orchestration layer, which refuses to execute any tool call flagged `irreversible` without a recorded approver ID, and the approval events are in the agent audit log” is a control. The difference is whether someone can verify it without asking you.
| Field | Question it answers |
|---|---|
| Risk class | What can go wrong, stated as a failure not a fear |
| Containing control | What specifically prevents or bounds it |
| Enforcing system | Which component refuses the unsafe action |
| Owner role | Which named role is accountable when it fires |
| Evidence | What an auditor can read to confirm the control ran |
The twelve risk classes
The register below covers the failure classes that appear in enterprise generative AI deployments. It is deliberately organized by failure mode rather than by technology, because the technology changes faster than the register should.
Model behaviour risks
| # | Risk class | Containing control | Enforcing system | Owner |
|---|---|---|---|---|
| 1 | Output inaccuracy — the system produces a confident, wrong answer | Deterministic recomputation of any figure the model states; confidence thresholds that route to human review | Application layer, not the model | Product owner |
| 2 | Silent model regression — a model version change alters behaviour with no code change | Pinned model versions; a regression suite that runs before any version is promoted | Evaluation harness in CI | Engineering lead |
| 3 | Evaluation gap — no measurable baseline, so degradation is invisible | A scored test set representing real cases, versioned alongside the prompt | Evaluation harness | Engineering lead |
Risk 1 is the one that gets misclassified most often. Treating inaccuracy as a model-quality problem leads to model shopping. Treating it as a systems problem leads to recomputation and thresholds, which work regardless of which model is behind them.
Security and access risks
| # | Risk class | Containing control | Enforcing system | Owner |
|---|---|---|---|---|
| 4 | Indirect prompt injection — instructions arrive inside retrieved content or tool output | Treat all retrieved content as untrusted data; no privileged action triggered by model-read text without an independent check | Tool layer and orchestration | Security architect |
| 5 | Identity inheritance — the agent runs with a human user’s access | Distinct machine identity per agent, least-privilege scopes, no shared service accounts | IAM | IAM ownser |
| 6 | Excessive agency — the system acts beyond intended scope | An allow-list of callable tools, with irreversible actions gated behind approval | Orchestration layer | Product owner |
| 7 | Data boundary leakage — sensitive data crosses into a context or training boundary it should not | Classification-aware retrieval filters; contractual and technical no-training guarantees; redaction before the call | Retrieval layer and vendor contract | Data protection lead |
Risks 4, 5 and 6 compound. Injection is a nuisance against a read-only assistant and a serious incident against an agent that inherited a finance user’s permissions and can call a payment API. Register them separately, assess them together.
Supply and change risks
| # | Risk class | Containing control | Enforcing system | Owner |
|---|---|---|---|---|
| 8 | Model and dependency supply chain — provenance of weights, libraries and MCP servers is unverified | Approved-model list; dependency pinning and review for anything the agent can load | Platform / procurement | Platform lead |
| 9 | Shadow AI — teams deploy agents outside the governed path | A discoverable inventory, and a governed path fast enough that bypassing it is not worth it | Inventory and egress controls | AI governance owner |
| 10 | Cost runaway — token or tool spend scales past the value delivered | Per-workflow budget ceilings and alerting on cost per transaction, not just total spend | Gateway / metering | FinOps |
Risk 9 is the one where the control is partly cultural. An inventory catches what exists; a slow approval process is what creates the thing to catch. Measure the time from request to governed deployment, and treat a rising number as a leading indicator of shadow AI.
Legal and regulatory risks
| # | Risk class | Containing control | Enforcing system | Owner |
|---|---|---|---|---|
| 11 | IP and licensing contamination — generated output carries licensing exposure | Provenance recording on generated assets; license scanning where output enters a codebase | Code and content pipelines | Legal |
| 12 | Regulatory classification — the system falls into a regime nobody assessed it against | A classification decision recorded per use case, revisited when scope changes | Governance process | Legal / compliance |
For risk 12, record the classification decision and its date even when the answer is “out of scope”. An unrecorded decision that a system is low-risk is indistinguishable, a year later, from nobody having looked. `DATA_REQUIRED: confirm which regimes apply to the target markets before naming any specific regulation here. Owner: Legal.`
How to run the register
Review it when something changes, not on a calendar. Four events should trigger a re-read: a new model version reaching production, an agent gaining a new tool, a use case crossing into regulated data, and any incident.
Registers decay because they are treated as annual documents. A register attached to change events stays accurate; a register attached to a quarterly meeting is accurate on four days a year. The practical implementation is a required field on the change ticket: which register entries does this change touch, and does the control still hold.
Assess Risks Before Scaling Generative AI
Evaluate your AI use cases, technical environment, and operating processes to identify risks and define appropriate safeguards before wider deployment.
Where this fits
This register is the parent document for the control-level detail. Each entry below links to the post that covers its control in depth.
– Risk 4 — Prompt Injection in Enterprise AI Systems
– Risk 6 — Approval Gates in Agentic Workflows
– Risks 2 and 3 — Building an Evaluation Harness for AI Agents
– Risk 9 — Agent Sprawl: Building an AI Agent Inventory
– Risks 4 and 7 — Securing Enterprise GenAI
Building agents that have to satisfy this register from day one is a design problem, not a compliance one — we cover the architecture in AI agent development, and the code-level assessment in AI code audit.
FAQs
Is a generative AI risk register the same as an AI system inventory?
No. An inventory records what exists; a register records what can go wrong with it. The inventory answers "how many agents do we run", the register answers "what contains their failure modes". You need both, and the inventory is the cheaper one to build first.
How many risk classes should a register have?
Enough to cover the failure modes that apply, and few enough that each entry has a real owner. Twelve is a working starting point. A register with forty entries and three owners is a register nobody maintains.
Who should own the register itself?
A single named role, separate from the teams that own individual controls. The register owner's job is to keep entries current against change events, not to implement the controls.
Put Responsible AI Into Practice
Talk to an AI Expert
