Software is now a product: what the revised EU Product Liability Directive means for AI

If you are shipping an AI system into the EU and your compliance plan starts and ends with the AI Act, you have half a picture. The revised Product Liability Directive, Directive (EU) 2024/2853, published in the Official Journal on 18 November 2024, defines software as a product. That puts AI systems inside a strict liability regime where an injured person can claim compensation without proving you did anything careless.

Software is inside the definition

The old debate about whether software counts as a product is over. The Directive answers it in its definitions article:

'product' means all movables, even if integrated into, or inter-connected with, another movable or an immovable; it includes electricity, digital manufacturing files, raw materials and software;

That is Article 4(1). Software is listed by name, alongside electricity and raw materials. There is no carve-out for AI, no distinction between embedded and standalone code, and no requirement that the software ship on a physical medium.

Two further definitions widen the net. "Making available on the market" under Article 4(7) means any supply of a product for distribution, consumption or use on the Union market in the course of a commercial activity, "whether in return for payment or free of charge." A free tier does not take you out of scope if the supply is commercial. And Article 4(2) covers "digital manufacturing files," meaning digital templates that enable automated machinery to produce a tangible item. If your model outputs files that drive fabrication, the file itself can be a product.

Strict liability does not need your fault

Product liability is strict liability. The claimant does not have to show that you were negligent, that you cut corners, or that you knew about the problem. The claim rests on the product being defective and that defect causing the damage. Your state of mind is not an element.

This is a different kind of exposure from regulatory enforcement. Under a regulatory regime, an authority checks whether you met your obligations, and a diligent compliance program is your defense. Under strict product liability, a person who was harmed sues you, and the quality of your paperwork is not the question. The question is whether the product was defective and hurt someone.

The AI Act and the Directive do different jobs

The AI Act is regulatory and forward-looking. It sets obligations you must meet before and while you place a system on the market, and public authorities enforce it. Product liability is compensatory and backward-looking. It exists to make an injured person whole after the harm has happened, and private claimants enforce it in court.

	AI Act	Product Liability Directive
Character	Regulatory	Compensatory
Direction	Forward-looking: prevents harm before it occurs	Backward-looking: compensates harm after it occurs
Who acts	Public authorities	Injured persons bringing claims
Fault required	Not the frame; the frame is compliance with obligations	No; liability is strict
What compliance buys you	Avoids enforcement	Does not, by itself, defeat a claim

Both regimes can apply to the same system at the same time. Complying with the AI Act does not immunize you against a product liability claim, and paying out on a claim does not settle your regulatory position. Treat them as parallel tracks.

Who is on the hook

The Directive attaches liability to "economic operators," and Article 4(15) defines that term broadly: a manufacturer of a product or component, a provider of a related service, an authorised representative, an importer, a fulfilment service provider or a distributor.

The manufacturer definition in Article 4(10) deserves a close read. It covers anyone who develops, manufactures or produces a product. It also covers anyone who has a product designed or manufactured and presents themselves as its manufacturer by putting their name, trademark or other distinguishing features on it. White-labeling a third-party model under your brand can make you the manufacturer. So can developing a product for your own use, which Article 4(10)(c) covers expressly.

Article 4(4) then defines "component" as any item, "whether tangible or intangible," including a raw material or related service, that is integrated into or inter-connected with a product. A model supplied as a component of someone else's system is inside the definition even though it has no physical form.

Related services count too

Article 4(3) defines a "related service" as a digital service integrated into, or inter-connected with, a product in such a way that its absence would prevent the product from performing one or more of its functions. If your AI system runs as a cloud service behind a physical device, and the device cannot do its job without you, you are providing a related service. Providers of related services appear in the economic operator list, so this is not an academic point.

Updates keep you in the frame

Article 4(5) defines "manufacturer's control," and it reaches well past the moment of sale. A manufacturer is in control where it performs, authorizes or consents to the integration, inter-connection or supply of a component, "including software updates or upgrades," or the modification of the product. Control also exists where the manufacturer simply "has the ability to supply software updates or upgrades, themselves or via a third party."

Read that last clause again. The ability to push updates is enough. For AI systems that are patched, fine-tuned or upgraded on a continuous basis, the practical effect is that the manufacturer's control extends across the deployed life of the system.

Article 4(18) adds "substantial modification": a change to a product after it is placed on the market or put into service that is treated as substantial under Union or national product safety rules, or, where no such threshold exists, a change to the product's original performance, purpose or type that was not foreseen in the manufacturer's initial risk assessment. If you retrain a deployed model in a way that changes what it does, that definition is where the analysis starts.

No softer national version is coming

Article 3 sets full harmonization. Member States "shall not maintain or introduce" national provisions that diverge from the Directive, whether more stringent or less stringent, unless the Directive itself provides otherwise. You cannot pick a friendly Member State and expect a gentler liability regime, and you should not expect a national legislature to carve software back out.

The practical takeaway is a shift in mindset. The AI Act asks whether your governance is adequate before harm occurs. The Directive asks who pays after it does, and it answers that question without asking whether you were at fault. For the AIGP exam, you need to be able to keep these two frames separate and apply both to a single fact pattern: identify that software is a product under Article 4(1), classify the actors in a supply chain against the economic operator definitions, and recognize that update capability keeps a manufacturer within the Directive's concept of control. Candidates who only know the AI Act tend to reach for compliance answers when the question is about compensation. Knowing which regime is doing the work is the skill this material tests.