AI Liability in 2026: Who Pays, and on What Evidence

AI liability is the question of who compensates a person harmed by an AI system, on which legal basis, and with what proof. In the European Union the answer changes on 9 December 2026, when a rewritten Product Liability Directive starts to treat software and AI systems as products and lets courts presume a defect when the manufacturer cannot show its file. This guide explains who answers, what the claimant has to prove, and which records decide the case.

Key takeaways

• From 9 December 2026, Directive (EU) 2024/2853 applies no-fault product liability to software, including AI systems supplied as a service.
• The planned AI Liability Directive is gone, so AI liability now rests on product law and national law: the Commission withdrew the proposal in its 2025 work programme, and no successor has been tabled.
• A court can order the manufacturer to disclose evidence, and presumes the defect if it does not, if a mandatory safety requirement was breached, or if the case is too technically complex for the claimant.
• AI Act documentation becomes the evidence. Logs must be kept six months; the liability exposure lasts ten years.
• Germany’s Bundestag adopted its transposition on 8 October 2026. Most Member States have no adopted text yet.

AI liability: what it means in 2026

AI liability is civil liability for harm caused by an AI system: the obligation of a natural or legal person to pay damages to someone injured by what the system did or failed to do. An AI system has no legal personality in any jurisdiction covered here, so the claim always lands on a person: the company that built it, the one that integrated it, the one that imported it, or the one that used it. Three legal bases for AI liability coexist, and a single incident can trigger all three.

• Contract. A customer sues its supplier because the system did not perform as agreed. Warranties, caps and indemnities are negotiated, and they bind only the parties.
• Fault-based liability. An injured person shows that someone breached a duty of care: a deployer that ignored the instructions for use, a developer that shipped without testing. The rules are national (tort law in common-law systems, the general civil liability clauses of the civil codes in continental Europe).
• No-fault product liability. The injured person proves a defect, a damage and a causal link, and does not need to prove that anyone was careless. In the EU this regime is harmonised, and it is the one that has just been rewritten for software.

AI liability is not the same subject as accountability. Accountability is the internal and regulatory question of who is answerable for a system and how that is recorded, which we cover in our guide to AI accountability. Liability is what happens when harm has occurred and a court has to allocate the loss. The two meet in one place: the records produced for the first become the evidence in the second. One shift explains the rest of this article. Until now, the hard part of an AI liability claim was proof: the claimant could not see inside the system. The new European rules move that difficulty to the manufacturer, who must either open the file or bear a presumption.

Who is liable: the chain of economic operators

The directive does not use the AI Act vocabulary of providers and deployers. It speaks of economic operators, and it arranges them so that an injured person in the Union always finds someone to sue. Recital 13 closes the gap between the two texts: a developer or producer of software, “including AI system providers within the meaning of Regulation (EU) 2024/1689″, is to be treated as a manufacturer. <table header-row=”true”> <tr> <td>Operator</td> <td>Basis</td> <td>When it applies</td> </tr> <tr> <td>Manufacturer of the product (including the AI system provider)</td> <td>Article 8(1)(a)</td> <td>Always, for a defective product it placed on the market or put into service</td> </tr> <tr> <td>Manufacturer of a component (an integrated model, a related digital service)</td> <td>Article 8(1)(b)</td> <td>When the component was integrated within the product manufacturer’s control and made the product defective</td> </tr> <tr> <td>Importer and authorised representative</td> <td>Article 8(1)(c)</td> <td>When the manufacturer is established outside the Union</td> </tr> <tr> <td>Fulfilment service provider</td> <td>Article 8(1)(c)(iii)</td> <td>When there is neither an importer in the Union nor an authorised representative</td> </tr> <tr> <td>Distributor, then online platform</td> <td>Article 8(3) and (4)</td> <td>When no Union operator is identified within one month of the injured person’s request</td> </tr> <tr> <td>Whoever substantially modifies the product</td> <td>Article 8(2)</td> <td>When the modification is made outside the original manufacturer’s control and the product is then made available or put into service</td> </tr> <tr> <td>Deployer as a mere user</td> <td>National fault-based law</td> <td>Outside the directive: negligence in the way the system was used or supervised</td> </tr> </table> Two rows deserve attention from anyone who thinks AI liability stops at the builder. A company that fine-tunes a supplier’s model, changes its intended purpose or retrains it on its own data may be making a substantial modification, and Article 8(2) then treats that company as a manufacturer. The same act can turn a deployer into a provider under Article 25 of the AI Act, so the two regimes move together. This is why vendor due diligence now has to ask what the customer is allowed to change. Where several operators are liable for the same damage, they are liable jointly and severally (Article 12). And under Article 15, liability toward the injured person cannot be limited or excluded by contract. A limitation clause still allocates the loss between supplier and customer; it does nothing against the claimant.

