An AI risk register is a structured log of every AI system an organization operates, the risk each one poses, who owns that risk, and what was done about it. A usable AI risk register template needs six things at minimum: a system identifier, a risk tier, a named owner, a last review date, documented findings, and a current status. Anything less turns into a spreadsheet nobody trusts.
Most organizations do not lack a risk register. They lack one that survives contact with a second AI system. A single-model list built for a pilot project rarely scales to a portfolio of ten, thirty, or a hundred deployments, each with different owners, different data sensitivity, and different regulatory exposure.
What Is an AI Risk Register, and Why Does It Need a Template?
An AI risk register is the master inventory that connects every AI system in use to its risk profile, its accountable owner, and its review history. It is the single artifact a board, a regulator, or an auditor asks for first, because it answers the question every other governance document assumes: what do we actually have, and how risky is each thing.
A template matters because consistency is the entire value of a register. If one entry scores risk on a five-point scale and another uses "high, medium, low" with no defined thresholds, the register cannot be aggregated, sorted, or trusted. A template forces every system through the same fields, the same tiering logic, and the same review cadence, which is what makes portfolio-level reporting possible instead of thirty disconnected assessments.
The register is not the risk assessment itself. It is the index that points to each assessment, tracks its status, and forces a review date. Treating it as a summary document, rather than the underlying analysis, keeps it usable at scale.
What Columns Does a Working AI Risk Register Need?
A working register needs enough structure to support triage at a glance, without so many fields that nobody keeps it updated. The following seven columns cover what a governance committee, an auditor, or a regulator will ask for.
| Column | Purpose | Example entry |
|---|---|---|
| System name / ID | Unique identifier tied to the model inventory | CS-BOT-03, customer support chatbot |
| Risk tier | Standardized tier based on impact and autonomy | High |
| Business owner | Named individual accountable for the system's use | J. Alvarez, Head of Support |
| Last review date | Date of the most recent formal risk review | 2026-04-18 |
| Key findings | Specific issues identified, not a generic summary | Hallucinated refund policy in 3 of 40 sampled transcripts |
| Mitigation status | Whether identified issues are open, in progress, or closed | In progress, guardrail patch scheduled |
| Next review due | Forces a recurring cadence rather than a one-time entry | 2026-07-18 |
Two columns do the most work in practice: risk tier and mitigation status. Risk tier determines how much scrutiny a system receives going forward. Mitigation status is what separates a register that drives action from one that only records history.
A register missing a next review date is not really a live risk management tool. It is a snapshot, and snapshots go stale within a quarter as models get updated, prompts change, and new use cases get added without anyone revisiting the original entry.
How Should Risk Tiers Be Defined?
Risk tiers should be defined by the severity and reversibility of a wrong output combined with how much autonomy the system has, not by how sophisticated the underlying model is. A simple rules-based system making high-stakes decisions can outrank a large language model doing low-stakes drafting.
A defensible four-tier structure, aligned with the risk-based logic in the EU AI Act and the function-based categories in the NIST AI Risk Management Framework, looks like this:
- Critical: the system makes or materially influences decisions with legal, financial, or safety consequences for individuals, with limited human review before action. Loan approvals, medical triage support, and autonomous safety systems sit here.
- High: the system informs consequential decisions but a human reviews the output before it takes effect. Hiring shortlist generation and credit risk scoring for underwriter review are typical examples.
- Moderate: the system affects operational outcomes or customer experience without touching legal or financial status. A customer support chatbot answering account questions fits this tier.
- Low: the system supports internal productivity with no external-facing decision authority. Internal document summarization and meeting note generation belong here.
Tier assignment should be revisited whenever a system's scope changes, not only at its initial deployment. A chatbot that expands from answering FAQs to processing refund requests has moved tiers, whether or not anyone updated the register to reflect it. This is the same expansion-without-reassessment pattern that shows up repeatedly in model risk audits, and it is preventable only if the register ties tier review to scope change, not to a fixed annual date.
Who Owns Each Entry, and What Does Ownership Actually Require?
Every entry needs one named individual accountable for the system's continued fit for purpose, distinct from whoever built or deployed it technically. Ownership assigned to a department or a team name, rather than a person, is a common reason registers stop being maintained: no single person feels responsible for the next review.
The owner's job is not to personally test the model. It is to ensure the review happens on schedule, that findings get addressed or formally accepted as residual risk, and that the entry reflects the system's actual current use. For higher-tier systems, good practice separates this business owner from the technical owner responsible for monitoring and change history, mirroring the separation of duties auditors expect in broader model risk documentation.
Where an organization is too small to separate these roles fully, the register should state that plainly rather than imply a separation that does not exist. An honest note about a resourcing gap reads better to an auditor or a board than a structure that quietly assumes no one will check.
How Often Should Entries Be Reviewed?
Review frequency should scale with risk tier, not run on a single fixed calendar for the whole portfolio. A critical-tier system reviewed once a year alongside a low-tier internal tool is either over-auditing the low-risk system or under-auditing the critical one.
A workable cadence:
- Critical tier: quarterly review, plus an ad hoc review triggered by any material change to the model, prompt, or scope.
- High tier: semi-annual review, with the same change-triggered review requirement.
- Moderate tier: annual review, or sooner if incident volume or user complaints spike.
- Low tier: annual review, primarily to confirm the tier assignment still holds.
The trigger-based review matters as much as the calendar. A model version change from a vendor, a new integration, or a shift in the population the system affects should force a review regardless of when the last scheduled one occurred. A register that only reviews on schedule will consistently miss the exact moment risk actually changed.
How Does the Register Connect to Formal Risk Frameworks?
The register operationalizes what regulatory and standards frameworks require in the abstract, converting a principle into a row a board member can actually read. Three references show up most often in how the register's fields map to external obligations.
The EU AI Act's risk-based classification, particularly for high-risk systems under Annex III, expects an organization to know which systems fall into which category and to maintain technical documentation proportionate to that category. The register's tier column is the practical mechanism for that classification, and the review cadence supports the Act's ongoing conformity requirements rather than a one-time assessment at launch.
NIST's AI Risk Management Framework organizes its functions as govern, map, measure, and manage. The register sits closest to "map," giving the organization a current inventory of what exists and what risk it carries, while feeding the "manage" function through the mitigation status column.
ISO/IEC 42001, as the management system standard for AI, expects a documented process for identifying and treating AI-related risks as part of a continuous improvement cycle. The register is the artifact an external certification auditor will ask to see first, because it demonstrates the inventory and treatment process the standard requires, rather than a policy statement describing intent.
None of these frameworks specify a spreadsheet format. They specify outcomes: a known inventory, a documented risk basis, and evidence of ongoing management. The register is simply the most direct way to produce all three in one artifact.
What Makes a Register Fail in Practice?
Three failure patterns account for most registers that exist on paper but do not function as a real control. The first is scope creep without reassessment, where a system's use case expands but its original risk tier and review cadence stay fixed, so the register understates the organization's actual exposure. The second is stale ownership, where the named owner has left the organization or changed roles and no one has reassigned the entry, which is easy to check by cross-referencing owner names against current staff before any audit. The third is findings without resolution tracking, where issues get logged during a review but the mitigation status column never moves from "open," which tells an auditor the register records problems without ever fixing them.
A fourth, quieter failure is a register that only includes systems someone remembered to add. Shadow AI use, meaning tools adopted by individual teams without going through a formal deployment process, does not show up in a register built solely from IT-approved procurement records. A periodic reconciliation against actual usage data, such as SaaS spend or API billing, catches systems the register would otherwise miss entirely.
Key Takeaways
- A usable AI risk register needs seven core fields: system ID, risk tier, owner, last review date, findings, mitigation status, and next review due.
- Risk tiers should reflect decision severity and human oversight, not model sophistication, and should be reassessed whenever a system's scope changes.
- Review cadence should scale with tier, quarterly for critical systems, and should be triggered by material change events, not only by the calendar.
- Ownership belongs to a named individual, not a department, with separation between business and technical owners where the organization's size allows it.
- The register is the practical bridge between abstract framework requirements, EU AI Act risk tiers, NIST's map and manage functions, ISO/IEC 42001's continuous improvement cycle, and something a board or auditor can actually read.
Building, tiering, and maintaining an AI risk register that holds up under audit and board scrutiny is core material in AICA's Certified Chief AI Governance Officer (CCAIGO) certification, covering AI governance frameworks and operating models, global AI regulation and standards including the EU AI Act, NIST AI RMF, and ISO/IEC 42001, AI risk management and assurance, responsible AI policy design and enforcement, AI audit readiness and documentation, and board and regulator engagement.