The AI risk register: a template and worked example for Australian risk teams

Most organisations already have an enterprise risk register. Very few have one that actually copes with how AI fails. AI systems do not break in the tidy, discrete ways your operational risk framework was built for — they degrade quietly, they behave differently in production than in testing, and they introduce failure modes (a model confidently inventing a fact, a user smuggling instructions into a prompt) that simply have no equivalent in a traditional process-and-control world. That gap is where ai risk management either becomes a real discipline or stays a slide in a board pack.

The summary you can act on: stand up a dedicated AI risk register as a living operating artefact — not a compliance document you write once and file. Give it AI-specific columns, populate it with the failure modes that are actually characteristic of these systems, map each entry to the guardrails you are expected to meet, and review it on a cadence that matches how fast your models and vendors change. Below is a structure and a worked example you can adapt.

Why AI needs its own risk register

The obvious question from any risk committee is: why not just add a few rows to the register we already have? Because the general enterprise register is optimised for a different shape of risk. It tends to assume stable, testable controls, clear ownership, and failure modes that stay put once you understand them. AI breaks all three assumptions.

• The failure modes are unfamiliar. Hallucination, prompt injection, model drift and training-data bias do not map onto categories like “process failure” or “system outage”. If you force-fit them, you lose the specificity a control owner needs to actually do anything.
• The system changes underneath you. A model provider ships a new version, a vendor tweaks a system prompt, your own data distribution shifts — and a control that worked last quarter silently stops working. Static registers do not capture that.
• Ownership is genuinely split. The business owns the use case, data teams own the inputs, a third party often owns the model, and governance owns the policy. A generic register rarely forces that conversation.

A dedicated register does not replace your enterprise risk framework — it feeds it. Think of it as a specialised sub-ledger that rolls up into the top-level register, giving your risk team the granularity to manage AI properly while still reporting in a language the board recognises. If you are formalising this alongside a broader programme, our view on how this fits the operating model is set out in /services/ai-governance/.

The columns that matter

A workable AI risk register does not need to be elaborate. It needs a consistent set of columns that force the right thinking. Here is the structure we recommend, and why each field earns its place.

• Risk ID and description. A stable identifier plus a plain-English description of what could go wrong and in which system or use case. Be specific about the flow — “hallucinated policy detail in the customer-facing service chatbot” is useful; “AI errors” is not.
• Category. A small, AI-specific taxonomy: accuracy/reliability, data and privacy, security, model behaviour, third-party/supply chain, fairness/bias, and legal/regulatory. Consistent categories let you spot concentrations.
• Likelihood and impact. Use the same scale as your enterprise framework so the numbers translate. The judgement is harder for AI because base rates are poorly understood — be honest about the uncertainty rather than manufacturing false precision.
• Inherent risk. The exposure before controls. This matters more than teams expect: for something like prompt injection in an internet-facing agent, inherent risk is high, and naming that plainly justifies the control investment.
• Controls. The specific mitigations in place — technical (guardrails, retrieval grounding, human review), procedural (approval gates, escalation paths) and contractual (vendor obligations). List what actually exists, not what you intend to build.
• Residual risk. Exposure after controls. The gap between inherent and residual is the story you tell the board: how much risk your controls are genuinely buying down, and how much you are choosing to accept.
• Owner. A named accountable person, not a team. AI risk drifts precisely because ownership is fuzzy.
• Review cadence. How often this entry is reassessed. High-velocity risks (drift, vendor changes) may need monthly review; stable ones quarterly. This column is what makes the register living rather than static.
• Status. Open, mitigating, accepted, or closed — with a date. Gives you an at-a-glance view of what is moving and what is stuck.

A worked example

Below is a representative AI risk register — generic, not tied to any client — showing how a handful of characteristic AI risks are treated. It is deliberately small; a real register grows per use case, but the pattern holds.

Risk	Category	Inherent	Key controls	Residual	Owner	Cadence
Hallucinated information in a customer-facing chatbot leads to wrong advice and a complaint	Accuracy	High	Retrieval grounding to approved content; confidence thresholds; clear scope limits; human handoff for high-stakes queries; standing disclaimer	Medium	Head of Customer Ops	Monthly
Sensitive data leaked to an external model provider via prompts	Data & privacy	High	Data classification and input filtering; contractual no-training/retention terms; regional hosting; DLP on the integration	Low–Medium	CISO	Quarterly
Prompt injection in an agent with tool access causes unintended actions	Security	High	Least-privilege tool scopes; input sanitisation; action allow-lists; human approval for irreversible steps; monitoring	Medium	Security Architecture	Monthly
Model drift degrades output quality over time as data or the model version changes	Model behaviour	Medium	Output quality monitoring; periodic re-evaluation against a golden set; change alerts from the provider; rollback plan	Medium	ML/Platform Lead	Monthly
Third-party model supplier changes terms, deprecates a version, or suffers an outage	Third-party / supply chain	Medium	Vendor due diligence; contractual notice periods; abstraction layer to enable switching; documented fallback	Medium	Vendor Manager	Quarterly
Biased outputs produce unfair treatment across customer segments	Fairness / bias	Medium	Representative test sets; outcome monitoring by segment; human review of adverse decisions; documented evaluation	Medium	Model Risk / Governance	Quarterly

