Logs connect system behaviour to the incident
AI logs can help establish which software ran, what information it received, what it produced and which actions followed. They are evidence, rather than a complete explanation or an automatic finding of defectiveness. Directive (EU) 2024/2853 still requires the relevant product, safety issue, covered damage and causal connection. The AI product liability framework explains how logs support those separate elements.
A useful record links a specific event to the deployed system state. A timestamp without a model version may be insufficient where the supplier changes models behind one endpoint. An output without the input or subsequent action may leave the causal pathway unclear. Begin with the question each record can answer and its limitations, rather than assuming that a large volume of technical data necessarily provides a reliable account.
Build one event sequence
Identify the incident time and the clocks used by the application, model endpoint, connected device and human reporting system. Clock differences can change the apparent order of events. Preserve original timestamps and time zones, then explain any conversion or correction. A normalised chronology should remain traceable to the underlying records so that another reviewer can check the reconstruction.
Link request identifiers, inputs, preprocessing, retrieved material, model responses, output filters and actions where those records exist and can lawfully be used. An application may alter a response before showing it to a user. A downstream rules engine may convert a suggestion into a command. The distinction between generated, displayed and executed content can determine which layer needs investigation. Missing links should remain visible as uncertainty.
Preserve originals and document exports
Record who obtained the logs, from which system, when and through what method. Keep original exports where practicable and use copies for analysis. If an export omits fields, truncates content or changes formatting, document that limitation. A dashboard screenshot can be useful but may not show all relevant records or explain the filters applied to produce the display.
Retention settings also matter. Rolling logs, account closure and automatic deletion may remove earlier events. Preserve what remains through appropriate processes, while recording any gap and its likely cause. Do not infer that an unlogged action did not occur unless the system was reliably expected to log that action. A logging failure and an absence of the event are different hypotheses that may need separate technical evidence.
Connect logs with version and control evidence
Combine event records with model identifiers, application builds, configuration and update history. Where a supplier's alias can point to different models, preserve any response metadata identifying the actual deployment. Distinguish the version requested from the version served if the records permit. The model update analysis explains why planned rollout dates cannot automatically stand in for the installed or hosted state.
Logs can also show who changed settings or authorised a deployment, but user names alone may not settle legal control. Compare access permissions, approval records and supplier arrangements. Article 4's manufacturer-control definition and Article 11's later-defect rules require their own analysis. A technical administrator, contracting customer and statutory manufacturer can be different persons, even when they all appear in the same event history.
Logging duties and disclosure are separate questions
The AI Act contains logging provisions for relevant high-risk AI systems, including Article 12. Their application depends on classification, actor, provision and applicable dates. It would be inaccurate to turn those provisions into a universal rule requiring every AI application to retain every prompt indefinitely. Product liability evidence needs and regulatory logging duties should be identified separately.
Article 9 of the Product Liability Directive provides a route for necessary and proportionate disclosure of relevant evidence in proceedings where its conditions are met. It includes confidentiality safeguards and does not grant unrestricted access to every model or dataset. Article 10 includes a rebuttable defectiveness presumption for a defendant's failure to disclose relevant evidence pursuant to Article 9(1). That is different from saying every missing internal log proves a defect.
Read records critically and preserve context
Logs may contain errors, incomplete messages or information supplied by another system. Compare them with device records, user accounts and physical evidence. A successful status code might show that a request was handled, rather than that its output was safe or correct. A recorded warning may not prove that a person saw it. Record what the field technically means before drawing a legal inference from its label.
Personal data and confidential information require lawful handling. Preserve relevant records without assuming that evidence collection overrides every other obligation. The corrected Directive's product scope begins after 8 December 2026, separately from the 9 December 2026 transposition deadline. National law remains relevant to procedure. A useful log analysis explains the event sequence, version identity, causal clues and remaining gaps, while avoiding a conclusion that either extensive records or missing records determine liability by themselves.
Where analysts annotate an event, keep the annotation separate from the original log field. A later explanation such as unsafe response is an interpretation, not necessarily text produced by the system. Preserving that distinction makes it possible to reassess the evidence when another technical explanation emerges.
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.