Start with a structured question, rather than a conclusion
An AI product liability investigation should identify the product, legal framework, alleged safety defect, harm, causal pathway and potentially responsible actors. It should also preserve evidence supporting alternative explanations. The checklist below is an educational method for organising an investigation, rather than a required universal document pack or a prediction that a particular claim will succeed. The AI product liability framework explains the underlying Directive-level concepts.
Safety comes before reproducing a dangerous event. Technical investigation should use appropriate controlled methods and preserve the affected state where practicable. A later correction may be necessary without proving the original cause. Keep the incident evidence and remedial-action record distinct so that a replacement model or configuration does not silently become the only surviving description of the product involved.
Establish jurisdiction and the relevant dates
Record the market and supply route, the product's first placement on the market or putting into service, later changes, the incident and discovery of harm. The corrected Article 2(1) of Directive (EU) 2024/2853 concerns products placed on the market or put into service after 8 December 2026. The national transposition deadline is 9 December 2026. Those dates perform different functions.
Check applicable national legislation and procedural rules rather than assuming the Directive alone establishes every operational detail. An incident after the scope date does not automatically bring an older product within the new rules. If a later change might constitute substantial modification, preserve the before-and-after purpose, performance and risk profile, authorisation and subsequent supply facts. Do not select a legal regime solely from the accident year.
Identify the complete system state
Record the model, application build, relevant configuration, retrieval data, tools and any connected physical product. Where possible, preserve fixed version identifiers rather than only public aliases. Distinguish software supplied by different organisations and note remote dependencies. An application can keep the same name while its underlying model changes, making incident-time evidence more useful than a current product description.
Map the decision pathway from input to output and any downstream action. Preserve lawful copies of relevant original records, including transformations, warnings and human interventions. The AI log evidence guide explains how timestamps, request identifiers and missing fields affect reconstruction. Document gaps instead of filling them with assumptions about what the system probably did.
Define the alleged defect and expected safety
State the suspected mechanism specifically. An allegation that AI failed is less useful than an allegation that a particular output conversion bypassed a device interlock. Compare the mechanism with the product's presentation, instructions, reasonably foreseeable use, learning and interaction with other products. Article 7 calls for all relevant circumstances, rather than a conclusion based on one unfavourable output or one successful benchmark.
Collect safety tests, risk assessments, known limitations, release approvals and relevant incident reports. Identify which version and operating environment each document describes. Preserve evidence that challenges the proposed defect as well as evidence supporting it. A test conducted after a correction may show improvement without describing the earlier system, and a later product enhancement does not by itself establish that its predecessor was defective.
Separate the harm from the product problem
Identify the actual injury, affected property or corrupted data and preserve supporting records. Article 6 includes specified damage categories and exclusions. Damage to the defective product itself is excluded, as are certain component-related product damage and exclusively professional property. Data used for professional purposes is outside the specified data-damage category. A disappointing answer, lost fee or business opportunity does not automatically fall within this framework.
Then connect the alleged defect to the harm step by step. Who received the output, what decision followed and what caused the physical or digital damage? Consider independent inputs, installation problems, external events and later changes. A chronology showing that harm followed an output is useful, but it does not establish the causal mechanism by itself. Preserve uncertainty where the evidence cannot distinguish between explanations.
Map actors and evidence access
Identify who developed, supplied, branded, integrated and modified the relevant products or components. Record importer and other supply-chain roles where relevant. Do not automatically substitute AI Act provider or deployer labels for the Product Liability Directive's manufacturer categories. Associate each actor with a concrete activity, decision and source document. Contracts can illuminate arrangements without necessarily deciding the injured person's statutory rights.
Article 9 provides conditional, necessary and proportionate disclosure within proceedings, with safeguards. Article 10 begins with proof of defectiveness, damage and causation and provides defined rebuttable presumptions. Complexity alone does not decide the case. Record which evidence exists, who holds it and which question it could answer. A useful closing record distinguishes established facts, supported hypotheses, missing information and the national-law questions still requiring verification.
Assign a clear evidence reference to each factual statement in the investigation record. If two sources conflict, retain both and explain the unresolved difference. Review conclusions when new records become available, preserving the reason for any revision. This allows a later reviewer to see which conclusions depend on direct observation, supplier statements, technical inference or an assumption. The distinction is particularly valuable where a changing hosted model prevents exact reconstruction of the original deployment.
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.
- Product and market-date chronology
- Model, application, configuration and event identifiers
- Separate alleged defect, damage and causal-path records
- Actor map and evidence-location register
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.