People do, always. An AI agent cannot be held accountable or asked to explain itself to a regulator. The question is which people, and the answer should be written down for each agent and each capability before anything goes wrong. If you are working out who answers after the mistake, you have already lost most of the value of knowing.
Why does accountability get blurry with agents?
Because the work passes through many hands and none of them feels like the decision-maker. A technology team built the agent. A vendor supplied the model. A process owner asked for it. A data team maintains its sources. An operations team runs the queue. A reviewer approved the held item, or did not see it because it was within limits. When the agent gets something wrong, each party can point to another.
The agent itself becomes a convenient place for blame to rest. "The AI made a mistake" sounds like an explanation. It is not one. It describes what happened without saying who allowed it to happen, who should have caught it, or who will fix it.
Legal liability is a separate question that depends on contracts and the law where you operate; our piece on who is liable when an AI agent makes a mistake looks at that side. This article is about internal accountability: which named person stands up and answers.
What are the different ways an agent can be wrong?
Mistakes have different causes, and each cause points to a different owner. Mapping them in advance is the core of the job.
| What went wrong | Example | Who should answer |
|---|---|---|
| The agent acted beyond what it should be allowed to do | It issued a refund that should have been held | Whoever owns the agent's bounds for that capability |
| The agent acted within bounds, but the bounds were wrong | The refund limit was set far above the business's appetite | Whoever set or approved the limit |
| The agent relied on a wrong or stale source | It quoted last season's fee schedule | The owner of that source |
| A person approved a held action that was wrong | The reviewer approved a payout without checking the payee | The named approver, and whoever sized their queue |
| The agent's answer was not grounded in its sources | It stated a policy term that does not exist | Whoever certified the agent for that capability |
| The platform let through something it should always block | A floor rule failed to apply | The platform provider, under contract, and your owner of that relationship |
Notice that "the agent" never appears in the right-hand column. Every row ends at a person or a role filled by a person.
Why should accountability be assigned per capability, not per agent?
An agent with one owner sounds tidy, but agents do many different things. A customer service agent may answer questions, draft complaint responses, issue small refunds and update contact details. The right person to answer for a wrong refund is probably in payments operations. The right person to answer for a wrong answer about product terms is probably the product owner. One name against the whole agent pushes all of that to someone who cannot reasonably answer for most of it.
Assign an overall owner for each agent, who answers for its existence, its scope and its general health. Then assign an owner for each capability that touches customers, money or regulated activity. The capability owner decides the depth, approves the evidence for widening it, and answers when that capability goes wrong.
How does evidence change who answers?
A mistake is easier to place when the record shows what happened. If every verdict names the bound that decided it, you can tell at once whether the agent acted within limits that were wrong, or outside limits that should have stopped it. If every fact the agent used carries its source, you can tell whether the source was bad or the agent misread a good one.
Evidence from before the mistake matters too. If the agent was certified for a capability on scored cases, the certification shows what the business accepted about its accuracy. An agent whose answers were tested for grounding against its sources, as in testing whether an AI agent's answers are grounded, gives the capability owner something concrete to stand behind. One that was switched on because the demo looked good leaves its owner with nothing.
Scoring answers continuously in production helps further. Our guide on how to score an AI agent's answers shows how to build the running evidence that tells an owner whether the agent is drifting before a customer notices.
What should happen in the first hour after a mistake?
The capability owner, not the technology team, should lead. Their first decisions are business decisions: is the customer harmed, does the agent's depth on this capability need to fall now, are other cases affected? Technology supports with the record and the fix.
Narrowing authority should be fast and should not need a debate. If a capability has gone wrong, dropping it to draft, so a person sends everything, contains the risk while the cause is found. It can be widened again once evidence supports it. An owner who has to seek permission to narrow an agent's authority does not really own it.
What is the trade-off in naming owners in advance?
Named owners are uncomfortable. People hesitate to put their name against something they did not build and do not fully understand. Some will push back, and some capabilities will turn out to have no natural owner, which is itself a sign they should not be automated yet.
The alternative is discovering ownership in an incident review, when everyone's instinct is to protect themselves. Assigning it in advance turns the conversation into one about what the owner needs to be comfortable: evidence, limits, review, the power to narrow. Those are the right conversations to have before the agent acts. For every live agent, write down the agent owner and, for each capability that touches customers, money or regulated activity, a capability owner with the power to narrow it. Any blank is a mistake waiting for someone to answer for it. The structure that supports this is in our guide to agent governance as a bound, not a model.
Questions people ask
Can the vendor who supplied the agent be the accountable owner?
No. A vendor can be responsible under contract for its platform and can owe you remedies, but your customers and regulators will look to your organisation. The accountable owner must be someone inside your business with authority over the process.
What if the named approver approved a mistake under time pressure?
Then accountability is shared with whoever sized the queue and set the time available. An approver given too little time or information to refuse is not exercising a real control, and the review should look at the design of the approval step as well as the individual decision.
Should an agent's owner be technical?
Not usually. The owner should understand the business process and its risks, and have authority over it. Technical support is essential, but accountability for outcomes belongs with the people who answer for the process.