The EU Product Liability Directive and your AI: what changes from 9 December 2026

A lot of what I read about the EU’s new Product Liability Directive sounds like a reason to panic. For many AI systems, you don’t need to. For some, you do.

Four questions tell you which. And if the answer is yes, what your team keeps from now on (tests, traces, change logs) will matter more than any policy document.

I build and run AI systems; I’m not a lawyer. Here’s what the text says, and what I’d keep.

General orientation, not legal advice. Where the exact wording matters, I cite the article, so you or your lawyer can check it against the text.

The short version

• What changes: for products placed on the market or put into service (sold or supplied, or first used in your business) on or after 9 December 2026, software, including AI, is a product under EU product liability law. If it’s defective and harms someone, the claimant doesn’t have to prove anyone was careless.
• Who it reaches: only individuals have the right to compensation, and only for three types of damage: death or personal injury, damage to their property, and destruction or corruption of their data not used for professional purposes. Losses that stay inside your business aren’t covered. Harm to a person, their property or their data not used for work is.
• What to keep: if a claim comes, the court can order you to disclose evidence, and if you don’t, your AI is presumed defective (you can still rebut it, meaning prove it wrong). The evidence that helps is the kind you kept at the time: tests, traces, and a record of every change.

What changes: software becomes a product

The revised Product Liability Directive ¹ replaces the EU’s 1985 rules ². It applies to products placed on the market or put into service on or after 9 December 2026 (Art. 2(1)). Anything placed on the market or put into service before that date stays under the old rules (Art. 21).

An official corrigendum of 7 May 2026 ⁶ changed Art. 2(1) from “after 9 December 2026” to “after 8 December 2026”. Some commentary still says “after 9 December”.

Four things matter for anyone building or running AI:

• Software is a product. The Directive names “AI systems” as an example, and says software counts however it’s supplied, including as software-as-a-service (recital 13).
• No fault needed. The question is whether the product was defective, not whether you were careless.
• No floor and no ceiling. The old rules had a €500 minimum for property claims and let countries cap liability. The €500 minimum is gone (Art. 6), and national law can no longer cap liability (Art. 15, recital 56).
• Longer reach in time. A person has three years from when they knew, or should have known, about the damage, the defect and who’s liable (Art. 16). Claims can come up to 10 years after the product was placed on the market or put into service, and up to 25 years for some personal injuries that only show up late (Art. 17).

Each EU country puts the Directive into its own law by 9 December 2026 (Art. 22). In Germany, that’s the government bill to modernise product liability law (Bundestag Drucksache 21/4297) ³. It had its first reading in March 2026 and a committee hearing in April, and as of early October 2026 the Bundestag hadn’t passed it yet. As drafted, it treats software as a product however it’s supplied, including SaaS, and drops the current €500 deductible and €85 million cap. Check your own country’s version.

Two things this is not. It isn’t the AI Liability Directive. That was a separate proposal, and the Commission withdrew it in 2025 ⁴. And it isn’t the AI Act, whose high-risk rules were moved back to December 2027 and August 2028 ⁵. The product liability date didn’t move.

In the UK: the Directive doesn’t apply in Great Britain. But if your AI is placed on the market in the EU, it applies there, and the EU importer or your authorised representative can be held liable too (Art. 8(1)(c)).

Does it reach you? Four questions

Only individuals have the right to compensation (Art. 5), and only for three types of damage (Art. 6(1)):

1. Death or personal injury, including medically recognised damage to psychological health.
2. Damage to property, except the defective product itself, a product damaged by a defective component its manufacturer built in, and property used exclusively for professional purposes.
3. Destruction or corruption of data not used for professional purposes.

That turns into four questions about your AI system, timing first:

• Is it, or will it be, placed on the market or put into service on or after 9 December 2026, or substantially changed after that?
• Could a malfunction plausibly injure someone? For example, a consumer app that gives wrong dosage or safety instructions.
• Could it destroy or corrupt a person’s data that isn’t used for work?
• Could it damage property that isn’t purely a business asset? For example, a home or vehicle control that damages someone’s belongings.

If the first answer is yes but the other three are no, this Directive probably isn’t your biggest AI risk. A loss that stays inside the business, like a supplier paid twice by an invoice agent, isn’t one of the three types, and neither is a customer refunded the wrong amount by an order agent: pure economic loss doesn’t trigger this Directive on its own (recital 24). If any of the harm questions is a yes, read on.

Three questions the Directive doesn’t settle

Some cases aren’t clear from the text alone. Don’t take my reading as the answer on any of these. If one applies to you, raise it with your lawyer.

AI you build or commission and run yourself, including customer-facing agents your customers use but don’t buy. The Directive counts as a manufacturer anyone who “develops, manufactures or produces a product for their own use” (Art. 4(10)(c)). And “putting into service” means the first use of a product in the EU in the course of a commercial activity, where it wasn’t placed on the market first (Art. 4(9)). What the text doesn’t spell out is how that applies to an AI system a company runs itself, whether for its own staff or to serve its customers.

