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: software, including AI systems, is now legally treated as a product. If it causes harm to a person, you can be liable 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 8 December 2024. EU member states have until 9 December 2026 to write it into their national laws. It applies to products placed on the market after 9 December 2026; earlier products remain under the old 1985 rules. From then on, 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.
One important limit: only natural persons (individuals) can claim compensation under the directive. Business customers can’t use it to claim for their own losses. However, a B2B software provider can still be liable if its software harms an individual, such as an employee or end user.
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 where there is no importer the EU authorised representative, can be held liable alongside the manufacturer. Where neither exists, a fulfilment service provider can be liable.
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 product safety requirements designed to protect against the type of harm suffered, courts will presume it is defective. You can still rebut this presumption with evidence.
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 breaches mandatory safety requirements under the AI Act, that can trigger the presumption of defectiveness, as long as the requirement was meant to protect against the harm suffered. 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 new 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 data that is not used for professional purposes, such as personal photos, files or messages. It isn’t limited to “personal data” in the GDPR sense. Data used purely for business or professional purposes falls outside the directive.
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. The “development risk” defence also remains. A manufacturer isn’t liable if the defect couldn’t have been discovered given scientific and technical knowledge at the time, although some Member States may choose to remove this defence. 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. Breaching mandatory AI Act requirements can support a presumption of defectiveness under this directive, so getting your AI products into shape on that front is a priority. The EU withdrew its separate AI Liability Directive proposal in 2025, so this Directive is now the main EU-wide route for compensation claims involving AI.
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.
