The Product You Didn’t Know You Shipped

You do not run a factory. You ship code — or a model behind an API — and let customers reach it over the network. So product liability read like someone else’s problem: a matter for carmakers and appliance manufacturers, not software. From December 2026, that reading is wrong.

In one paragraph: from 9 December 2026, the EU Product Liability Directive 2024/2853 treats software and AI systems as products. Strict liability applies without proof of fault; it cannot be excluded by contract against the injured person; a documentation gap can become a courtroom presumption of defect; and a non-EU maker must have an accountable operator inside the Union.

Directive (EU) 2024/2853, the new Product Liability Directive, repeals the 1985 regime (Directive 85/374/EEC) and rewrites it for the digital economy. It keeps the old bargain — liability without fault for a defective product that causes harm — and widens the word product until it reaches you. Member States must transpose it by 9 December 2026, and it bites on every product placed on the EU market from that date. Romania transposes on the same clock.

Software is the product now

The directive settles a question the 1985 text left open: software is a product. Operating systems, firmware, applications and AI systems all count, and so do the digital files that drive a manufacturing process. How the software reaches the user is deliberately irrelevant — embedded in a device, downloaded, or delivered as a service. The SaaS wrapper does not take your software out of scope.

There is one narrow exit. Free and open-source software supplied outside a commercial activity falls outside the regime — but the moment you charge for it, or take personal data in exchange, its product character returns. For a company that sells software or an AI system, no version of the business sits outside the definition.

Strict liability you cannot draft away

Strict means the claimant need not prove you were careless — only that the product was defective and caused harm. A product is defective when it fails to provide the safety a person is entitled to expect, and the directive reads that expectation through digital eyes: a missing security update, a known cybersecurity vulnerability, or the behaviour a system learns after it ships can each render a product defective. Defectiveness is judged even after the product leaves you, for as long as you keep control of it through updates.

The damage that counts has widened too. Alongside death and personal injury — now including medically recognised psychological harm — the directive covers the destruction or corruption of data a person does not use for professional purposes, and it drops the old €500 floor. Small harms now clear the bar.

Here is the part that reorganises a software business. As against the injured person, liability under the directive cannot be limited or excluded by contract. The limitation-of-liability clause that anchors every SaaS agreement — the cap, the exclusion of consequential loss — does not touch a product-liability claim. It still governs what your counterparties recover from you in contract, and operators can still allocate the loss among themselves by recourse; it simply offers no shelter from the directive itself.

The evidence rules were rebuilt for the black box

Regulators understood that no consumer can reverse-engineer a neural network, so they moved the burden. First, disclosure: once a claimant shows the claim is plausible, a court can order you to hand over the evidence in your possession about how the product works. Refuse, and defectiveness is presumed.

Then the presumptions stack. Defectiveness is presumed where you breach that disclosure order, where the product broke a mandatory safety rule — non-compliance with the AI Act among them — or where an obvious malfunction caused the harm in ordinary use. Causation is presumed where the damage is of a kind typically consistent with the defect. And the provision written for AI: where the technical or scientific complexity of a product makes defect or causation excessively difficult to prove, a claimant who shows both are merely likely gets the presumption anyway.

Read with the AI Act, the two instruments interlock: the AI Act tells you how to build and document the system; the directive turns a gap in that documentation into a presumption you must rebut in court. Your build record stops being paperwork and becomes your defence.

Who answers when the maker sits outside the EU

Liability does not rest on the manufacturer alone. The directive names a chain of economic operators — the maker of the product, the maker of a defective component, the provider of a service that makes it work — and, for anyone entering the single market from outside it, a cascade for foreign makers.

When the manufacturer is established outside the EU, the injured person looks first to the EU importer. If there is no importer in the Union, the maker’s EU authorised representative answers. If there is neither, the fulfilment service provider does. A distributor is on the hook if it cannot name an operator further up the chain when asked, and anyone who substantially modifies a product becomes its manufacturer for what follows. The architecture is deliberate: a claimant inside the EU should always have someone inside the EU to sue.

This is where product liability becomes a market-entry question. A MENA or US software or AI company reaching European customers is placing a product on the EU market, and the directive asks a blunt question back: who is your accountable operator inside the Union? Enter without an importer or an authorised representative and you have not escaped the liability — you have left it to attach to whichever distributor or partner cannot deflect it, which is not a relationship that survives the first claim. Entering the EU means switching this layer on deliberately, the way every other layer of European law switches on at the threshold (see Entering the EU Through Romania).

Build to the directive, and insure to it

Two moves follow, and neither waits for December 2026. The first is by design. Because you cannot contract out, and because a documentation gap becomes a courtroom presumption, the sound posture is to build safety and evidence into the product itself: AI Act conformity where it applies, a committed cadence of security updates, and a traceable record of how each release was built and decided — the material that lets you rebut a presumption instead of conceding it. A practice that already runs its work through logged, standards-checked pipelines is most of the way there (see Standards as Code).

The second is cover. Product-liability policies were written for manufacturing defects and often say nothing useful about software as a product; technology E&O and cyber policies were written for other risks and may exclude bodily injury or property damage. Between the three sits a gap the exact shape of the new directive. Map your exposure to your policies now, before a claim finds the seam — and remember that insurance sits behind a liability you can no longer cap by contract, not in front of it.

General information on the new Product Liability Directive (Directive (EU) 2024/2853) as an EU instrument and its transposition in Romania, not legal advice, and no lawyer–client relationship is created. The directive applies to products placed on the market from 9 December 2026, carries defences and detailed conditions not covered here, and any specific situation needs advice on its own facts and sector.