The EU reset: one directive withdrawn, one rewritten

Europe planned two instruments on AI liability. The first, the AI Liability Directive proposed on 28 September 2022, would have eased the burden of proof in fault-based claims against providers and users of AI systems. The Commission withdrew it in its 2025 work programme, published on 11 February 2025, citing “no foreseeable agreement”. No replacement has been tabled since, and the Commission’s own page on liability rules for artificial intelligence still presents the 2022 proposal without mentioning the withdrawal. The second instrument survived, and it now carries most of European AI liability. Directive (EU) 2024/2853 was adopted on 23 October 2024, published on 18 November 2024, and repeals the 1985 directive with effect from 9 December 2026. Products placed on the market before that date stay under the old rules; products placed from that date fall under the new ones. Its scope is the part of AI liability most often misread.

• Software is a product. Article 4(1) lists it by name, and recital 13 adds that this holds “irrespective of the mode of its supply or usage”, whether the software is stored on a device, accessed through a cloud, or supplied through a software-as-a-service model.
• Information is not. The content of digital files and “the mere source code of software” are outside the definition.
• Non-commercial open source is excluded. The directive does not apply to free and open-source software developed or supplied outside the course of a commercial activity (Article 2(2)). A company that integrates such a component into a commercial product is the manufacturer of that product.

The damage covered is defined in Article 6: death or personal injury, “including medically recognised damage to psychological health”; damage to property, other than the defective product itself and property used exclusively for professional purposes; and the destruction or corruption of data that are not used for professional purposes. Only natural persons can claim.

What the directive does not cover

Much of what people call AI harm sits outside that list. Pure economic loss, a discriminatory hiring or credit decision, a privacy intrusion as such, damage to a company’s own equipment or data: none of these is compensated under the directive. They go to national fault-based law, to contract, or to Article 82 of the GDPR, which we discuss in our guide to GDPR-compliant AI. AI liability in Europe therefore remains a two-track system: harmonised and strict for safety harms to individuals, national and fault-based for the rest.

Proving AI liability: disclosure and presumptions

In an AI liability claim under the directive, the claimant still has to prove three things: the defect, the damage and the causal link (Article 10(1)). What changed is how. A product is defective where it does not provide the safety that a person is entitled to expect or that is required under Union or national law. Among the circumstances a court must weigh, Article 7(2) names several written with AI in mind: the effect on the product of “any ability to continue to learn or acquire new features” after it is placed on the market; the foreseeable effect of other products used with it, including by interconnection; relevant product safety requirements, “including safety-relevant cybersecurity requirements”; and any recall or intervention by an authority. Then comes the disclosure mechanism. Under Article 9, a claimant who has presented facts and evidence sufficient to support the plausibility of the claim can obtain a court order requiring the defendant to disclose relevant evidence at its disposal. The order is limited to what is necessary and proportionate, and the court protects trade secrets. It can also require the evidence to be presented “in an easily accessible and easily understandable manner”. Article 10 attaches consequences. The defect or the causal link is presumed in four situations.

1. Non-disclosure. The defendant fails to disclose the evidence ordered under Article 9.
2. Regulatory breach. The claimant shows that the product does not comply with mandatory product safety requirements intended to protect against the risk of the damage suffered.
3. Obvious malfunction. The damage was caused by an obvious malfunction during reasonably foreseeable use.
4. Complexity. Despite disclosure, the claimant faces excessive difficulties, “in particular due to technical or scientific complexity”, and shows that a defect or a causal link is likely. Recital 48 gives machine learning as an example of such complexity.

