EU Product Liability Directive: What Every Software and AI Business Needs to Know
If you sell software, run a SaaS platform, or use AI in your products, there is a major legal change coming to the European Union that you need to prepare for. The EU’s new Product Liability Directive (officially known as Directive 2024/2853) comes into full effect in December 2026, and it changes the rules in a way that will affect thousands of businesses.
The short version: AI and software is now legally treated as a product. And products that cause harm can result in serious liability, even if you did nothing wrong.
This guide explains what the directive means, who it applies to, and what you should be doing right now to get ready.
What Is the EU Product Liability Directive?
The EU Product Liability Directive has existed since 1985, but it was written for a world of physical goods. Back then, software was not clearly covered. That grey area is now gone.
In October 2024, the EU adopted Directive 2024/2853, which explicitly names software, AI systems, and SaaS (Software as a Service) as products. This means they fall under the same liability rules as a faulty car, a broken electrical appliance, or a defective medical device.
The directive entered into force on 9 December 2024. EU member states have until 9 December 2026 to write it into their national laws. Once that happens, businesses can be held liable for harm caused by their software or AI products, even without any proof of negligence.
Who Does It Apply To?
This directive applies to a much wider group of businesses than most people realise. It covers:
Software developers and publishers
If you build and sell software, you are a manufacturer under this directive. It does not matter whether you sell a one-time licence or charge a monthly subscription.
SaaS providers
Cloud-delivered software is fully covered, regardless of how it is delivered or where the servers are located.
AI systems and machine learning products
Any product that uses automated decision-making or machine learning is included. This covers everything from simple recommendation engines to complex AI models.
Embedded software
If your physical product contains software, the software component is covered. This is relevant for smart devices, connected hardware, and electronics.
Importers and authorised representatives
If a business is based outside the EU but sells into the EU market, the importer or EU authorised representative can be held liable if the manufacturer cannot be reached.
It is also worth knowing that if you build a product on top of someone else’s AI model, you may be treated as the manufacturer of what you have built. For example, if you take an existing AI model and adapt it for your own product, the original model provider is responsible for the base model, but what you build on top of it is your responsibility.
What About Free and Open-Source Software?
There is an exemption for free, open-source software, but only where it is developed and distributed with no commercial activity involved.
In practice, this covers less than many developers expect. If you use open-source libraries or components inside a commercial product, your product is fully covered by the directive. The fact that some parts are open source does not make the whole product exempt. This catches a lot of developers off guard.
When Is Software Considered Defective?
The directive uses the concept of a “defective product” to determine liability. A product is defective when it does not provide the level of safety that users are reasonably entitled to expect.
For software and AI, defectiveness can arise from several situations:
Non-compliance with safety requirements. If your software does not meet mandatory safety or regulatory standards, the directive creates an automatic presumption that it is defective.
AI learning behaviour. If your AI model learns from user data after it has been released and that learning causes harm, this can count as a defect. You cannot simply say the AI changed on its own after launch.
Updates that introduce problems. If a software update causes harm, you are still liable for that update, because you chose to release it.
Lack of security updates. Failing to provide expected security updates can also be considered a defect. Users have a reasonable expectation that you will keep your product safe.
There is also an important link to the EU AI Act. If your product is non-compliant with the AI Act, the directive creates a presumption of defectiveness. This means the two pieces of legislation work together, and failing on one can make things significantly harder under the other.
What Counts as Damage Under the New Rules?
The original 1985 directive covered death, personal injury, and physical property damage. The 2026 directive adds two new categories that are highly relevant for digital products:
Data destruction or corruption
If your software damages, deletes, or corrupts a user’s data, that is now a form of damage that can be claimed. This is a big change for any product that handles user data.
There is one limit worth knowing. This protection covers personal data only. If the data is used purely for business or professional purposes, it falls outside the scope of this directive. Data that is used for a mix of personal and work purposes can still be covered, but purely professional data is not.
Medically recognised psychological harm
If your product causes a psychological injury that a medical professional has diagnosed, that can now be claimed as damage too.
Together, these additions open up significantly more liability for software and AI companies than existed before. It is also worth knowing that a single incident can trigger more than one set of rules at the same time. For example, if your software corrupts a user’s files and personal data is involved, a claim could arise under both this directive and GDPR. The two frameworks are separate and operate independently, but one event can set off obligations under both.
The Update Problem: Why Every Release Matters
One of the most important and often overlooked aspects of this directive is how it treats software updates.
Not every update creates new liability. Routine bug fixes, minor patches, and regular updates do not change your legal position. What matters is whether an update counts as a substantial modification, meaning a change that significantly alters what the product does, how it performs, or the level of risk it carries. When that threshold is crossed, the updated product is treated as a new product, and the 10-year liability clock starts again.
That said, any update you release and control is still your responsibility. If an update introduces a defect or fails to fix a known security problem, you can still be held liable for that.
Your responsibility can be reduced in some situations. If a customer modifies your software themselves, they take on responsibility for those changes. If a customer refuses a security update you provided, that can reduce your liability for problems the update would have fixed. Outside of those situations, if you are in control of the software, you remain responsible for it.
The Burden of Proof Has Changed
Under the old rules, the person making a claim had to prove the product was defective and that the defect caused the harm. That was often difficult and expensive, especially when the product involved complex technology.
The new directive keeps that as the starting point, but it gives courts the ability to step in and help claimants when proving their case would be unreasonably hard.
If a product fails to meet mandatory safety requirements, the law presumes it is defective. The same applies if there is an obvious malfunction during normal use, or if a company refuses to hand over relevant evidence. In cases where the product is simply too technical for a claimant to prove everything on their own, a court can presume defectiveness, causation, or both.
This does not mean the burden fully flips onto businesses. Companies can still challenge any claim, including whether those conditions were actually met. But the balance has shifted clearly in favour of consumers. If your product is not compliant with safety rules, including the EU AI Act, you will be in a much weaker position if something goes wrong.
How Long Do Claims Last?
There are two time limits to be aware of. A claimant has 3 years to bring a claim from the point they knew, or should have known, about the defect and the damage. There is also an overall cut-off of 10 years from the date the product was first placed on the market. For personal injuries that are slow to show up, that cut-off extends to 25 years.
For software companies, the 10-year clock can reset if a product goes through a substantial modification, as covered in the updates section above. Keeping clear records of when products and major changes were released will matter if a claim ever arises.
Can Your Terms of Service Protect You?
Many software businesses use their terms of service or end-user licence agreements to limit what they can be held liable for. Under this directive, that approach no longer works.
Any clause that tries to exclude or cap your liability under the directive is invalid, even if the user clicked to agree to it. Your legal documents cannot override these rules. If your product causes harm, the directive applies regardless of what your terms say.
What Should You Do Before December 2026?
There are several practical steps you should be taking now:
1. Review your insurance coverage. Product liability insurance, professional indemnity insurance, and cyber insurance policies may all need updating. Premiums are expected to rise as insurers adjust to the new risk landscape, so acting early is worthwhile.
2. Audit your compliance with the EU AI Act. Since AI Act non-compliance creates a presumption of defectiveness under this directive, getting your AI products into shape on that front is a priority.
3. Review your update and release processes. Make sure you have documentation around every significant release, including what was changed, when it was released, and how it was tested.
4. Check your supply chain and third-party components. If you use third-party AI models, open-source libraries, or other software components, understand where the line of responsibility sits between you and your suppliers.
5. Update your legal documentation. While your EULA cannot exclude liability, your contracts with suppliers and partners can help allocate responsibility appropriately within the supply chain.
Final Thoughts
December 2026 is not far away, and the businesses best placed to handle these changes will be the ones that start preparing now. If you sell software, run a SaaS platform, or use AI in your products in the EU, it is worth reviewing how your products are built, documented, and supported before the rules come into force.
Software is now treated much more like a physical product under EU law. That means more responsibility, and more exposure if something goes wrong.
Starting early gives you time to get your compliance in order, have better conversations with insurers, and be in a stronger position if a claim ever comes your way.
If you are not sure how these rules apply to your products, Euverify can help you work through the relevant EU and UK compliance requirements.
