An application deletes family photographs, connected medical equipment gives a dangerous reading, or a software update damages a device. Who may be responsible? The EU’s new Product Liability Directive expressly includes software and artificial intelligence systems. It does not, however, turn every incorrect chatbot answer into a compensation claim. The relevant dates, the kind of harm and the evidence still matter.

Position on 10 October 2026: Directive (EU) 2024/2853 has been adopted, but its new product period begins on 9 December 2026. A claim in Greece also requires checking the national transposing legislation and the law applicable to the particular product and incident.

1. Why 9 December 2026 is the relevant date

The original Directive must be read with its official May 2026 corrigendum. Corrected Article 2(1) refers to products placed on the market or put into service after 8 December 2026. The practical starting date is therefore 9 December; this is not an October change to every existing dispute.

The deadline for national transposition and a product’s market date answer different questions. Buying a subscription today, installing an update later and suffering damage on another date do not by themselves establish the applicable regime. The product concerned and when it was marketed or put into service must first be identified.

The EUR-Lex national-measures page displayed no Greek notifications when checked. That describes what had been notified to that database. It does not establish that Greece has enacted no legislation. Before giving advice or bringing proceedings, the actual national act and its official publication require a fresh check.

2. Software and AI can qualify as products

Being digital no longer excludes a product. Applications, operating systems and AI systems can fall within the product definition, whether installed on hardware or supplied through another digital delivery method. The Commission’s official explanation describes the adaptation to new technologies.

Not every digital service has the same legal treatment. Its actual function, each business’s contractual role and the connection between software, hardware and related services need examination. A specific exclusion concerns free and open-source software developed or supplied outside commercial activity. An “open source” label alone does not establish that exclusion.

Users should identify the application, version, supplier, terms and change history. A company integrating somebody else’s tool into its own product should map who designs, controls and markets the final result before an incident occurs. A familiar brand name does not necessarily identify every legally relevant participant.

3. Defectiveness concerns product safety

The central question is whether the product provides the safety a person is entitled to expect or the safety required by law. A disappointing service is not necessarily a defective product in this sense. Presentation, instructions, reasonably foreseeable use and interaction with other products can matter to the assessment.

An inaccurate travel recommendation from a chatbot is not automatically equivalent to a dangerous failure in software controlling medical equipment. These examples show why the analysis must be factual and technical; they do not predict a court’s decision. Cybersecurity requirements and an AI system’s capacity to learn after deployment may also be relevant.

Regulatory compliance and compensation liability are connected but distinct. Our AI Act article addresses AI obligations, while the Cyber Resilience Act article explains separate digital-product security requirements. Referring to either framework does not replace evidence of the harm in an individual case.

4. The covered harm has defined boundaries

The Directive covers categories including death or personal injury, medically recognised psychological harm, damage to property subject to specified exclusions, and destruction or corruption of data not used for professional purposes. It does not indiscriminately cover all financial loss or every mistaken software output.

If defective software destroys personal photographs, the data provisions may be significant. Losing a company’s commercial files raises a different question: the provision for non-professional data is insufficient on its own. Contractual remedies, other civil-liability rules or data-protection law may need to be considered.

Document the nature, duration and cost of the harm. Backups, restoration invoices and an independent technical report can help distinguish an actual loss from speculation about what might have happened. Keeping evidence does not establish entitlement by itself, but it allows the legal question to be assessed properly.

5. Updates and substantial modifications matter

Responsibility does not always end with the first release. Updates, upgrades or machine-learning functions remaining within the manufacturer’s control can affect the assessment. Failure to provide necessary security updates may also matter under the Directive’s conditions. This does not make the original manufacturer liable for every later intervention by an unrelated party.

The manufacturer is the primary responsible operator. Other economic operators may be relevant where production and supply chains extend outside the EU. A person substantially modifying a product outside the original manufacturer’s control and then marketing it or putting it into service can be treated as a manufacturer.

A reseller’s invoice therefore answers only part of the identification question. Information about the creator, importer or other relevant operator and the party making the decisive modification should be preserved. Separate the product’s development history from assumptions based solely on its retail packaging.

6. Evidence, disclosure and rebuttable presumptions

The framework retains the core issues of harm, defect and a causal connection. It also permits court-ordered disclosure of relevant evidence, subject to necessity and proportionality, and rebuttable presumptions in specified circumstances. Confidential information and trade secrets remain protected considerations.

A presumption is not an automatic victory. The other party can rebut it, and the court examines the applicable conditions. Technical complexity should be connected to the actual evidential difficulty, rather than invoked as a blanket reason to dispense with proof.

Keep secure copies of incident logs, notices, support exchanges and the steps preceding the problem. Avoid altering a device to reproduce a fault where doing so could destroy evidence or create danger. Technical examination should preserve the record, distinguish observed facts from hypotheses and explain the limits of its conclusions.

7. Useful preparation before December

Businesses can already inventory their products and versions, supply-chain responsibilities, update policies, incident reporting and retention of technical records. Support contracts and insurance terms should be assessed against the product’s actual functions. The aim is a usable account of responsibility when a complaint arrives.

For an individual, preparation means a coherent chronology: purchase, installation, update, incident, harm and communications. A product-liability claim, a contractual demand or another legal route may be appropriate. The choice follows the facts and applicable law, rather than an impressive description of the technology.

Official sources and editorial note

Sources: Directive 2024/2853, the 2026 corrigendum, the European Commission and the notified national-measures database.

Prepared with AI assistance and checked against the cited official sources on 10 October 2026. This is general legal information, not individual legal advice or a statement that a human lawyer has assessed a particular case.