Deloitte’s 2026 enterprise research delivered a line that has been quoted in boardrooms all year: organizations that have not designed their accountability model for AI by the end of this year risk finding it designed for them, whether by an audit finding, a regulatory requirement, or a visible AI failure. That is not a rhetorical flourish. It is a description of what will actually happen to programs that have deferred this work, and it is happening already in the enterprises that have had to explain an AI incident to a regulator, a customer, or a board.
Decision rights and accountability are the least glamorous chapter of any operating model. There are no launch photos of a RACI chart. And yet this is where a program either has a spine or does not. Every earlier article in this track, the structures, the platform, the teams, the change management, the funding, presupposes a working answer to the questions: who decides, who approves, who is responsible, who is answerable when it goes wrong. When that answer is fuzzy, everything above it wobbles. When it is crisp, the operating model can absorb pressure without collapsing.
This article makes the answer explicit.
The four questions accountability has to answer
The word “accountability” gets used loosely. Cut it into components and it resolves into four distinct questions that need four distinct answers.
Who decides? For any given AI initiative or system, which named role makes the go/no-go call at each significant milestone: initial approval, deployment to production, autonomy upgrade, incident escalation. Decision rights are about who has the authority to say yes, and just as importantly, who has the authority to say no.
Who is responsible for execution? Which named role owns the day-to-day building, running, and improving of the system. Responsibility flows to the delivery team, but the specific person who takes the phone call when something is wrong needs to be named, not implied.
Who is accountable for the outcome? This is the question decisions like refunds, incident reports, and board presentations depend on. Whose objectives and career move with the success or failure of this system. Accountability is a single named role; if two people are accountable, no one is.
Who is consulted or informed? Every serious AI initiative has stakeholders whose input matters or whose visibility is required. Security, legal, risk, business owners, downstream teams. The pattern that fails is not asking them; it is asking them so late that they become blockers rather than partners.
The framework is not new; it is the classic RACI, applied specifically to AI systems where it turns out to matter more than usual. What is new is that in the pre-agent era, the answers could stay implicit and things would mostly work out. In the agent era, they cannot.
The five decision types that need named owners
Not every decision needs the same level of clarity. Five categories in particular are where operating models most reliably fail without explicit ownership, and they map neatly onto the risk-tiering the Governance track described.
Intake decisions: does this idea become a project. The gate between “someone wants to build an AI thing” and “an AI thing is being built.” Without an intake decision owner, ideas either accumulate in a shadow backlog or start unofficially with no risk assessment. The CoE is often the natural owner of the intake framework; the business owner of the specific initiative is the natural sponsor.
Risk classification decisions: what tier does this system belong in. The risk-tier assignment drives everything downstream: what governance applies, what testing is required, what documentation must exist, what oversight posture the system uses. This is a decision the responsible AI advisor makes, formally, with clear criteria, and it should be revisited whenever the system’s scope changes.
Deployment decisions: is this system ready to go live. The go/no-go for production. The default should be that the business owner makes the call on the recommendation of the technical owner and the responsible AI advisor. In higher-risk tiers, additional sign-offs may be required. What matters is that the sign-off is a named person and a documented decision, not a committee that no one can quote later.
Autonomy adjustment decisions: does this system move up or down the trust ladder. From the previous article on hybrid workforces: the decision to upgrade an agent’s authority, or, more importantly, to downgrade it when evidence calls for it. This should almost never be a single-person decision; it needs the business owner, the technical owner, and the responsible AI advisor to concur, precisely because it is the decision most likely to be regretted.
Incident decisions: how does this event get handled. When something goes wrong in production, someone needs to decide whether to pause the system, roll it back, escalate to leadership, notify customers, or file a regulatory disclosure. These decisions are made under pressure; the operating model owes clear pre-defined authority for each of them, or the wrong person will end up making the call by default.
Figure 1 lays these five decision types as a lifecycle, with the named accountability role at each gate and the default consultees. The picture is not novel; the discipline of using it is.
The default accountability model
Most enterprises will not invent their accountability model from scratch; they will adapt an emerging default that the field has been converging on. The shape looks like this.
The business owner carries the outcome accountability. When the AI system succeeds, their objectives move. When it fails, the business impact lands on their P&L first. This is the person whose team consumes the system’s outputs and whose customer relationship is affected. This person is named per system, not per portfolio.
The technical owner carries the design and operational responsibility. This is the AI engineer, agent operations specialist, or equivalent role who built the system and runs it. When something misbehaves technically, this is where the diagnostic path starts.
The responsible AI advisor carries the oversight authority. They set the risk tier, sign off on the appropriate controls, and are the second signature on high-risk changes. They are typically a specialist role in the CoE, embedded through the domain hubs as the operating model matures.
The CoE lead carries the platform and standards accountability. When the platform enables or fails to enable something, this is where it lands.
The executive sponsor carries the strategic accountability. For the portfolio, not for individual systems. When the AI investment case is questioned, this is who defends it.
These are five hats, not five people. In small teams one person may wear three of them. In scaled programs each is a full role. What matters is that every hat is on someone’s head, and that everyone knows which hat is on which head.
The default accountability model deserves one strong caveat: the five roles do not include the AI system itself, even when the AI system is an agent that takes actions autonomously. The Berkeley research from the previous article was emphatic on this point, and it bears repeating in this context. Agents do not carry accountability. Humans do. Language that softens this distinction, “the agent is responsible for,” “the agent decided to,” is a subtle abdication that regulators and courts have started to notice. Design the accountability model as if humans are the only accountable actors, because they are.
The escalation path
Related to decision rights but distinct from them is the question of who gets called when things go wrong, in what order. A working escalation path has three properties.
It is written down before the incident. Escalation paths designed during incidents are usually incoherent; the discipline is to define them in calm conditions and let them run under pressure.
It has named humans, not distribution lists. “The AI team” is not an escalation path; the AI team lead’s mobile number is. Distribution lists absorb urgency; named contacts respond to it.
It has fallbacks. Anyone can be on holiday, on a plane, or unavailable. Every named contact needs a documented deputy, and everyone knows the substitution rule. Escalation paths that assume the primary contact is always available fail predictably at the worst possible moment.
The kill switch owner from the hybrid workforce article is a specific and important node in this path. Writer’s 2026 finding, that 35 percent of executives could not immediately pull the plug on a rogue AI agent, is essentially a finding about missing escalation authority combined with missing technical capability. The two failures compound each other; the fix requires both.
Where decision rights meet governance
The Governance track describes what standards apply, what documentation must exist, and what regulatory obligations attach. The decision rights framework in this article describes who applies the standards, who owns the documentation, and who is answerable for the obligations. The two tracks meet at the point where a policy commitment becomes an operating reality, and that meeting is where most enterprises are quietly weakest.
Three specific overlaps deserve attention.
Model documentation, model cards, system cards, and audit trails discussed in the Governance track, exists only if a named role is accountable for producing and maintaining it. Ownership decays without a name.
Risk assessments are only as good as the person authorized to reject an initiative on their basis. Assessments produced by teams with no authority to say no become paperwork.
Incident disclosure decisions, whether to notify regulators, whether to inform customers, whether to publish a post-mortem, sit at the intersection of the responsible AI advisor’s judgment, the legal function’s advice, and the executive sponsor’s authority. When those three are not aligned in advance, disclosure decisions get made too slowly or too late.
Figure 2 shows the accountability model as an architectural blueprint: business owner and technical owner at the center of each system, responsible AI advisor and CoE lead as the horizontal beams, executive sponsor as the vertical support, and the escalation path threaded through as the reinforcing structure. It is deliberately built, not accidentally accumulated, and every mature program eventually looks something like it.
The test that decides everything
There is a five-minute test that reveals whether the accountability model is real. Pick a production AI system at random. Ask the head of the operating model to answer, in a single sentence per question, without checking notes: Who is the business owner? Who is the technical owner? Who signed off the current risk tier? Who is the kill switch owner? What is the escalation path for a Sunday-night incident?
An answer within a minute for each question suggests the model is real. Consultation with three people to piece it together suggests the model exists on paper but not in practice. Vague answers or shrugs suggest that whatever exists is decorative, and the operating model is one incident away from finding out.
The organizations that pass this test have not usually done anything exotic. They have done the unglamorous work of writing decisions down, assigning names, keeping the assignments current as people move, and making sure the paperwork reflects the practice. Looking at Figure 1’s five decision gates and Figure 2’s architectural picture together, none of it is rocket science; the discipline lies in keeping each named role current across the whole system as reality moves. That work is not deep; it is just boring, and it is why so many programs postpone it until the boredom becomes an emergency.
Delight in the boredom. The operating model that gets decision rights right is the operating model that survives its first big incident, its first regulator visit, and its first board challenge, in a state where leadership can still explain what happened and who owned it. Every article in this track adds capability; this one adds the spine that holds the capabilities together under stress.
Which sets up the last two articles nicely. Once the structures, platforms, people, ways of working, funding, and accountability are in place, the question becomes how the whole thing scales beyond one team, one function, one business unit, and becomes what everyone has been calling an AI-native organization. That is where we go next.