Accountability for AI Agent Mistakes: Who Answers

Every AI governance conversation reaches the same question eventually: when the agent gets it wrong, who actually answers for it? Four candidates get proposed in almost every version of this conversation, the operator who ran the task, the approver who assigned it, the vendor who built the tool, and the provider that trained the model underneath it. Only one of those four survives contact with an actual audit, and most PMOs have not decided which one before they need the answer.

The direct answer: accountability for AI agent mistakes lands on whoever assigned the work and set the permission scope it acted inside, the same person who would answer for a human report's mistake made under their direction. The tool vendor and the model provider are contractual parties, not accountable parties inside your own audit, and naming either of them "responsible" just delays writing the policy that actually holds up.

Accountability for AI Agent Mistakes: The Four Candidates

Here is how each one holds up once an auditor actually asks the question.

Candidate	The case for them	Why it does or doesn't hold
The operator who ran the task	They triggered the specific run	Rarely accountable alone: they usually acted inside a scope someone else defined
The approver who assigned the work	They set the permission scope and accepted the risk	Holds. This is the accountable party in almost every case
The tool vendor	They built the feature that misfired	Contractually liable under an SLA, not organizationally accountable inside your audit
The model provider	They trained the model that produced the output	Never saw your data, scope, or policy; naming them is a category error

Why Three of the Four Don't Survive an Audit

The operator alone rarely holds up because they were usually following an authorized scope, not exercising independent judgment about what the agent should be allowed to touch. Punishing the operator personally teaches people to stop using the tool, or worse, to stop reporting when something goes wrong, neither of which is the outcome a policy should produce.

The tool vendor holds contractual accountability: a support agreement, an uptime SLA, a liability clause in the terms of service. That is real, but it is a different question from who inside your organization answers for this specific decision. A PMO cannot point to a vendor's contract as its own internal audit trail.

The model provider is the easiest to eliminate and the most commonly proposed, usually right after an incident when the instinct is to find the biggest name in the chain. But the provider trained a general-purpose model with no visibility into your permission scope, your data, or your policy. It cannot be accountable for a decision it never had the context to make.

Who Is Actually Accountable

The approver, the person who assigned the agent its task and set the permission scope it operated inside, is the one who survives. This is the same standard already applied to human delegation: a manager who assigns work to a report and defines what that report can approve is accountable for the outcome, even though the report did the actual work. An AI agent does not change that chain; it changes how fast decisions happen and how many of them get made, which is exactly why the scope has to be set deliberately instead of defaulting to whatever access was easiest to grant.

Who is accountable when an agent treated as a team member makes a mistake covers the same conclusion from the identity side: a named persona with a defined scope is what makes this chain traceable at all. Without a persona and a scope, "the AI did it" is the only answer left, and that answer satisfies nobody in an audit.

The diagram below shows the four candidates and where the accountability chain actually terminates.

What to Write Into the Policy Before You Need It

A PMO that decides this in advance gets a consistent answer under pressure. One that waits gets a political fight on the worst possible day.

1. Name the accountable role explicitly, by seat, not by team. "The PMO" is not accountable; the PMO director who approved the agent's scope for that task class is.
2. Log the permission scope at the moment of assignment, not reconstructed afterward from memory or a support ticket.
3. Define what counts as expensive to undo for your own work, so the accountable person knows in advance which task classes need approval before they run and which can be reviewed after the fact.
4. Set a review cadence for every task class currently running on-the-loop, so a widening scope gets re-evaluated on a schedule instead of by accident.
5. Decide the answer to "who's accountable" while nothing has gone wrong yet. Naming the accountable seat is the clause every other clause in a governance policy depends on; write it first.

The five levels of AI agent autonomy maps how this accountability question changes as an agent's scope widens: the higher the level, the more the permission-scope decision is doing the actual work of protecting the organization. AI governance for PMOs covers the broader policy structure this accountability clause sits inside. The NIST AI Risk Management Framework makes the general case for the same practice: oversight has to be built into the system's design, not bolted on after an incident forces the question.

None of this is unique to any one vendor's agent. The chain, operator, approver, vendor, provider, is the same regardless of which tool ran the task, and the answer is the same too: it lands on the person who decided what the agent was allowed to do. The rest of the Onplana blog covers the adjacent governance decisions, autonomy levels, audit trail requirements, and what a policy needs to say before the first incident makes the question urgent.