Short answer

  • When an AI agent fails, the business that deployed it usually pays the harmed customer, not the foundation model provider. The deployer chose the agent, put it in front of customers, and authorised it to act, so under ordinary agency and contract principles the deployer answers to the person harmed.
  • The model provider normally has no direct legal link to that customer. Its exposure is upstream and contractual (duties owed to the deployer it licensed the model to) plus, in the EU, distinct statutory duties as a provider under the AI Act (Regulation (EU) 2024/1689).
  • A claimant can sometimes also reach a maker in the chain through product liability. From 9 December 2026 the revised Product Liability Directive (Directive (EU) 2024/2853) brings AI systems inside strict, no-fault liability and eases the burden of proof. But the front-line payer is the deployer.

"The AI did it" is not a defence. When an autonomous agent makes a costly mistake, the law does not let the deploying business point at the model and walk away, and it rarely lets the harmed customer reach past that business to the model's maker. This analysis maps the full multi-party chain (foundation model provider, fine-tuner, deployer, user), shows how the EU AI Act splits provider and deployer duties, explains where the revised Product Liability Directive changes the picture from December 2026, and looks at where the courts are already testing it.

The four parties in the chain

Most AI agent deployments involve four distinct parties. Liability questions become tractable only once you can name which is which, because the law attaches different duties and different exposure to each role.

The foundation model provider. This is the organisation that builds and supplies the general-purpose model that sits underneath the agent, typically a large language model accessed through an API or licence. It supplies a capability, not a finished application. It rarely knows or controls the specific use a downstream business puts the model to.

The fine-tuner or integrator. This is the party that adapts the general-purpose model and assembles the agent: adding tools, retrieval, system prompts, guardrails, and the workflow that lets the model take actions. Sometimes this is a separate vendor. Often it is the deploying business itself. This role matters disproportionately, because building an agent on top of a model is frequently the act that shifts legal responsibility, as the AI Act sections below explain.

The deployer. This is the business that puts the agent into use under its own authority and, usually, its own brand, to serve its customers or run its operations. In EU AI Act language the deployer is the natural or legal person using an AI system under its authority, except where the system is used in a personal non-professional activity. The deployer is the party the outside world deals with.

The user. This is the customer, claimant, or member of the public who interacts with the agent and may be harmed by what it does: a passenger told the wrong refund rule, a client given wrong advice, a person whose data the agent exposed. The user is who the liability question is ultimately about.

Liability runs along this chain in two directions that are easy to confuse. Between the commercial parties (provider, integrator, deployer) it runs through contracts: licences, service agreements, warranties, indemnities, and liability caps. Toward the harmed user it runs through statute and tort: agency, negligence, consumer protection, data protection, and product liability. The single most common operator error is to assume the contractual chain and the tort chain point the same way. They do not. The user almost always sues the business it dealt with, and that business then has to try to recover up its own contract chain, which is a separate fight it may lose.

The default rule: the deployer faces the customer

Start with the position before any AI-specific instrument applies, because it is still the position that decides most disputes. An AI agent is a tool a business chooses to use. When a business uses a tool to deal with the public and the tool causes harm, the business is answerable for that harm. This is not novel law. It is ordinary agency and the ordinary duty to take reasonable care in how you serve customers, applied to a new kind of tool.

The reason the model provider usually sits outside this is structural. The harmed customer has no contract with the provider, never chose the provider, and in most cases does not know which provider's model was involved. There is no relationship for a claim to travel along. The provider's counterparty is the deployer that licensed the model, and the duties the provider owes flow to that deployer under their agreement, not to the deployer's customers.

This is why the recurring corporate argument that the AI system is somehow a separate actor responsible for its own conduct has failed every time it has been tried. An agent is not a legal person. It cannot hold duties, cannot be sued, and cannot carry liability. The duties stay with the humans and companies around it, and the closest of those to the customer is the deployer.

How the EU AI Act allocates duties: provider versus deployer