Every presumption can be rebutted, and in AI liability cases rebuttal needs records. The defences have narrowed as well. A manufacturer can still escape by proving that the defect probably did not exist when the product was placed on the market. Article 11(2) removes that defence where the defect is due to software, including updates or upgrades, to a lack of updates necessary to maintain safety, to a related service or to a substantial modification, as long as these were within the manufacturer’s control. A model that degrades after release, a case we examine in our article on model drift, is not a later defect that frees its maker. The development-risk defence remains, but it is now assessed over the whole period in which the product stayed within the manufacturer’s control.

Where the AI Act becomes liability evidence

For AI liability, the directive sets no safety standard of its own. It points to Union product safety law, and for AI systems that law is the AI Act. As one law firm put it in April 2026, “non-compliance with the applicable regulatory obligations can lead to liability exposure under the new PLD framework”. Read together, the two texts produce a simple result: the file a provider builds for the market surveillance authority is the file a civil court will order it to disclose. <table header-row=”true”> <tr> <td>Provision of the directive</td> <td>AI Act artefact</td> <td>What a court will look for</td> </tr> <tr> <td>Article 7(1), safety required under Union law</td> <td>Risk management system (Article 9)</td> <td>Whether the risk that materialised was identified, and what was done about it</td> </tr> <tr> <td>Article 9, disclosure of evidence</td> <td>Technical documentation (Article 11, Annex IV)</td> <td>Design choices, training data description, test results, in a readable form</td> </tr> <tr> <td>Article 10(2)(a), non-disclosure</td> <td>Automatically generated logs (Article 12)</td> <td>Whether the events around the incident were recorded and still exist</td> </tr> <tr> <td>Article 10(2)(b), breach of a safety requirement</td> <td>Requirements for high-risk AI systems and the conformity assessment</td> <td>A requirement that protects against the damage suffered and was not met</td> </tr> <tr> <td>Article 7(2)(a), instructions and presentation</td> <td>Instructions for use (Article 13), human oversight measures (Article 14)</td> <td>Whether limits and oversight needs were communicated to the deployer</td> </tr> <tr> <td>Article 7(2)(g), recalls and interventions</td> <td>Post-market monitoring (Article 72), serious incident reports (Article 73)</td> <td>Earlier signals of the same failure, and the corrective action taken</td> </tr> <tr> <td>Articles 4(18) and 8(2), substantial modification</td> <td>Substantial modification (Articles 3(23) and 25)</td> <td>Who changed the system, and whether the change was foreseen in the initial risk assessment</td> </tr> </table>

Two clocks that do not match

The AI Act asks providers to keep technical documentation for ten years after the system is placed on the market (Article 18). It asks them to keep logs for a period appropriate to the intended purpose, “at least six months” (Article 19), and deployers to do the same for the logs under their control (Article 26(6)). AI liability under the directive runs on a different clock. A claim must be brought within three years of the day the injured person knew of the damage, the defect and the operator. The right itself expires ten years after the product was placed on the market, twenty-five where a personal injury was latent, and the ten years restart after a substantial modification. In our reading, this is the most practical consequence for AI liability. A provider that deletes logs at six months complies with the AI Act and may be unable, in year four, to disclose what a court orders or to rebut a presumption of causation. Retention should be set against the liability period.

The 2027 gap

The directive applies from 9 December 2026. The Digital Omnibus, Regulation (EU) 2026/1744, deferred the AI Act requirements for Annex III high-risk systems to 2 December 2027 and for systems embedded in regulated products to 2 August 2028. For roughly a year, the regulatory-breach presumption has little AI Act content to rest on for those systems, because the requirements are not yet applicable. The other three presumptions are fully available from day one. A provider that used the deferral to postpone its documentation will meet the disclosure order before it meets the regulator.

Transposition: who is ready for 9 December 2026

