When Software Becomes a Product
Directive (EU) 2024/2853 is the European Union’s new common regime for damage caused by defective products, and this opening focuses on the question its digital extension makes unavoidable: when does software, an AI system, or a SaaS-dependent product become part of product liability? The answer matters because the Directive does not merely add a few digital examples to an old rulebook. It changes the legal map by following safety through a product’s lifecycle and by asking which economic operator still controls, supplies, integrates, or modifies that safety. This series gives readers a way to make that map without treating every online service as a product or every software failure as a compensable injury.
The legal problem is no longer only a physical object
The Directive regulates liability for damage suffered by natural persons and caused by defective products. Its stated objectives are paired: keep the internal market functioning while ensuring a high level of protection for consumers and other natural persons. It repeals and replaces the earlier 1985 product-liability Directive because technologies, business models, and supply chains changed faster than the older meaning of “product” could comfortably accommodate.
That change is not just a response to novelty. The Union’s own explanation identifies three practical pressures. Software and AI can influence whether a product is safe. A product may be assembled from components and services supplied across a global chain. And an injured person may be at a serious information disadvantage when they must explain how a technically complex system produced harm. A rule that looks neutral on paper can therefore allocate risk unfairly if the person who was hurt cannot access the evidence needed to connect a defect with the damage.
The Directive’s answer remains no-fault liability. An injured person does not have to prove that a manufacturer or another economic operator was careless in the ordinary negligence sense. But “no fault” does not mean “no proof.” The claimant generally still has to establish three things: the product was defective, damage occurred, and the defect caused that damage. Later provisions soften that burden in defined situations, including technical or scientific complexity, but they do not turn every unexplained output or service interruption into liability.
This distinction changes what a claimant must ask. In a negligence claim, the central dispute may be whether an actor failed to take reasonable care. In this product-liability framework, the first question is instead whether the product supplied the safety a person was entitled to expect, followed by whether that safety failure caused a covered kind of damage. The operator may still have arguments about timing, control, scientific knowledge, modification, or the injured person’s own conduct, but the initial inquiry does not depend on proving a careless state of mind. That is particularly important where the system’s behaviour emerges from several layers of code, hardware, service, and later update rather than from one plainly identifiable human decision.
The regime also aims at a common baseline across the Union. Article 3 generally prevents Member States from choosing a more or less stringent level of consumer protection for matters covered by the Directive, unless the Directive itself allows a different approach. That does not eliminate national procedure or every other legal route. It means that the core product-liability question is meant to travel across the internal market with a shared structure, even while courts must apply it to different technologies and facts.
This is why the primary subject is the Directive itself, not AI regulation in the abstract. Its central relationship is between a product’s safety state and the operators who shape that state. The term “economic operator” is deliberately broad: it can cover the 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 relevant actor may therefore be a manufacturer, a software developer, an AI system provider, a component maker, an importer, a platform, or a later modifier. The relevant item may be physical, digital, or a service so closely integrated with a product that the product cannot perform a function without it.
From a product’s label to its safety lifecycle
The common intuition about SaaS is that it is “only a service”: code runs in a cloud, a customer accesses it through a network, and no boxed object changes hands. The Directive does not use that delivery channel as the decisive test. Its recitals say that software can be a product whether it is stored on a device, accessed through communication networks or cloud technologies, or supplied through a software-as-a-service model. Software can stand alone, or it can become a component of another product. The same reasoning reaches AI systems.
Yet the important shift is not simply that software has been renamed hardware. The better mental model is a safety lifecycle. A connected product may be placed on the market in one condition, receive an update in another, learn from later operation, depend on a third-party digital service, and remain under the manufacturer’s influence after the first transaction. The legal question is consequently not frozen at the moment of sale. It asks what safety a person was entitled to expect, what changed, and who had the relevant ability to affect the change.
A lifecycle view also prevents two opposite mistakes. One mistake is to treat the first market release as the only legally meaningful moment, as if later code could never change the product’s safety. The other is to treat every later improvement as proof that the earlier version was defective. The Directive rejects the second shortcut: a better product or later update does not, by itself, make an earlier product defective. The relevant issue is whether the earlier or later state failed the applicable safety expectation, taking account of foreseeable use, interactions, learning, cybersecurity, and control.
Consider a hypothetical home device that uses an AI application to detect dangerous conditions and a cloud service to deliver alerts. The physical device, the application, and the alert service should not be collapsed into one thing automatically. The first questions are functional: is the software itself a product, is the cloud service a related service whose absence would stop a product function, or is it merely a separate service? If the device becomes unsafe when connectivity disappears, that may be a defect in the device’s safety design even though ordinary internet access is not treated as a related service within the manufacturer’s control.
The second questions concern control. The Directive treats software updates and upgrades as relevant components of manufacturer’s control. Control can include the ability to supply an update through a third party, or authorising or consenting to integration, interconnection, or supply. It does not arise merely because technical integration is possible, because a brand is recommended, or because a manufacturer has not prohibited every potential service. That distinction prevents the regime from attaching every compatible cloud tool to a product while still reaching a service deliberately presented as part of the product.
The third questions concern time and change. The Directive requires courts to consider a product’s ability to learn or acquire new features, foreseeable effects of other products, safety-relevant cybersecurity requirements, recalls or other safety interventions, and the point at which the product leaves the manufacturer’s control. A later update or a better product does not by itself make the earlier version defective. But a missing safety update, a controlled related service, or a substantial modification can matter when the defect arose within the manufacturer’s control. Continuous learning by an AI system can even be relevant to when a substantial modification is treated as occurring.
The map can be reduced to one governing movement:
The arrows are not a promise that every case travels cleanly from one box to the next. They are a way to keep separate questions that are often confused. Classification asks what the relevant thing is. Defectiveness asks whether it supplied the safety people were entitled to expect. Operator analysis asks who made, integrated, supplied, presented, or controlled it. Damage asks whether the loss fits the Directive’s categories. Evidence asks how the claim can be proved. Time and defences then limit what follows.
The boundary is also a date
The new regime has a transition that is easy to summarise incorrectly. A corrigendum published on 7 May 2026 corrected Article 2(1): the Directive applies to products placed on the market or put into service after 8 December 2026, not after 9 December as the original wording stated. That correction must be kept separate from two other dates. Member States must bring their implementing measures into force by 9 December 2026, and the earlier Directive is repealed with effect from that date while continuing to apply to products placed on the market or put into service before it.
Those dates do not answer every temporal question for a long-lived SaaS or AI system. A product might enter the market before the new boundary and later receive software, or it might undergo a substantial modification after launch. The Directive separately addresses limitation, expiry, and modifications, so “the effective date” is not a sufficient analysis. The safest starting point is to identify the product and the relevant market or service event, then ask which legal regime applies to that event.
This also shows why the series will keep returning to the same core theme. The Directive’s importance is not that Europe has declared every digital business a manufacturer. It is that a product’s safety can be distributed across code, hardware, services, updates, data, and supply-chain decisions. Responsibility follows those relationships only where the statutory conditions are met, and the boundaries matter as much as the expansion.
The first practical task, then, is classification. Before asking who pays for harm caused by a SaaS-delivered AI feature, we must determine what the feature is in the Directive’s vocabulary, what it does to the product’s safety, and where its connection to the product begins and ends.