An AI risk register that makes AI risk visible, owned, and trackable, and connects it to the enterprise risk management the board already trusts.
Executive summary
- An AI risk register makes AI risk visible, owned, and trackable alongside other enterprise risk, rather than leaving it as an abstract concern that no one manages.
- The primary operating unit is usually the use case because context determines risk, but the register must also preserve model, provider, platform, concentration, and enterprise-level risks that span use cases.
- The register must capture AI specific risks that traditional software registers miss, such as excessive agency, prompt injection, unsafe tool use, biased outcomes, and data leakage through prompts and models.
- A register is credible only when each risk links to the controls that manage it and the evidence that those controls operate. Without the evidence column, a register is a wish list.
- The AI risk register should connect to enterprise risk management rather than sitting apart, so the board sees AI risk through the governance it already trusts.
Source basis: ISO 31000:2018, Risk management guidelines; ISO/IEC 23894:2023, AI risk management guidance; COSO Enterprise Risk Management Framework. Full citations and scope notes appear below.
Why a risk register for AI
A risk register is where risk stops being a conversation and becomes something an enterprise can manage. For AI, it is the instrument that turns a vague sense that AI carries risk into a specific list of risks, each with an owner, a treatment, and a way to track it. Without a register, AI risk lives in presentations and anxieties, visible when someone raises it and forgotten otherwise. With one, AI risk becomes a managed portfolio, reviewed on a cadence and reported through the same governance as every other enterprise risk.
The register matters because AI risk is easy to feel and hard to hold. Everyone senses that AI carries risk, but that sense does not tell anyone what to do, who is responsible, or whether the risk is growing. A register forces the enterprise to name each risk concretely enough to own and treat it, which is a discipline that both clarifies thinking and creates accountability. The act of writing a risk down, with an owner and a treatment, is what converts a worry into a managed exposure.
A register is also what lets AI risk be governed rather than merely discussed. When AI risks sit in a register linked to owners and controls, they can be reviewed, escalated, and reported like any other risk, and they become part of the enterprise risk management the board already understands. This is the difference between AI risk as a special topic that surfaces occasionally and AI risk as a normal, governed part of the enterprise risk picture, which is where it needs to be.
Use cases as the primary operating unit
The most useful primary operating unit in an AI risk register is usually the use case. A model is one component, and the same model can carry very different risk depending on how it is used. A language model that drafts internal notes and the same model wired into a workflow that reads customer records, calls tools, and sends communications are two use cases with different data, authority, impact, and therefore risk profiles.
Registering use-case risks captures the context that determines exposure: data, tools, autonomy, affected people, business impact, and controls. A model-only register misses much of this context. But the reverse simplification is also unsafe. A shared model defect, provider outage, platform vulnerability, or concentration in one vendor can affect many use cases at once. Those cross-cutting risks need their own model, provider, platform, concentration, or enterprise-level records and must be linked to every affected use case.
A sound structure therefore combines granular use-case entries with portfolio roll-ups and cross-cutting records. Use-case owners remain accountable for their workflows, while model, platform, vendor, and enterprise owners manage risks that span them. This preserves contextual ownership without hiding correlated or systemic exposure, and supports aggregation for board reporting and enterprise risk management.
AI specific risks the register must capture
An AI risk register must capture risks that a traditional software risk register would not think to include, because AI fails in ways that conventional software does not. These include excessive agency, where an agent takes actions beyond its intended authority through a chain of tool calls, prompt injection, where crafted input manipulates a model into unintended behaviour, and unsafe tool use, where a model invokes a capability in a harmful way. They also include confabulation, where a model produces plausible but false output, and data leakage, where sensitive data flows to an unapproved destination.
These risks are catalogued in resources the register should draw on. The OWASP Top 10 for Large Language Model Applications describes the common failure modes of language model systems, including prompt injection and excessive agency, and MITRE ATLAS catalogues adversarial techniques against AI systems. Using these as a checklist when building the register helps ensure it captures the AI specific risks rather than only the general ones, which is important because the AI specific risks are precisely the ones a conventional register would omit.
Beyond the technical failure modes, the register must capture the socio technical risks that AI creates: biased or unfair outcomes, decisions that cannot be explained or contested, over reliance by users who trust the AI too much, and accountability gaps where no one is answerable for an AI influenced decision. The stack below lists common AI specific risk categories the register should cover. These risks are not exotic; they are the everyday ways AI use goes wrong, and a register that omits them is blind to the risks most likely to materialise.
Risks a conventional register would miss
A checklist of AI specific risk categories, drawn from resources such as the OWASP LLM Top 10 and MITRE ATLAS, that the register should cover.
Structuring the register
A working AI risk register has a small set of columns that together make each risk manageable. It records the risk clearly, names the use case it belongs to, identifies the owner accountable for it, records its assessed likelihood and impact, describes the controls that manage it, states the treatment decision, and points to the evidence that the controls operate. These columns turn a risk from a statement into something that can be owned, treated, and verified, which is the difference between a register that governs risk and a list that merely notes it.
The most important and most neglected column is evidence. It is easy to record a risk and name a control, and much harder to point to evidence that the control actually operates. A register that names controls without evidence describes intended risk management, not actual risk management, and the gap between the two is where risk hides. The evidence column forces the honest question of whether the named control is real, and it is what lets an auditor or a board test the register rather than trust it.
The matrix below shows the core columns of a working register. It is deliberately compact, because a register with too many fields becomes a burden that no one maintains, and a burdensome register decays into a stale artefact that no longer reflects reality. The discipline is to capture enough to manage each risk (owner, controls, treatment, and evidence) without so much that the register becomes a documentation project rather than a risk management instrument.
Core columns of an AI risk register
Every risk links to an owner, the controls that manage it, a treatment decision, and the evidence that proves those controls operate.
Identifying AI risks
Risk identification is where the register is populated, and it should be systematic rather than left to whoever happens to raise a concern. The enterprise identifies risks by examining each use case against the AI risk taxonomy, asking which of the known failure modes apply given the data, tools, autonomy, and impact of that use case. This structured approach catches the risks that are known to affect AI systems, which is more reliable than waiting for risks to surface through incidents or the intuition of individual reviewers.
Identification should also draw on the experience of others, because AI failure modes are increasingly documented. Published incident databases, the OWASP and MITRE resources, regulatory findings, and the enterprise’s own incident history all reveal risks that a use case might carry. An enterprise that identifies risks only from its own imagination will miss the failure modes it has not yet thought of, while one that draws on the accumulating body of AI risk knowledge can anticipate risks it has not yet experienced.
Identification is not a one time exercise but a continuous one, because new risks emerge as use cases change and as the field learns. A use case that gains a new tool, expands its data access, or moves from recommendation to action acquires new risks that must be identified and added to the register. And the field itself surfaces new failure modes over time, which should be reviewed against the existing portfolio. A register that is populated once and never revisited slowly becomes a record of yesterday’s risks while today’s risks go unrecorded.
Assessing likelihood and impact
Once identified, each risk is assessed for likelihood and impact, which determines how much attention it warrants. For AI, both dimensions require care, because AI risks can have unusual profiles. Some AI failures are low likelihood but catastrophic impact, such as an agent taking a large irreversible action, while others are high likelihood but low impact, such as an occasional confabulation in a low stakes context. The assessment should place each risk on both dimensions honestly, resisting the temptation to downplay a risk because it is uncomfortable or to inflate one because it is fashionable.
Impact assessment for AI should consider the full range of harm, not only the obvious financial one. An AI risk can cause harm to people through unfair or wrong decisions, harm to the enterprise through operational failure or reputational damage, and harm to third parties. It can also create regulatory exposure and erode trust. Assessing impact across these dimensions gives a fuller picture than a single financial estimate, and it captures the harms that AI is particularly prone to cause, which are often to people rather than to balance sheets.
Likelihood assessment for AI is genuinely difficult, because the probability of an AI failure often cannot be estimated precisely, and the register should be honest about this uncertainty rather than manufacturing false precision. Where likelihood cannot be well estimated, the assessment should say so and lean toward caution for high impact risks, applying compensating controls rather than pretending to a confidence it does not have. Documenting uncertainty is more useful than a precise looking estimate that rests on no real basis, because it tells the reader what is actually known.
Treatment and risk appetite
Every risk in the register needs a treatment decision, which is the choice of what to do about it: accept it, reduce it with controls, avoid it by not proceeding, or transfer it where possible. A risk with no treatment decision is an unfinished entry, because identifying and assessing a risk achieves nothing if no one decides how to handle it. The treatment column records this decision and its owner, so that the register reflects not just what risks exist but what the enterprise has decided to do about each.
Treatment decisions are made against a risk appetite, which is the enterprise’s statement of how much risk it is willing to accept in pursuit of the benefits of AI. Without a defined appetite, treatment decisions are made ad hoc, and the enterprise cannot say whether its accumulated risk sits within its tolerance. A defined appetite for AI, covering autonomy, sensitive data, customer impact, and third-party reliance, gives treatment decisions a reference point, so that a risk beyond appetite is escalated rather than quietly accepted by whoever happens to own it.
Accepting risk should be a deliberate, owned, and time bound act, not a default. When an enterprise decides to accept a residual risk, it should record who accepted it, on what basis, and when the acceptance will be reviewed, because an accepted risk that is never revisited becomes a permanent exposure that no one is watching. Treating risk acceptance as a decision with an owner and an expiry, rather than as the absence of action, is what keeps the register from accumulating silently accepted risks that add up to more than the enterprise realises.
Linking risk to controls and evidence
A risk register earns its credibility from the link between each risk and the controls and evidence that manage it. Naming a control against a risk is a claim that the risk is managed, and the evidence is what substantiates the claim. Without the link to controls, a register is a list of worries. Without the link to evidence, a register is a list of intentions. Only with both does a register become an instrument that shows not just what risks exist but that they are actually being managed, which is what a board and an auditor need.
The evidence link is where the register connects to the wider governance system, because the strongest evidence is produced by controls as they operate. A control that holds high impact actions for approval produces records of approvals and blocks, a data control produces records of prevented leakage, and these records are the evidence the register points to. This is why a register is easiest to maintain in an enterprise that enforces controls at runtime, because the evidence the register needs is generated automatically as the controls run.
Maintaining the link over time is what keeps the register honest. Controls change, and a control that managed a risk last year may have been altered or removed, leaving the risk exposed while the register still claims it is managed. Periodically verifying that the named controls still exist and still operate, using the evidence, is what prevents a register from drifting into fiction. A register whose control and evidence links are never verified slowly becomes a record of controls the enterprise used to have rather than the ones it has.
The risk management cycle
The register is not a static document but the centre of a cycle that runs continuously: identify risks, assess them, treat them, and monitor them, feeding what monitoring reveals back into identification. Seeing the register as the hub of this cycle keeps it alive, because each turn of the cycle updates the register with new risks, changed assessments, and the results of monitoring. A register that is treated as a document to be completed, rather than the record of a running cycle, decays as soon as reality moves on from the moment it was written.
Monitoring is the step that connects the register to the running system, and it is where the register earns its keep. Monitoring watches for the risks in the register materialising, for controls failing, and for new risks emerging, and it updates the register accordingly. The flow below shows the cycle. The monitoring step is what makes the register a living instrument rather than a periodic snapshot, because it continuously reconciles the register against what is actually happening.
The cycle also connects the register to change, which is constant for AI. When a use case changes materially, through a new model, expanded data, added tools, or increased autonomy, the change should trigger a pass through the cycle for that use case: reidentify its risks, reassess them, reconsider treatment, and update monitoring. This change trigger is what keeps the register matched to reality, and an enterprise that updates its register only on a calendar, without change triggers, will find its register describing use cases as they were rather than as they are.
Identify, assess, treat, monitor
The register is the hub of a continuous cycle. Monitoring feeds back into identification, and material change triggers a fresh pass.
Examine each use case against the AI risk taxonomy.
Judge likelihood and impact, documenting uncertainty.
Decide accept, reduce, avoid, or transfer, against appetite.
Watch for materialisation, control failure, and new risk.
Connecting to enterprise risk management
An AI risk register should not be an island. AI risk is enterprise risk, affecting operations, customers, privacy, security, compliance, and reputation, and it should be governed through the enterprise risk management the board already trusts rather than in a separate scheme that competes with it. Connecting the AI register to the enterprise risk framework means AI risks are reported, escalated, and reviewed alongside other risks, with the same discipline and the same board visibility, which is what gives them the attention they deserve.
Connection does not mean dissolving AI risk into the general register until its specifics are lost. AI risks have particular characteristics (autonomy, model behaviour, susceptibility to prompt injection) that a general register would not capture, so the AI register retains its AI specific detail while feeding into the enterprise view. The relationship is one of a specialised register that rolls up into the enterprise picture, so that the board sees AI risk both in its specifics and in its contribution to the overall risk position. This mirrors how enterprises handle other specialised risk domains.
The connection also aligns AI risk with the enterprise risk appetite and reporting cadence, which is what makes it governable at board level. When AI risks flow into the enterprise risk register, they are assessed against the same appetite, reported on the same cadence, and escalated through the same paths as other risks, which normalises AI risk as a managed part of the enterprise rather than a special case. Frameworks such as COSO enterprise risk management provide the structure into which AI risk connects, and using them avoids building a parallel risk universe for AI.
The risk register for agents
Agentic AI puts particular demands on the register, because an agent carries risks that a passive model does not. The register entry for an agent use case must capture the delegation risk, who delegated authority and under what identity, the tool access risk, what the agent can invoke, the autonomy risk, whether it can act without approval, and the chaining risk, whether it can combine actions into a material outcome. These are the risks that make agents distinct, and a register that treats an agent like a passive model misses exactly what makes it risky.
The controls and evidence for agent risks are also distinct, and the register should reflect this. The control for excessive agency is enforced tool and scope limits, and the evidence is records of actions permitted and blocked. The control for chaining risk is designed decision points with approval, and the evidence is records of those approvals. Because these controls operate at runtime, the register for agents depends heavily on runtime enforcement producing evidence, and an agent register with no runtime evidence is claiming controls it cannot demonstrate.
Agent risks also change faster, because an agent capability can be expanded quickly by adding a tool or widening its scope. This makes the change trigger especially important for agents: a change to an agent’s tools, data, or autonomy should immediately trigger a reassessment of its register entry, because such a change can materially alter its risk in a way that a model update to a passive system would not. The register for agents therefore needs to be more responsive to change than the register for passive AI, tracking a risk surface that shifts as the agent’s capabilities evolve.
Common register failures
The most common register failure is the register with no evidence column, which names risks and controls but cannot show that the controls operate. This register looks complete and provides false comfort, because it describes intended risk management rather than actual risk management. The remedy is to require evidence for each control, treating a control with no evidence as an unmanaged risk, which forces the honest question of whether the named controls are real.
A second failure is using only one level of record. A model-only register misses workflow context, while a use-case-only register can hide shared model defects, provider concentration, and platform-wide exposure. The remedy is to use use cases as the primary operating view and link them to cross-cutting model, vendor, platform, and enterprise risks. A third failure is the stale register, populated once and never revisited. The remedy is a continuous cycle with change triggers.
A fourth failure is the isolated register, maintained separately from enterprise risk management, which the rest of the enterprise ignores because it does not connect to real governance. The remedy is to connect the AI register to the enterprise risk framework, so AI risk is governed with the authority the enterprise already has. Each of these failures shares a root: treating the register as a document to be produced rather than an instrument to be used, and the remedy in each case is to make the register a living part of how the enterprise actually manages risk.
Conclusion: the Helixar perspective
The Helixar research perspective is that a risk register earns trust through its evidence column. A register that names risks and controls is easy to produce and easy to believe, but only the evidence that controls actually operate turns it from a wish list into an assurance tool. When the controls named against each risk genuinely operate and produce records, through operational policy governance, the register becomes something a board can rely on and an auditor can test, rather than a document that has to be taken on faith.
This is why the register is easiest to maintain where governance is operational. When controls enforce policy at runtime and produce evidence as they run, the evidence column populates itself, and the register reflects actual risk management rather than intended risk management. An enterprise that enforces and records its AI controls finds that its risk register is largely a view over evidence that already exists, which is both more trustworthy and less effortful than a register assembled from claims.
Read alongside the model risk, operational risk, third-party risk, and vendor governance reports, this framework shows how the enterprise makes AI risk visible, owned, and managed: primarily at use-case level, linked to cross-cutting model, provider, platform, concentration, and enterprise risks, and connected to controls, evidence, and enterprise risk management. The register turns AI risk from a worry into a managed portfolio. For the whole discipline these reports support, the Enterprise AI Governance Framework is the anchor.
Enterprise checklist
- Record AI risk primarily at use-case level, linked to a named owner and to cross-cutting model, provider, platform, and enterprise risks.
- Capture AI specific risks such as excessive agency, prompt injection, and data leakage.
- Structure the register with owner, controls, treatment, and, above all, evidence.
- Assess likelihood and impact honestly, documenting uncertainty rather than faking precision.
- Make every treatment a decision, and treat risk acceptance as owned and time bound.
- Run the register as a continuous cycle with triggers on material change.
- Connect the AI risk register to enterprise risk management.
Frequently asked questions
Why assess AI risk at the use case level?
What AI specific risks should the register capture?
What is the most important column in the register?
Should AI risk sit in a separate register?
What changes for agent risks?
Method and source use
This report is a Helixar synthesis of the cited public standards and guidance. Named sources are linked at first mention and listed below. Unless a cited source is identified, maturity levels, diagrams, allocations, scores, and operating models are illustrative Helixar reference models, not survey findings or legal requirements. Organisations should verify current obligations with the authoritative source and qualified advisers.
References
- ISO 31000:2018, Risk management guidelines
- ISO/IEC 23894:2023, AI risk management guidance
- COSO Enterprise Risk Management Framework
- OWASP Top 10 for LLM Applications (2025)
- MITRE ATLAS, adversarial threat landscape for AI systems
- NIST AI Risk Management Framework (AI RMF 1.0)
- Helixar research: Enterprise AI Risk Management
- Helixar research: Enterprise AI Governance Framework