Who's responsible when your AI agent makes a bad decision?

01.The answer should never be "the AI"

An AI agent is a tool. It has no accountability. A regulator, a customer or a board will not accept "the model decided" as a reason.

The answer should never be "the AI". Every agent needs a named human owner, the same way every production service has an on-call engineer. Nobody asks whether the database is responsible when it goes down. They ask who is on call.

Without a named owner you get three common problems:

• Nobody reviews the agent's decisions, so quiet errors continue for months.
• When a fix is needed, teams argue about whose job it is.
• Auditors ask who is accountable and the room goes silent.

02.A simple responsibility model

Four roles are enough for most agents. One person can hold more than one in a small company, but the roles should still be written down.

• Owner: one person accountable for what the agent is allowed to do and for reviewing its decisions. This is usually the business lead of the process the agent works in, not an engineer.
• Builder: the team that implements the rules and fixes defects. They answer for whether the agent does what the owner specified.
• Approver: a person who signs off on any action above a set risk level, such as payments or deletions. They need to see the agent's input and proposed action side by side.
• Auditor: someone outside the team who reviews logs on a fixed schedule. Independence matters here. People are poor judges of their own work.

Notice what each role covers. The owner decides the limits. The builder makes the agent respect them. The approver handles the exceptions. The auditor checks that all three are doing their jobs.

03.Make it enforceable

A responsibility model on a slide is not a control. These four steps turn it into something real.

Write the agent's permissions down. List what it can read, what it can change and what it cannot touch. Keep the list next to the code. If the agent gets a new tool, the list changes in the same review.

Log every action with the input it saw. A log that says "refund issued" is not enough. You need the request, the data the agent looked at, the rule or reasoning it applied and the result. That is what lets the owner understand a bad decision after the fact.

Set thresholds above which a human must approve. Pick limits by risk, not by comfort. A refund above a certain value, a message to an external party, a change to a user's permissions: these go to the approver. You can move the line as you gain evidence.

Review a sample of decisions every week. Even twenty decisions, read carefully, will show you drift. Look for cases that were technically allowed but felt wrong. Those are the cases that become incidents.

04.A worked example

Take an agent that approves refund requests up to a set value.

• The owner is the head of customer operations. She decides the refund limit and the eligible reasons.
• The builder is the support engineering team. They implement the rules, keep the test cases and fix bugs.
• The approver is a team lead who handles any refund above the limit or any case the agent marks as uncertain.
• The auditor is someone from finance, who reads a sample of refunds each month and checks them against the policy.

One day a customer is refunded twice. The log shows that the agent saw two near-identical requests a minute apart and treated them separately. The owner decides to add a duplicate check. The builder adds it and a test case. The auditor confirms in the next review that duplicates are caught. Nobody argues about whose problem it was, because it was written down.

05.How accountability fails in practice

Three patterns turn up again and again.

The orphaned agent. A developer builds an agent as a side project. It proves useful and other people start relying on it. The developer changes teams. The agent keeps running on their credentials. Nobody reviews it. A year later, it is making decisions no one can explain. The fix is simple: no agent runs without a current owner, and leavers hand over or shut down what they built.

The diffuse committee. A steering group "oversees" AI. It meets quarterly, reads a slide and approves. Nobody on it looks at a single decision. Committees are fine for policy. Day-to-day accountability needs a person with time to read logs.

The approval treadmill. A team adds human approval to everything out of caution. Within weeks the approver is clicking "yes" on forty items an hour. The control exists on paper and does nothing. Fewer, better-chosen approvals work better. Set the threshold so that the approver can read each case.

06.Common mistakes

• Making the vendor or the model the owner. A vendor can supply the tool. It cannot carry your accountability.
• Naming a team, not a person. "The data team" is not an owner. A person has a name and a calendar.
• Choosing an owner with no authority. If the owner cannot change the rules or pause the agent, the role is decoration.
• Skipping the auditor. Without independent review, problems are found by customers.
• Treating approval as a rubber stamp. If approvers click through hundreds of requests a day, the control is theatre. Keep the approval volume low enough to be read.

07.What to do next

For each agent you run today, answer five questions on one page:

• Who is the owner?
• What is the agent allowed to read and change?
• Which actions need approval and from whom?
• Where are the logs, and who reads them?
• How do we stop the agent quickly?

If you cannot answer all five, that agent is not ready for more access. Fill the gaps first.

Accountability is not a brake on adoption. It is what lets leadership say yes to the next agent. A company that can explain who is responsible and show the logs will get approval faster than one that asks everyone to trust the demo. If you want help setting up the model, roles and logging for the agents you already have, Brandsmashers security engineers can run that review with your team.