The accountability chain that gives AI governance authority, and the decision rights that make it operate.
Executive summary
- Accountability is the capability that gives every other governance activity its authority. Policy, risk, and assurance mean little if no one is answerable for the outcome.
- A clear model names who approves AI use, who owns the risk, who can accept it, and who can stop a deployment, and it connects those rights to the enterprise structures that already carry authority.
- Accountability and responsibility are different. One executive should be accountable for the AI risk position, while responsibility is shared across business, model, security, and privacy owners with explicit decision rights.
- Agentic AI adds a new dimension: accountability for delegated authority. When work is delegated to an agent, someone remains answerable for what the agent does, whatever identity it acts under.
- Accountability is real only when it is supported by evidence and the ability to act. An owner who cannot see what their AI does, or cannot stop it, holds a title rather than accountability.
Source basis: ISO/IEC 38507:2022, Governance implications of the use of AI by organizations; OECD Recommendation of the Council on Artificial Intelligence; Australia's AI Ethics Principles. Full citations and scope notes appear below.
Accountability is the foundation of governance
Every other governance capability depends on accountability, because policy, risk assessment, and assurance are only as strong as the answer to a single question: when this AI system causes harm or crosses a line, who is answerable, and who could have prevented it. Where that question has a clear answer, governance has authority and decisions have owners. Where it does not, governance becomes activity without consequence, and decisions drift to whoever happens to be closest to the technology, which is rarely where accountability should sit.
The reason accountability comes first is that it converts governance from advice into obligation. A policy with no accountable owner is a suggestion. A risk with no owner is a note. An approval with no one answerable for it is a formality. Naming who is accountable turns each of these into a commitment that someone must honour and can be held to, which is what gives the whole governance system its force. Without accountability, the other capabilities are scaffolding around an empty centre.
Accountability is also what a board, a regulator, and a customer ultimately look for. When something goes wrong with an AI system, the first question is not which framework was used but who was responsible and whether they exercised that responsibility. An enterprise that can name the accountable owner, show the decision rights they held, and demonstrate that they acted, is in a fundamentally stronger position than one that can point only to a policy document. Accountability is the human spine of AI governance.
What accountability means for AI
Accountability for AI has two components that are easy to conflate. The first is answerability: being the person who must explain and justify what an AI system did and who bears the consequence if it went wrong. The second is control: having the authority and the means to shape what the system does, including the ability to approve, restrict, or stop it. Accountability requires both. Answerability without control is unfair, because it holds someone responsible for what they could not influence, and control without answerability is dangerous, because it gives power without consequence.
This dual nature shapes how accountability should be assigned. An accountable owner needs enough authority over an AI use case to actually govern it, and enough visibility to know what it is doing. Assigning accountability to someone who lacks the authority to change the system, or the information to see its behaviour, creates the appearance of governance without its substance. The model therefore pairs each accountability with the decision rights and the visibility needed to exercise it, so that the owner can genuinely govern rather than merely absorb blame.
Accountability for AI is also broader than accountability for software, because AI systems make or influence decisions that affect people. A traditional system that fails produces a technical fault. An AI system that fails may produce an unfair decision, a harmful recommendation, or an action taken without authority. The accountability model must therefore reach beyond engineering to the business owner who decided to use AI for a purpose, and to the executive who set the risk appetite that allowed it. Accountability follows the impact, not only the technology.
The accountability chain
Accountability for AI runs along a chain from the board to the model owner, with each link holding a distinct role. The board provides oversight, sets risk appetite, and holds management to account through assurance. An executive risk owner is accountable for the overall AI risk position and answers to the board for it. The AI governance function operates policy, approvals, and independent challenge. The business owner owns each use case and its outcomes. The model or system owner owns the system, its data, and its controls. Each link is necessary, and a break anywhere weakens the whole.
The chain matters because accountability that is not connected tends to pool at the wrong end. Without an explicit chain, accountability often settles on the technical team, because they are closest to the system, even though they may not have set the purpose or the risk appetite that created the exposure. The chain corrects this by making explicit that the business owner is accountable for the decision to use AI, and the executive for the risk appetite, so that engineering is not left holding a responsibility that belongs higher up.
The chain also defines how accountability flows when risk rises. A risk that exceeds the authority of one link escalates to the next, so that a decision beyond the business owner reaches the executive risk owner, and a decision beyond the executive reaches the board. The flow below shows the chain and the direction of escalation. A well designed chain means that every AI decision has an owner at the right level, and that no decision is made by someone without the authority to make it.
From board oversight to model ownership
Each role holds distinct decision rights. Risk that exceeds one link escalates to the next, so every decision has an owner at the right level.
Oversight, risk appetite, and assurance.
Accountable for the AI risk position.
Policy, approvals, and independent challenge.
Owns the use case and its outcomes.
Owns the system, data, and controls.
Decision rights and a RACI for AI
Accountability becomes operational when it is expressed as decision rights: who can approve a use case, who owns its risk, who must be consulted, and who must be informed. A responsibility assignment, often captured as a RACI that names who is responsible, accountable, consulted, and informed, turns the accountability chain into a set of specific, testable rights. The value is precision. When a decision arises, there is no ambiguity about who makes it, who owns it, and who must be involved, which is what prevents both paralysis and unauthorised action.
Decision rights should be tiered by risk, because not every decision needs the same people. A low risk productivity use case may be approved by a business owner within a policy, while a high impact, customer affecting, or autonomous use case may require the AI governance function, the executive risk owner, and specific consultation with privacy, security, and legal. Tiering keeps governance proportionate, so that low risk use is not slowed by senior approval and high risk use is not decided by someone without the authority to accept the exposure.
The matrix below shows how decision rights can be assigned across roles and risk tiers. It is a reference model that each enterprise adapts, and its value is that it makes the rights explicit and comparable. When decision rights are written down this way, an auditor can test whether the right person approved a given use case, and a team can see in advance who they need. Decision rights that live only in people’s heads are decision rights that break under pressure and cannot be assured.
Who decides what, by risk tier
A responsibility assignment turns the accountability chain into specific, testable rights. Tiered by risk so governance stays proportionate.
Connecting AI accountability to enterprise governance
AI accountability fails when it is built as a parallel structure rather than connected to the governance the enterprise already trusts. AI risk is not a separate category that a dedicated committee can own in isolation. It cuts across enterprise risk, information security, privacy, legal, compliance, procurement, operations, and audit, and accountability for it should connect to each of those functions rather than duplicate them. The AI governance function coordinates, but the accountable owners sit within the existing structure, so that AI is governed by the organisation, not beside it.
This connection is what gives AI accountability its reach. When the accountable owner for a customer affecting AI decision is the same business owner accountable for that customer relationship, and when AI risk flows into the enterprise risk register the board already reviews, AI is governed with the authority the enterprise already has. Building a separate AI governance island, by contrast, produces a committee with strong opinions and weak authority, whose decisions the rest of the organisation can quietly ignore because they do not connect to real accountability.
Connecting to existing governance also avoids a common trap, which is to make the AI governance function accountable for everything and therefore for nothing. A function that is nominally accountable for all AI cannot actually own the outcomes of every business use case, and treating it as the single accountable party lets the real owners off the hook. The model keeps the business and executive owners accountable for their own AI use, with the governance function providing policy, challenge, and coordination rather than absorbing an accountability it cannot exercise.
Escalation and thresholds
Escalation is how accountability moves up the chain when a decision exceeds the authority of its current owner, and it works only when the thresholds are explicit. A business owner may accept residual risk up to a defined limit, beyond which the decision escalates to the executive risk owner, and beyond the risk appetite it reaches the board. Without defined thresholds, escalation depends on individual judgement about when a decision is too big, which means it often does not happen until after something has gone wrong.
Thresholds should be defined in terms the enterprise can apply consistently: the risk tier of the use case, the sensitivity of the data, the degree of autonomy, the reversibility of the action, and the size of the potential impact. When these are explicit, a team knows in advance when a decision must escalate, and an auditor can test whether escalation happened when it should have. The stack below sets out common escalation triggers, which turn escalation from an act of individual courage into a defined part of the process.
Escalation must also be safe to use, or it will be avoided. If escalating a concern is treated as an admission of failure, or if it is slow and punishing, people will find reasons not to escalate, and risk will be absorbed silently at the wrong level. A healthy accountability model makes escalation expected and low friction, so that raising a decision to the right level is a normal act rather than a last resort. The willingness to escalate is a sign of a healthy governance culture, not a weakness in the person who does it.
When a decision must move up the chain
Explicit triggers turn escalation from individual judgement into a defined part of the process, testable after the fact.
Accountability for autonomous agents
Agentic AI introduces a distinct accountability question, because an agent acts under a delegated authority rather than only producing an output for a human to use. When a person or a system delegates work to an agent, and the agent then reads data, calls tools, and takes actions, someone remains answerable for what the agent does, even though no human performed each action directly. The accountability model must therefore address delegation explicitly: who delegated the authority, what identity the agent acts under, and who is accountable for the actions taken in that identity.
Delegated accountability does not transfer to the agent, because an agent is not a party that can be held to account. It remains with the human or the function that delegated the authority and configured the agent scope. This means the accountable owner of an agent is responsible not only for approving its use but for the boundaries of its authority: the tools it may call, the data it may reach, and the actions it may take. An agent that acts outside those boundaries is an accountability failure of the owner who set them, not of the agent that exceeded them.
This is why the accountability model connects tightly to runtime control for agents. An owner can only be genuinely accountable for an agent if the boundaries of its authority are enforced and its actions are recorded, so that the owner can see what was delegated, what the agent did, and whether it stayed within scope. Where those boundaries are enforced and evidenced through operational policy governance, delegated accountability is real. Where they are not, the owner is accountable in name for actions they could neither see nor control, which is accountability in title only.
Individual and collective accountability
A recurring question is whether accountability should rest with an individual or a committee, and the answer is that the two serve different purposes and should not be confused. Individual accountability is what makes a decision ownable: one named person who is answerable for a specific outcome and can be asked to explain it. Collective bodies such as an AI governance committee are valuable for setting policy, sharing information, and making decisions that genuinely require multiple perspectives, but a committee cannot be accountable in the way an individual can, because a shared accountability is easily no one accountability.
The model therefore uses committees for what they do well and individuals for what they must own. A committee may set the risk appetite, approve a high impact use case, or review the portfolio, but the accountability for a specific use case rests with a named business owner, and the accountability for the overall risk position rests with a named executive. This keeps the benefits of collective judgement without diffusing accountability to the point where no one can be held to account for a particular outcome.
Getting this balance wrong is a common failure. An enterprise that assigns all AI accountability to a committee finds that when something goes wrong, everyone on the committee can point to everyone else, and no one is truly answerable. An enterprise that assigns everything to individuals without any collective forum finds that decisions requiring multiple perspectives are made too narrowly. The model uses both deliberately: individuals for ownership and answerability, collective bodies for judgement and coordination, with the line between them explicit.
Accountability, evidence, and the ability to act
Accountability that cannot be exercised is accountability in name only, and two things make it real: evidence and the ability to act. An accountable owner needs to see what their AI systems are doing, because accountability for behaviour one cannot observe is a fiction. They need records of the approvals, exceptions, and actions in their domain, so that they can exercise oversight rather than discover problems after the fact. Without visibility, an owner is accountable for outcomes they learn about only when they become incidents.
The ability to act is the second requirement. An owner must be able to approve, restrict, or stop the AI they are accountable for, or their accountability is a burden without a lever. This is particularly acute for agents, where the ability to contain an agent that is behaving unsafely is what makes its owner genuinely accountable for its behaviour. An owner who can see a problem but cannot act on it, or who can neither see nor act, holds a title rather than a role, and the governance that rests on that title is hollow.
This is why the accountability model depends on the evidence and runtime layers of the wider framework. When operational policy governance gives owners visibility of what their AI does and the means to approve or contain high impact actions, accountability becomes a governed reality: owners can see, decide, and act, and their decisions are recorded. Accountability, in the end, is not a name on a chart. It is a person who can see what their AI does, has the authority to shape it, and is answerable for the result, supported by the evidence that shows they exercised the role.
Common accountability failures
The most common failure is accountability that pools on the technical team by default, because they are closest to the system. This leaves engineering answerable for decisions of purpose and risk appetite that were made elsewhere, which is both unfair and ineffective, because engineering cannot govern the business decision to use AI for a sensitive purpose. The remedy is an explicit chain that keeps the business owner accountable for the use and the executive for the risk appetite, so that accountability sits where the decisions were actually made.
A second failure is diffuse accountability, where a committee is nominally responsible for all AI and therefore no individual owns any particular outcome. When something goes wrong, the diffusion means no one can be held to account, and the lesson is not learned because no one owns it. The remedy is individual accountability for specific use cases and the overall risk position, with committees used for judgement and coordination rather than as a place for accountability to disappear.
A third failure is nominal accountability, where owners are named but lack the visibility or the authority to exercise the role. This is the most insidious failure, because it looks complete on paper: every use case has an owner. But an owner who cannot see what their AI does, or cannot stop it, is accountable in title only, and the governance that rests on that title fails silently the first time it is tested. The remedy is to pair each accountability with the evidence and the ability to act that make it real.
Accountability across the AI lifecycle
Accountability is not fixed at a single moment but moves and persists across the life of an AI system, and a model that ignores this leaves gaps at the handovers. At the build stage, accountability for how a system is designed and tested sits largely with the model owner and the teams that build it. At approval, accountability for the decision to deploy sits with the business owner and, for higher risk, the governance function and executive. In operation, accountability for behaviour and outcomes sits with the business and model owners together, and at change or retirement, someone must be accountable for deciding that a system is revised or withdrawn safely.
The dangerous moments are the handovers, because that is where accountability can fall between owners. A system built by one team and operated by another can end up with neither fully accountable for its behaviour in production, each assuming the other holds the role. The model closes these gaps by making the handover explicit: when a system moves from build to operation, or from one owner to another, the transfer of accountability is recorded, so that at every moment there is a named owner rather than a shared assumption that quietly becomes no owner at all.
Accountability must also persist through change, which is constant for AI. When a model is updated, a data source expands, an agent gains a new tool, or a workflow moves from recommendation to action, the accountable owner remains answerable and must decide whether the change is within the approved envelope or requires reassessment. A system that has drifted far from what was approved, with no owner having decided that the drift was acceptable, is an accountability failure even if nothing has yet gone wrong. Accountability across the lifecycle means someone is always answerable for the system as it actually is, not as it was first approved.
Conclusion: the Helixar perspective
The Helixar research perspective is that accountability needs evidence and the ability to act to be more than a name on a chart. An enterprise can draw a perfect accountability chain and still fail, if the owners at each link cannot see what their AI does or cannot shape it. The chain is necessary, but it is completed by the visibility and control that let each owner actually exercise the role they hold. Accountability is a human capability supported by an operational one.
This is where operational policy governance makes accountability real. When owners can see what their AI systems and agents are doing, approve or contain high impact actions, and rely on retained records of what happened, accountability moves from an organisation chart into daily practice. The owner is answerable, and they have the means to be answerable for something they can actually govern, which is the difference between accountability and blame.
Read alongside the decision accountability and oversight reports, this model shows how the enterprise stays answerable for AI: through a clear chain, explicit decision rights, safe escalation, and delegated authority that is enforced and evidenced. Accountability is the foundation the rest of governance is built on, and it is only as strong as the visibility and control beneath it. For the whole discipline these reports support, the Enterprise AI Governance Framework is the anchor.
Enterprise checklist
- Name accountable owners for the AI portfolio and each high impact use case.
- Pair each accountability with the decision rights and visibility to exercise it.
- Express decision rights as a RACI tiered by risk, so approvals are proportionate.
- Connect AI accountability to enterprise risk, security, privacy, legal, and audit.
- Define explicit escalation triggers and make escalation low friction and expected.
- For agents, assign accountability for delegated authority, enforced and evidenced.
- Use individuals for ownership and committees for judgement, never the reverse.
Frequently asked questions
Should one executive own all AI risk?
Where does the board fit in AI accountability?
Who is accountable when an autonomous agent acts?
Can a committee be accountable?
What makes accountability real rather than nominal?
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/IEC 38507:2022, Governance implications of the use of AI by organizations
- OECD Recommendation of the Council on Artificial Intelligence
- Australia's AI Ethics Principles
- NIST AI RMF Playbook, Govern function
- IIA Three Lines Model and position papers
- Helixar research: AI Governance Operating Model
- Helixar research: Enterprise AI Governance Framework