The EU AI Act (Regulation (EU) 2024/1689) is the instrument most often invoked in this debate, so it is worth being precise about what it does and does not do. The Act is a product-safety style regulation. It allocates obligations across roles and backs them with administrative penalties. It is not a civil liability statute. It does not, by itself, decide who compensates a harmed person. That question is left to national civil law and, from December 2026, to the revised Product Liability Directive discussed below. Keep that distinction in mind: the AI Act tells you who must do what to be compliant, not who writes the cheque after a loss.

Within that frame, the Act draws a clear line between the provider and the deployer of a high-risk AI system.

The provider carries the design and documentation duties

The provider of a high-risk AI system carries the heavy front-end obligations, set out chiefly in Articles 16 to 21. The provider must establish a risk management system (Article 9), meet data governance standards (Article 10), prepare technical documentation (Article 11), design in logging (Article 12), ensure transparency to deployers (Article 13), build in human oversight capability (Article 14), and meet accuracy, robustness, and cybersecurity requirements (Article 15). The provider runs the conformity assessment (Article 43), draws up the EU declaration of conformity, affixes the CE marking, and registers the system. These are the duties of the party that designs and places the system on the market.

The deployer carries the operational duties

The deployer's obligations sit principally in Article 26. The deployer must use the high-risk system in accordance with the provider's instructions for use, assign human oversight to competent people, ensure that input data is relevant and sufficiently representative where the deployer controls that data, monitor operation and suspend use and inform the provider if it identifies a risk, keep the automatically generated logs, and inform affected persons where the Act requires. Where Article 27 applies, certain deployers (public bodies and some private deployers in defined contexts) must complete a fundamental rights impact assessment before the first use. Article 50 adds transparency duties from 2 August 2026: telling people they are interacting with an AI system, and labelling AI-generated or manipulated content. Article 4, in force since 2 February 2025, already requires deployers to ensure a sufficient level of AI literacy among the staff operating their systems.

The Article 25 trap: a deployer can become a provider

Here is the provision that catches most AI agent builders, and the reason the model provider often sits further from liability than operators expect. Under Article 25, a deployer, distributor, or other third party is treated as a provider of a high-risk AI system, and assumes the provider's obligations, in three situations: if it puts its own name or trademark on a high-risk system already placed on the market, if it makes a substantial modification to such a system, or if it modifies the intended purpose of a system so that the system becomes high-risk. The original provider must then cooperate, but the obligations shift.

Building an AI agent very often triggers this. A business that licenses a general-purpose model, fine-tunes it, wraps it in tools and a workflow, brands the result as its own product, and ships it to customers has, on a plain reading, both put its name on a system and modified it. It is then carrying provider obligations on top of its deployer obligations. The foundation model provider, meanwhile, supplied a general-purpose model and carries the GPAI duties below, which are real but sit upstream of the deployer's customer. The structure of the Act pushes responsibility toward the party closest to the deployed use, which is usually the operator.

What the foundation model provider does owe under the Act

The foundation model provider is not off the hook, but its duties are owed to the regulator and to downstream integrators, not directly to the deployer's end customers. Providers of general-purpose AI (GPAI) models carry obligations under Chapter V, in force since 2 August 2025. These include maintaining technical documentation, supplying information and documentation to downstream providers who integrate the model so those parties can comply, putting a policy in place to respect EU copyright law, and publishing a sufficiently detailed summary of the content used for training. Providers of GPAI models with systemic risk carry additional duties: model evaluation including adversarial testing, assessment and mitigation of systemic risks, serious-incident tracking and reporting, and adequate cybersecurity. A provider that fails these can face penalties and can hand a downstream claimant useful material for a negligence or product-defect argument, but the obligations do not by themselves create a direct compensation claim for the end user.

Penalties, not damages

Breach of these duties is enforced through Article 99. The maximum administrative fines are up to EUR 35 million or 7 per cent of total worldwide annual turnover for prohibited-practice breaches (Article 5), up to EUR 15 million or 3 per cent for breaches of other obligations including most provider and deployer duties, and up to EUR 7.5 million or 1 per cent for supplying incorrect or misleading information. These are regulatory penalties paid to the state. They are not compensation to the harmed customer. A company can be fully compliant with the AI Act and still owe damages to a customer under ordinary civil law, and it can breach the AI Act and face a fine while a separate civil claim proceeds in parallel.

