When an AI agent makes a mistake, the business that deployed it is usually the first party liable, because to the customer the agent is the business. Whether that business can pass the loss on to the model provider or agent platform depends mostly on the contract between them, which often limits the vendor's exposure. In the EU, the revised Product Liability Directive adds a second route: software, including AI systems, is now a product, and a defective one can create no-fault liability for the manufacturer. Across all of these routes, the party that can prove what the agent was allowed to do, and what it actually did, is in the stronger position.

This post is a practical map for engineering and risk leads, not legal advice. Liability rules differ by country and by contract, so confirm your position with counsel.

The deployer is liable first

A widely cited example is Moffatt v. Air Canada (2024), decided by the British Columbia Civil Resolution Tribunal. The airline's website chatbot gave a customer wrong information about a bereavement fare refund. The airline argued, in effect, that the chatbot was responsible for its own statements. The tribunal rejected that and held the airline liable for negligent misrepresentation; the chatbot was part of its website.

The principle carries over to agents. An agent that issues a refund, sends an email, changes a record or commits to a price is acting for the business that deployed it. Customers, counterparties and regulators will look to that business. "The model did it" is not a defence; it is an admission that the business let the model act.

Three routes to liability

Route Who can claim Against whom What must be shown What helps the defence
Contract A customer or partner with a contract The deploying business Breach of an express or implied term Clear terms, agent limits disclosed, actions within those limits
Negligence and other fault-based torts Anyone owed a duty of care Deployer, and sometimes vendor Duty, breach (unreasonable conduct), causation, damage Evidence of reasonable controls: scoping, approvals, monitoring
Product liability (EU, revised Directive) Natural persons who suffer covered damage Manufacturer of the defective product, and others in the chain A defect, damage, and a causal link, with presumptions available Proof the product met safety requirements and was not defective

National law decides most of the detail. The useful point for engineering teams is the right-hand column: every defence rests on records.

The new EU Product Liability Directive

Directive (EU) 2024/2853 replaces the 1985 Product Liability Directive. Member States must transpose it by 9 December 2026, and it applies to products placed on the market after that date. The changes that matter for AI agents:

  • Software is a product. The Directive explicitly includes software, and its recitals name AI systems. Free and open-source software developed or supplied outside a commercial activity is excluded.
  • No-fault liability for defects. A claimant does not need to show the manufacturer was careless, only that the product was defective and caused covered damage.
  • Covered damage. Death or personal injury, including medically recognised psychological harm; damage to property, excluding the defective product itself and property used exclusively for professional purposes; and destruction or corruption of data not used for professional purposes.
  • Updates and cybersecurity count. A product can be defective because of a lack of software updates or security updates within the manufacturer's control, and a substantial modification can make the modifier a manufacturer.
  • Easier proof for claimants. Courts can order the defendant to disclose relevant evidence. Defectiveness is presumed if the defendant fails to disclose, if the product breaches mandatory safety requirements, or if damage came from an obvious malfunction. Where technical complexity makes proof excessively difficult, defect or causation can be presumed if they are likely.

Two limits are worth noting. The Directive protects natural persons, so business-to-business losses mostly fall back on contract and national tort law. And it does not replace fault-based claims; it sits alongside them. A separate proposed AI Liability Directive, which would have added fault-based rules specific to AI, was announced for withdrawal in the Commission's 2025 work programme and formally withdrawn in October 2025.

Why the vendor rarely carries the loss

A deploying business often expects the model provider or agent platform to share the risk. Look at the contract first. Common patterns include liability caps tied to fees paid, exclusions for indirect or consequential loss, and terms that make the customer responsible for how outputs are used. Indemnities, where offered, often cover narrow risks such as intellectual-property claims over outputs, not operational mistakes.

Insurance is the other place people look, and it has gaps of its own. Our post on the AI agent cyber insurance coverage gap covers where standard policies stop. Regulated sectors face extra duties on top; see AI agent governance in the legal industry for one example.

How controls change the outcome

You cannot remove liability for an agent you deploy. You can reduce the chance of harm and strengthen your position when something goes wrong. Fault-based claims turn on whether you acted reasonably; product claims can turn on what you are able to disclose. Both reward the same evidence:

  • Scoped authority. The agent could only reach the tools and data its task needed. Overly broad access is hard to defend as reasonable.
  • Human approval for high-impact actions. Refunds above a threshold, external communications and record deletions waited for a named person.
  • Guardrails on inputs and outputs. Sensitive data was redacted and known-bad patterns were blocked.
  • A way to stop it. A tested kill switch, as covered in rogue AI agents and kill switches, shows you could contain harm quickly.
  • Records that hold up. A tamper-evident trail of what the agent did and who approved it. A court-ordered disclosure is far easier to answer when the audit trail holds up.

Liability readiness checklist

Where Praesidia fits

Praesidia does not shift legal liability; that stays with contracts and courts. It helps you build the record a defence depends on. It discovers the agents and MCP servers in use, so you know which ones can act. It secures the paths routed through it with guardrails that block, redact or warn, scoped MCP tool access, human-in-the-loop approvals and a kill switch. And it helps you prove what happened: decisions are recorded in an append-only, hash-chained audit trail, signed under the default configuration, which an auditor can verify offline without contacting Praesidia. A signed record shows it was not changed afterwards; it does not show that every action was captured, and calls that bypass Praesidia are not recorded.

FAQ

Can an AI agent itself be liable?

No. An AI agent has no legal personality. Liability falls on the people and companies that build, supply or deploy it.

Does the Product Liability Directive cover purely financial loss?

Not as such. Covered damage is death or personal injury, damage to certain property, and destruction or corruption of non-professional data. Pure economic loss is left to contract and national law.

Are we a manufacturer if we only configure a third-party agent?

Usually the deployer is not the manufacturer, but a substantial modification of a product can make the modifier one. Where you build and ship an agent to others, assume you may be.