Who is liable when an AI agent makes a mistake?

There is a recurring instinct, when an autonomous system causes a loss, to treat the system as the actor and ask whether it can be held responsible. European and common-law systems answer the same way: it cannot. An AI agent has no legal personality, holds no assets, and cannot be a defendant. Responsibility flows through the agent to the people and the organisation that chose to deploy it. The interesting work is not deciding whether a business is responsible. It is deciding which business, in a chain of several, and on what legal basis.

Why the agent itself is never the answer

The starting point is the one most commentary skips. An AI agent is not a legal subject. It cannot own property, cannot be insured in its own name, and cannot be a defendant in proceedings. When a model produces a confident but false statement that a customer relies on, the loss is real, but the entity that caused it in any legal sense is the one that placed the agent between itself and that customer. The law treats the agent the way it treats any instrument a business uses: a delivery van, a pricing algorithm, an outsourced call centre script. The business answers for the instrument.

This is why the question "who is liable when an AI agent makes a mistake" resolves, in the first instance, to "which business deployed it." The harder version of the question only appears when more than one business is involved in producing the agent, which is now the normal case.

The two cases that already settle the principle

Two decisions, neither of them an AI Act ruling, already establish how courts treat an AI mistake. They are worth stating precisely because they are the proof that the principle is not theoretical.

In Moffatt v. Air Canada (2024 BCCRT 149), a customer asked Air Canada's website chatbot about bereavement fares. The chatbot told him he could book at full price and claim a partial refund within 90 days. That policy did not exist. When the customer claimed the refund, the airline refused and argued, among other things, that the chatbot was a separate legal entity responsible for its own actions. The British Columbia Civil Resolution Tribunal rejected that argument directly, holding that Air Canada was responsible for all the information on its website, whether from a static page or a chatbot, and that it was the airline's duty to ensure the chatbot was accurate. The airline was ordered to compensate the customer. The case is small in value and large in principle: a business cannot disclaim its own automated agent.

In Mata v. Avianca (S.D.N.Y. 2023, case 22-cv-1461), lawyers submitted a court filing that cited cases which did not exist, because they had used ChatGPT to draft it and had not checked the output. The court sanctioned the lawyers. The model's fabrication became the professionals' responsibility, because they had adopted its output as their own work product. The lesson generalises beyond law firms: when a business relies on an AI output and passes it on as its own, the error is the business's error.

The European liability chain: provider, deployer, and the parties between

Modern AI deployments rarely involve one party. A foundation model provider trains and offers the base model. An integrator builds an application on top of it, with retrieval, tool access, and fine-tuning. A deployer puts the finished application in front of users. The EU AI Act, Regulation (EU) 2024/1689, allocates duties along that chain by role, and the revised Product Liability Directive, Directive (EU) 2024/2853, allocates civil liability for defects at the end of it.

Article 3(3) defines the provider as the party that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. Article 3(4) defines the deployer as the party that uses an AI system under its own authority in the course of a professional activity. For most businesses running a bought-in agent, the deployer role is the one they occupy, and it is the role that meets the customer.

The duties differ by role. A provider of a high-risk system must complete conformity assessment under Articles 43 to 48, maintain the technical documentation under Article 11 and Annex IV, affix the CE marking, register the system, and run post-market monitoring under Article 72. A deployer of a high-risk system must, under Article 26, use the system within the provider's instructions, assign competent human oversight under Article 14, keep the automatically generated logs that Article 12 requires the system to produce, monitor operation, and report serious incidents under Article 73. The provider's duties are largely discharged once, before market. The deployer's duties are continuous, for as long as the system runs.

When a deployer becomes the provider: Article 25

The most important boundary in the chain is Article 25, because it is where a business that thinks of itself as a mere user is reclassified as a provider and inherits the heavier obligations. A deployer is treated as the provider, with all that implies, in three situations: it places a high-risk system on the market under its own name or trademark; it makes a substantial modification to a high-risk system; or it changes the intended purpose of a system so that the modified system becomes high-risk. Recital 66 frames substantial modification as any change affecting the system's compliance or altering the purpose for which it was assessed.

In practice this catches the business that takes a general model, fine-tunes it on its own data, brands the result as its own product, and deploys it into hiring, credit, or another Annex III use. The test, as the courts and the Act both frame it, is the effect of what the deployer did, not whether it intended to take on the provider's role. A full reading of how this allocation works across every party sits in the AI liability chain analysis.

Two engines of liability, running in parallel

A frequent confusion is to treat the AI Act as the instrument that makes a business pay when its agent harms someone. It is not. The AI Act is a product-safety and governance regime. Compensation to a harmed person comes from a separate civil track. Understanding "who is liable" means seeing that two distinct engines run at the same time over the same incident.

The regulatory engine is the AI Act's penalty regime under Article 99. Breaches of the prohibited-practice rules in Article 5 can draw fines up to 35 million euro or 7 percent of global annual turnover. Breaches of other obligations, including the deployer duties in Article 26, can draw up to 15 million euro or 3 percent. Supplying incorrect or misleading information to authorities can draw up to 7.5 million euro or 1 percent. These are administrative fines paid to the state, not compensation to the customer.