The crucial distinction. The AI Act answers "who must do what, and who the regulator fines." Civil liability answers "who pays the harmed person." The deployer often carries both: provider-style duties under Article 25 because it built the agent, deployer duties under Article 26 because it runs it, and the front-line civil exposure because it is the party the customer dealt with. The foundation model provider typically carries GPAI duties to the regulator and contractual duties to the deployer, but sits behind a wall of contract and lack of direct relationship when it comes to the end customer.

What changes on 9 December 2026: the revised Product Liability Directive

The picture shifts in the customer's favour, and toward the makers in the chain, when the revised Product Liability Directive takes effect. Directive (EU) 2024/2853 was adopted and entered into force on 8 December 2024. Member States must transpose it into national law by 9 December 2026, and it applies to products placed on the market or put into service after 9 December 2026. The old Directive 85/374/EEC continues to govern products placed on the market before that date.

Three features make it central to AI agent liability. First, it expressly brings software and AI systems within the definition of a product, closing the long-standing argument that software is a service rather than a product and so falls outside product liability. Second, it imposes strict, no-fault liability on the manufacturer of a defective product: the claimant does not have to prove the manufacturer was negligent, only that the product was defective and caused the damage. The maker of a defective AI system or a defective component can be a manufacturer for this purpose. Third, it eases the claimant's burden of proof through rebuttable presumptions of defectiveness, including where a product is technically complex or opaque and the claimant faces excessive difficulty proving the defect, which is squarely aimed at the black-box character of AI. It also expands compensable damage to include the loss or corruption of data and medically recognised psychological harm. Free and open-source software supplied outside the course of a commercial activity is excluded.

The practical effect for the chain is real. After December 2026, a customer harmed by a defective AI agent has a route to a manufacturer in the chain, which can include the maker of the system or a defective component, without proving fault. This is the clearest mechanism by which a maker (potentially including a foundation model provider, where its model is found to be the defective component supplied as part of the product) can be pulled into a claim. It does not displace the deployer's exposure. The deployer remains liable in parallel under contract, agency, negligence, the AI Act duties, and consumer law. The Directive widens the field of who can be sued; it does not move the deployer out of it.

A decision aid: who carries what

The table below summarises where each role sits across the instruments that matter. It is a map, not legal advice for a specific dispute, and the allocation in any real case turns on the contracts and the facts.

Who carries what across the AI agent liability chain (EU frame, mid-2026)
Party Faces the harmed customer directly? EU AI Act role and duties Revised PLD exposure (from 9 Dec 2026) Main contractual lever
Foundation model provider Rarely. No direct relationship with the end customer. GPAI obligations under Chapter V (documentation, downstream information, copyright policy, training summary; systemic-risk duties if applicable). Possible, as a manufacturer of a defective component, if its model is the defective part supplied within the product. Model licence and API terms: as-is supply, warranty disclaimers, low liability caps, deployer indemnity.
Fine-tuner or integrator Sometimes, if it contracted directly with the customer; often it is the deployer. Often a provider under Article 25 (substantial modification, name on the system) plus any deployer duties it holds. Likely, as manufacturer of the AI system it built and placed on the market. Build or vendor agreement: warranties, service levels, indemnities, caps between it and the deployer.
Deployer (the operating business) Usually yes. The party the customer dealt with. Article 26 operational duties; Article 27 FRIA where it applies; Article 50 transparency from 2 Aug 2026; Article 4 literacy. Often also a provider under Article 25. Exposed in parallel under contract, agency, negligence, and consumer law; may also be a manufacturer if it built the system. Customer terms upstream; vendor and model contracts downstream (its route to recover, if any).
User (customer or public) Is the claimant. Protected party; in some cases owed transparency and information under Articles 26 and 50. Beneficiary: strict liability and eased proof against the manufacturer. Contract with the deployer (consumer or commercial terms).

