Directive (EU) 2024/2853. Your AI Is Now a Product.
The one-paragraph answer
The revised EU Product Liability Directive (Directive (EU) 2024/2853) makes software and AI systems products, subject to strict liability. No fault to prove. It applies to anything placed on the EU market after 9 December 2026. Courts can order you to disclose your technical evidence, and if you do not, they presume your product was defective. So can a court if you breached EU product safety law, which now includes the AI Act. Liability cannot be contractually excluded. And here is the part almost nobody has connected: the Digital Omnibus deferred the AI Act’s high-risk obligations to 2027 and 2028. It did not move this deadline.
Every AI compliance roadmap we see right now is built around the same relief. The Digital Omnibus deferred the EU AI Act’s Annex III high-risk obligations to December 2027 and embedded-product obligations to August 2028. Sixteen extra months. Teams have rescheduled accordingly.
The liability regime did not move. On 9 December 2026, five months from now, software and AI become products under EU strict liability law. And the AI Act, whose obligations you have just been told you have until 2027 to meet, is one of the safety regimes whose breach presumes your product was defective.
Read that sequence twice. The obligation is deferred. The liability that attaches to failing it is not. There is a window in which a company can be simultaneously not-yet-required to comply and already strictly liable for the consequences of not complying, and that window opens in December.
The second pain is quieter and lands on the general counsel. This directive imports disclosure into European product litigation. If a claimant makes a plausible case, a court can order you to hand over your technical documentation. If you cannot or will not, the court presumes the product was defective. Your risk assessments, your model documentation, your testing records, your patch logs: these stop being compliance artefacts kept in a folder and become litigation evidence a judge will read. Most organisations have never written them for that audience.
Directive (EU) 2024/2853 was adopted 23 October 2024 and entered into force 8 December 2024. Member States must transpose it by 9 December 2026. It repeals the 1985 Product Liability Directive, which stays in force only for products placed on the market before that date. It is a fully harmonising directive: Member States may not go stricter or looser.
The change that matters is one word. The 1985 directive covered “movables”, and whether software counted was argued for four decades. The new directive settles it. A product now expressly includes software, AI systems, and digital manufacturing files, whether embedded, standalone, or supplied as a service. Free and open-source software developed outside a commercial activity is excluded; the moment it enters a commercial product, it does not.
The claimant does not have to prove you were negligent. They prove a defect, damage, and a causal link. Whether you did everything right is not the question. Whether the product was defective is.
Death and personal injury, including medically recognised psychological harm. Property damage. And new for the digital age: destruction or corruption of data that is not used professionally. The old €500 property-damage threshold is abolished, and so are the financial caps on personal injury. Small claims are now viable, and consumer organisations can bring them collectively as representative actions.
Not in your EULA, not in your terms of service, not anywhere. You can allocate risk between yourself and your suppliers. You cannot allocate it away from the injured person.
The claimant bears the burden of proof. Then the directive hands them four ways around it.
A claimant who makes a plausible case can ask the court to order disclosure of your relevant technical evidence. If you do not comply, the court presumes the product was defective. The court can also require that the evidence be presented in a form that is accessible and understandable, which means a document dump does not discharge it.
If the claimant shows the product breached applicable EU product safety law, defectiveness is presumed. The AI Act is such a law. So is the Cyber Resilience Act. An AI Act non-conformity is no longer just a regulatory problem with a regulatory penalty. It is a civil-litigation presumption against you.
Damage caused by an obvious malfunction during normal use, in ordinary circumstances, presumes defectiveness.
This one was written for AI. Where the claimant faces excessive difficulties proving defect or causation because of the technical or scientific complexity of the product, and shows that defectiveness or causation is likely, the court must presume it. The directive tells courts to weigh the complexity of the technology, expressly naming machine learning.
A model whose behaviour cannot be explained is, in the design of this directive, a model whose defectiveness will be presumed. Opacity is not a defence. It is the trigger.
The directive treats the failure to supply security updates or patches, where those are within your control, as capable of rendering a product defective. An unpatched vulnerability that is exploited and causes harm is a strict-liability event.
Note the timing, because it is the single most useful thing on this page. This bites on 9 December 2026. The Cyber Resilience Act’s full obligations do not bite until 11 December 2027. For a full year, a software vulnerability can make you strictly liable in the EU under a regime that arrived before the regulation everyone associates with product cybersecurity. The SBOM, the patch log, and the defined support period were built for the CRA. They will be read in court first.
It applies to products placed on the EU market, wherever you are. And if a claimant cannot reach you because you sit outside the EU, the directive makes sure they can reach someone else in your supply chain: the importer, the authorised representative, the fulfilment service provider, and in defined circumstances the online platform that offered the product. If a platform will not identify the responsible operator within one month, it can be held liable as though it were the manufacturer.
Your European partners understand this perfectly, and they will price it into every contract you sign with them from now on. The commercial consequence will reach you before the legal one does.
The presumptions are not arbitrary. They exist because the literature is unambiguous that a claimant cannot realistically interrogate a modern software product.
“99% of vulnerabilities in client programs are caused by their dependencies”
If almost every defect arrives through a component the manufacturer did not write, then a consumer plainly cannot trace it, and a legislature that wants strict liability to mean anything has to shift the burden. That is precisely what the directive did.
“it remains challenging for practitioners to identify the harmful repercussions of their own systems prior to deployment”
If the builders cannot identify the harm in advance, the injured party certainly cannot reconstruct it afterwards. The technical-complexity presumption is the law’s answer to that asymmetry, and it points in one direction: the party that can account for its product wins, and the party that cannot, loses.
The deadline is 9 December 2026 and it is fixed in the EU text. It does not move with your Member State’s transposition progress.
Yes. Software is a product under this directive whether it is embedded, standalone, or delivered as a service. This is a deliberate change from the 1985 regime.
It reaches products placed on the EU market. If a claimant cannot reach you, they can reach your importer, your authorised representative, your fulfilment provider, or the online platform that offered the product. Your supply chain absorbs the exposure and will contract accordingly.
No. Liability under this directive cannot be contractually excluded or limited as against the injured person. Supplier contracts can allocate risk between businesses. They cannot remove it.
No, and this is the most consequential misunderstanding available. The Digital Omnibus deferred AI Act high-risk obligations to December 2027 and August 2028. It did not touch this directive, which applies from 9 December 2026. And AI Act non-compliance presumes defectiveness. The obligation moved. The liability did not.
It is closer to the opposite. Where technical complexity makes proof excessively difficult and the claimant shows defect or causation is likely, the court must presume it. Opacity does not protect you; it triggers the presumption. The evidence that rebuts it is exactly the evidence a well-governed AI programme produces anyway.
Directly. The whole discipline of The Operating Discipline for AI Library™ is the production of dated, documented, defensible evidence, and that is precisely what rebuts a presumption of defectiveness. Volume III produces the governance record; Volume V produces the security record and the Regulatory Crosswalk. The AI Risk & Governance Review builds the file before a court asks for it.
Read the source. This page exists because the interaction between this directive and the deferred AI Act deadlines is being widely missed, and the consequence of missing it is strict liability.
The AI Business Enablement Audit™ measures your organization against every framework in this library, including EU Product Liability Directive, and delivers a defensible governance dossier. Start or finish your audit below.
Start or finish your AI Audit →