A few things are worth drawing out. Notice that residual risk is rarely “low” — honest registers accept that AI carries irreducible uncertainty, and the point is to make that acceptance deliberate and visible rather than accidental. Notice too that the controls mix technical, procedural and contractual measures; over-relying on any one layer is a common failure. And notice the cadence varies: the fast-moving risks get looked at monthly because that is roughly how fast the underlying systems move. If you want a deeper treatment of the failure modes themselves — particularly retrieval and the reasons pilots stumble — /insights/why-most-enterprise-ai-pilots-fail/ is a useful companion.

Mapping the register to the Voluntary AI Safety Standard

Australia’s Voluntary AI Safety Standard sets out guardrails covering accountability, risk management, data governance, testing, human oversight, transparency, contestability and record-keeping. A well-built register is one of the more direct ways to evidence several of them at once — which is the practical reason to bother.

• The risk management guardrail is essentially asking for exactly this: a documented process for identifying, assessing and treating AI risks across the lifecycle. The register is the artefact.
• Accountability is served by the owner column — clear, named responsibility for each risk.
• Testing and human oversight show up in your controls column, where re-evaluation, monitoring and human-in-the-loop measures are recorded against specific risks.
• Record-keeping and transparency are served by the register’s history: what you knew, when, and what you did about it.

The mapping is not one-to-one, and you should not oversell it — a register alone does not make you compliant with the Standard. But it is a load-bearing piece of evidence, and it turns an abstract set of guardrails into something a risk team can actually operate. We walk through the guardrails in practical terms in /insights/voluntary-ai-safety-standard-guide/.

How it supports APRA CPS 230 for regulated entities

For APRA-regulated entities, an AI risk register is not just good practice — it plugs directly into existing obligations. CPS 230 requires strong operational risk management, including identifying and assessing operational risks, maintaining effective controls, and managing the risks arising from material service providers. AI systems generate operational risk (accuracy failures, security exposure, availability of a model service) and frequently involve third-party model suppliers who may be material to a critical operation.

An AI-specific register helps you meet CPS 230 in three concrete ways: it surfaces AI operational risks in a form that rolls up into your operational risk profile; its controls column evidences the effectiveness testing the standard expects; and its third-party rows feed your service-provider assessments, including the tolerance and continuity questions APRA cares about. For entities juggling CPS 230 alongside CPS 234 and the prudential expectations more broadly, the register becomes a shared reference point across risk, security and technology. Our broader take on the regulated-entity context is at /insights/ai-for-apra-regulated-entities/.

Keep it living, not laminated

The single biggest failure with risk registers of any kind is that they are written once, approved, and then quietly ignored until an incident or an audit. With AI that failure is fatal, because the systems change faster than almost anything else on your register. A model version ships, a vendor changes a default, your usage scales into a new pattern — and yesterday’s residual risk assessment is simply wrong.

Treat the register as an operating artefact with a heartbeat:

• Tie reviews to change events, not just the calendar. A new model version, a new use case, a vendor announcement — any of these should trigger a re-look at the affected rows.
• Make it accessible. If it lives in a document only the risk team opens, control owners will not use it. It should be where the people doing the work can see it.
• Report the delta. What the board should see each period is what moved — new risks, changed residuals, controls that failed. A static heatmap tells them nothing.

If you want a running start, our /tools/ai-policy-template/ gives you the policy scaffolding that sits above the register, and a structured /productised/ai-governance-review/ will pressure-test both your register and the controls behind it. For risk and board-level framing specifically, /insights/ai-governance-for-australian-boards/ covers what directors should actually be asking.

None of this needs to be heavy to be effective — a disciplined register run properly beats an elaborate one that nobody maintains. If you would like a second set of eyes on how you are structuring ai risk management, or help mapping your register to the guardrails and CPS 230 obligations that apply to you, get in touch. We will tell you plainly what is working and what is theatre.