Where the courts are testing the chain

No court has yet decided a damages claim under the EU AI Act or the revised Product Liability Directive, because the relevant obligations and the Directive itself are still phasing in. What we have are existing-law cases that already test the core question of who answers for an AI system's output. They are decided under ordinary contract, tort, and professional-conduct rules, and they point consistently in one direction: to the deployer and the humans who relied on the output.

Moffatt v. Air Canada: the deployer answers for its chatbot

The clearest decision is Moffatt v. Air Canada (2024 BCCRT 149), from the British Columbia Civil Resolution Tribunal. Air Canada's website chatbot told a grieving passenger he could claim a bereavement fare retroactively. That was wrong; the airline's actual policy did not allow it. Air Canada argued, in substance, that the chatbot was a separate legal entity responsible for its own statements and that it should not be bound by what the chatbot said. The tribunal rejected that argument directly. It held that Air Canada was responsible for all the information on its website, whether the information came from a static page or an interactive chatbot, and that it owed a duty to take reasonable care that the information was accurate. The deployer paid. The maker of the chatbot was nowhere in the customer's claim; whether the vendor owed anything back to Air Canada was a separate, upstream question the passenger's case never had to reach. This is the canonical illustration that the deployer, not the agent's maker, faces the customer.

Mata v. Avianca: the human who relied on the output is responsible

In Mata v. Avianca (22-cv-1461, S.D.N.Y. 2023), lawyers filed a brief citing cases that a generative AI tool had fabricated. The court sanctioned the lawyers, not the tool's maker. The responsibility attached to the humans who chose to rely on the output without verifying it. For the agent chain this makes two points concrete: the law attaches responsibility to the party that deployed and relied on the output, and an absent human check is treated as that party's failure rather than the tool's. It is not an AI Act ruling, but it is a direct statement of where existing law places responsibility.

The pattern, and what it does not yet settle

Across these and similar matters, the consistent holding is that responsibility to the harmed party sits with the deployer and the humans in the loop, and that "the system did it" is not a defence. What the cases do not yet settle is the upstream question the new instruments are built to answer: when the failure traces to a genuine defect in the model or a component rather than to the deployer's setup or supervision, how far can liability be pushed back up the chain to a manufacturer or provider. The revised Product Liability Directive is the instrument designed to make that push possible from December 2026, and it is where the next wave of testing will happen. Until then, the safe planning assumption for any operator is that the customer comes to you first.

How model and vendor contracts shape the answer

The reason the deployer so often cannot pass a loss up the chain is the commercial contract, and operators underestimate this. Foundation model and API terms are written to keep the provider out of downstream liability. They typically supply the model as is, disclaim implied warranties of merchantability and fitness for a particular purpose, cap aggregate liability at a low figure or the fees paid over a recent period, exclude indirect and consequential loss (which is where most real damage sits), and put responsibility for the deployer's specific application and outputs squarely on the deployer. Many go further and require the deployer to indemnify the provider against third-party claims arising out of the deployer's use of the model.

Stack those terms together and the result is stark: even where a provider's model genuinely contributed to a failure, the deployer frequently has no meaningful recovery against it. The same is true one layer down, between a deployer and a smaller integration vendor, where a low liability cap or a thinly capitalised counterparty can make a contractual indemnity close to worthless in practice. This is why aligning the contract with the AI Act roles matters. A deployer should know, in writing, who is the provider and who is the deployer for each system, should require any vendor to evidence the duties it carries, and should not assume the model provider stands behind the output simply because the output came from its model.

What an operator should do now

The exposure is manageable, but only if it is mapped before a loss rather than discovered after one. Five priorities follow directly from the analysis above.

Map the chain for every agent. For each deployed agent, name the foundation model provider, the fine-tuner or integrator, and the deployer, and decide honestly whether you have crossed into provider status under Article 25 by branding or modifying the system. This single exercise resolves most of the uncertainty about who carries what.