AI that’s already live. Systems placed on the market or put into service before 9 December 2026 stay under the old rules (Art. 21). The Directive doesn’t say expressly what happens when one of them is substantially modified after that date. It does say that anyone who substantially modifies a product outside the manufacturer’s control, and then makes it available on the market or puts it into service, counts as its manufacturer (Art. 8(2)). And for a modified product, the 10-year clock starts again (Art. 17(1)(b)). “Substantial modification” has its own definition (Art. 4(18)): where product safety rules don’t set one, it’s a change to the system’s performance, purpose or type that the original risk assessment didn’t foresee, and that changes the nature of the hazard, creates a new one or raises the risk. If you’re planning a big change to a live system, ask your lawyer whether it counts, and which rules then apply.

Customer data your company holds. The data clause covers data “not used for professional purposes” (Art. 6(1)(c)). The text doesn’t say whether data your company holds about a customer, such as a saved account or order history, counts. If your AI can delete or corrupt that kind of data, ask your lawyer.

Who is the manufacturer when someone else builds it?

Most AI systems involve more than one company: someone builds it, someone runs it, and it usually sits on someone else’s model. The Directive has a clear starting point for each.

The short answer: if your system counts as a product here, you, your builder and your model vendor can all be on the hook, and who approves changes after handover matters as much as who built it.

The text. A manufacturer is anyone who develops or produces a product, anyone who “has a product designed or manufactured”, or anyone who puts their own name or brand on it (Art. 4(10)(a) and (b)). A developer of software, including an AI system provider, “should be treated as a manufacturer” (recital 13). Where more than one company is liable for the same damage, the injured person can ask any one of them for the whole amount (“jointly and severally”, Art. 12(1)). The one who pays can then claim the money back from the others under national law (Art. 14).

A consultant builds it for you

The general answer: if your system counts as a product here, you are likely a manufacturer, and so may your builder be. In the Directive’s words, you “have a product designed or manufactured”, and if it carries your name, you present yourself as its manufacturer (Art. 4(10)(b)). Your builder developed it (Art. 4(10)(a)). An injured person could claim from either.

What the text leaves to the facts is the timing. A manufacturer isn’t liable if it proves it didn’t place the product on the market or put it into service. Whether your builder’s handover to you counts as placing it on the market, or only your first use counts as putting it into service, depends on how the deal is set up (Art. 11(1)(a), Art. 4(7) to (9)).

If you later change it substantially, who approved the change decides a lot. If you make a substantial change your builder didn’t control, and then make the system available or put it into service, you count as its manufacturer for that change. As the one who modified it, you avoid liability only if you prove the defect is in a part the change didn’t affect (Art. 8(2), Art. 11(1)(g)). Your builder can then argue the defect only appeared after its release. That argument is closed to it if the change was within its control, which includes changes it authorised or consented to (Art. 11(1)(c), Art. 11(2)(d)).

It runs on a vendor’s model

The general answer: whoever builds the system on top is the product manufacturer, and stays liable for the whole system, including vendor parts built in or connected within its control (Art. 8(1), last subparagraph). The vendor can be liable too, as manufacturer of a defective component that made the system defective (Art. 8(1)(b)). Both are liable to the injured person (recitals 36 and 53).

The Directive doesn’t name AI models or model APIs. But a “component” is any item, tangible or intangible, built into or connected to a product (Art. 4(4)), and a “related service” is a digital service without which the product can’t perform one or more of its functions (Art. 4(3)). A model your system calls is likely to fit one of those, and that’s worth confirming for your setup. The vendor has its own defence: it isn’t liable where the defect comes from the design of your system, or from your instructions to it (Art. 11(1)(f)). If the vendor is outside the EU, its EU importer or authorised representative can be liable as well (Art. 8(1)(c)).

Putting it together. Say your company runs a customer-facing agent that a consultancy built on a model from a US vendor. If the system counts as a product, you and the consultancy are both likely manufacturers of it, and the vendor may be liable for its model as a component, or through its EU importer or representative. Whatever the vendor’s setup, don’t assume a claim stops with the vendor: as a likely manufacturer, you’re one of the companies it can reach (Art. 8(1), Art. 12(1)).

What your contracts can and can’t do. Who ends up paying whom between you, your builder and your vendors follows national law (Art. 14), and your contracts can shape that. They can’t reduce what’s owed to the person harmed (Art. 15).

The exact allocation depends on your contracts and the facts: who built what, whose name is on it, who controls updates, and when it went live. Take this as the map, and have your lawyer check your own setup against it.

How a claim works: disclosure, then presumptions

The person claiming still has to prove three things: the product was defective, they suffered damage, and the defect caused it (Art. 10(1)). What’s new is how much help they get.

Step 1: disclosure. If the claimant presents facts and evidence that make the claim plausible, a court can order you to disclose relevant evidence you hold (Art. 9(1)). It’s limited to what’s necessary and proportionate, trade secrets are protected, and the court can require it in an “easily accessible and easily understandable manner” (Art. 9(3) to (6)).

