New Product Liability Directive: Software and Chat Assistants
Directive (EU) 2024/2853 counts software as a product; this article sets out key dates, types of damage, updates and rules of evidence for chat assistants.
In plain language
A new EU rule counts software as a product. This also holds when it runs as a service over the web. Anyone who offers an AI system is to count as the maker. The rule covers products put on the market after a key date in December. It pays for harm to people, to things used privately and to private data. A wrong answer that only costs money is not enough on its own. If a needed security update is missing, the maker stays liable. Courts can order that evidence be shown.
Since 1985, a European directive has governed who is liable for defective products, and it was written with movable goods in mind. Directive (EU) 2024/2853 replaces it and names software expressly as a product, whether it runs on a device or is delivered as a service over the network. For providers and operators of a chat assistant, this raises a new question alongside the familiar ones from contract and competition law: can an assistant be a defective product, and who is then liable for what? This article classifies the directive by its wording: the concept of product, key dates, types of damage, the notion of defect, updates, rules of evidence and the boundary with other bases of liability. It explains the legal position and does not replace professional advice in the individual case.
Labels in the illustration
- Placed on market by 8 Dec 2026
- previous law still applies (Art. 21)
- Placed on market from 9 Dec 2026: Directive (EU) 2024/2853
- Art. 2(1) as corrected; transposition deadline 9 Dec 2026 (Art. 22)
- 1
- Placing on market
- ten-year expiry
- period starts running
- Art. 17(1)
- 2
- Operation, updates
- stays within the
- manufacturer's control
- Art. 4(5), Recital 19
- 3
- Missing update
- security update missing:
- no later-defect defence
- Art. 11(2)
- 4
- Substantial change
- treated as newly supplied;
- new expiry period
- Recital 40, Art. 17(1)
- Covered damage (Art. 6)
- Death, personal injury, psychological health
- Property not used solely for professional purposes
- Private data, including recovery costs
- Not covered by themselves (Recital 24)
- Pure economic loss, e.g. from wrong prices
- Privacy infringements, discrimination
- Instead: contract, competition law, GDPR (Art. 2(4))
- Claims: three years from awareness (Art. 16); no exclusion by contract (Art. 15)
Software Becomes a Product
The German Product Liability Act (ProdHaftG) currently transposes Directive 85/374/EEC and defines the concept of product narrowly. Under its Section 2, a product is any movable item, even if it forms part of another movable or of an immovable item, as well as electricity. Software does not appear in that wording. The new directive considers it necessary, in the interest of legal certainty, to clarify that software is a product (Recital 13), and includes it in the definition:
‘product’ means all movables, even if integrated into, or inter-connected with, another movable or an immovable; it includes electricity, digital manufacturing files, raw materials and software
The same recital explains how far this reaches. Software is a product irrespective of the mode of its supply or usage, whether it is stored on a device, accessed through a communication network or cloud technologies, or supplied through a software-as-a-service model. As examples, the directive names operating systems, firmware, computer programs, applications and AI systems. Developers or producers of software, including AI system providers within the meaning of the AI Act, are to be treated as manufacturers. A chat assistant that runs as a service on a website is therefore not excluded merely because nobody downloads a file.
Key Dates: When the New Rules Apply
The directive dates from 23 October 2024 and is addressed to the Member States. They have to adapt their rules by 9 December 2026 (Directive EU 2024/2853, Article 22). Which products the new rules apply to is set out in Article 2(1), and that paragraph was corrected in May 2026: covered are products placed on the market or put into service after 8 December 2026 (Corrigendum to Directive EU 2024/2853). The original version named 9 December at this point. With the correction, the scope fits the transitional rule: the old Directive 85/374/EEC is repealed with effect from 9 December 2026 and continues to apply to products placed on the market or put into service before that date (Article 21).
| Date | What happens | Basis |
|---|---|---|
| 23 October 2024 | Adoption of Directive (EU) 2024/2853 | Title of the directive |
| Up to 8 December 2026 | Products placed on the market remain under the previous law | Article 21 |
| 9 December 2026 | Transposition deadline ends, Directive 85/374/EEC repealed | Articles 21 and 22 |
| From 9 December 2026 | Newly placed products fall under the new directive | Article 2(1), corrected version |
| 9 December 2030 | First evaluation of its application by the Commission | Article 20 |
For a chat assistant that is operated as a service and changed continuously, the moment of placing on the market is not always easy to determine. The directive offers a reference point: where a substantial modification is made through a software update or due to the continuous learning of an AI system, the modified product should be considered to be made available or put into service at the time the modification is actually made (Recital 40). Under Article 4(18), a modification is substantial where product safety rules classify it as such or, where they contain no threshold, where it changes the original performance, purpose or type of the product without this having been foreseen in the initial risk assessment, and the nature of the hazard changes, a new hazard is created or the level of risk increases as a result. An assistant that was on the market before the key date can thus fall under the new rules after a substantial modification.
The time limits also depend partly on the moment of placing on the market. Claims become time-barred after three years (Directive EU 2024/2853, Article 16), counted from the day on which the injured person became aware, or should reasonably have become aware, of the damage, the defectiveness and the liable economic operator. Independently of that, after ten years (Directive EU 2024/2853, Article 17) from placing on the market there is as a rule no longer any entitlement, unless proceedings are already pending. For a substantially modified product, this period starts when it is made available again, and for personal injuries with a latency period Article 17(2) provides a longer period.
Who Counts as the Manufacturer of an Assistant
Primarily liable is the manufacturer of the defective product (Article 8(1)). Under Article 4(10), a manufacturer is anyone who develops, manufactures or produces a product, who has a product designed or manufactured or presents itself as its manufacturer by putting its name, trade mark or other distinguishing feature on it, and who develops a product for its own use. In addition, the manufacturer of a defective component is liable where that component was integrated into a product under the manufacturer’s control and caused its defectiveness. A chat assistant typically involves several parties, and the directive does not assign them by name. The overview shows which features the assignment turns on:
| Party | Hook in the directive | Open question in the individual case |
|---|---|---|
| Provider of the assistant software | Develops the product (Article 4(10)(a)) | Which parts it controls itself and which are supplied |
| Provider of an integrated language model | Manufacturer of a component integrated under the manufacturer’s control (Article 8(1)(b)) | Whether the defect stems from the component or from its integration |
| Operator using the assistant under its own name | Presenting itself as manufacturer through name or trade mark (Article 4(10)(b)) | Whether use on its own website amounts to making available or putting into service |
| Operator that substantially modifies the assistant itself | Deemed manufacturer if it substantially modifies the product outside the manufacturer’s control and then makes it available or puts it into service (Article 8(2)) | Whether rules and knowledge base amount to a substantial modification |
| Free software outside a commercial activity | Excluded from the scope (Article 2(2)) | Liability of whoever integrates it into a product |
Compensation is available only for damage suffered by natural persons (Article 5). A company that deploys an assistant therefore cannot seek compensation for its own losses under the directive; its relationship with the software provider is governed by contract. For people who work with or use the assistant, by contrast, death and personal injury are covered regardless of the purpose of use, while property used exclusively for professional purposes and data used for professional purposes are excluded (Article 6(1), Recital 22). Whether an operator counts as manufacturer, as distributor or not as an economic operator at all in a specific set-up depends on the contract, the presentation and control over the individual parts. That assignment should be clarified with professional advice before a contract is concluded.
Which Damage Is Covered
The directive does not compensate every disadvantage a product causes. Article 6(1) lists the types of damage exhaustively, and for a chat assistant this list is the first point to check:
- Death or personal injury, including medically recognised damage to psychological health.
- Damage to or destruction of property, excluding the defective product itself, a product damaged by a defective component integrated into it by its manufacturer or within that manufacturer’s control, and property used exclusively for professional purposes.
- Destruction or corruption of data not used for professional purposes, including the cost of recovering or restoring them (Recital 20).
- Material losses resulting from this damage, and non-material damage insofar as national law provides compensation for it (Article 6(2)).
Types of damage other than those provided for in this Directive, such as pure economic loss, privacy infringements or discrimination, should not by themselves trigger liability under this Directive.
For an assistant’s day-to-day operation, this means that most errors that can occur in a chat are not product liability cases. A wrongly quoted price, an invented delivery promise or an incorrect statement about qualifications lead, if at all, to economic loss or to misleading information. Contract law and competition law apply to these; how competition law takes effect here is shown by the ruling on chatbot liability by the OLG Hamm. A data protection breach is not a product liability case by itself either; data protection law remains unaffected under Article 2(4). The directive gains significance where an assistant can affect a person’s body, property or private data, for example through tools that change data in a customer account, or through information on the safe use of a product.
Safety, Not Accuracy
Product liability asks whether a product provides the safety one is entitled to expect. Whether a piece of information is accurate is a different question with different rules. Both matter for an assistant, but they belong in separate checks.
The Notion of Defect: What Safety One May Expect
A product is defective where it does not provide the safety that a person is entitled to expect or that is required under Union or national law (Article 7(1)). Paragraph 2 lists the circumstances to be taken into account in the assessment. Several of them aim directly at software, and for a chat assistant they can be read as follows:
-
Presentation
Labelling, design, technical features and instructions count (point (a)). For an assistant, this includes how it introduces itself and what it says about its purpose.
-
Foreseeable use
What counts is reasonably foreseeable use (point (b)), which under Recital 31 also includes misuse that is not unreasonable. In a chat, these are the questions visitors are likely to ask.
-
Learning in operation
The ability to continue to learn or acquire new features after placing on the market must be considered (point (c)). Under Recital 32, a manufacturer should remain liable for unexpected behaviour that causes damage.
-
Timing and control
Where the manufacturer retains control, what counts is the moment the product left its control (point (e)). For a service that is continuously maintained, that may be well after launch.
-
Cybersecurity
Safety-relevant cybersecurity requirements are part of the product safety requirements (point (f)). Under Recital 32, a product can also be defective because of cybersecurity vulnerabilities.
-
User group
The specific needs of the group of users for whom the product is intended must be considered (point (h)), for example when an assistant is aimed at older people or at children.
Two clarifications are particularly instructive for operators. First, warnings are not sufficient to make an otherwise defective product safe; liability cannot be avoided simply by listing all conceivable side effects (Recital 31). A sentence such as “The assistant can make mistakes” is part of the presentation in this sense, but no substitute for a safe design. Second, a product is not defective solely because a better product or an update becomes available later (Article 7(3)). Improving an assistant does not by itself amount to admitting a defect in the earlier version (Recital 35).
The most delicate borderline case for assistants concerns information on how to use products. If someone asks in a chat how to connect a device or how to dose a substance and follows a wrong answer, personal injury or property damage can result. Whether that counts as a defect of the assistant software or as mere information, which under Recital 13 is not a product, is not expressly answered by the directive. Anyone answering usage questions after a purchase in a chat should therefore have safety-relevant details answered only from checked sources such as the operating manual and refer to a person when in doubt.
Updates and Security Updates
What is new is that a manufacturer’s responsibility does not end with delivery. Under Article 4(5), a product is within the manufacturer’s control where it is able to supply software updates or upgrades itself or via a third party; Recital 19 expressly clarifies this for the period after placing on the market. For an assistant operated as a service, this is the normal case, because the provider can roll out a new version without anything having to be installed on the operator’s side. For such cases, Article 11(2) restricts an important ground for exemption:
By way of derogation from paragraph 1, point (c), an economic operator shall not be exempted from liability where the defectiveness of a product is due to any of the following, provided that it is within the manufacturer’s control:
The provision then names four causes: a related service, software including software updates or upgrades, the lack of updates necessary to maintain safety, and a substantial modification of the product. In these cases, the argument that the defect only arose after placing on the market does not succeed. Recital 51 sets two limits: the directive does not impose any obligation to provide updates, and liability should not apply where installation is beyond the manufacturer’s control, for example where the owner does not install an update that was supplied. Which cybersecurity requirements apply to products with digital elements and which reports are due is governed separately by the Cyber Resilience Act; see the article on CRA reporting duties for chat assistants.
At XICBOT, updates run on three separate levels: the software via the rollout path, the embedded widget via version names without action on the operator’s side, and the knowledge via the refresh interval per source. The changelog names the level for every entry, so it is clear whether the operator has to do anything. The knowledge base writes every indexing run into a new version and only switches over at the end; earlier versions remain available for a rollback. How an assistant can be updated without switching it off is described in the article on updating during operation.
Disclosure of Evidence and Presumptions
The claimant still has to prove the defectiveness, the damage and the causal link (Article 10(1)). The directive does, however, compensate for the fact that injured persons rarely know how a product works internally. If a claimant presents facts and evidence sufficient to support the plausibility of the claim, the defendant is required, on request, to disclose relevant evidence at its disposal (Article 9(1)). Disclosure remains limited to what is necessary and proportionate, trade secrets are to be protected, and the court can require an easily accessible and understandable form. In addition, there are presumptions: defectiveness is presumed, among other cases, where the defendant fails to disclose relevant evidence (Article 10(2)). Where, despite disclosure under Article 9, proof is excessively difficult, in particular due to technical or scientific complexity, it is sufficient for the claimant to demonstrate that a defect or the causal link is likely (Article 10(4)); the defendant can rebut any presumption. On AI systems, the directive states:
For example, in a claim concerning an AI system, the claimant should, for the court to decide that excessive difficulties exist, neither be required to explain the AI system’s specific characteristics nor how those characteristics make it harder to establish the causal link.
For the provider of an assistant, this above all raises a question of traceability: can it be shown afterwards which version was active at a given time, which sources an answer came from and which rules applied? At XICBOT, binding answers to sources is the core mechanism: the assistant answers from what the stored sources say instead of formulating freely; a source reference only counts as used once its number appears in the answer text, and a finished answer without a single source reference used is recorded as a gap. The knowledge base page describes how this works. What legal consequence such documentation has in a dispute cannot be derived from this; it does, however, make it traceable what an answer was based on. Provability argues for logs and data protection law for data minimisation. Both can often be combined by keeping versions, rules and sources longer than individual conversation histories; see the article on retention periods for chat logs.
Boundaries: Contract, Competition Law and the OLG Hamm Ruling
Product liability applies alongside other bases of liability; it does not displace them. Article 2(4) expressly leaves data protection law unaffected, as well as claims under national rules on contractual or non-contractual liability on grounds other than the defectiveness of a product. For a chat assistant, this results in several levels that ask different questions and entitle different persons:
| Basis | Who can act | What it is about | Example in the chat |
|---|---|---|---|
| Product liability under the directive | Injured natural persons | Lack of safety, damage to body, property or private data | A tool of the assistant deletes private data in a customer account |
| Competition law | Competitors, associations and, for damages, consumers | Misleading commercial statements | The assistant names a qualification that does not exist |
| Contract law | Contracting parties | Defects and commitments | Dispute over whether a property named in the chat forms part of the contract |
| Data protection | Data subjects and supervisory authorities | Processing of personal data | Chat logs are kept longer than intended |
The difference from the OLG Hamm ruling lies in the subject matter. That case concerned the attribution, under competition law, of misleading statements by a chatbot to the company deploying it. The Product Liability Directive, by contrast, asks on a no-fault basis about the safety of a product and about damage to natural persons. Both share one point: whoever sets the framework of a system and can steer it will find it hard to rely on the system’s autonomy. How disputes about defects are handled in the chat is described in the article on complaints and warranty.
Towards injured persons, liability cannot be limited by contract: Member States ensure that the liability of an economic operator under the directive is not limited or excluded by a contractual provision or by national law (Article 15). Recital 56 expressly mentions financial ceilings in this context. Where several economic operators are liable for the same damage, one that has compensated the injured person can seek recourse against the others in accordance with national law (Article 14). Responsibilities and cooperation between provider and operator, on the other hand, are settled by contract. For micro and small enterprises supplying software as a component, Article 12(2) also allows the integrating manufacturer to waive its right of recourse by contract.
What Providers and Operators Can Check Now
There is still time before the key date to go through your own assistant along the lines of the directive. Whether it holds up in conversation is shown by test questions asked before go-live and after every change; how such an acceptance test is structured is described in the article on acceptance testing an AI assistant. The following points do not replace a legal review, but they structure the questions that arise in it:
- It is clear who develops software in your own set-up, who supplies components and under whose name the assistant appears.
- For every function it is recorded whether it can affect a person’s body, property or private data, for example through tools in the customer account.
- Safety-relevant information, for example on using a product, comes only from checked sources; otherwise the assistant refers to the manual or a person.
- Updates and security updates have an owner and are documented with their date.
- Versions of rules, instructions and knowledge base can be assigned to a point in time.
- Contracts with providers settle recourse, responsibility for updates and cooperation in any disclosure of evidence.
- Retention periods take account of both the interest in evidence and data minimisation.
Frequent questions
Is a chat assistant a product under the new directive?
Under Article 4(1), software is a product, and Recital 13 clarifies that this also applies to software supplied as a service over the network. A chat assistant can therefore fall within the scope. The content of an answer as mere information is not covered. How this applies to a specific set-up can be clarified professionally in the individual case.
From when do the new rules apply?
Member States must transpose the directive by 9 December 2026 (Directive EU 2024/2853, Article 22). It covers products placed on the market or put into service after 8 December 2026 (Corrigendum to Directive EU 2024/2853). For older products, the previous law generally continues to apply, although a substantial modification can change that.
Is a provider liable for a wrong price quoted by the assistant?
Under the Product Liability Directive, at least not because of the price alone: under Recital 24, pure economic loss does not by itself trigger liability under the directive. Other bases may apply to wrong statements in the chat, above all contract and competition law. How prices are stated properly in the chat is described in the article on prices in the chat.
Does a provider have to supply updates for its assistant?
According to Recital 51, the directive does not impose a general obligation to provide updates. However, if an update necessary to maintain safety is missing and this is within the manufacturer’s control, under Article 11(2) it cannot argue that the defect only arose after placing on the market. Obligations under other rules, for example on cybersecurity, remain unaffected.
Does a disclaimer in the terms of use help?
Towards injured persons, as a rule it does not: under Article 15, liability under the directive may not be limited or excluded by a contractual provision or by national law. According to Recital 31, warnings do not replace a safe design either. Between companies, for example between provider and operator, contractual arrangements on recourse remain possible.
How long can claims be brought?
The limitation period is three years (Directive EU 2024/2853, Article 16) from the day on which the injured person became aware, or should reasonably have become aware, of the damage, the defectiveness and the liable economic operator. Independently of that, after ten years (Directive EU 2024/2853, Article 17) from placing on the market there is generally no longer any entitlement, counted for a substantially modified product from when it is made available again. A longer period applies to personal injuries with a latency period.
Ask it yourself, Assistant of this website
Automated assistant