Keep a human in the loop on consequential actions, and log it. The absent check is what converted Air Canada and Mata into liability findings. Documented human oversight on actions that bind the business or affect a person is both an Article 26 duty and the single strongest factual defence available.

Read the contracts before you ship. Read the limitation of liability, indemnity, warranty, and acceptable use clauses of every model and vendor you build on. Know, in advance, how far you can actually recover if their component is at fault. Assume less than the marketing implies.

Classify against the AI Act and meet the deployer duties. Determine the risk tier of each system, meet the Article 26 operational duties for anything high-risk, prepare for Article 50 transparency from 2 August 2026, and keep the AI literacy obligation under Article 4 satisfied. For the live state of the high-risk timeline, including the proposed Digital Omnibus deferral, see the live global regulatory tracker and the extraterritorial reach guide.

Confirm your insurance responds, before a loss. Check whether your existing Errors and Omissions, professional indemnity, or cyber cover responds to AI-caused loss, because insurers are adding explicit AI exclusions at renewal through 2026. Purpose-built AI agent cover has begun to appear: in February 2026 ElevenLabs secured the first AIUC-1-backed AI agent policy, and the market is moving quickly. For the operator coverage view, see the coverage guide for operators.

Next step. The fastest way to see where your deployment sits across these duties is a structured readiness check. The deployer readiness scorecard walks the Article 26 duties in order, and the seven-dimension assessment framework published by Future Proof Intelligence maps your agent against the obligation clusters so you can see, dimension by dimension, where you stand and what is still open.

Frequently asked questions

When an AI agent fails, who pays, the model provider or the business?

In most cases the business that deployed the agent pays the harmed customer, not the foundation model provider. The deployer chose the agent and authorised it to act, so under agency and contract principles it answers to the person harmed. The provider usually has no direct relationship with that customer; its exposure is contractual to the deployer and, in the EU, statutory as a provider under the AI Act. Product liability can sometimes reach a maker in the chain, but the front-line payer is the deployer.

Who is in the AI agent liability chain?

Usually four parties: the foundation model provider who supplies the general-purpose model, the fine-tuner or integrator who builds the agent on top of it, the deployer who puts the agent into use under its own authority, and the user who interacts with it and may be harmed. Liability runs through contracts between the commercial parties and through statute and tort to the user. In the EU the AI Act assigns different duties to provider and deployer roles, and one company can hold several roles at once.

Does the EU AI Act decide who pays a damages claim?

No. The AI Act (Regulation (EU) 2024/1689) is a product-safety style regulation that allocates obligations and backs them with administrative penalties under Article 99. It does not decide who compensates a harmed person. That is answered by national civil law and, from 9 December 2026, by the revised Product Liability Directive. A company can comply fully with the AI Act and still owe civil damages, or breach it and face a fine while a separate civil claim proceeds.

Can a deployer become the provider under the AI Act?

Yes, under Article 25. A deployer is treated as a provider, and takes on the provider's obligations, if it puts its own name or trademark on a high-risk system, makes a substantial modification to it, or modifies the intended purpose so the system becomes high-risk. A business that fine-tunes a model, brands the agent as its own, and ships it to customers can therefore carry provider duties as well as deployer duties. This is a common reason the model provider sits further from liability than operators expect.

What does the revised Product Liability Directive change?

Directive (EU) 2024/2853 brings software and AI systems inside the definition of a product, imposes strict no-fault liability on the manufacturer of a defective product, and eases the claimant's burden of proof through rebuttable presumptions of defectiveness for complex or opaque systems. It applies to products placed on the market after 9 December 2026, with national transposition due the same day. It widens who a harmed customer can reach, potentially including a maker or component supplier in the chain, without displacing the deployer's parallel exposure.

Why was Air Canada liable for its chatbot and not the chatbot's maker?

In Moffatt v. Air Canada (2024 BCCRT 149) the tribunal held Air Canada responsible for all information on its website, including from its chatbot, and rejected the argument that the chatbot was a separate entity responsible for its own statements. The deployer owed a duty to take reasonable care that the information was accurate, and paid. The chatbot's maker was not part of the customer's claim; any liability the vendor owed back to Air Canada was a separate upstream matter.

