A model update can change the safety analysis
An AI model update can be relevant to product liability when it changes product safety and contributes to covered harm. It does not create automatic liability simply because an incident occurred after deployment. Directive (EU) 2024/2853 addresses software, learning behaviour and manufacturer control after supply. The AI product liability framework explains why classification, safety, damage, causation and operator responsibility must still be assessed separately.
An update can change model weights, fine-tuning, inference settings or the model selected behind a stable endpoint. Application prompts and retrieval sources may also change behaviour without changing the underlying model. Distinguish these events in the release history. Otherwise an investigation may describe a model update when the material change was in application logic, or miss a supplier-controlled change because the public product name stayed the same.
Identify the deployed change
Preserve the old and new model identifiers, release time, rollout population and application configuration. Account-level, regional and staged deployments can mean that two users receive different behaviour on the same day. A release announcement proves that a change was announced, not necessarily that the affected installation received it. Stronger evidence connects the incident request or device to the deployed version.
Record what the update was intended to achieve, known limitations, evaluation results and approval decisions. A change improving average performance may introduce a different safety risk in a narrow use case. Conversely, a lower benchmark score may have no connection to the incident. Compare the actual failure pathway rather than assuming that aggregate improvements or regressions decide whether the product provided the legally expected safety.
Distinguish a new feature from a safety requirement
Article 7 considers all circumstances, including learning, reasonably foreseeable use and interaction with other products. It also states that a product is not defective solely because a better product, update or upgrade exists. The mere availability of a newer model therefore does not prove the earlier one was defective. Identify the safety issue that the alleged defect actually concerns.
Article 11 separately addresses software updates and the absence of updates necessary to maintain safety where the relevant matter is within manufacturer control. A desirable feature upgrade is not automatically a necessary safety update. Preserve the risk assessment explaining why a particular update was classified as a correction, enhancement or safety measure. Those labels are useful evidence but do not bind the legal assessment without the underlying facts.
Manufacturer control affects later-defect arguments
Article 4's control definition includes specified authorised integration or modification and the ability to supply updates or upgrades. Article 11 limits the exemption based on defectiveness arising after supply for listed matters within manufacturer control. This prevents the time of initial supply from being treated as the only relevant point in every software case, while leaving the other liability conditions intact.
Identify who could deploy the model, who approved its use in the finished application and whether the update was authorised. A model supplier, application developer and device manufacturer may have different powers. The learning-behaviour analysis addresses local adaptation, which should be kept distinct from a deliberate supplier release. Both can affect behaviour, but their records and decision-makers may differ substantially.
A chronology is necessary but not conclusive
An incident beginning after an update is a reason to investigate a causal connection. It is not itself proof that the update caused the harm. Other variables may have changed at the same time, including sensor calibration, input data, operating conditions or user instructions. Preserve those changes and identify whether they can explain the observed failure independently or in combination with the model.
A rollback can provide useful comparative evidence if carried out safely and documented. Record what was reverted, which other settings changed and whether the same conditions were reproduced. If the symptom disappears, that may support an update-related hypothesis without identifying the precise defect. If it remains, the update may still be relevant to another pathway. Retain original event evidence rather than relying entirely on later experiments.
Separate losses and legal dates
Article 6 defines covered injury, property and data damage, with exclusions. Lost business revenue, dissatisfaction with a model's style or a reduced service score does not automatically qualify. Where an update corrupts data, distinguish the affected data, its use and the mechanism from an inaccurate newly generated output. The remedy available under another contract or statute may differ from this product liability framework.
The corrected Directive concerns products placed on the market or put into service after 8 December 2026, with national transposition due by 9 December 2026. Do not assume that every update automatically restarts product dates or legal periods. Substantial modification has its own conditions. Under Article 10, defectiveness and causation still require proof or an applicable rebuttable presumption. A well-supported update analysis connects the exact change to the safety failure and resulting harm.
Keep partial rollout and failed deployment records as well as successful update records. A device may report a new release while retaining an older component, or receive only part of an intended configuration. The installed state is stronger evidence than the planned rollout schedule when the two differ. Document uncertainty where that state cannot be verified.
Records that help the review
Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.
- Incident-time model, application and configuration identifiers
- Relevant inputs, outputs and decision records
- Supplier roles and change-control history
Independent educational information at EU Directive level. National implementing law and procedure require separate review.
Primary sources and legal scope
This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.
- Directive (EU) 2024/2853, consolidated text: Articles 2, 4, 6, 7, 8, 9, 10, 11 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.