Unexpected AI Output and Product Liability

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Unexpected does not automatically mean defective

An unexpected AI output can be important evidence, but it does not by itself establish a defective product or legal liability. Under Directive (EU) 2024/2853, the relevant issue is expected safety in all the circumstances, together with covered damage and causation. A surprising answer might be harmless, unsafe, misunderstood or caused by a different system layer. The AI product liability framework keeps those questions separate.

Unexpected also needs a reference point. Was the output unexpected to the user, contrary to the supplier's stated function, outside technical specifications or inconsistent with a mandatory safety requirement? These descriptions are not interchangeable. Preserve the expectation and its basis rather than treating surprise as a self-explanatory legal conclusion. The product's presentation and instructions may help explain what users were entitled to expect in the actual circumstances.

Preserve the complete event

Capture the original input, relevant system instructions, retrieved material, output and subsequent actions where lawful and available. A screenshot may omit hidden prompts, tool calls or a later transformation by application code. Record the application and model versions, timestamp, account configuration and operating environment. If the output reached a device or another program, preserve what was actually transmitted as well as what appeared on screen.

Do not replace an original record with a cleaner reconstruction. A later prompt that looks similar may have different context or settings. When records are incomplete, state the gap. Repeated experiments can test hypotheses, but their value depends on describing what matches the original event and what differs. Sampling variability can produce different outputs without any update or learning, so failed repetition does not necessarily invalidate the original observation.

Ask whether the output concerned safety

Article 7 assesses safety rather than demanding perfect accuracy or uninterrupted satisfaction. Relevant circumstances include presentation, reasonably foreseeable use, learning and interactions with other products. A wrong trivia answer and an unsafe command to machinery raise different questions. The same sentence may also have different implications depending on whether the application presents it as entertainment, tentative assistance or an instruction for operational use.

Warnings and human review can matter, but their practical operation must be examined. Was review possible before the output took effect? Did the interface communicate uncertainty? Were foreseeable users able to understand the limitation? A warning is evidence within the full assessment, rather than a universal answer. Equally, a user disregarding a relevant instruction does not eliminate the need to investigate the product's actual safety and the applicable legal rules.

Follow the pathway from output to harm

Article 6 specifies covered damage categories, including certain injury, property and non-professional data damage, with exclusions. Offence, disappointment or a bad business recommendation is not automatically covered damage under this Directive. If an output allegedly caused injury, identify the decisions and physical events linking the software behaviour to that injury. Preserve intervening actions and evidence that may support a different cause.

A separate decision-maker might accept, modify or reject an output. A safety layer might block it or introduce a new error. The relevant defect could arise in the model, application instructions, output conversion or integration with another product. The safety-testing evidence analysis explains how tests can examine the suspected mechanism without treating a single dramatic output as the whole case.

Understand obvious malfunction carefully

Article 10 includes a rebuttable defectiveness presumption where the claimant demonstrates that damage was caused by an obvious malfunction during reasonably foreseeable use or under ordinary circumstances. An allegation that an output was unexpected does not automatically meet that condition. The provision still requires the specified malfunction, circumstances and connection to damage. Other presumptions have different conditions and must be analysed separately.

Technical or scientific complexity can support a further conditional mechanism where excessive difficulties remain despite disclosure and the claimant demonstrates the relevant likelihood. It is not an automatic rule for every opaque model. Preserve enough factual evidence to identify what happened and why the alleged product behaviour is material, while recognising that internal technical evidence may be held by another party. Article 9 provides a structured disclosure route within proceedings, subject to safeguards.

Keep corrective action and original evidence distinct

A supplier may remove a model, change a filter or withdraw a feature after an incident. Such action can be relevant but does not independently prove that the earlier product was legally defective or caused the harm. Preserve the stated reason for the change and what was actually altered. Do not describe an ordinary enhancement as an admission without supporting evidence.

The corrected Directive's product scope starts after 8 December 2026; national transposition is due by 9 December 2026. Applicable national law and relevant supply dates remain necessary. A useful analysis of unexpected output identifies the original event, safety expectation, covered harm and competing causal explanations. It treats the output as evidence to investigate, rather than as a verdict about the system or its supplier.

Where several people observed the event, retain their accounts separately before reconciling differences. One person may have seen the output while another saw the resulting action. Combining those accounts too early can hide uncertainty about the sequence and make a later reconstruction appear more complete than the original evidence supports.

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.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.