For forty years, if your software caused harm, a claimant had to sue you under a contract or prove negligence. The 1985 Product Liability Directive, the strict-liability regime that made carmakers and toaster manufacturers pay for defects without the victim proving fault, treated a "product" as a physical thing. Code was not a product. That is over. Directive (EU) 2024/2853 rewrites the rule so that software, firmware, AI systems and even the digital services a product depends on are products in their own right, and it is strict liability: a claimant has to show the defect and the damage, not that you were careless.
The clock is specific. Member States must have the new rules in national law by 9 December 2026, and they apply to anything placed on the EU market or put into service after that date. Products already out before then stay under the old 1985 regime. So this is not a "someday" compliance item, it is a line in the sand roughly four months out, and it lands squarely on anyone who ships software into Europe, whether you are a SaaS vendor, a studio delivering a custom build, or a manufacturer whose hardware runs your own code. Here is what actually changes and where to put your attention first.
What counts as a defective product now
The old test still anchors the new one: a product is defective when it does not provide the safety a person is entitled to expect. What has expanded is the list of things that can make software fall short of that expectation.
Cybersecurity failures. A product that ships with an exploitable vulnerability, or that stops getting security updates it needed to stay safe, can be defective. Security is now a product-safety question, not just a contractual promise.
Missing or broken updates. If an update was within your control and you did not provide it, that omission can be the defect. The flip side matters too: because updates stay under your control, your liability window does not close when you ship version 1.0.
AI that changes after deployment. The Directive explicitly anticipates products that keep learning. An AI system that develops unsafe behaviour after release is not automatically off the hook because "it taught itself".
Poor instructions or foreseeable misuse. The same expectations around documentation and reasonably foreseeable use that applied to physical goods now apply to your software.
This turns AI Act compliance into a liability question
The EU AI Act tells you how to build and document an AI system. The Product Liability Directive is what happens when it goes wrong anyway. A breach of your AI Act or Cyber Resilience Act obligations can now trigger a legal presumption that your product was defective, which shifts the burden onto you to prove it was not.
The burden of proof moved toward the claimant's side
The part that should get a product owner's attention is procedural, not conceptual. The old regime often failed consumers because software is a black box: how do you prove a defect in a system you cannot see inside? The new Directive answers that in two ways.
First, courts can order you to disclose relevant evidence. If a claimant makes a plausible case, you may have to hand over technical documentation, and if you refuse, the court can presume the product was defective. Second, the Directive builds in presumptions of defectiveness: where the case is too technically complex for a claimant to prove, or where you failed to disclose, or where the product obviously malfunctioned in normal use, the court can assume the defect and make you rebut it.
In plain terms, "you cannot possibly prove what went wrong inside our model" stops being a defence and starts being a reason you lose. Good logging, versioning and documentation are no longer just engineering hygiene, they are the evidence that protects you.
Who is on the hook
The Directive spreads liability across the chain of "economic operators", so it is worth knowing where you sit:
RoleExposure under the new PLDManufacturer / software developerPrimary liability for defective products and componentsImporter / authorised representativeLiable when the manufacturer is outside the EUFulfilment or distribution providersCan be liable if an upstream operator cannot be identifiedAnyone who substantially modifies a productTreated as a manufacturer for the modified version
That last row matters for anyone doing integration or heavy customisation work. If you take someone else's product and change it substantially outside their control, you can inherit manufacturer-level liability for what you changed. One relief valve exists: genuinely open-source software developed or supplied outside a commercial activity is carved out. The moment it is monetised or shipped as part of a commercial offering, it is back in scope.
What "damage" covers, and for how long
Compensation now clearly includes death and personal injury (including medically recognised psychological harm), damage to property, and, new for the digital era, destruction or corruption of data that was not used for professional purposes. Pure commercial loss between businesses is still largely a contract matter. Liability generally runs for 10 years from when a product is placed on the market, stretched to 25 years in cases where an injury surfaces slowly.
What to do before December
You do not need a legal department to start, you need a short, honest inventory.
Map what you place on the EU market after 9 December 2026. New products and substantially updated ones fall under the new rules. Know which of your releases cross that date.
Treat security updates as a lifecycle commitment. Decide, per product, how long you will support it and say so. Undefined support windows are now a liability, not a shrug.
Make your build auditable. Version control, deployment logs, model and dataset documentation, and a clear record of what shipped when are exactly the evidence the disclosure rules will ask for. If you have been meaning to modernise a legacy codebase you cannot fully account for, this is another reason.
Read your contracts. Liability allocation, indemnities and the definition of "defect" in your client and supplier agreements were written for a world where code was not a product. They need a second look.
Get the AI paper trail right. If you ship AI features, the documentation that satisfies the AI Act is the same documentation that rebuts a presumption of defect. Build it once.
None of this requires panic, but it does require a decision about how you build and support software from here on. The teams that treat auditable, well-documented, actively-maintained software as the default will find compliance is mostly a byproduct of good engineering. The ones still shipping black boxes with no support plan are the ones who will meet this Directive in a courtroom. If you want a build that is designed to be defensible from day one, tell us what you are shipping and we will scope it with the deadline in mind.