Step 2: presumptions. A court presumes your product is defective if any of these is true (Art. 10(2)):

• you fail to disclose the evidence;
• the claimant shows it doesn’t meet mandatory product safety requirements meant to protect against that risk;
• the claimant shows the damage came from an obvious malfunction during reasonably foreseeable use or under ordinary circumstances.

If it’s established that the product is defective, and the damage is of a kind typically consistent with that defect, the causal link is presumed too (Art. 10(3)).

Step 3: the complexity rule. Where, even after disclosure, proving the case is excessively difficult, “in particular due to technical or scientific complexity”, a court presumes defectiveness, causation or both, as long as the claimant shows it’s likely (Art. 10(4)). Recital 48 names machine learning as an example of complex technology.

Step 4: you can rebut (prove wrong) any of these presumptions (Art. 10(5)). The Directive gives you that right. It doesn’t tell you how.

Four lines that matter more for AI than for a toaster

Most of the Directive reads the same for any product. Four lines land harder on AI.

• It keeps changing. Courts weigh “the effect on the product of any ability to continue to learn or acquire new features” after release (Art. 7(2)(c)). Changes your team makes, such as tuning, new prompts or a new model, fall under the modification and update rules instead (Art. 8(2), Art. 11(2)).
• Security counts as safety. Courts also weigh “safety-relevant cybersecurity requirements” (Art. 7(2)(f)). So security testing, like the prompt-injection tests from my last post, isn’t only an IT question.
• Updates stay your responsibility. You can’t escape liability by showing the defect appeared after release if it came from software, an update, or a missing update needed to keep it safe, while it’s within your control (Art. 11(2)). “Within your control” includes being able to push updates (Art. 4(5)(b)).
• You can’t contract out of it. Liability to the injured person can’t be limited or excluded by contract (Art. 15). Your terms of service won’t do this job.

One line works in your favour: a product isn’t defective just because a better version or update comes out later (Art. 7(3)). An update alone doesn’t make the earlier version defective.

What to keep, starting now

This part is my view, not the Directive’s text. If you have to rebut a presumption, or disclose evidence a court can understand, the strongest material is evidence made at the time: what the system was meant to do, how it was tested, what it did, and what changed. A record written after a claim arrives is weaker.

That evidence lines up with the five gaps from my last post: the five things a pilot needs before it’s ready for real customers.

Two practical points:

• Keep it long enough. Claims can arrive up to 10 years after release, longer for some injuries (Art. 17). Traces deleted after 30 days won’t help in year three. Test sets, change logs and pass rates hold little or no personal data, so keep them long. Case traces often do, so agree how long you keep them, and whether to pseudonymise, with your data protection officer.

• Keep it readable. A court can ask for evidence in an easily understandable form (Art. 9(6)). A dashboard export only your team can read is a start, not the finish.

Five questions to ask your team this week

One question per piece of evidence. A vague answer shows you where to start.

1. Scope: Could this system injure someone, damage a person’s property, or destroy or corrupt a person’s data that isn’t used for work? Who checked?
2. Timing: Will it be placed on the market or put into service on or after 9 December 2026, or substantially changed after that date?
3. Testing: If a court asked how it was tested before release, which dated test results would we hand over?
4. Changes: Can we show every change since launch (prompt, model, tool) and the test result that came with it?
5. Retention: How long do we keep traces and test results, and would they still exist in three years?

Where to start

The Directive doesn’t ask you to stop building AI. It asks whether you can show, after the fact, how it was built, tested and changed. For a system that’s still being built, that evidence is far easier to keep now than to rebuild later.

If you have a pilot heading for launch, or nothing built yet but a workflow you know needs it, the AI delivery sprint builds it in from day one: tests on cases the system has never seen, traces of every case, security tests, and a handover with the code, documentation, test cases and audit trail in your accounts. Already live, with a new version planned? The new version can start the sprint from “have a pilot”, with the evidence designed in from week one. If you’re weighing a few workflows and aren’t sure which one is exposed, the AI value review is the place to start.

This post is general orientation, not legal advice. It restates Directive (EU) 2024/2853 and Germany’s government bill as published, and cites the article wherever the exact wording matters. The section on who is the manufacturer gives the general picture the text supports; the exact allocation in your case depends on your contracts and facts, so have your own lawyer check it. Where this post says the Directive doesn’t settle a question, it means the text doesn’t, not that the answer is unknowable.

Sources

1. Directive (EU) 2024/2853 on liability for defective products
2. Council Directive 85/374/EEC
3. Deutscher Bundestag, Drucksache 21/4297: Entwurf eines Gesetzes zur Modernisierung des Produkthaftungsrechts (Feb 2026)
4. Official Journal C/2025/5423: Withdrawal of Commission proposals (Oct 2025)
5. Regulation (EU) 2026/1744
6. Corrigendum to Directive (EU) 2024/2853, OJ L, 2026/90364, 7 May 2026