A directive needs national law, and AI liability is no exception. Eight weeks before the deadline, the picture drawn by two law-firm trackers, Reed Smith (8 September 2026) and Faegre Drinker (updated 4 September 2026), is uneven. <table header-row=”true”> <tr> <td>Member State</td> <td>Status</td> <td>Detail</td> </tr> <tr> <td>Hungary</td> <td>Adopted</td> <td>16 December 2025, the first Member State</td> </tr> <tr> <td>Lithuania</td> <td>Adopted</td> <td>25 June 2026, in force 9 December 2026</td> </tr> <tr> <td>Croatia</td> <td>Adopted</td> <td>Summer 2026, notified to the Commission</td> </tr> <tr> <td>Germany</td> <td>Adopted by the Bundestag</td> <td>Vote of 8 October 2026; second passage in the Bundesrat pending</td> </tr> <tr> <td>Netherlands, Slovakia</td> <td>In parliament</td> <td>Bills close to the text of the directive</td> </tr> <tr> <td>Finland, Sweden</td> <td>Drafts published</td> <td>Both drop the word “excessive” from the complexity test; Finland drops the development-risk defence</td> </tr> <tr> <td>Italy</td> <td>In preparation</td> <td>No significant departure from the directive expected</td> </tr> <tr> <td>France</td> <td>Early stage</td> <td>Interministerial working group confirmed, no draft published</td> </tr> <tr> <td>Spain, Portugal</td> <td>No public draft</td> <td>Preparatory work reported for Portugal</td> </tr> </table> The German act follows the directive closely. It keeps the development-risk defence except for genetic engineering products, and it leaves products placed on the market up to 8 December 2026 under the current Product Liability Act. The Bundestag also asked the government to examine insurance requirements for the authorised representatives of non-Union manufacturers. The variations matter for groups managing AI liability in several countries. Where the word “excessive” disappears, the complexity presumption is easier to reach. Where the development-risk defence disappears, a manufacturer answers even for defects that the state of scientific knowledge could not reveal. And where no national text exists on 9 December 2026, courts will be asked to interpret existing law in the light of the directive, with less predictable results. AI liability will not be identical across the Union on day one.

Outside the EU: US courts and statutes

The United States has no equivalent AI liability statute. As RAND’s analysis of liability for harms from AI systems explains, tort law there is mostly state common law, and open questions remain on products liability, the First Amendment and Section 230. The movement comes from courts and state legislatures.

• Garcia v. Character Technologies (Middle District of Florida). On 21 May 2025 the court largely denied a motion to dismiss, accepting at that stage that a chatbot application could be treated as a product and declining to hold that its output was protected speech. The case settled in January 2026, so no final judgment decides the point.
• Mobley v. Workday (Northern District of California). The court allowed discrimination claims to proceed against a software vendor on an agent theory in July 2024, and conditionally certified a collective action on the age discrimination claim in May 2025. The case is pending.
• California Civil Code section 1714.46, in force since 1 January 2026, bars a defendant that developed, modified or used an AI system from arguing that the AI autonomously caused the harm. Our overview of California SB 243 covers the related companion chatbot duties.
• The AI LEAD Act, S.2937, introduced on 29 September 2025, would classify AI systems as products and create a federal cause of action. It has not been enacted.
• The American Law Institute approved a project on civil liability for artificial intelligence in October 2024, to state principles grounded in existing tort doctrine.

Canada supplied the most quoted precedent. In Moffatt v. Air Canada (2024 BCCRT 149), a British Columbia tribunal held the airline liable for a negligent misrepresentation made by its website chatbot and rejected the argument that the chatbot was a separate entity responsible for its own actions. For a European group selling on both sides of the Atlantic, the AI liability lesson is about evidence. The same product faces discovery in a US court and an Article 9 disclosure order in a Union court. One file, kept once, serves both.

The AI liability evidence file in seven steps

Managing AI liability does not require new paperwork invented for litigation. It requires that the records already expected by the AI Act and by a sound AI risk management practice survive long enough and can be read by a judge.

