Product Liability For AI Systems
On 9 December 2026 European product liability changes shape, and software walks into it. Directive (EU) 2024/2853 of 23 October 2024 repeals the 1985 directive from that date. It covers products placed on the market or put into service after it. Under Article 4 a product includes software, so an AI system is a product.
Most AI governance reading stops at the AI Act. That skews the picture. The AI Act tells you what to do; product liability law tells you what follows when something goes wrong and somebody gets hurt.
What changed in product liability
The old regime dealt with physical goods, and courts spent decades arguing about whether code counted. Article 4 settles it. Software is a product however it reaches you, on a device, over a network or as a service. Pure information content stays outside. A manual, an e-book or raw source code falls out of scope.
Product liability here is strict. A claimant need not show that anyone was careless. Three things carry the claim: a defect, damage, and a causal link between them.
Who sits inside the net
Manufacturers of AI-enabled products and providers of standalone AI software are both economic operators for product liability purposes. A component supplier can carry liability alongside the manufacturer of the finished product. That matters when a foundation model goes into somebody else’s system under licence.
What a product liability claim can recover
Article 6 covers death and personal injury, including medically recognised psychological harm. Property damage counts too, other than damage to the defective product itself.
It also covers destruction or corruption of data that is not used for professional purposes. Read that line twice. A consumer-facing model that mangles a user’s files has caused compensable damage, and nobody needs to prove negligence.
Proving a product liability claim
Strict product liability is worth little if the claimant cannot see inside the system. A model’s behaviour resists reconstruction from the outside. The evidence sits with the defendant.
Article 9 lets a court order the defendant to disclose relevant evidence. Disclosure stays limited to what is necessary and proportionate, with protection for trade secrets. Article 10 goes further and builds in rebuttable presumptions.
A court presumes defectiveness in three situations. The defendant ignores a disclosure order. The product breaches mandatory safety requirements. Or an obvious malfunction caused the damage. Technical complexity opens a fourth route: where it makes the claimant’s task excessively difficult, a court may presume defectiveness or causation, provided the claim looks likely.
Treat that as a governance instruction. Documentation you cannot produce turns into a presumption against you.
Learning after deployment
Article 7 lists the factors a court weighs when deciding whether a product is defective. One of them names the effect of any ability to continue to learn or acquire new features after the product reaches the market.
Article 11(2) closes the obvious escape route. An economic operator cannot argue that the defect did not exist at the moment of supply where the defectiveness comes from software. The same applies to software updates or upgrades, to a lack of updates needed to maintain safety, and to a substantial modification. In each case the defence fails while the product remains within the manufacturer’s control.
Post-market monitoring therefore carries weight in a product liability claim. A model that drifts is a model whose safety was never fixed at the point of supply, and the choices made at deployment decide how much of that drift stays under your control.
The directive that did not survive
The Commission proposed a separate AI Liability Directive on 28 September 2022, aimed at fault-based claims. It never made it. Withdrawal was announced in the 2025 work programme, and the proposal formally fell in October 2025, as the European Parliament’s legislative train record confirms.
The practical consequence is worth stating plainly. Strict product liability for AI now runs through Directive (EU) 2024/2853. Fault-based claims fall back on national negligence rules, which differ across the member states.
What the exam does with this
The AIGP Body of Knowledge, the IAPP document setting out what the exam can test, asks candidates to understand how existing laws apply to AI. It names product liability alongside intellectual property, non-discrimination and consumer protection. Version 2.1 took effect in February 2026, and the 2026 update explains what moved.
Those questions rarely ask for an article number. They describe a harm and ask which regime answers it. Three things decide most of them. Is the claim strict or fault-based? Does the loss count as a compensable head of damage? Did the defendant still control the product when the behaviour emerged?
Domain II is where AIGP candidates most often lose marks to overconfidence. The AI Act feels familiar; everything around it does not. The free AIGP assessment will show you whether that describes you.
If it does, start with the EU AI Act fact sheet, which is free and worth an hour of anybody’s evening.
For the comparison questions specifically, the AIGP Exam Question Masterclass takes apart how they are put together.
