Who Is Liable When an AI Agent Makes a Mistake in 2026?

An agent you deployed emailed a customer the wrong refund amount. Who is liable when an AI agent makes a mistake is a question with a boring answer: a person or a company, never the software. The interesting part is which one, and that is decided by your role, your records, and a contract somebody signed without reading the indemnity clause.

Can you argue that the agent acted on its own?#

In California, no. Assembly Bill 316 was signed on 13 October 2025 and took effect on 1 January 2026, and it bars a defendant who developed, modified or used an AI system from arguing as a defence that the AI autonomously caused the harm. Other defences survive; that specific one does not.

The bill is short and its target is narrow, which is what makes it useful to read. It does not decide who wins. It removes one argument from the table, and the argument it removes is the one most builders instinctively reach for when something goes wrong in an autonomous system.

The direction of travel elsewhere is similar even where no statute says so explicitly. Liability frameworks are built around legal persons who owe duties, and software is not one. Every route to a finding runs through somebody who designed, sold, configured or operated the thing, so "the model hallucinated" describes the mechanism rather than transferring the responsibility.

Status column matters more than the name. Two of these are commonly cited as though they say the opposite of what they say.

Treat this as the base case for any system you ship. The agent is not a party. You, your vendor, or your customer will be, and which of those it is depends on the next question.

Which role are you in, provider or deployer?#

The distinction the EU AI Act draws is between the party that develops or places a system on the market and the party that uses it under its own authority. Most teams building on someone else's model are deployers of that model and providers of their own product, at the same time, and the duties differ for each.

Being both is normal and it is where confusion starts. You are a deployer with respect to the model vendor, so you carry obligations around how you use and oversee the system. You are a provider with respect to your own customers, so you carry obligations for the thing you built on top, including how it behaves when the underlying model changes.

That dual role has a practical consequence people miss. A model provider's terms may allocate risk to you as their customer, while your terms allocate risk to your customer, and the two allocations are unlikely to line up neatly. The gap between them is yours by default.

Both columns describe one team on one product. The terms governing each side are written by different people.

What happened to the EU's AI liability rules?#

They were withdrawn, and this is the fact most often gotten wrong. The AI Liability Directive proposed in 2022 was listed for withdrawal in the Commission's February 2025 work programme and formally withdrawn, with the notice published in the Official Journal on 6 October 2025. It never became law.

What did pass is the revised Product Liability Directive, adopted in October 2024, which extends strict product liability to software and AI systems. Strict liability means a claimant does not have to prove you were careless, only that the product was defective and caused damage. That is a meaningfully different exposure from a negligence claim.

The withdrawal left a gap rather than a freedom. Fault based claims fall back to national tort law across member states, which is exactly the fragmentation the withdrawn directive was meant to fix. So the practical position is stricter in one direction and less predictable in the other.

Read the right column as the planning assumption. Nothing here depends on a case being decided, because these are the instruments as they currently stand.

What does your contract actually say about this?#

Usually that the customer is responsible for compliance, while the supplier controls the behaviour that determines whether compliance is possible. That mismatch is the liability gap in agentic deployments, and it is normally invisible until an agent does something nobody wrote a clause for.

Read your vendor terms for three things specifically. What the vendor warrants about output, what it excludes, and what the cap on its liability is relative to what you have promised your own customers. A cap set at 12 months of fees is common and is unrelated to the size of the harm an autonomous system can cause.

The test is one specific decision from weeks ago, not the average. Aggregates answer a different question.

The asymmetry is not always unreasonable, because a vendor genuinely cannot control what you build. It just needs to be a decision rather than a discovery. If you are carrying the gap, price it or insure it.

What should you build so the question has an answer?#

A record that survives the incident. Almost every route to a defence depends on showing what the system was told, what it decided, what a person approved, and when. Systems that cannot reconstruct that are in a much weaker position regardless of how well they performed on average.

The useful mental test is whether you could reconstruct one specific decision from 6 weeks ago. Not aggregate metrics, one decision: the prompt, the retrieved context, the tool calls, the output, and whether a person saw it. If the answer is no, the record is a dashboard rather than evidence. Tracing every call covers the mechanics.

Preservation comes before analysis. Retention windows delete the evidence while people are still deciding what happened.

Scope of authority matters as much as logging. An agent permitted to draft is a very different risk from one permitted to send, refund or delete, and the boundary should be written down before it is discovered. Deciding what an agent may do alone is a design decision with legal consequences.

Who ends up carrying it in practice?#

Whoever controlled the decision and cannot show they exercised oversight. That is not a legal test in any single statute, but it is the shape most frameworks converge on: control plus foreseeability, minus whatever you can evidence about the guardrails you actually operated.

All three inputs are set before the incident, when they are cheap. Afterwards they are fixed.

Liability follows the reporting line. An agent nobody is drawn above is an agent nobody answers for. The reassuring part is that all three inputs are things you decide rather than things that happen to you. Scope of authority, quality of record, and contractual allocation are set before anything goes wrong, and they are cheap then. After an incident, all three are fixed and only the arguing is left.