What does Mata v. Avianca add?

In Mata v. Avianca (22-cv-1461, S.D.N.Y. 2023) lawyers were sanctioned for filing a brief with case citations a generative AI tool had invented. The court penalised the humans who relied on the output without checking it, not the tool's maker. It shows that existing law attaches responsibility to the party that deployed and relied on the output, and treats an absent human check as that party's failure.

How do model providers limit their liability to deployers?

Through their contracts. Model and API terms typically supply the model as is, disclaim warranties of fitness for a particular purpose, cap liability at a low figure or the fees paid, exclude indirect and consequential loss, place responsibility for the specific use and outputs on the deployer, and often require the deployer to indemnify the provider. The effect is that even where a provider's model contributed to a failure, the deployer frequently cannot pass the loss up the chain.

If we use a third-party AI vendor, can we push liability onto them?

Only as far as your contract allows, and the customer can usually still come to you first. Allocation between you and your vendor is whatever you negotiated. Against the outside world the customer normally sues the business it dealt with, and you then try to recover from the vendor. If the vendor is small or its cap is low, that recovery may be worth little. Align the contract with the AI Act roles and confirm your insurance responds before a loss.

What should an operator do to limit exposure when an agent fails?

Map the chain for each agent and check whether you are a provider under Article 25; keep and log human oversight on consequential actions; read the model and vendor contracts for caps and indemnities before shipping; classify against the AI Act risk tiers and meet the Article 26 deployer duties plus Article 50 transparency from 2 August 2026; and confirm whether your Errors and Omissions, professional indemnity, or cyber cover responds to AI-caused loss, since insurers are adding AI exclusions at renewal through 2026.

References

  1. Regulation (EU) 2024/1689 (the EU AI Act), in force 1 August 2024. Article 4 (AI literacy, applies 2 February 2025); Article 5 (prohibited practices); Articles 9 to 15 (high-risk requirements); Articles 16 to 21 (provider obligations); Article 25 (responsibilities along the value chain, deployer-as-provider); Article 26 (deployer obligations); Article 27 (fundamental rights impact assessment); Article 43 (conformity assessment); Article 50 (transparency, applies 2 August 2026); Chapter V (general-purpose AI models, applies 2 August 2025); Article 99 (penalties).
  2. Digital Omnibus on AI: provisional political agreement reached in trilogue on 7 May 2026 to defer high-risk obligations (Annex III standalone to 2 December 2027; Annex I product-embedded to 2 August 2028). Not yet adopted, not published in the Official Journal, and not in force as of mid-June 2026. The original dates (2 August 2026 and 2 August 2027) remain the law until publication.
  3. Directive (EU) 2024/2853 (revised Product Liability Directive), entered into force 8 December 2024; national transposition due 9 December 2026; applies to products placed on the market or put into service after 9 December 2026. Brings software and AI systems within the definition of a product, imposes strict liability on manufacturers of defective products, and introduces rebuttable presumptions of defectiveness.
  4. Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal): airline held liable for its website chatbot's incorrect statement of the bereavement fare policy.
  5. Mata v. Avianca, Inc., No. 22-cv-1461 (S.D.N.Y. 2023): sanctions imposed on lawyers for filing a brief containing fabricated, AI-generated case citations.
  6. EIOPA Opinion on Artificial Intelligence governance and risk management (EIOPA-BoS-25-360), 6 August 2025: situates AI within existing insurance-sector law (Solvency II, IDD, DORA, GDPR); interpretive guidance, not new rules.
  7. ElevenLabs secured the first AIUC-1-backed AI agent insurance policy, announced 11 February 2026. AIUC-1 is a certification standard based on adversarial simulation across data and privacy, safety, security, reliability, accountability, and societal impact.
  8. ISO/IEC 42001 (AI management system standard) and the NIST AI Risk Management Framework: voluntary management-system and risk frameworks used to evidence reasonable care; frameworks, not law.