Software Is a Product: What the New Product Liability Rules Change from 9 December 2026

A deadline expires on 9 December 2026 that has drawn far less attention this year than the AI Act. By that date, member states must have transposed Directive (EU) 2024/2853 of 23 October 2024 — the new Product Liability Directive. Its decisive sentence is short: software is a product — installed locally, consumed from the cloud or used as SaaS. AI systems are covered as a subcategory of software.

More interesting than that classification is what it sets in motion. Product liability is strict: what counts is not whether someone worked carefully, but whether the product was defective. That shifts the allocation of risk between developer, client and purchaser — in matters of proof, in obligations after delivery, in how far a manufacturer can invoke the state of the art. It affects anyone who places software or AI on the market, including small developers and system houses.

At a glance

• What applies: Directive (EU) 2024/2853, in force, to be transposed by 9 December 2026. Software is a product, AI systems a subcategory.
• What follows: strict liability for anyone placing software on the market; easier proof for injured parties; responsibility for updates after delivery.
• The catch: the German transposing act has not been passed; what is verified is a government bill of 25 February 2026. A fixed deadline, a moving statutory text.

What changes for software

The German Produkthaftungsgesetz (Product Liability Act) dates from 1989 and has not been fundamentally recast since. The government bill of 25 February 2026 — the “Gesetz zur Modernisierung des Produkthaftungsrechts” (Act Modernising Product Liability Law) — is meant to change that. The direction is set by the directive:

Question	Position so far	Directive (EU) 2024/2853
Is software a product?	disputed, mostly denied for intangible delivery	yes — local, cloud and SaaS treated alike
Are AI systems covered?	not specifically regulated	yes, as a subcategory of software
Burden of proof	essentially on the injured party, causation included	relief where proof is technically very difficult
After delivery?	state at the time of placing on the market	updates controlled by the manufacturer are covered
Defence “not discoverable”	classic ground for exoneration	remains — open how far it reaches for continuously controlled software

The last row is the most uncomfortable. The development-risk defence is cut for a product that leaves the factory and stays as it is. Software leaves nothing; it keeps being built while it runs — and whoever keeps building it can less easily claim he only had to know the state of the art for the day of delivery. How courts will resolve this is open; I am not aware of a decision on it.

Three objections worth thinking through

First: the deadline is fixed, the act is not. The directive is in force and 9 December 2026 is the transposition date; the German act is still in procedure. Whether and with what content it has been passed, I have not cross-checked and therefore do not present. Anyone drafting clauses today against a transposing act is drafting against a text he has not read — the sensible approach is to work from the mechanics of the directive.

Second: product liability does not replace your contractual risk, it comes alongside it. It is statutory liability towards the injured party, not contractual liability towards your client, and it targets personal injury and damage to property — not your customer’s lost profit because an interface stood still for three days. That remains a matter for the Werkvertrag (contract for work under German law). The difference lies in what can be shaped: contractual liability you can limit within bounds, statutory liability you cannot — and the injured party is not a party to your contract.

Third: with continuously updated software, placing on the market is not a point in time. For a machine it is a date on a delivery note. For software on a two-week release cycle it is a series, and for SaaS operated continuously it is doubtful whether that moment exists at all. Yet limitation periods and the relevant state of the art hang on that attribution. Anyone relying on his product having been on the market “before the cut-off date” is relying on a classification that is hard to defend.

Handover is the caesura everything used to be counted from. The thread beyond it is what is new: update responsibility whose end is as little visible as in the open statutory text.

What this means for your business

Settle the update obligation before it is attributed to you. If responsibility extends past delivery, the decisive contractual question is no longer only what is delivered, but for how long it will be maintained. Three points belong in explicitly: the promised period for security updates, the client’s duty to install them, and the consequence if he does not. How long that period must legally be is unsettled while transposition is open — the only thing you can plan with is what you fix yourself. The remaining building blocks are in AI contracts: what really has to be in them.

Keep a versioned software bill of materials — it acquires a liability function. The list of all third-party components with version and origin used to be a security topic. Now it is the basis for being able to attribute at all whether a fault comes from your code or from a supplied component — and thus the precondition for any recourse. Without it you answer externally for software you did not write, with no way to attribute it to anyone. That belongs in the build-vs-buy calculation.

Check insurance and release documentation before the next product ships. Does your liability policy cover product liability arising from software delivery, or does it stop at advisory errors? That is clarified beforehand, in writing. And can you evidence, for every release, what went out when and which tests ran? Where the injured party enjoys easier proof, your own documentation is what you are left with — and what is saved on it during an MVP phase is missing precisely when it is needed.

Conclusion

Treating software as a product is objectively overdue; the distinction between tangible and intangible delivery had long lost its persuasive force. The effect should not be overstated, though: the damage that hits most software projects remains a contractual matter.

What really shifts is the documentation burden. Easier proof on one side and update responsibility on the other mean that a dispute over software will be decided more by who wrote down what he shipped and tested, and when. That is not a legal but a craft question — and the part you can handle regardless of how the transposing act turns out.

If you want to know which of your contracts leave the update question open, let’s talk. I draft such clauses as a business lawyer and deliver the software they are about, under a Werkvertrag, myself.

FAQ

Does the new product liability regime already apply to software?

Not yet. Directive (EU) 2024/2853 of 23 October 2024 is in force, but it only has to be transposed by 9 December 2026. A legislative procedure is under way in Germany; what is verified is a government bill of 25 February 2026. Whether it has been concluded was an open question as of this article.

Am I affected as a small developer or system house?

Yes, if you place software or AI on the market. Liability attaches to that act, not to company size; small developers and system houses are covered too. Local, cloud or SaaS makes no difference. The question is not whether you are affected, but whether contracts and insurance fit.

Can I exclude product liability by contract?

Not towards the injured party. Product liability is statutory liability; the injured party is not a party to your contract. What you can shape is the internal relationship: recourse against suppliers, the client’s duty to install updates, warranties about the operating environment. The contract shifts the risk, it does not remove it.

What should I concretely do before December 2026?

Four things that hold even without the final statutory text. First, fix the period for security updates in the contract, including the client’s duty to install them. Second, keep a versioned software bill of materials so you can attribute a fault and seek recourse. Third, clarify insurance cover; fourth, document release dates and test steps so they can be evidenced.

---

Sources — as of 19/09/2026

• Bundesministerium der Justiz (Federal Ministry of Justice), product liability legislative procedure — https://www.bmjv.de/SharedDocs/Gesetzgebungsverfahren/DE/2025_Produkthaftung.html
• PwC Legal, product liability for software — https://legal.pwc.de/de/news/fachbeitraege/einfuehrung-der-produkthaftung-fuer-software
• Ferner, reform of product liability law — https://www.ferner-alsdorf.de/reform-des-produkthaftungsrechts-software-und-ki/
• IHK Hannover, what changes from December — https://www.ihk.de/hannover/hauptnavigation/recht/wirtschafts-und-wettbewerbsrecht2/wettbewerbsrecht/neues-produkthaftungsgesetz-ab-dezember-was-aendert-sich—6966802

On reliability: the content and deadline of the directive are well documented; the date of the government bill rests on secondary sources. The state of the German procedure was not cross-checked and is therefore not presented; individual articles of the directive are deliberately not cited.

This article is general information and not legal advice in an individual case. As of 19 September 2026 — check the current state of the legislative procedure before deciding.