The Safety Lifecycle: Control After Launch
Directive (EU) 2024/2853 treats defectiveness as a question of safety, not of whether a newer feature exists, and this chapter examines how that test operates after a software-enabled product reaches the market. The practical task is to judge a product that can learn, interact with other products, receive updates, or become vulnerable as conditions change. Readers should leave able to distinguish ordinary technological improvement from a safety defect and to identify the facts that keep a post-market software or service event within a manufacturer’s legally relevant control.
Defectiveness is a failure of expected safety, not a failure to be newest
Article 7 says that a product is defective when it does not provide the safety a person is entitled to expect or that is required under Union or national law. This is an objective safety test. It is not the same as asking whether the product was convenient, commercially successful, or as capable as the latest competitor. It is also not limited to the private expectation of one user. The Directive’s recitals describe the relevant benchmark as the safety the public at large is entitled to expect, assessed against the product’s purpose and circumstances.
The rule matters for software because a digital product can be perfectly functional in a narrow engineering sense and still be unsafe. An application might execute its instructions reliably while producing a dangerous command under conditions that its design should have anticipated. An AI system might return an output every time while learning a behaviour that creates an unsafe product response. A connected device might perform its ordinary function but fail in a way that exposes people when a foreseeable companion product or network condition changes. “It worked as coded” is not a complete safety analysis.
Article 7 requires courts to consider all relevant circumstances. The list begins with how the product is presented and its characteristics: labelling, design, technical features, composition, packaging, and instructions for assembly, installation, use, and maintenance. It includes reasonably foreseeable use, which is broader than the narrowest interpretation of intended use. It includes the effect of a product’s ability to continue learning or acquire new features after placement on the market or putting into service. It also includes the foreseeable effect of other products used together with it, the time at which it was placed on the market or put into service, and, where the manufacturer retains control, the time when it leaves that control.
That list prevents a digital product from being evaluated as if it were a sealed object. The safety analysis can include the surrounding system when interconnection is a reasonably foreseeable part of use. A smart-home product does not exist in a vacuum if it is designed to work with other devices. A software-controlled machine cannot be assessed without considering how its instructions explain installation, maintenance, and expected operation. For an adaptive system, the ability to learn is not a mysterious extra feature; it is a product characteristic that can affect the level of safety users are entitled to expect.
Safety-relevant cybersecurity is expressly included among the factors. This does not mean every security weakness automatically proves defectiveness. The relevant question is whether the weakness affects safety in a way that makes the product less safe than the public is entitled to expect or than applicable law requires. A vulnerability that allows an attacker to change a safety-critical command may be relevant in a way that a purely cosmetic or non-safety issue is not. The legal significance depends on the product, the foreseeable conditions, the applicable safety requirement, and the connection to the damage.
Recalls and other product-safety interventions also belong in the assessment. They can be evidence about the safety context, but the Directive’s recitals caution that an intervention does not by itself create a presumption of defectiveness. That distinction keeps a recall from becoming an automatic admission while allowing the court to consider why an authority or economic operator intervened. The same pattern appears throughout the Directive: a fact can matter to the safety inquiry without deciding the case alone.
The rule also accounts for products whose purpose is to prevent damage. If a smoke alarm, warning mechanism, or comparable protective product fails to fulfil that purpose, the failure is part of the defectiveness assessment. For an AI-enabled safety system, the question is not only whether the system produced an output but whether the product fulfilled the protective function for which people reasonably relied on it.
Warnings do not automatically cure an unsafe design. The Directive’s recitals explain that listing every conceivable side effect cannot make an otherwise defective product safe. Foreseeable use can include misuse that is not unreasonable in the circumstances, such as behaviour arising from a lack of concentration or the predictable behaviour of particular user groups. This does not make a manufacturer responsible for every imaginable action. It prevents a manufacturer from defining the safety analysis so narrowly that ordinary, predictable human behaviour disappears from it.
The other side of the rule is equally important. Article 7(3) says that a product is not defective merely because a better product, including an update or upgrade, has already been or is later placed on the market or put into service. Product liability is therefore not a general warranty of technological leadership. A later model can be faster, more secure, or more capable without proving that the earlier product was unsafe. The distinction is between improvement and a failure to provide the safety the earlier product was already required to provide.
A digital product can change after the first transaction
The first market event is not necessarily the end of the product’s legally relevant life. Manufacturer’s control under Article 4 includes performing, authorising, or consenting to the integration, interconnection, or supply of a component, including software updates or upgrades. It also includes modification of the product and the ability to supply software updates or upgrades itself or through a third party. The Directive therefore recognises a form of continuing control that has no close equivalent in a purely static product model.
Imagine a connected household device with an embedded model, a companion application, and a cloud service that sends safety alerts. At launch, the manufacturer may know the physical hardware and the initial software state. Later, the manufacturer can release a patch, authorise a third party to provide a service, change a model’s behaviour, or continue collecting the information that affects how the system operates. Each event can change the safety state. The relevant legal question is not whether the original box was defective on day one in isolation. It is whether the product’s safety failure emerged during a period in which the manufacturer retained a meaningful ability to affect the product.
Article 7 makes that timing explicit. When assessing defectiveness, the court can consider the moment the product was placed on the market or put into service and, where the manufacturer retains control, the moment the product leaves that control. Recital (19) says that a product should be considered to remain within the manufacturer’s control when the manufacturer retains the ability to supply updates or upgrades directly or through a third party. The product’s legal lifecycle can therefore extend beyond its commercial launch.
This continuing state is not unlimited. A manufacturer does not automatically control every service that can communicate with its product. Recital (18) says that technical possibility, recommendations of certain brands, or failure to prohibit potential services do not by themselves establish consent to integration or supply. Control is tied to an affirmative relationship: integration, supply, authorisation, consent, or presentation of the component or service as part of the product.
That boundary has practical consequences. If a manufacturer markets a particular cloud application as part of a smart product, the presentation can connect the application to the product more strongly than generic compatibility would. If the product is merely capable of communicating with independent tools selected by the user, the manufacturer’s control question is different. Neither example dictates an outcome without evidence, but both show why the analysis must follow decisions and representations rather than network topology alone.
Learning and cybersecurity turn time into a safety question
The Directive expressly requires attention to a product’s ability to continue learning or acquire new features. This is significant for AI systems because behaviour can change without a conventional software release. The recital explains that a manufacturer that designs a product with the ability to develop unexpected behaviour should remain liable for behaviour that causes harm. The point is not to impose liability for all uncertainty in machine learning. It is to prevent the fact that a product can change from being used as a reason to ignore that capability when judging safety.
Continuous learning can also matter to the legal timing of a substantial modification. The Directive’s recital says that when a substantial modification is made through a software update or upgrade, or because of the continuous learning of an AI system, the substantially modified product should be considered made available on the market or put into service when that modification actually occurs. A model’s later state is therefore not necessarily just an invisible continuation of the original product for every purpose. If the change is substantial, it can create a new legally relevant event.
Cybersecurity creates a parallel lifecycle problem. Security risks evolve after release. A product can be safe against a known threat at one moment and become unsafe when a vulnerability emerges or is left unaddressed. Recital (51) says economic operators should not escape liability when defectiveness consists of a lack of software updates or upgrades necessary to address cybersecurity vulnerabilities and maintain safety, where the relevant supply or installation remains within the manufacturer’s control. This is a limitation on relying on the ordinary claim that the defect did not exist when the product first left the manufacturer.
The qualification is carefully bounded. The Directive does not itself impose a general obligation to provide updates or upgrades for every product. Nor does it make an operator responsible where supplying or installing the relevant software is beyond the manufacturer’s control, for example when an owner does not install a safety update that was supplied to maintain the product’s safety. The question is therefore not “Was there any later patch?” but “Was a safety-relevant update needed, was it within the operator’s control, and how did its absence or installation affect the defect and the damage?”
Those questions keep three ideas separate. A security update can be necessary for safety without every update being legally necessary. A manufacturer can retain control without controlling the user’s final installation decision. And a vulnerability can be relevant to defectiveness without proving causation for a particular injury or property loss. The lifecycle model expands the facts a court may consider, but it does not remove the need to connect those facts to a covered harm.
The state model
The product’s safety lifecycle can be represented as a sequence of states, but the important point is what triggers a transition and what control persists through it:
The diagram should not be read as a presumption that every product passes through every state. Some products do not learn. Some receive no update. Some leave the manufacturer’s control quickly. The value of the model is that it asks what happened at the transition. A claimant may point to a safety failure after an update or a change in learned behaviour. An operator may argue that the relevant defect arose after control ended, that the change was not within its control, or that the user’s own conduct broke the connection. The facts determine which path matters.
The same model also explains why a better product is not automatically evidence of an earlier defect. “Updated” can mean a safer improvement, a new feature, or a response to a known vulnerability; those are not interchangeable. A court must still assess the safety expected at the relevant time and whether the later change reveals a defect, merely improves performance, or substantially changes the product.
What the lifecycle test changes
The Directive does not ask a manufacturer to guarantee that a digital product will never change. It asks the legal system to account for change when evaluating safety. Learning, interconnection, cybersecurity, updates, recalls, and post-market control become relevant because they can alter the product’s risk, not because technology receives a special presumption of defectiveness.
The practical result is a shift from a one-time release question to a controlled lifecycle question. Was the product safe in the relevant conditions? Could it change or acquire new behaviour? Did another product or service foreseeably affect it? Who could supply, authorise, or present that dependency? Was a safety update needed and within control? Did a user’s failure to install it matter? Did the event amount to a substantial modification? These questions do not identify the liable operator yet, but they define the safety state that the next analysis must assign to the people and businesses behind the product.