What changed on 9 December 2026
Directive (EU) 2024/2853 replaced the 1985 product liability rules on 9 December 2026. It applies to products placed on the market or put into service after that date (Article 2(1)), which is also the deadline every member state had to write it into national law (Article 22(1)). Products sold before then stay under the old regime (Article 21), which is the one thing about this that gives you room to plan.
The change that matters is four words in the definitions. A product now means "all movables, even if integrated into, or inter-connected with, another movable or an immovable", and the list that follows explicitly includes software (Article 4(1)). Recital 13 goes further and closes the three exits owners usually look for. Software counts "irrespective of the mode of its supply or usage" — on a device, over a network, through cloud infrastructure, or as software-as-a-service. A developer or producer of software, including providers of AI systems under the AI Act, "should be treated as a manufacturer".
So the shape of your business does not decide this. A twenty-person firm that wrote a stock-control tool for a distributor, a freelancer who ships a booking app on a subscription, an integrator who wrote the dashboard their machine needs to run: all of them are placing a product on the market in the sense the directive uses.
Three fine lines are worth knowing before you panic or relax. First, information is not a product, and neither is the content of a digital file or the mere source code — a price list, an e-book, an article you publish. Second, a digital manufacturing file is a product, because it contains the instructions that drive a machine (Recital 16): the CAD file that runs a CNC or a 3D printer is in scope, and a defective one that produces a part which injures someone gives rise to liability. Third, a "related service" — a digital service integrated into a product such that its absence stops the product from doing one of its jobs (Article 4(3)) — counts as part of the product, even though services as such do not.
What this replaced was not nothing. The 1985 directive already made sellers liable for defective goods without proof of fault. What it never settled was whether the thing you sold could be intangible, whether an update was part of it, and what happened when the defect appeared two years after delivery because the system kept learning. Those questions now have answers, and the answers are in the manufacturer's column.
Who can claim, and why your business customers mostly cannot
Start with who is allowed to bring the claim. The directive does not create a general right to compensation for anyone who loses money because your software failed. Article 1 limits it to damage "suffered by natural persons", and Article 5(1) gives the right to claim to a natural person. A company that lost a week of production is not the claimant this directive was written for.
Article 6 then cuts the damage list down further. Compensation covers death and personal injury, including medically recognised damage to psychological health. It covers damage to property, with three exclusions, one of which is property "used exclusively for professional purposes" (Article 6(1)(b)(iii)). It covers destruction or corruption of data, but only data "not used for professional purposes" (Article 6(1)(c)). The European Law Institute's analysis of the software provisions spells out the consequence: pure economic loss is not recoverable, and neither are most of the harms people associate with bad AI — discrimination, manipulation, a wrong recommendation that cost someone a deal.
| What went wrong | Compensable under the directive? | Why |
|---|---|---|
| A patient is harmed because your scheduling tool dropped an appointment | Yes | Personal injury to a natural person (Article 6(1)(a)) |
| A household's laptop and photo archive are destroyed by your update | Yes | Private property and private data (Article 6(1)(b), (c)) |
| A client's warehouse database is corrupted | No | Data and property used for professional purposes are excluded |
| A client loses a month of sales after a bad forecast | No | Pure economic loss is outside Article 6 |
Read that table twice, because it inverts the fear most owners have. If you sell only to businesses, and nothing you ship can injure a person or damage private property, the new directive adds very little to your exposure. Your business client still has every contractual remedy it had before — Article 2(4)(b) says national contract and fault-based rules survive untouched — and that is where a real dispute with a business customer has always been fought.
Where the directive bites is the moment your product touches a member of the public. A clinic's booking system used by patients, a machine an operator stands next to, a shop's loyalty app on a customer's phone, a delivery tracker whose failure sends a driver down a closed road at night. That is the perimeter to draw on a whiteboard before you decide how much of this article applies to you.
Two details sharpen it. The old regime had a minimum damage threshold; the European Parliament's summary of the revision confirms the €500 floor is gone, so small claims become viable claims. And a natural person includes your own staff, which means an internal tool that hurts an employee is not shielded by the fact that no customer ever touched it.
Three mechanisms that keep you on the hook after delivery
Liability that ends the day you invoice is a comfortable idea. The directive does not work that way for software, and the reason is control: a product that you can still change is a product still in your hands.
The first mechanism is learning. When a court weighs whether a product is defective, it must consider "the effect on the product of any ability to continue to learn or acquire new features after it is placed on the market or put into service" (Article 7(2)(c)). The official EUR-Lex summary states it plainly: the manufacturer is liable for defects that appear through the continuous learning of an AI system, where the system remains under the manufacturer's control. A model that drifts into worse answers after three months is not a maintenance issue you can invoice separately. It is a defectiveness question about the product you supplied.
The second is security. Article 7(2)(f) puts "safety-relevant cybersecurity requirements" into the assessment of whether something is defective. A version of your tool with a known hole becomes harder to defend than one that was merely imperfect. This dovetails with the Cyber Resilience Act, which is why the two pieces of law are read together by anyone advising on machinery or connected devices.
The third is the update trap, and it is the one small firms trip over. Article 11 lets a manufacturer escape liability if it proves the defect did not exist when the product was placed on the market. Article 11(2) then removes that escape for four things: a related service, software including updates and upgrades, a lack of updates needed to keep the product safe, and a substantial modification — always while the product is within your control. So the moment you offer support and monthly updates, you keep the clock alive. Not offering them does not rescue you either, because the lack of a necessary security update is on the list.
One reassurance sits next to all this. Article 7(3) says a product is not defective for the sole reason that a better one, including an update, came later. Shipping version 4 does not retroactively condemn version 3.
Now the arithmetic, with assumptions stated so you can replace them with your own. Say you run a twelve-person firm selling shift-planning to care homes: 40 customers at €250 a month, so €120,000 a year. Keeping the file that defends you means release notes, test evidence, the security-patch log and the dated record of every support decision. Call it four hours a month of one developer at €45 an hour: €180 a month, €2,160 a year, about 1.8% of revenue. A contested claim asks for two years of that file, assembled in weeks rather than months. The €2,160 buys you the ability to answer. What it does not buy is a lawyer, which is why the same exercise should end with a call to your insurer rather than to your accountant.
Your disclaimer clause does not survive Article 15
Most small software firms carry a version of the same sentence in their terms: the software is provided as is, and the supplier accepts no liability for indirect or consequential loss. It has done a lot of quiet work for twenty years. Article 15 removes it from the one scenario where it mattered most.
Article 15 says member states must ensure that the liability of an economic operator under the directive "is not, in relation to the injured person, limited or excluded by a contractual provision or by national law". Point the clause at a patient who was hurt, or a household whose files were destroyed, and it does nothing. The clause still governs your relationship with a business customer over warranty scope, service levels and what counts as a defect for the purposes of the deal — but it cannot reach the person the directive protects.
That produces two separate jobs, and confusing them is the usual mistake. The first job is the contract you sign with the business that buys your software. There, allocation still works: indemnities, caps, the split of responsibility for updates and security patches, and who answers for which component. Article 12(1) makes operators who are liable for the same damage liable jointly and severally, which means the injured person can come to you first and let you chase the rest. A recourse clause is what turns that into a solvable problem rather than a cash-flow event.
The second job concerns the small firm on the other side of that clause. Article 12(2) gives a real, if narrow, protection to a micro or small enterprise that supplied a defective software component: the manufacturer that integrated it has no right of recourse against them, provided the software supplier was a micro or small enterprise at the time it was placed on the market and the contract waived that recourse. If you are the ten-person component supplier, that waiver is worth asking for in writing. If you are the integrator, it is worth reading before you sign.
One more clause belongs in the same review. Article 8(3) makes a distributor liable when an EU operator in the chain cannot be identified and the distributor fails to name one within one month of a request from the injured person. If you resell software built outside the EU and your paperwork does not say who the importer or authorised representative is, silence for four weeks converts you into the defendant.
None of this requires a law firm on retainer to fix. It requires reading your own standard terms once, marking the paragraphs that claim to exclude liability, and deciding which of them were doing real work and which were decoration.
The paperwork decides the case
By the time a claim is filed, the technical facts are two years old and the person who wrote that module has left. What a court has to work with is what you kept. The directive makes that worse than it sounds, because it does not merely let the other side ask for documents — it attaches consequences to not having them.
Article 9(1) requires a defendant to disclose relevant evidence at its disposal once the claimant has presented facts sufficient to make the claim plausible. Proportionality and trade secrets are protected, and the court can order measures to keep them confidential. That part is manageable. Article 10 is where it gets sharp: if the defendant fails to disclose evidence under Article 9(1), the product is presumed defective (Article 10(2)(a)). The same presumption applies if the claimant shows the product breached mandatory safety requirements intended to prevent the damage suffered, or that an obvious malfunction happened in reasonably foreseeable use.
Article 10(4) closes the loop for software and AI specifically. Where the claimant faces "excessive difficulties" in proving the defect or the causal link, in particular because of technical or scientific complexity, and can show it is likely, the court presumes one or both. A black-box model is the example everyone cites. The presumptions are rebuttable, and your evidence is what rebuts them — but an empty folder is not evidence, it is a concession.
The one real defence you have on the merits is in Article 11(1)(e): no liability if the state of scientific and technical knowledge at the relevant time was not such that the defect could have been discovered. It is the reason a firm is not expected to have predicted a vulnerability nobody had found. Two limits apply. Member states may derogate and keep or introduce stricter rules (Article 20), so the defence is not uniform across the EU. And it only works if you can show what you knew and when, which is a documentation question again.
The clocks set the retention rule. A claim must be brought within three years of the injured person knowing about the damage, the defect and who is liable (Article 16(1)), but the outer limit is ten years from placing on the market (Article 17(1)), extended to 25 years where a personal injury is slow to appear (Article 17(2)). Ten years is the number to design around.
- Release record per version: date, what changed, what was tested, and who signed it off.
- Test evidence for the failure modes that can hurt someone, not just the ones that annoy users.
- Security log: known vulnerabilities, patch dates, and any update you decided not to ship, with the reason.
- Support decisions in writing, dated, including the ones where you told a customer their request was out of scope.
- Supplier and component list, with who supplied what and who is the EU operator for anything built outside the EU.
Ten years of release notes is cheaper than one hearing where you cannot explain what you shipped.
The retention rule that falls out of Articles 9, 10 and 17
When this does not apply, and when waiting is the right move
Plenty of small firms will read this, check their situation, and correctly do almost nothing. Getting to that conclusion deliberately is worth an hour, because the alternative is either a pointless compliance project or a nasty surprise.
You can put the file down if your software never reaches a natural person outside your own staff and cannot damage private property or private data. A tool that only a trained professional uses, inside their own business, to produce work for other businesses, sits largely outside the damage categories in Article 6. Same for a pure distributor that never brands, modifies or resells under its own name — with the one-month identification duty in Article 8(3) as the exception you still have to respect.
Free and open-source software developed or supplied outside a commercial activity is excluded (Article 2(2)). The exclusion is narrower than the slogan suggests. Recital 14 says that software supplied in exchange for a price, or for personal data used for something beyond improving its security, compatibility or interoperability, counts as a commercial activity and comes back into scope. An open-core product with a paid tier is a commercial product. A library you publish for free and also sell support for is the grey area worth asking a lawyer about.
Products placed on the market before 9 December 2026 stay under the 1985 rules (Article 21), which is genuine relief for an installed base. Two doors stay open, though. Article 8(2) treats anyone who substantially modifies a product outside the manufacturer's control as a manufacturer of it, and a substantial modification is defined by reference to changed performance, purpose or type plus a changed or increased hazard (Article 4(18)). Customising an old platform for a new client can walk an old product into the new regime. And updates you ship after the date are software supplied after the date.
One last thing to skip: there is no certificate, no register, no filing and no fee attached to this directive. Nothing goes to an authority. It is a liability rule that switches on when something goes wrong, so the work is internal and the deadline was the day it applied. A consultant selling you a compliance badge for it is selling you a badge.
What to do on Monday
The work is small enough to start in a single afternoon, and it starts with a list rather than a document. Write down every product you supply that a person outside your company touches: the app, the client portal, the dashboard that comes with the machine, the file that drives the customer's cutter. Next to each one, note who could be hurt and what they could lose. That list is the whole scope of your exposure, and most owners find it is shorter than they feared and different from what they assumed.
Then match your role against what changes.
| Your role | What changes | First move |
|---|---|---|
| You build and sell your own software | You are the manufacturer, including for defects that appear after an update or through learning | Start the release and security log this week, dated |
| You embed someone else's components | Joint liability, and recourse only as far as the contract takes you | Read the component contract for the Article 12(2) waiver |
| You resell software built outside the EU | A claim can land on you if you cannot name the EU operator fast enough | Record the importer or authorised representative for each supplier |
| You ship CAD or machine files with a product | Digital manufacturing files are products in their own right | Version and test them like a deliverable, not an attachment |
Two habits carry the rest. Give one named person the update and end-of-support decision, because Article 11(2) turns "we stopped patching it" into a liability question rather than an internal one. And put the insurer conversation on the calendar: product liability cover written for hardware often excludes software, data and the psychological injury the directive now recognises, and a broker who has not been asked about AI features will not volunteer the gap. Whatever your policy says today, find out before a letter arrives — that is the one item on this list where being late is expensive rather than embarrassing.
Frequently asked questions
Does this apply to software-as-a-service, or only to installed software?
It applies to both. Recital 13 states that software counts as a product "irrespective of the mode of its supply or usage", whether it is stored on a device, reached over a network or supplied as a service. There is no SaaS exemption to find.
Do I have to register, certify or notify anyone?
No. The directive creates liability and disclosure duties inside a court case; it sets up no register, no certificate and no filing. Your obligations become relevant when a person claims damage, which is why the practical preparation is internal records rather than a submission to an authority.
My product is free and open source. Am I out of scope?
If you develop or supply it outside a commercial activity, yes (Article 2(2)). The exclusion narrows the moment money or personal data enters: Recital 14 brings software supplied for a price, or for personal data used beyond security, compatibility or interoperability improvements, back into scope. A paid hosted version of an open-source project is a commercial product.
How long do I have to keep the records?
Plan for ten years from placing the product on the market, because that is when the outer limit in Article 17(1) expires. Where a personal injury takes years to appear, Article 17(2) extends that to 25 years. Three years is only the window in which the injured person must act after learning about the damage.
Can a business customer sue me under this directive?
Not through this route. Articles 1 and 5(1) give the right to claim to natural persons, and Article 6 excludes property and data used for professional purposes. That does not mean a business customer has no remedy — estimate, warranty and contract claims are untouched by Article 2(4)(b) — but they are fought on the contract, not on this directive.
If your firm builds, embeds or resells software and you want a second pair of eyes on where the exposure actually sits, tell us what you ship and who touches it. We build and maintain automation for small firms, and we would rather map this before a letter arrives than after.
