When an AI agent makes a mistake, responsibility stays with people: the business that deployed it toward customers and partners, the named owner who set its permissions and approved its actions, and in some cases the vendor under the terms of its contract. “The AI did it” is not a defence anyone will accept. To be ready, you need a clear chain of accountability before the agent starts, logs that show what happened, a written plan for incidents, and contracts that spell out what the vendor is responsible for.
Most businesses think about accountability only after something has gone wrong, when it is too late to collect the evidence they need. This guide covers who answers for what, how to sort incidents by severity, a step-by-step response, a realistic example, what to check in vendor contracts, the mistakes that make incidents worse, and when to bring in lawyers or the authorities.
Who answers for an agent’s mistakes?
Start from the customer’s point of view. If your agent sends a wrong quote, leaks a document or cancels an order, the customer sees your business doing it. They will expect you to fix it, apologise and, where appropriate, compensate. Whether your vendor shares the cost is a matter between you and the vendor, decided by your contract.
Inside the business, accountability should rest with a named person for each agent: someone who approved its use, set its permissions, defined which actions need approval, and reviews its work. This is not about blame. It is about making sure someone has the authority and the information to act quickly when something goes wrong.
People who approve individual actions carry part of the responsibility for those actions. That is one reason approval should be meaningful, not a reflex click. If approvals happen too often to read, the design is at fault, and the owner should fix it.
Vendors are responsible for what they promised: security measures, data handling, uptime and the behaviour of features they document. They are rarely responsible for how you configured the tool or what you allowed it to do. Read the terms with this in mind.
The legal treatment of harm caused by AI systems is developing in many countries, including Vietnam. General principles about responsibility for one’s own business activities, consumer protection and personal data still apply. For a specific situation, take legal advice rather than relying on general articles.
Building an accountability chain before you start
Name an owner for each agent. Write the name, the task and the date the agent was approved. Update it when people change roles.
Document permissions and the reason for each. A short list: what the agent can read, write or send, and why it needs each. Our guide on prompt injection explains why narrow access limits the damage when content tricks an agent.
Define which actions need approval and by whom. Sending to customers, spending money, deleting data. Name the roles that can approve.
Keep logs where the agent cannot edit them. Sources read, actions taken, approvals given, errors and costs. Decide how long to keep them.
Write a one-page incident plan. Who to call, how to pause the agent, how to inform customers, where to record what happened.
Agree on thresholds for escalation. Decide in advance what counts as minor, serious or critical, so no one has to judge it in a panic.
Review the chain every few months. Check that owners are still in role, permissions still fit the task and contact details are current.
Train the people involved. Owners and approvers should know how to read the logs and how to stop the agent.
Sorting incidents by severity
Agree on these levels before you need them. Adjust examples to your business.
| Level | Examples | Response time | Who is involved |
|---|---|---|---|
| Minor | Wrong label on an email, a draft with a typo caught at review, a failed run with no effect | Within the normal weekly review | Agent owner |
| Moderate | Wrong information sent to a few customers, a record updated incorrectly, unusual cost spike | Same day | Owner and manager; inform affected customers |
| Serious | Many customers affected, confidential data shared outside, an order or payment wrongly placed | Immediately, within hours | Owner, management, IT; consider legal advice |
| Critical | Personal data exposed, money lost to fraud, agent acting on instructions from an outsider | Immediately, all hands | Management, IT, lawyer; bank and police where money or crime is involved |
When in doubt, classify one level higher. Downgrading later costs little; underreacting to a serious incident can cost a great deal.
Responding to an incident, step by step
Keep this list somewhere everyone involved can find it quickly.
- Stop the agent. Pause it or revoke its access. Do not try to “let it finish” the current batch.
- Preserve the evidence. Export logs, take copies of affected records and messages, note the time. Do not delete anything yet, even embarrassing drafts.
- Assess the scope. Which customers, records, files or payments were affected? Use the logs, not memory.
- Contain the damage. Recall or follow up on messages, correct records, cancel orders, change exposed passwords and keys.
- Inform the people affected. Tell customers or partners plainly what happened, what you have done and what they should do. Prompt honesty usually limits the harm to trust.
- Escalate where needed. For data exposure or financial loss, involve a lawyer; for fraud, contact the bank immediately and report to the police.
- Find the root cause. Classify it: compounding error, loop, wrong goal, changed input, manipulated content or bad configuration. The patterns in our guide on why AI agents fail are a useful checklist.
- Fix the design, not just the instance. Tighten permissions, add an approval, update the brief, add an alert. Then decide whether and when the agent restarts.
- Write it up. A short record of what happened, what was done and what changed. It protects the business and helps others learn.
A realistic example: forty wrong quotes
A furniture maker in Binh Duong (now part of Ho Chi Minh City) used an agent to prepare price quotes for trade customers from a price list and send them after a staff member approved a daily batch. One morning, a staff member updated the price list in a shared folder but left an old column of promotional prices in place. The agent read the wrong column. The approver, busy with a delivery problem, approved the batch after a quick glance. Forty customers received quotes well below the real prices.
The owner learned about it when a long-time customer called to place a large order at the quoted price. Because there was a written plan, the response took hours rather than days: the agent was paused, logs were exported, the affected customers were identified, and a short apology with a corrected quote was sent the same afternoon.
Several customers were unhappy, and the company chose to honour the wrong price for a small number of orders already confirmed, after taking advice on its obligations. The root cause was not the model but an ambiguous price list and an approval step that had become a formality.
The fixes were simple. The price list now has one clearly labelled column for the agent. Quotes that differ from the previous quote for the same item by more than a set percentage are flagged automatically. Approvals are scheduled for a quiet time of day, and the approver checks three random quotes in each batch.
What to check in a vendor contract
Data use and retention. Whether your data is used to train models, how long it is kept, and how you can request deletion.
Security commitments. What protections the vendor promises and whether they notify you of security incidents, and how quickly.
Logs and access to evidence. Whether you can export logs and how long the vendor keeps them, in case you need them for an investigation.
Responsibility and limits. What the vendor accepts responsibility for and the limits on their liability. These clauses often favour the vendor; know where you stand.
Changes to the service. Whether model updates and feature changes are announced in advance.
Subprocessors and data location. Which other companies handle your data and in which countries data is stored.
Exit terms. How you get your data back and how access is shut down if you stop using the service.
Have a lawyer read it. For tools that will touch customer data or core systems, a review by a lawyer is worth the cost.
Mistakes that make incidents worse
Letting the agent keep running while you investigate. The batch it is processing may contain more of the same error.
Deleting logs or drafts out of embarrassment. You lose the evidence needed to understand and fix the problem, and may breach obligations.
Blaming the tool in customer messages. Customers care that you take responsibility, not which software was involved.
Fixing only the visible case. If the root cause stays, the same error will return under a different form.
Silence toward affected customers. People usually discover the problem anyway; hearing it from you first preserves trust.
No one with authority available. An incident plan without a reachable decision-maker stalls at the worst moment.
Restarting the agent unchanged. Resuming without a design change invites a repeat.
When to call a lawyer or the authorities
Call a lawyer when personal data of customers or staff may have been exposed, when a customer threatens legal action, when you are unsure whether you must honour a wrong price or offer sent by the agent, or when a contract with a vendor or partner is involved. Rules on personal data, consumer protection and electronic transactions in Vietnam carry specific duties; a lawyer can tell you which apply now.
Contact your bank immediately if money left your accounts because of an agent’s action or because someone manipulated it. Speed matters: the sooner the bank knows, the better the chance of stopping or tracing a transfer.
Report to the police when fraud or a deliberate attack is involved, such as an outsider steering the agent through planted content to send data or money. Bring the logs and the evidence you preserved.
Inform the vendor in any serious incident. They may be able to provide additional logs, confirm whether other customers were affected, or fix a weakness in the product. Keep your own record of what you told them and when.
Making it safe for staff to report problems
Most agent incidents are first noticed by someone close to the work: the staff member who sees an odd reply, the accountant who spots a strange figure. Whether they speak up quickly depends on what happened the last time someone reported a problem.
If reporting leads to blame, people hesitate, try to fix things quietly, or assume someone else has noticed. Small errors then grow. If reporting is thanked and handled calmly, problems surface while they are still cheap.
Make reporting simple: one channel, one named person, and a promise that the first goal is to understand the system, not to find a culprit. Share short write-ups of incidents with the team, including what changed afterwards, so people see that reports lead to improvements. A team that hears about an agent’s near-misses early is a team that rarely has to deal with a serious incident.
Frequently asked questions
Can a business blame the AI vendor for an agent’s mistake?
Toward customers, usually not: they deal with your business. Between you and the vendor, responsibility depends on the contract and on whether the problem came from the product or from your configuration.
Do I have to honour a wrong price the agent sent?
It depends on the circumstances and applicable law, such as whether the customer could reasonably believe the price and whether an order was confirmed. Take legal advice and communicate quickly with the customers involved.
How long should agent logs be kept?
Long enough to investigate problems that surface late and to meet any legal or contractual duties. Decide a period with your lawyer or accountant, and store logs where the agent cannot alter them.
Is the person who approved the action at fault?
They share responsibility for what they approved, but if approvals were too frequent to review properly, the design is the bigger problem. Good incident reviews look at the system, not only at individuals.
Should small businesses have a written AI incident plan?
Yes, if any agent can act on customers, data or money. One page is enough: who to call, how to stop the agent, how to preserve evidence and how to tell customers.
What if someone outside manipulated our agent?
Treat it as a security incident: stop the agent, preserve logs, change exposed credentials, inform the vendor, contact the bank if money moved and report to the police. Then narrow the agent’s permissions before restarting.
