AI Software Supplied as a Standalone Product

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

A physical device is not essential

AI software can be relevant to product liability even when supplied without a physical device. Article 4 of Directive (EU) 2024/2853 includes software within the product definition. Delivery by download, hosted access or another arrangement does not justify assuming that the software falls outside the framework. The precise product and supply facts still matter. The AI product liability framework explains the remaining safety, harm, actor and causation requirements.

Standalone software should be distinguished from every service performed with software. Describe what the customer received and what the software actually did. An AI application provided to users raises different classification questions from a professional producing a report with internal software tools. A subscription label does not answer the legal question, but neither does the presence of software make every associated activity a product.

Define the supplied application

Record the application name, release, model identifier and configuration relevant to the event. An AI writing application, navigation tool or control program may have several dependencies hidden behind one interface. Determine whether the incident concerns the whole application, a model component or another element. The distinction between models and systems is particularly useful where a branded application uses a separate supplier's capability.

Preserve the presentation shown to users, including intended functions, limitations and instructions. Marketing statements can affect the safety context, but must be connected to the relevant release and foreseeable use. A tool presented as suitable for operational decisions raises different factual questions from an entertainment feature. This does not mean every advertising claim creates liability; it means the product's presentation belongs in the assessment rather than being ignored.

Assess safety instead of simple output quality

Article 7 asks whether the product provides the safety a person is entitled to expect or that applicable law requires, taking all circumstances into account. Relevant circumstances include foreseeable use, interoperability and learning behaviour. A software error might affect convenience, factual accuracy or safety. Those categories can overlap, but they should not be collapsed into a single conclusion that the software was defective in the legal sense.

For example, an application might misclassify an image without exposing anyone to a relevant safety risk. The same classification error in a different application could contribute to physical injury through a subsequent decision. Investigators need the actual product purpose and event sequence. The seriousness of a possible outcome does not dispense with evidence that the supplied software lacked the expected safety or that its behaviour caused the particular harm.

Damage categories limit the compensation framework

Article 6 covers death or personal injury, including medically recognised psychological harm, certain property damage and destruction or corruption of data not used for professional purposes. It excludes damage to the defective product itself and property used exclusively for professional purposes. The professional-use exclusion for data is different and broader. These boundaries are important when the affected item is intangible software.

A subscription fee, lost productivity or an unsuccessful business decision is not automatically covered damage under this Directive. Other national contractual or statutory remedies may be available, but they need separate analysis. Where data is corrupted, preserve what data existed, how it was used and what evidence distinguishes corruption from mere inaccuracy in a generated answer. An output containing false text is not necessarily destruction or corruption of existing protected data.

Follow the development and distribution chain

The application developer may be a manufacturer under Article 4, depending on the actual activities and branding. An upstream model or software supplier may raise component questions under Article 8. Importer, authorised representative and distributor provisions have their own conditions. Do not assume that a supplier's location outside the Union prevents the Directive from identifying a relevant operator within the supply chain.

Contracts, invoices, release notes and account records can help reconstruct that chain. A hosted model may change without a visible application update, making supplier-controlled deployment records particularly important. Preserve version aliases, requests and response identifiers where available and lawful. Their evidential value depends on whether they identify the actual product state, rather than simply proving that an account existed or that an API call occurred.

Establish timing and proof

The corrected Directive applies to products placed on the market or put into service after 8 December 2026. National transposition is due by 9 December 2026. A later software update does not automatically settle the temporal treatment of an existing product; changes, control and any substantial modification require examination. Check national implementing law rather than treating the EU-level explanation as a completed national determination.

Article 10 begins with proof of defectiveness, damage and causation. Its technical-complexity mechanism requires excessive difficulties despite disclosure and the specified demonstration of likelihood, and remains rebuttable. Preserve the original inputs, outputs, user actions and competing causes. A coherent assessment explains how the standalone software allegedly produced unsafe behaviour and how that behaviour reached the harm, rather than relying on the absence of hardware or the presence of an AI label.

Where access to the application ends, retain lawful copies of the material already available, including the relevant account settings and incident report. A later inability to log in should be recorded as an evidence limitation, rather than filled with assumptions about how the application must have behaved.

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.