Learning is a safety circumstance
A product's ability to keep learning or acquire new features after supply is expressly relevant to defectiveness under Article 7 of Directive (EU) 2024/2853. This means adaptation belongs in the safety analysis. It does not mean every learning system is defective or that every change in behaviour establishes liability. The AI product liability framework connects learning with the relevant product, harm, operator and causal evidence.
Learning can describe several different processes. A device may adapt locally from its operating environment, a supplier may deploy newly trained model weights, or an application may change behaviour through updated retrieval data. The technical mechanism matters because it identifies what changed, when it changed and who controlled the change. A broad statement that the AI learned something is too imprecise to explain an incident.
Distinguish adaptation from ordinary variability
A probabilistic system may produce different outputs without learning anything new. Changes in inputs, sampling settings or external tools can also alter a result while the model stays fixed. Begin by testing the hypothesis that the relevant state changed. Compare model identifiers, stored parameters, configuration, input processing and environmental data, rather than inferring learning from the existence of two different outputs.
Preserve how the system was designed to adapt. Was adaptation enabled, constrained to a specific function or subject to human approval? What records show that an update or learning process actually occurred? The analysis of AI model updates distinguishes supplier-released changes from local adaptation. That distinction helps identify the evidence needed without assuming that one type of change is legally more significant in every case.
Assess foreseeable safety consequences
Article 7's assessment includes presentation, instructions, reasonably foreseeable use and interaction with other products. A product designed to adapt should be examined in its foreseeable operating conditions, including how adaptation affects safety measures. A high initial test score does not necessarily establish safe behaviour after a system changes in use. Equally, observing later deterioration does not prove the original product failed the legal safety test.
Relevant questions can include whether adaptation had meaningful limits, whether dangerous drift could be detected and what happened when monitoring detected a problem. Instructions may explain operating boundaries, but they should be considered with design and actual user circumstances. A safeguard that depended on information unavailable to the operator may work differently from one tested with expert supervision. These are factual considerations supporting the safety assessment, rather than separate automatic liability rules.
Preserve the state before and after change
Record the initial released state and the state closest to the incident. Keep model versions, parameter changes, adaptation settings and the inputs associated with the transition where those records exist and can lawfully be retained. A rolling log that overwrites earlier events can make reconstruction difficult. Clearly mark any gap rather than treating the latest snapshot as an accurate record of every earlier state.
Reconstruction should distinguish original evidence from experiments. Disabling learning and repeating a task may isolate a variable, but it also changes the system being tested. A simulation trained from later data can be informative without reproducing the original environment. State which conditions match and which do not. Reliable technical evidence depends on an honest account of those limits, especially where the precise adaptation sequence cannot be repeated.
Control and responsibility need their own analysis
Article 4 defines manufacturer control, including specified authorised integration or modification and the ability to supply software updates or upgrades. Article 11 restricts a later-arising-defect exemption for certain matters within that control, including software and missing updates necessary for safety. This makes authority and technical capability relevant, but does not establish that the manufacturer is responsible for every event involving an adaptive product.
Where another party changes the system, preserve whether the change was authorised, what risk it introduced and whether it could amount to substantial modification under the Directive. Do not assume that user feedback, ordinary configuration or every learned parameter creates a new manufacturer. Role allocation depends on the actual statutory conditions and supply history. The investigation should connect each relevant decision to its maker and supporting records.
Connect learning to covered harm
The claimant must address defectiveness, Article 6 damage and causation under Article 10, subject to conditional rebuttable presumptions. A graph showing model drift does not establish that drift caused the injury or property damage alleged. Investigate the path from changed behaviour through decisions or physical actions to the harm, including alternative causes and interventions that may have interrupted it.
The corrected Directive's product scope begins after 8 December 2026, separately from the 9 December 2026 transposition deadline. Applicable national legislation remains important. Preserve supply dates as well as the adaptation chronology. A useful conclusion identifies the safety consequence of the particular learning process and the evidence supporting it, while separating a plausible hypothesis from an established defect or a completed finding of legal responsibility.
Monitoring records can also show whether an adaptation warning reached anyone able to act on it. Record the warning time, recipient, interpretation and response. A warning generated internally but never presented to an operator has a different factual significance from a clear warning that was received and acted upon.
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.