What the EU’s New Product Liability Regime Changes
Directive (EU) 2024/2853 changes the answer to a deceptively simple question: what happens when software or AI contributes to harm? The final judgment is not that every SaaS offering is a product, every model provider is automatically liable, or every digital loss is compensable. The deeper change is that product liability now follows the safety lifecycle and the operator’s legally relevant control across physical products, software, related digital services, updates, learning systems, and supply chains. This conclusion gives readers a reusable way to analyse a new system while keeping the Directive’s boundaries, evidence limits, and unresolved questions visible.
The central change is functional and temporal
The Directive’s subject is liability for damage suffered by natural persons and caused by defective products. Its reason for replacing the 1985 regime is not simply that technology became fashionable. Software, AI, global supply chains, and changing business models made it harder to decide what the product was, who controlled its safety, and how an injured person could obtain evidence. The new regime responds by extending the product concept and adjusting the liability architecture around the way digital products actually operate.
The functional part comes first. A product includes software, AI systems, digital manufacturing files, electricity, and raw materials within the Directive’s definition of product. Software can be supplied on a device, through a network or cloud, or through a software-as-a-service model. A digital service can become a related service and a component when its absence would prevent a product from performing one or more functions. A developer or producer of software, including an AI system provider in the relevant sense, is treated by the Directive’s recital as a manufacturer.
But inclusion is not unlimited. Information, the content of digital files, and mere source code are not products as such. A general internet-access service is not automatically a related service. Free and open-source software supplied outside commercial activity is excluded, while commercial supply and downstream integration can change the analysis. The first question is therefore not whether a system is digital. It is what safety-relevant function the thing performs, how it is integrated, and how it entered commercial supply.
The temporal part is just as important. Article 7 assesses safety through foreseeable use, interconnection, the ability to learn or acquire features, safety-relevant cybersecurity, product interventions, user needs, and the point at which the product leaves manufacturer control. Article 4 treats the ability to supply software updates or upgrades as part of manufacturer’s control. Article 11 narrows the ordinary post-market defence when a defect comes from controlled software, related services, necessary safety updates, or substantial modifications. A product can therefore remain legally connected to an operator after the first transaction.
This is the meaning of the series’ central theme: liability follows the safety lifecycle and control, not the product’s physical form or marketing label. “SaaS,” “AI platform,” “cloud service,” and “smart device” are useful commercial descriptions, but they do not finish the legal analysis. They identify an architecture to be examined.
One connected product, one complete analysis
Consider a hypothetical connected kitchen appliance. It has sensors and embedded software, uses an AI model hosted by another provider to detect dangerous conditions, depends on a digital alert service, is sold through an online marketplace, and comes from a manufacturer outside the Union. The manufacturer later authorises a third-party update, while the AI model continues learning from later operation. A harmful event occurs after the update.
The Directive does not allow the whole system to be treated as one undifferentiated “AI product.” The physical appliance is a product. The embedded software and model may be products in their own right or components of the appliance. The alert service may be a related service if the appliance cannot perform a function without it. The marketplace may be a mere intermediary, an economic operator, or subject to a distributor-style fallback if the statutory conditions apply. The general internet connection remains a separate boundary.
The analysis proceeds by relationships. What was placed on the market or put into service? Which software, service, or component determined safety? Did the manufacturer integrate, supply, authorise, consent to, or present that dependency as part of the product? Did a later actor substantially modify the product outside the original manufacturer’s control? Which Union-established operator can be identified if the original manufacturer is outside the Union? The answers may point to several candidate operators, but they do not make every participant liable.
The safety question comes next. Was the appliance unsafe under the public safety expectations and legal requirements applicable to it? Did the AI’s learned behaviour, the update, the alert service, a foreseeable loss of connectivity, or a cybersecurity vulnerability affect that safety?