Who is liable when AI-generated code causes damage?

01

Is there a dedicated liability rule for AI-generated code?

No. None of the EU rules described here turns on where the code came from. The Product Liability Directive asks whether a product is defective and who placed it on the market or put it into service. Whether a person or a language model wrote the lines is not a criterion the directive text mentions.

The European Commission has withdrawn its proposal for a dedicated AI liability directive (COM(2022) 496); the withdrawal has appeared in the Official Journal since 6 October 2025 (C/2025/5423). Claims in contract or tort on grounds other than defectiveness are left untouched by the Product Liability Directive (Article 2(4)(b)). The technical side of the topic is covered by From prototype to a production-ready application.

02

Which dates shape the legal position for software?

NIS2 has applied in Germany since 6 December 2025, Article 50 of the EU AI Act since 2 August 2026, and the Cyber Resilience Act's reporting duties since 11 September 2026. The transposition deadline for the Product Liability Directive ends on 9 December 2026, and the Cyber Resilience Act applies in full from 11 December 2027.

Dates can shift: in July 2026, Regulation (EU) 2026/1744 pushed back the EU AI Act's high-risk requirements to 2 December 2027 and 2 August 2028, while keeping the start date for Article 50 unchanged.

03

What does the new Product Liability Directive change for software?

Directive (EU) 2024/2853 names software as a product explicitly, including software used over a network. It applies to products placed on the market or put into service after 9 December 2026, and turns on whether the product is defective, not on fault.

• Product: software, including as software-as-a-service (Article 4(1), recital 13). Pure source code as information is not a product.
• Manufacturer: anyone who develops a product, has it developed, presents it under their own name, or develops it for their own use (Article 4(10)). Anyone who substantially modifies a product outside the manufacturer's control and then makes it available or puts it into service also counts as a manufacturer (Article 8(2)).
• Defectiveness: the product does not provide the safety a person is entitled to expect; safety-relevant cybersecurity requirements feed into that assessment (Article 7).
• Exemption: free and open-source software developed or supplied outside a commercial activity (Article 2(2)).

Who can claim, and which damage counts

Natural persons have a claim (Article 5), for death, personal injury including medically recognised harm to mental health, damaged property, and destroyed or corrupted data (Article 6). Property used exclusively for professional purposes is excluded, as is data used for professional purposes. The directive therefore does not cover damage that a business alone suffers to such property or data; where the line falls for mixed use depends on the individual case and on the German transposition.

Updates and transposition in Germany

The defence that a defect did not yet exist when the product was placed on the market does not apply under Article 11(2) where the defect stems from software, from updates, or from missing safety-critical updates within the manufacturer's control. For code that is built quickly and kept under continuous development, the update route is therefore the one that counts. The directive must be transposed by 9 December 2026 (Article 22). The German Bundestag debated the government's bill to modernise product liability law (Drucksache 21/4297) at first reading on 4 March 2026. For older products, Directive 85/374/EEC continues to apply (Article 21).

04

When do the Cyber Resilience Act's reporting duties apply?

Article 14 of Regulation (EU) 2024/2847 has applied since 11 September 2026. Manufacturers of products with digital elements made available on the EU market report actively exploited vulnerabilities and severe security incidents to the competent CSIRT and to ENISA, and according to the Commission this also covers products already on the market.

Making a product available on the market means supplying it for distribution or use on the Union market in the course of a commercial activity, whether for payment or free of charge (Article 3(22)). According to the Commission's FAQ, no placing on the market occurs where a product is manufactured for own use; a purely internally developed and used application therefore, as a rule, falls outside the Cyber Resilience Act. Standalone SaaS solutions are, in the Commission's own view, not products with digital elements, unless they form remote data processing belonging to a product.

Intermediate cases stay open: an internal application later opened up to customers, a tool used by other companies within a group, a companion app for a device. The remaining requirements apply from 11 December 2027; for products already placed on the market beforehand, Article 69(2) applies them only where there is a substantial modification.

05

What role does Article 50 of the EU AI Act play?

Article 50 of Regulation (EU) 2024/1689 governs transparency, not damages. Since 2 August 2026, people are meant to be able to tell when they are interacting with an AI system, and providers must mark generated content in a machine-readable format. Article 99 provides for fines for breaches; Article 50 itself contains no separate claim for damages.

Roles, internal applications and practical labelling are covered in Does AI in an application need to be labelled?. A first orientation on classification is given by the EU AI Act check, and the whole regulation is set out on Implementing the EU AI Act.

06

How does NIS2 affect a company's own software and its service providers?

Germany's NIS2 implementation act has been in force since 6 December 2025 and obliges entities, not individual applications. Section 30(2) no. 4 of the BSI Act names supply chain security as a risk management measure. According to the BSI, this indirectly affects service providers too, even ones that do not themselves fall under the act.

The BSI states that regulated entities should contractually oblige their suppliers to take security measures and have them demonstrate compliance, for example on security by design, incident handling and patch management. For software built with AI tools, that can turn into concrete contract questions: which tools are in use, how generated code is reviewed, and how dependencies are maintained. Whether a company is itself regulated can be checked, as a legally non-binding orientation, with the BSI's NIS2 applicability check.

07

The four rules side by side

08

Which assumptions do not hold up against the legal text?

09

Which topics belong in a conversation with legal counsel?

10

Which documents make such a conversation easier?

How these documents come together in practice is covered in The business unit built an app and Running an application in-house.