1. Fix the role and the date for each system. Manufacturer, component supplier, importer, modifier or user; placed on the market before or from 9 December 2026. An AI inventory that records both answers the first question of any claim: which regime applies. A registry such as our AI Registry keeps that information per system.
2. Decide what is a product. Standalone software, a component of another product, or a related service. Note which updates stay within your control, because liability follows control.
3. Set log retention against the liability period. Six months is the regulatory minimum. Three years from knowledge and ten years from release are the periods a claim can use.
4. Keep the documentation legible. A court can require evidence in an easily accessible and easily understandable manner. A risk file that only its author can read works as a non-disclosure.
5. Keep an update and modification register. Each model change, retraining or fine-tuning, with the risk assessment that foresaw it or did not. That is the test of a substantial modification.
6. Review the contracts. No clause excludes liability toward the injured person. Organise recourse along the chain, check the waiver the directive allows in favour of small software suppliers, and ask suppliers for the evidence you would be ordered to disclose.
7. Connect incident handling to claims. A serious incident report, a recall or a corrective action is a circumstance of defectiveness. Prepare the trade-secret protection request in advance, and review insurance wording with the broker.

An internal AI audit can test the file with one question per system: if a court ordered disclosure tomorrow, what would we hand over, and who could explain it?

FAQ

Is AI legally liable? No. An AI system has no legal personality, so it cannot be sued or ordered to pay damages. AI liability always attaches to a natural or legal person: the manufacturer or provider, a component supplier, an importer, a company that substantially modified the system, or the organisation that used it carelessly. Courts have rejected attempts to treat a system as a separate actor. In Moffatt v. Air Canada, a Canadian tribunal held the airline responsible for what its chatbot told a customer. Who is liable when AI fails? AI liability depends on the harm and the legal basis. For death, personal injury, damage to private property or loss of personal data, the EU directive makes the manufacturer liable without fault, then the importer, the authorised representative and, in last resort, the distributor or platform. A company that substantially modifies the system takes the manufacturer’s place. For economic loss or discrimination, national fault-based law and contract apply, and the deployer’s own conduct is examined. What happened to the AI Liability Directive? The Commission proposed it on 28 September 2022 to ease the burden of proof in fault-based claims involving AI systems. It withdrew the proposal in its 2025 work programme, published on 11 February 2025, stating that no agreement was foreseeable. No successor has been proposed as of October 2026. The revised Product Liability Directive fills part of the gap for safety harms to individuals; the rest stays with national law. Does the Product Liability Directive apply to SaaS and open-source models? Yes for software-as-a-service: software is a product whatever the mode of supply. Free and open-source software developed or supplied outside a commercial activity is excluded. A company that integrates an open-source model into a commercial product is the manufacturer of that product and answers for the component. Article 12(2) allows it to waive recourse by contract against a micro or small software supplier. Has anyone successfully sued over AI? Yes, on ordinary legal grounds. Moffatt v. Air Canada ended in a damages award for negligent misrepresentation by a chatbot. In the United States, Garcia v. Character Technologies survived a motion to dismiss on product liability theories in May 2025 and settled in January 2026. Mobley v. Workday is proceeding as a collective action. None of these needed an AI-specific statute, which is why existing law should not be underestimated. What is AI liability insurance, and does it replace the evidence file? It is cover for losses arising from the use or supply of AI systems, either written as a dedicated policy or read into cyber, professional liability and errors and omissions policies. Reporting by the IAPP in January 2026 noted that some insurers seek to exclude AI from corporate policies. Insurance transfers part of the cost. It does not rebut a presumption of defect, and underwriters increasingly ask for the same records a court would.

Conclusion

AI liability used to be a debate about theories: negligence or strict liability, product or service, developer or user. In the European Union that debate is largely settled for safety harms. From 9 December 2026 software is a product, the manufacturer is the first to answer, and the court can ask to see the file. What remains open is whether the file exists, covers the right period and can be understood. The AI Act and the directive were drafted separately, and they now work as one mechanism: the first says what to document, the second says what happens when the documentation is missing. Companies that treat the AI Act deferral as extra time should count again. The disclosure order arrives first. This article is legal information, not legal advice; for a specific claim, consult counsel in the Member State concerned.