Who Is Liable for AI Agent Decisions? Accountability in 2026
Who is liable for an AI agent's decisions? Toward your customer and the law, the company that deploys the agent is liable, not the model and not the model vendor. \"The AI made a mistake\" is not a defense. Since the liability is yours, you need an architecture of accountability: boundaries, an audit trail, escalations, and least privilege.
For an AI agent's decision, the party liable toward your customer and toward the law is the company that deploys the agent, meaning you. Not the model and not the model vendor. "The AI made a mistake" is not a defense, only a description of the event. Since the liability is yours, the only sensible question is: how do you build the agent so that it cannot do the thing you do not want to answer for?
Who is actually liable for an AI agent's decision
The company that deploys the agent is liable. That is the shortest honest answer. When the agent sends a customer wrong information, changes a record, or makes a decision in your name, your customer holds you accountable, not the model vendor and not the implementation partner.
It helps to separate three levels, because they blur in conversation:
- The model vendor (the maker of the language model) is responsible for the model under its own license terms, usually with broad disclaimers about how it is used.
- The implementation partner is responsible for the quality of what it built: whether the system works as agreed, whether the boundaries were implemented, whether the trail is complete.
- The deploying company is liable for the outcome toward its customer and for legal compliance. That liability cannot be assigned away by any clause, because it was your brand that sent the email and your process that changed the data.
The rest of this piece follows from that one fact. Since the risk stays with you, you are not buying "intelligence," you are buying a set of boundaries around it.
"The AI made a mistake" is not a defense
That sentence does not protect a company, because the law and the customer do not ask what the model did, they ask what the company failed to do. A model has no legal standing: it does not sign contracts, does not bear costs, does not face the customer. The party who decided to use it in a given process, on given terms, is the party liable.
It works like any other tool or subcontractor. If your employee errs on an invoice, you do not tell the customer "the calculator did it." You answer for the outcome and for the safeguards you had in place. An AI agent is the same, with one difference: it acts faster and at larger scale, so the absence of boundaries costs faster.
Hence the conclusion that changes the whole conversation. Since "the AI made a mistake" defends nothing, stop asking whether the model can be trusted and start asking what it is even able to do inside your system. Trust is not a property of the model. It is a property of the architecture you build around it.
The accountability architecture: four elements
Liability toward the customer is yours, so you build it with engineering, not with a declaration. Four elements do the work.
Boundaries: what the agent may not do on its own. Before you decide what the agent does, you decide what it does not do without a human. Sending to a customer, changing production data, a financial decision: these are gates, not default actions. A boundary written into configuration is worth more than one written into the model's instructions, because it holds even when the model gets it wrong.
The trail: what happened and why, reproducibly. If after the fact you cannot reconstruct what the agent did, on what data, and why, it is not an agent, it is a roulette wheel with a nice interface. Without a trail you cannot even establish whether the error was yours, the vendor's, or the input data's.
Escalations: when the agent stops and calls a human. A good agent knows what it does not know. On low confidence, an unusual case, or a high-impact action, it stops and hands the matter to a human instead of guessing. That is not a weakness, it is its most important part.
Least privilege. The agent gets exactly as much access as the task needs, and not one privilege more: a separate technical account, no access to production, irreversible actions only with approval. This shield works regardless of how good or bad the model is on a given day. More on error-limiting techniques is in the piece on AI hallucinations and how to limit them, and on attacks against privileges in the piece on prompt injection in agent work.
"An AI agent deleted the database": what that story really means
Such stories almost never mean the model is bad. They mean someone granted broad privileges without boundaries. The agent that wiped the database had full access on an account with delete rights, and nobody put a gate on the irreversible action. The model was the last link here, not the cause.
The answer is not the reassurance "our model would not do that," a promise with no backing. The answer is a design in which such a deletion is technically impossible:
- the agent runs on a separate technical account, with read-only rights wherever that is enough,
- it has no access to the production environment, only to the layer it is allowed to change,
- irreversible actions (deletion, bulk change, a transfer) require explicit human approval or are blocked entirely.
An agent that simply CANNOT delete the database will never delete it, no matter what it "comes up with." That is the difference between reassurance and engineering. You are buying the latter.
Who is liable for what: a short map
The table below organizes typical situations. It does not replace a contract or a lawyer's opinion, it shows where liability sits before you sit down to draft.
| Decision or incident | Who is liable toward your customer | What it means in practice |
|---|---|---|
| Agent sent the customer a wrong reply | Deploying company (you) | You need a send gate and a trail; "it was the model" does not defend |
| Agent changed the wrong record in CRM/ERP | Deploying company (you) | Least privilege and exception validation limit the impact |
| Agent deleted data because it had access | Deploying company, but it is a privilege-design failure | No production access and approval for irreversible actions |
| System did not work as agreed | Implementation partner (quality of work) | Scope and boundaries must be written down to be enforceable |
| Model returned a result within license, but poor | Model vendor on its contract terms | The architecture around the model (trail, escalation) catches the impact |
Sharing responsibility with the vendor: what to put in the contract
Since liability toward the customer stays with you, the implementation contract should clearly split what can be split. Four things belong in it:
- Scope and boundaries in writing: what the agent does and what it does not do without a human, at the level of configuration, not of a promise.
- The trail as a deliverable: a complete, reproducible record of actions is part of acceptance, not a nice extra.
- Maintenance and incident response: who responds, within what time, and what happens when something goes wrong after launch. We break this down in the piece on AI agent maintenance after deployment.
- System access: on what accounts and privileges the agent works, who grants and revokes them.
What no vendor can honestly take over: liability toward your own customer. The vendor answers for the quality of the work. Whether your process runs and your brand did not fail the customer is on you, which is why boundaries and a trail are in your interest. If you want to sort out this picture on one process first, it starts with an AI process audit.
The AI Act: what it imposes and on whom, without panic
The AI Act places obligations on two sides at once: on providers of AI systems and on the deployers that use them. That cements exactly the split this piece is about: by deploying an agent, you are a party with your own obligations, not merely the recipient of someone else's tool.
A few facts worth knowing, and one sentence of caution:
- The AI literacy obligation (Article 4), that is, ensuring the people operating AI systems understand how they work and their risks, has applied since 2 February 2025.
- Systems classified as high-risk carry additional requirements: human oversight, documentation, and risk management, with transition periods staggered over time.
- Most other general obligations phase in through 2026 and beyond.
This is not legal advice. Treat these points as input to your own documentation and consult a lawyer on the specific case. The aim is practical: the accountability architecture you are building anyway for operational reasons (boundaries, trail, human oversight) is at the same time what such regulations expect. You do one piece of work, not two.
When NOT to automate
Honestly: some processes should not go to an agent, even if it is technically possible.
- Irreversible effects with no review. If a decision deletes something permanently, moves money, or changes data that cannot be undone, and a human cannot fit into it as a gate, do not fully automate it.
- A process with no named rules. If the rules live in someone's head and change every week, an agent will only cement the chaos. Write the process down first, then automate it.
- You are looking for a system "no one is liable for." That system does not exist. Someone is always liable toward the customer, and if you do not want that someone to be you, it means you are not ready to automate this process yet.
If any of these fits your situation, we will say so plainly at the scan, before you spend anything.
FAQ
Who is liable for an AI agent's decisions?
Toward your customer and toward the law, the company that deploys the agent is liable, meaning you. The model vendor is responsible for the model under its own contract, and the implementation partner for the quality of what it built, but neither takes over liability toward your customer. That is why "the AI made a mistake" is not a defense, only a description of the event.
Can an AI agent delete a database by itself?
Only if it has the privileges to do so. Stories about a wiped database usually mean someone granted broad access without boundaries. An agent that runs on a separate technical account, has no access to production, and performs irreversible actions only with human approval simply CANNOT delete the database. It is a matter of privilege design, not trust in the model.
What should the implementation contract say about liability?
A written scope and boundaries (what the agent may not do on its own), the audit trail as a deliverable, maintenance and incident-response terms, and system access conditions. The vendor is liable for the quality of what it built. Liability toward your own customer cannot be assigned to a vendor by any clause.
What does the AI Act say about liability for an AI agent?
The regulation places obligations on both providers of AI systems and on deployers that use them, and high-risk systems carry human-oversight and documentation requirements. The AI literacy obligation (Article 4) has applied since 2 February 2025. This is not legal advice: treat these materials as input to your own documentation and consult a lawyer.
How to start
The cheapest sensible first step is to name one process and check where the risk actually sits in it.
- Write down one process you want to hand to an agent, and mark the irreversible actions in it.
- For each one, answer: who is liable toward the customer, what boundary stops it, what trail remains.
- Check whether the agent runs on a separate account and has no access to production.
- Book a call where we go through it together and say honestly what is worth doing and what is not.
Book a free process scan | AI process audit | Maintenance