The civil engine is where the harmed customer recovers. It runs on national tort and contract law and, for products placed on the market after 9 December 2026, on the revised Product Liability Directive. A single incident can fire both engines: a business can owe a regulatory fine for an oversight failure and civil damages to the person harmed by the same failure, with no double-counting between them because they answer to different claimants.

The revised Product Liability Directive: strict liability reaches AI

Directive (EU) 2024/2853 is the civil-side change that matters most for AI. It entered into force on 8 December 2024, with national transposition due by 9 December 2026, and it applies to products placed on the market or put into service after 9 December 2026. The previous regime, Directive 85/374/EEC, continues to govern products placed on the market before that date. Three features reshape AI exposure.

First, it brings software and AI systems expressly inside the definition of a product, so a defective AI system can ground a strict-liability claim. The claimant does not have to prove the business was at fault, only that the product was defective and caused the damage. Free and open-source software supplied outside a commercial activity is excluded.

Second, it eases the claimant's burden of proof. Where the technical or scientific complexity makes it excessively difficult to prove defectiveness or causation, courts may apply rebuttable presumptions, and the claimant has a right to disclosure of relevant evidence. For opaque, hard-to-explain AI systems, this shifts the practical burden toward the defendants, who must then show where the defect was not.

Third, it widens recoverable damage beyond death, personal injury, and property damage to include destruction or corruption of data, and medically recognised psychological harm. The double exposure this creates alongside the AI Act is treated in full in the double-exposure briefing, and the directive itself in the Product Liability Directive 2024 analysis.

A decision aid: who pays in five common situations

The chain becomes concrete when applied to recognisable scenarios. The table reads the first-line liability, which is to the harmed person, and notes where recourse against another party may follow. It is a guide to the structure, not legal advice on any specific facts.

The constant across every row is that the deployer meets the claim first, because the deployer has the direct relationship with the harmed person. Recovery from anyone upstream depends on the contract, the documentation, and the facts of the failure. Neither the AI Act nor Directive 2024/2853 makes that recovery automatic.

What evidence reduces exposure

Because the deployer carries the first claim, the practical question for a business is not whether it is liable in principle but how exposed it is on the facts. Exposure is decided by evidence, and most of the evidence that helps is the same evidence the AI Act already requires a high-risk deployer to hold. Five records do most of the work.

• A risk record. Documentation that the system was assessed for foreseeable risks before deployment, and that the deployment decision was deliberate. This is the difference between an incident that looks managed and one that looks negligent.
• An oversight register, aligned to Article 14. A named, competent person responsible for the agent, with a record that review actually happened. Article 14 requires effective human oversight for high-risk systems; the register is what shows the oversight was real rather than nominal, which is the line that separates a professional-services error from an uncontrolled autonomous loss.
• An instructions-for-use map. The provider's instructions, and a record showing the deployment stayed inside them. This is the document Article 26 turns on: a deployer operating outside the provider's stated boundaries is in breach from day one, while one operating inside them has a defence and a recourse route.
• Operation logs. Article 12 requires high-risk systems to keep automatically generated logs. These are what let a party rebut a causation presumption under the Product Liability Directive, by showing what the system actually did at the relevant moment instead of leaving the court to presume.
• An incident protocol, meeting Article 73. A defined process for detecting, escalating, and reporting serious incidents within the Act's deadlines. A clean, timely response narrows both the regulatory and the civil exposure; a missed report can become a separate breach.

This is the documentation architecture set out in full in how to document AI agent risk management for compliance, and the minimum operator file in the operator obligations guide. Held in advance, these records turn an open-ended liability into a bounded, defensible one. Assembled after an incident, they are worth far less.

Where insurance fits, and where it currently does not

Many businesses assume an existing policy will absorb an AI agent loss. Often it will not. Errors and omissions, professional indemnity, cyber, and general liability policies were written before autonomous agents existed, and through 2026 insurers are adding explicit AI exclusions at renewal. Professional indemnity or errors and omissions is the best existing chance, and usually only where a human stayed in the loop, which is one more reason the oversight evidence above matters. The arrival of strict product liability on 9 December 2026 sharpens the problem: a business can become more exposed under the Product Liability Directive at the same moment its insurer is narrowing cover for the risk.

Purpose-built cover has begun to appear. ElevenLabs secured the first AIUC-1-backed AI agent policy in February 2026, certifying the agent against an adversarial assessment standard before cover attached. The market for deployer-facing AI agent liability cover in Europe is early and uneven; a current reading of what exists and what does not is kept at Agent Insured's briefing on European enterprise AI liability coverage. The practical instruction is simple: check existing policies for an AI exclusion before the next renewal, not after a loss.

Related reading

For how liability is allocated across every party in the supply chain, see the AI liability chain analysis. For the civil exposure created by the revised directive, see the Product Liability Directive 2024 briefing and the double-exposure briefing. For the deployer's operational duties, see the Article 26 deployer guide. For the human-oversight evidence that decides how a loss is characterised, see the Article 14 human oversight guide.