1. Introduction: safety regulation and compensation in EU AI law
In 2024, the EU introduced rules on the safety of AI systems and general-purpose AI (GPAI) models by enacting the Artificial Intelligence Act (AIA)Footnote 1 and modified the rules on product liability by adopting the new Product Liability Directive (PLD),Footnote 2 which replaces the 1985 PLD.Footnote 3 Both instruments seek to adapt EU law to developments related to AI (Recital 3 sentence 1 PLD; Recital 1 sentence 1 AIA). This raises the question of the interplay between these two instruments. Product safety law, such as the AIA, and product liability law, such as the PLD, are rightly described as “two sides of the same coin” (Lohsse, Schulze & Staudenmayer, Reference Lohsse, Schulze, Staudenmayer, Lohsse, Schulze and Staudenmayer2023, p. 10), as they pursue a common goal – protection against dangerous products – but do so in different ways: while product safety law focuses on the ex ante prevention of harm, product liability law addresses ex post compensation (Lohsse et al., Reference Lohsse, Schulze, Staudenmayer, Lohsse, Schulze and Staudenmayer2023, p. 10). To the extent that their standards diverge, product safety legislation and product liability law can complement each other: risks that are not covered by product safety law may still be mitigated where manufacturers face liability for resulting damage, and vice versa. To the extent that their standards converge, both instruments can reinforce each other’s effectiveness: on the one hand, product liability claims can serve as a basis for the private enforcement of product safety law, complementing its public enforcement regimes. On the other hand, aligning product liability law with product safety law can facilitate the assessment of liability both for courts and for economic operators seeking to anticipate their liability risks.
This paper explores the extent to which these effects are realised by the AIA and the PLD. Recital 9 sentence 3 of the AIA makes clear that rules on compensation pursuant to the PLD “remain unaffected and fully applicable.”Footnote 4 Recital 46 sentence 3 of the new PLD, in turn, emphasises the “close relationship between product safety rules and liability rules.” Indeed, the new PLD contains several points of connection to product safety law. Its terminology is mostly aligned with the principles of the New Legislative Framework (NLF) for EU product safety regulation adopted in 2008 (Recital 12 PLD).Footnote 5 For example, the PLD now employs the terms “placing on the market” and “putting into service” instead of the term “putting into circulation” used in the 1985 PLD. Moreover, the new PLD establishes several substantive connections with product safety law. These links are explored in this paper. The paper takes into account developments up to March 2026.
The paper first briefly outlines the regulation of AI safety under the AIA (see Section 2). The focus is on mechanisms that can also be found in other EU safety laws, so that the following considerations may be applied analogously to the relationship between the new PLD and other product safety instruments, such as the General Product Safety Regulation (GPSR)Footnote 6 and the new horizontal Cyber Resilience Act (CRA).Footnote 7 In light of this focus on the general mechanisms of the AIA, the paper does not systematically address the Proposal for a Digital Omnibus on AI adopted by the European Commission in November 2025 and aimed at simplifying the implementation of the AIA,Footnote 8 as that proposal does not affect the AIA’s core regulatory concepts but merely introduces targeted simplification measures.
Following the introduction to the AIA, the paper examines how the new PLD integrates AI into its scope of application (see Section 3). Already at this stage, it becomes apparent that the PLD is limited in ways that reduce the potential alignment between the AIA and EU product liability – and, consequently, the aforementioned advantages of such an alignment. These limitations become even more evident in the subsequent, more detailed analysis: the paper examines how the AIA can influence the “defectiveness” of a product and thus the central element of product liability (see Section 4). It then considers the AIA’s role in the defendants’ key defences under Art. 11 PLD (see Section 5). Finally, the paper briefly addresses the influence of the AIA on the liability for “substantial modifications” under the PLD (see Section 6).
The analysis shows that the PLD provides several mechanisms that enable the AIA and the PLD to reinforce each other’s effectiveness. At the same time, it demonstrates that the PLD contains gaps that limit this effect and the associated benefits. In the final part, the paper argues that these gaps neither protect economic operators nor can be explained by the aforementioned complementary function of product safety law and product liability law; rather, they risk creating disparities and legal uncertainty, as they may be filled by divergent national laws applying different standards. The conclusion is that, although the PLD contains considerable potential for aligning AI safety and liability law, it does not fully exploit this potential (see Section 7).
2. AI in the AIA: “product” safety concepts for “systems” and “models”
The AIA regulates “AI systems” (Art. 3(1) AIA) and “general-purpose AI models” (Art. 3(63) AIA). It is built around a risk-based approach (Recital 26): certain AI practices are prohibited outright, such as the placement on the market of AI systems that exploit vulnerabilities, use purposefully manipulative techniques, or create facial recognition databases through the untargeted scraping of facial images from the internet (Art. 5 AIA). AI systems classified as high-risk, such as those that are components of certain machineryFootnote 9 or toys,Footnote 10 or that form part of critical digital infrastructureFootnote 11, are not banned but are subject to a dense regulatory regime (Arts. 6–49 AIA), which constitutes the core of the AIA. Certain AI systems, whether high-risk or not,Footnote 12 are subject to transparency obligations. For example, AI systems that interact directly with natural persons must comply with these requirements (Art. 50(1) AIA). Other AI systems are not specifically regulated under the AIA. Regarding GPAI models, the AIA notably imposes information and documentation obligations (Art. 53 AIA). GPAI models with systemic risk are subject to additional obligations related to risk assessment and risk mitigation (Art. 55 AIA). AI systems that form part of another product may also need to comply with other applicable EU product safety legislation, such as the GPSR, the Machinery Directive,Footnote 13 the Toy Safety DirectiveFootnote 14 or the CRA.
This paper focuses on the regulatory mechanisms employed by the EU legislator to govern high-risk AI systems. In this context, although the AIA does not regulate “products” but rather “systems” and “models” and imposes the main obligations on “providers” rather than on “manufacturers,” it nevertheless employs many techniques that are characteristic of EU product safety regulation under the NLF. Accordingly, the AIA has rightly been characterised as “predominantly a product safety instrument” (Almada & Petit, Reference Almada and Petit2025, p. 86). In line with the NLF, the AIA itself does not lay down detailed technical specifications for high-risk AI systems but instead formulates essential requirements.Footnote 15 For example, Art. 15(1) AIA requires high-risk AI systems to be “designed and developed in such a way that they achieve an appropriate level of accuracy, robustness and cybersecurity,” without further specifying the required level or the relevant parameters. Some of the requirements are clarified by other instruments. For example, high-risk AI systems that fulfil certain requirements of the CRA are deemed to comply with the cybersecurity requirement (Art. 12 CRA). Apart from that, the technical specifications are generally delegated to harmonised standards within the meaning of Art. 2(1)(c) Regulation (EU) No 1025/2012. Such standards are adopted by recognised standardisation bodies on the basis of a Commission request. Harmonised standards are not mandatory.Footnote 16 However, high-risk AI systems that conform to harmonised standards published in the Official Journal of the EU are presumed to be in conformity with the AIA’s requirements to the extent that the standards cover those requirements (Art. 40(1) AIA). The presumption is not irrefutable but makes it more difficult to establish non-compliance (Gerdemann, Reference Gerdemann2024, p. 618). In the absence of harmonised standards, the Commission may adopt implementing acts establishing common specifications for the essential requirements; compliance with such specifications likewise gives rise to a presumption of conformity (Art. 41(3) AIA).Footnote 17 As regards high-risk AI systems, the Commission has issued a standardisation request to the European Committee for Standardisation (CEN) and the European Committee for Electrotechnical Standardisation (CENELEC). This request is currently under execution.Footnote 18
Complying with harmonised standards can also facilitate the conformity assessment (Art. 43 AIA), a mechanism that is similarly typical of EU product safety law.Footnote 19 The applicable procedures vary depending on the system concerned: in some cases, internal control by the economic operator is sufficient, whereas in others, the involvement of a notified body is required. In some cases, it is permissible to rely on internal control instead of an external assessment if harmonised standards are applied (Art. 43(1) AIA). In the event of a “substantial modification” of the system, a new conformity assessment is required (Art. 43(4) AIA). Following the conformity assessment, an EU declaration of conformity must be drawn up (Art. 47 AIA), and the CE marking must be affixed to the high-risk AI system (Art. 48 AIA). Certain high-risk AI systems must also be registered in an EU database (Arts. 49, 71 AIA). The AIA further establishes post-market monitoring and incident-reporting obligations (Arts. 72, 73 AIA). Most obligations are imposed on the provider of the AI system or, where applicable, their authorised representative. However, the AIA also imposes obligations on importers and distributors and – departing from the traditional product safety approach – on deployers of AI systems (Arts. 26, 50(3) and (4) AIA), who form part of the user side.
Some of these mechanisms are also used to regulate GPAI models, notably the presumptions of conformity (Arts. 40(1), 41(3), 53(4) sentence 2, 55(2) sentence 2 AIA). To date, no standardisation request appears to have been issued in this area. However, pursuant to Arts. 53(4) sentence 1, 55(2) sentence 1 AIA, providers of GPAI models may also rely on a code of practice (Art. 56 AIA) to demonstrate compliance with their obligations.Footnote 20 In July 2025, the Commission published the “General-Purpose AI Code of Practice,” which also includes a “Safety and Security Chapter” (Samwald et al., Reference Samwald, Bengio, Schaake, Ziosi, Privitera, Reuel, Zacherl, Rajkumar and Anderljung2025). However, although the AIA is not entirely explicit in this respect, it is likely that reliance on a code of practice additionally requires formal approval of the code of practice by the Commission by means of an implementing act, as currently envisaged in Art. 56(6) subparagraph 2 AIA (Schneider, Reference Schneider, Schefzig and Kilian2026, mn. 20). At the same time, the Proposal for a Digital Omnibus on AI seeks to remove the Commission’s empowerment to adopt such implementing actsFootnote 21 and instead provides for a mere assessment of the adequacy of the code of practice,Footnote 22 so that no formal approval would be required.
Public enforcement of the AIA is entrusted to national market surveillance authorities, the Commission and the AI Office and is densely regulated in Chapter IX, Sections 3 and 5 of the AIA. By contrast, the AIA itself provides only a limited number of individual rights that may serve as a basis for private enforcement (Radtke, Reference Radtke2026, pp. 128–129). This emphasis on public enforcement is typical of EU product safety legislation. The AIA must, however, be read in conjunction with other EU instruments. Infringements of the AIA may have implications not only for the liability claims under the PLD, as discussed here, but also for other individual rights, for example, under the General Data Protection Regulation,Footnote 23 the Sale of Goods DirectiveFootnote 24 or the Digital Content DirectiveFootnote 25 (Radtke, Reference Radtke2026, pp. 130–131). It is also noteworthy that Art. 110 AIA adds the AIA to the list of EU instruments that may be enforced via representative actions according to the Representative Actions Directive.Footnote 26
3. AI in the new PLD: clarifications, limitations and open questions
When enacting the new PLD, the EU legislator clarified that product liability law also applies to software, including AI systems (Art. 4(1), Recital 13 PLD). However, there remain limits and unresolved questions regarding the application of the PLD to AI, which also affect the potential impact of the AIA on the PLD.
Above all, the PLD maintains the traditional distinction between “products,” on the one hand, and “services,” including “information,” on the other. According to Recital 13 sentence 4 of the PLD, information is not “to be considered a product, and product liability rules should therefore not apply to the content of digital files, such as media files or e-books, or the mere source code of software.” Defective services may give rise to product liability only insofar as “related services” can be classified as “components” of a product (Art. 4(3) and (4) PLD). The distinction between “products” and “services” already caused demarcation difficulties under the 1985 PLD and continues to do so under the new PLD, particularly with regard to AI (Gsell & Mayrhofer, Reference Gsell and Mayrhofer2025, p. 213; Rodríguez de Las Heras Ballell, Reference Rodríguez de Las Heras Ballell2025, pp. 14–17).
First, while Recital 13 PLD clarifies that AI systems qualify as products, it remains unclear whether AI models can themselves be classified as products or only as “components” of AI systems (see Rodríguez de Las Heras Ballell, Reference Rodríguez de Las Heras Ballell2025, p. 17). The fact that GPAI models are “capable of competently performing a wide range of distinct tasks” (Art. 3(63) AIA) and can be placed on the market independently – similar to AI systems – supports their qualification as products.Footnote 27 However, this view does not appear to be universally shared. AI models, as such, are not capable of being executed and may therefore be regarded only as components of a product when they become part of an AI system (see Borges, Reference Borges2025, p. 5).
Second, it remains unclear whether economic operators may incur liability for information generated by AI systems, such as harmful advice provided by AI chatbots. Liability appears conceivable where the output is generated or modified by the software itself and the system does not merely serve as a passive carrier of human-provided information (Gsell & Mayrhofer, Reference Gsell and Mayrhofer2025, p. 213; similarly, Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, pp. 90–91; Ebers & Vargas Penagos, Reference Ebers and Vargas Penagos2025, p. 34).Footnote 28
These demarcation difficulties – which may comparably arise in other legal instruments that rely on the notion of a “product”Footnote 29 – are avoided in the AIA, which, as previously mentioned, regulates “systems” and “models” rather than products and uses the term “provider” instead of “manufacturer.”Footnote 30
This limitation of the PLD to “products” and their “components” is closely related to another limitation: unlike the AIA (see Art. 25, Recital 83 AIA), the PLD does not seek to cover the entire AI value chain. Instead, it focuses on the production side and, to a more limited extent, on the distribution side, excluding mere users. The PLD establishes liability for manufacturers, including manufacturers of components and persons who substantially modify a product, as well as importers, authorised representatives, fulfilment service providers, distributors and certain online platforms (Art. 8 PLD). “Providers” within the meaning of the AIA are usually “manufacturers” (Recital 13 sentence 5 PLD).Footnote 31 By contrast, the PLD does not regulate the liability of mere “deployers” of AI systems within the meaning of the AIA that form part of the user side (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 103). As a result, liability claims against such deployers cannot be grounded in the PLD (Radtke, Reference Radtke2026, p. 132). Such claims could only be based on other legal regimes, notably national tort law.
4. AIA and defectiveness under Art. 7 PLD
Both the violation of (see Section 4.1) and compliance with (see Section 4.2) the AIA may influence the assessment of defectiveness within the meaning of Art. 7 PLD, albeit to different degrees. In determining whether a breach of safety-relevant requirements has occurred, the various product-safety-law mechanisms of the AIA, outlined above, should be taken into account (see Section 4.3).
4.1. Non-compliance with the AIA as a basis for defectiveness
According to Art. 7(1) PLD, a “product shall be considered defective where it does not provide the safety that a person is entitled to expect or that is required under Union or national law.” The second alternative explicitly states that a violation of product safety requirements renders a product defective. This effect was already widely recognised under the 1985 PLD, although it did not contain the second alternative; it was rightly held that “the safety which a person is entitled to expect” (Art. 6(1) PLD 1985) also encompassed the level of safety prescribed by law (see Fairgrieve et al., Reference Fairgrieve, Howells, Møgelvang-Hansen, Straetmans, Verhoeven, Machnikowski, Janssen, Schulze and Machnikowski2016, p. 102; Wagner, Reference Wagner2024a, p. 195; Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 97).Footnote 32 However, not every violation of the AIA results in a product being defective. The connection is limited by the scope of protection under the PLD (see Section 4.1.1) and by the temporal dimension of the assessment of defectiveness (see Section 4.1.2).
4.1.1. Limitations arising from the PLD’s scope of protection
The concept of “safety” referred to in Art. 7 PLD must be interpreted in light of the scope of protection offered by the PLD. The PLD does not protect against all types of product-related risks but only against the categories of damage defined in Art. 6 PLD, namely death or personal injury, damage to privately used property (excluding the product itself) and the destruction or corruption of privately used data. Accordingly, a violation of product safety law can render a product defective only where the breached requirement is intended to protect these interests (see Mayrhofer, Reference Mayrhofer2024, p. 492; Schucht, Reference Schucht2023, p. 77; Wagner, Reference Wagner2024a, p. 195). Consequently, not every infringement of the AIA leads to defectiveness within the meaning of the PLD. Product safety instruments do not only contain rules on substantive product requirements but also provisions designated to facilitate the enforcement of those requirements. Furthermore, the AIA does not only comprise product safety rules in the traditional sense but also pursues objectives of fundamental rights protection, such as privacy, that are usually not covered by EU product safety law (Recital 1 sentence 1 AIA) (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 84).
Given the scope of this paper, not all provisions can be examined.Footnote 33 Examples of safety-related rules include the prohibition of AI systems that use purposefully manipulative techniques or exploit vulnerabilities (Art. 5(1)(a) and (b) AIA), as such systems may cause personal injury within the meaning of Art. 6(1)(a) PLD. Other examples include the requirement that high-risk AI systems achieve an appropriate level of accuracy, robustness and cybersecurity (Art. 15(1) AIA),Footnote 34 the obligation to design high-risk AI systems in a manner that enables effective human oversight (Art. 14(1) AIA), and information and transparency obligations insofar as they aim to enhance the ability of deployers or other persons to avoid damage within the meaning of the PLD (e.g., Arts. 13(3)(b), 50(1), 53(1)(b) AIA). By contrast, the violation of provisions of the AIA that are intended solely to protect against purely economic loss or infringements of personality rights, or that merely facilitate the enforcement of the substantive requirements of the AIA does not lead to defectiveness. Examples include the prohibition of AI systems that create facial recognition databases through the untargeted scraping of facial images from the internet (Art. 5(1)(e) AIA), which primarily protects personality rights, as well as purely formal requirements such as the obligation to affix a CE marking (Art. 48 AIA) (Schucht, Reference Schucht2023, p. 77), to draw up technical documentation (Arts. 11, 53(1)(a) AIA) or other procedural obligations (see also Art. 83 AIA). Art. 12 AIA, which requires automatic record-keeping, serves both the monitoring of compliance with other regulatory requirements and the prevention of damage, as the resulting logs may help to identify and mitigate safety-related risks (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 106).Footnote 35
Three points should be added to this analysis: first, while the defectiveness of a product is assessed independently of the interest infringed in the individual liability case, causality between the defect and the damage (Art. 5(1) PLD) requires a link between the protected and the infringed interest. For example, a breach of record-keeping requirements can give rise to liability only if compliance would have prevented the specific damage. If the damage would have occurred even in the event of compliance – for instance, because the logs would not have enabled the risk to be avoided – the defect cannot be regarded as having caused the damage.
Second, it is noteworthy that where a violation of the AIA causes damage that is not covered by the PLD, liability may nevertheless arise under national law, for example, on the basis of fault-based liability regimes.
The third point concerns the relationship of Arts. 7(1), 10(2)(b) and 7(2)(f) PLD. Art. 10(2)(b) PLD establishes a presumption of defectiveness where “the claimant demonstrates that the product does not comply with mandatory product safety requirements laid down in Union or national law that are intended to protect against the risk of the damage suffered by the injured person.” It appears that the second alternative of Art. 7(1) PLD – which was introduced at a later stage of the legislative process than Art. 10(2)(b) PLD – renders this presumption redundant (Mayrhofer, Reference Mayrhofer2024, p. 494; Wagner, Reference Wagner2025, p. 144). In such cases, defectiveness is already established directly under Art. 7(1) PLD. Similarly, where product safety requirements are violated, there is no need to rely on Art. 7(2)(f) PLD, which requires that “relevant product safety requirements, including safety-relevant cybersecurity requirements,” are taken into account in assessing defectiveness. That provision becomes relevant primarily in cases of compliance with the AIA, where safety requirements inform – but do not conclusively determine – the assessment of defectiveness (see Section 4.2).
4.1.2. Limitations arising from the temporal dimension of defectiveness
The AIA is not confined to products that are placed on the market or put into service after its entry into force (see Art. 113 AIA), although Art. 111 AIA provides for certain exceptions and transitional periods.Footnote 36 Nor does the AIA preclude its own standards from evolving over time – for example, as a result of technological advances that enable higher degrees of accuracy and may thereby raise the “appropriate” level of accuracy within the meaning of Art. 15(1) AIA. Although the AIA primarily focuses on pre-market obligations, providers may be required to respond to such developments by taking corrective measures (Art. 20(1) AIA). Accordingly, the risk management system they need to establish must be “planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating” (Art. 9(2) AIA).
However, not every breach of the AIA’s post-market obligations leads to defectiveness under the PLD. Under the PLD, the relevant point in time for assessing defectiveness is, in principle, the moment when the product is placed on the market or put into service (Art. 7(2)(e) PLD). Accordingly, a violation of safety requirements that become applicable only after that moment does not, in principle, render a product defective. Unlike its predecessor, however, the new PLD provides that where the manufacturer retains control over the product, the relevant moment for assessing defectiveness is the time when the product leaves the manufacturer’s control. “Manufacturer’s control” exists where the manufacturer carries out or consents to the addition of a component to the product, modifies the product, or retains the ability to supply software updates or upgrades (Art. 4(5) PLD). This extension allows manufacturers to be held liable for the violation of certain – though not all – post-market obligations (Mayrhofer, Reference Mayrhofer and Messner-Kreuzbauer2026, pp. 96–97, 102–104; Wagner, Reference Wagner2024a, pp. 188–189). Defectiveness may arise, for example, where, after the entry into force of the high-risk AI requirements, a manufacturer significantly alters the design of a high-risk AI system that had been placed on the market before this date and fails to bring it into compliance with the applicable requirements (see Art. 111(2) sentence 1 AIA). Defectiveness may also be established where a required security update is omitted. The AIA does not explicitly impose update obligations; however, such updates may constitute corrective actions within the meaning of Art. 20(1) sentence 1 AIA (Spittka, Reference Spittka, Schefzig and Kilian2026, mn. 9).Footnote 37 By contrast, the mere violation of post-market obligations to inform about risks – for example under Art. 73 AIA – will not, in itself, render a product defective. As under the previous PLD, this issue is generally left to national law (Mayrhofer, Reference Mayrhofer and Messner-Kreuzbauer2026, pp. 106–109).
4.2. No general exoneration through compliance with the AIA
As previously mentioned, it follows from Art. 7(2)(f) PLD that compliance with product safety law shall be “taken into account” when assessing the safety that a person is entitled to expect. However, the exact consequences of compliance with product safety requirements are not explicitly regulated in the PLD (see Ulfbeck, Reference Ulfbeck, Lim and Morgan2024, p. 211). It can be inferred from the regulatory compliance defence (Art. 11(d) PLD), which exempts economic operators from liability for a defective product in certain cases of compliance, that conformity with product safety requirements does not automatically exclude defectiveness (Wagner, Reference Wagner2024a, pp. 196–197). At the same time, compliance with product safety law may, in exceptional cases, exclude defectiveness, namely where the legislator has exhaustively regulated legally unacceptable risks, leaving no room for additional safety expectations (Mayrhofer, Reference Mayrhofer2024, p. 496). The AIA, however, does not provide for an exhaustive regulation of AI-related risks. With regard to non-high-risk AI systems and GPAI models, the AIA regulates only certain aspects. In relation to high-risk AI systems, the regulatory framework is more detailed but still not exhaustive. This is evidenced by Art. 82 AIA, which empowers market surveillance authorities to intervene even where high-risk AI systems comply with the AIA. The legislator thus assumes that compliant high-risk AI systems may nevertheless pose unacceptable risks. Such risks are generally also capable of rendering a product defective. A further question is whether this category of compliant products that nevertheless entail a risk has any practical field of application (Wiebe, Reference Wiebe2022, p. 905). As high-risk AI systems are subject to numerous requirements that are formulated in broad terms in the AIA, in most cases where such a system fails to meet the safety expectations that a person is entitled to have, there will also be a violation of the AIA (see Gerdemann, Reference Gerdemann2024, p. 618). Where, for example, a high-risk AI system does not provide the level of robustness that a person is entitled to expect within the meaning of Art. 7(1) PLD, its robustness will typically also fail to meet the “appropriate” level required under Art. 15(1) AIA.
In any case, the manufacturer’s conduct may give rise to higher legitimate safety expectations than those provided for in the AIA. In particular, it can always be expected that the product conforms to the design specifications set by the manufacturer itself, as the manufacturer must be held accountable to its self-imposed standards (see Wagner, Reference Wagner2024a, p. 192). Liability for manufacturing defects – i.e. deviations from the manufacturer’s intended design – is therefore not affected by compliance with product safety law. Additionally, the product’s presentation, such as in advertising, must be taken into account (Art. 7(2)(a) PLD). For instance, a high price may indicate a higher standard (Vieweg, Reference Vieweg, Schulte and Schröder2011, p. 377), although it will usually not be sufficient on its own. The product presentation must also relate to safety within the meaning of Art. 7 PLD (see Section 3). For example, a product that is marketed as being more energy efficient than legally required cannot, for that reason alone, be expected to be safer than other products.
4.3. Assessing (non-)compliance with the AIA under the PLD
Overall, there is a strong connection between the AIA and the assessment of the defectiveness of AI products under the PLD, particularly in the case of high-risk AI systems subject to extensive regulation. However, as previously noted, the AIA's requirements are often formulated at a high level of abstraction and necessitate further interpretation. The following section therefore examines the mechanisms of the AIA that may assist courts and economic operators in assessing (non-)compliance. It focuses on harmonised standards and other technical specifications (see Section 4.3.1), certifications and declarations of conformity (see Section 4.3.2), measures adopted by public authorities or economic operators (see Section 4.3.3), as well as documentation obligations and other evidence-creating measures (see Section 4.3.4).
4.3.1. Harmonised standards and other technical specifications
With regard to high-risk AI systems and GPAI models, more detailed requirements than those outlined in the AIA itself will be laid down in harmonised standards, which are intended to translate the AIA’s requirements into technical specifications. Since these standards are not legally binding, non-compliance with them does not automatically render a product defective (Piovano & Hess, Reference Piovano and Hess2024, p. 85). Conversely, compliance with harmonised standards does not preclude a violation of the AIA. Furthermore, the (rebuttable) presumptions of conformity under the AIA arguably do not lead to a shift in the burden of proof under the PLD. It is generally unclear whether such presumptions of conformity could apply in civil liability proceedings at all.Footnote 38 With regard to the PLD, the presumptions correspond to its rules on the burden of proof insofar as Art. 10(1) PLD usually places the burden of proof of defectiveness on the injured party. However, Art. 10(2) and (4) PLD assign the burden of proof to the defendant under certain circumstances. These specific provisions of the PLD must arguably take precedence over the presumption of conformity contained in the AIA (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 101; Mayrhofer, Reference Mayrhofer2024, p. 497). Thus, where, for example, an obvious malfunction has occurred, defectiveness may be presumed pursuant to Art. 10(2)(c) PLD, even if the product complies with the relevant harmonised standards. Nevertheless, harmonised standards may still play a role in establishing defectiveness. Above all, they may serve as a basis for prima facie evidence.
A few words on prima facie evidence in general and in relation to the PLD: prima facie evidence makes it easier for the party bearing the burden of proof to meet that burden. It is generally recognised not only in some national legal systemsFootnote 39 but also at EU level, as illustrated by, for example, Art. 9(2) Antitrust Damages DirectiveFootnote 40 and Art. 70(1) Digital Services Act.Footnote 41 Prima facie evidence allows courts or authorities to treat a legal requirement that is typically fulfilled as also being fulfilled in the specific case, without the need for further investigation. Under the 1985 PLD, such prima facie evidence was applied, for example, by a German court with regard to the defectiveness of a cake consumed in a restaurant, where not only the claimant but also a large number of other customers fell ill after visiting the premises;Footnote 42 in such a case, a defect is typically present. Where prima facie evidence is not expressly regulated, it generally presupposes the existence of a general rule of experience that permits certain conclusions to be drawn from the established circumstances.Footnote 43 It is neutralised and therefore without effect where the defendant succeeds in demonstrating that the matter in dispute constitutes an atypical case in which the inference is not warranted.Footnote 44 Prima facie evidence appears to be reconcilable with the PLD’s rules on the burden of proof of defectiveness. As it may produce similar effects as a presumption, one might question whether it is compatible with Art. 10 PLD, which exhaustively (see Art. 3 PLD) regulates the burden of proof of defectiveness. However, under the 1985 PLD – which was likewise interpreted as fully harmonising the rules on the burden of proof laid down therein – the Court of Justice of the European Union (CJEU) held it permissible for national courts to draw conclusions from a set of circumstances where the available evidence is sufficiently serious, specific and consistent, taking into account all evidence and arguments.Footnote 45 In the case of prima facie evidence, these requirements are met, since the existence of a general rule of experience does not automatically result in a presumption of defectiveness but must be assessed alongside the other evidence presented by the parties (see Seibl, Reference Seibl, Gsell, Krüger, Lorenz and C.2026, mn. 142).Footnote 46
Returning to the role of harmonised standards: against the background of the aforementioned prerequisites of prima facie evidence, non-compliance with such standards may constitute prima facie evidence of a violation of the AIA (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 99; Mayrhofer, Reference Mayrhofer2024, pp. 494–495).Footnote 47 A general rule of experience can be formulated whereby non-compliance with such standards normally entails a violation of the relevant EU legal act: under the regulatory system of the AIA, adherence to harmonised standards represents the normal route to compliance with mandatory requirements, while compliance by other means is conceived as the exception (see Arts. 43(1), 53(4), 55(2) AIA). Moreover, harmonised standards are drafted by specialised standardisation organisations with the involvement of stakeholders and the Commission,Footnote 48 making it highly likely that they correctly specify the AIA’s requirements.Footnote 49 Conversely, compliance with harmonised standards may give rise to prima facie evidence of conformity with those requirements, thereby making it more difficult to establish defectiveness (Mayrhofer, Reference Mayrhofer2024, p. 496).Footnote 50
It appears that these considerations can be transposed to common specifications and to codes of practice within the meaning of Art. 56 AIA, insofar as providers of GPAI models may rely on them pursuant to Arts. 53(4) and 55(2) AIA. These instruments are intended to fill gaps in harmonised standards and are likewise expected to be developed with the involvement of experts, the Commission and relevant stakeholders.Footnote 51 By contrast, non-compliance or compliance with mere guidelines (Art. 96 AIA) and other specifications that are neither intended to substitute harmonised standards nor established through comparable procedures may constitute no more than an indication of the presence or absence of a defect (Mayrhofer, Reference Mayrhofer2024, pp. 495–496).
As previously noted, prima facie evidence is neutralised where atypical circumstances exist that undermine the inference drawn from the given circumstances.Footnote 52 Atypical circumstances capable of displacing the initial appearance of a violation of the AIA may include, for example, the choice of a conformity assessment procedure that does not presuppose the application of harmonised standards or the existence of formal objections to the relevant standard.Footnote 53 In the context of AI, the multiplicity of possible design choices could facilitate the neutralisation of the prima facie evidence. An initial appearance of compliance with the AIA's cybersecurity requirements may, for instance, be undermined where the applicable harmonised standards are outdated and fail to reflect newly identified cybersecurity risks.
The usefulness of the aforementioned specifications and the resulting prima facie evidence for assessing defectiveness – both by courts and by economic operators seeking to predict their liability risks – will depend on their degree of specificity and their adaptability to technological developments, two objectives that may come into tension with one another. For instance, the current version of the Code of Practice for GPAI models requires the implementation of “appropriate” safety mitigation measures to comply with Art. 55(1) AIA (Samwald et al., Reference Samwald, Bengio, Schaake, Ziosi, Privitera, Reuel, Zacherl, Rajkumar and Anderljung2025, p. 17). While this formulation lacks precision and may therefore raise questions regarding its interpretation, it remains adaptable to evolving risks. The Code of Practice also provides a list of examples of safety mitigation measures, which may serve as a reference point for courts and economic operators when assessing whether additional measures could be regarded as appropriate.
4.3.2. Certifications and declarations of conformity
The absence of a required certification or declaration of conformity does not, as such, establish a violation of the AIA’s safety-related requirements or indicate another form of defect (Schucht, Reference Schucht2023, p. 77). Usually, prima facie evidence of defectiveness is not justified either: there is no general rule of experience allowing non-compliance with substantive requirements to be inferred merely from the absence of a certification or declaration of conformity. Such an absence may be attributable to a wide range of causes. Prima facie evidence may, however, be conceivable where a conformity assessment procedure has been initiated but has not resulted in a positive decision; in such cases, the termination of the procedure will typically be due to a failure to meet the assessed requirements (Mayrhofer, Reference Mayrhofer2024, p. 497).
Conversely, the existence of a certification or declaration of conformity does not automatically establish that the product complies with the assessed requirements (see Foerste, Reference Foerste, Foerste and Graf von Westphalen2024, p. 415). Prima facie evidence of conformity may be conceivable where a notified body has issued a positive assessment of the AI system. By contrast, a certification or declaration of conformity based solely on self-assessment (e.g., Art. 43(1) subparagraph 1(a) AIA) cannot give rise to such prima facie evidence (see Foerste, Reference Foerste, Foerste and Graf von Westphalen2024, p. 415).
Exceptionally, Art. 42(2) AIA establishes a presumption of conformity with the cybersecurity requirements (Art. 15 AIA) for high-risk AI systems that have obtained a cybersecurity certificate or a statement of conformity pursuant to Regulation (EU) 2019/881. As in harmonised standards, such presumption, in principle, corresponds to the claimant’s burden of proof under Art. 10(1) PLD. However, once again, the divergent rules on the burden of proof set out in Art. 10(2) and (4) PLD must take precedence.
4.3.3. Measures adopted by authorities or economic operators
Similarly, neither a finding by authorities or by economic operators themselves that an infringement of EU product requirements exists, nor the absence of such a finding, automatically establishes either non-compliance or compliance with those requirements (Müller, Reference Müller2024, p. 10). In particular, the AIA does not provide for a binding effect comparable to that laid down in Art. 16(1) Council Regulation (EC) No 1/2003, Art. 9(1) Antitrust Damages Directive, or Art. 39(5) Digital Markets ActFootnote 54 (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 83).
Nevertheless, pursuant to Art. 7(2)(g) PLD, product recalls or other relevant interventions by a competent authority or an economic operator in connection with product safety must be taken into account when assessing defectiveness. According to Recital 34 sentence 2, such interventions “should, however, not in themselves create a presumption of defectiveness.” Here, too, prima facie evidence may be conceivable, in a manner comparable to Art. 9(2) Antitrust Damages Directive (Mayrhofer, Reference Mayrhofer2024, p. 498; Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 100).Footnote 55 Nevertheless, such prima facie evidence is likely to be easily neutralised, for example, where relevant circumstances were not considered by the authority, or where the manufacturer adopted a measure based merely on suspicion (see Schucht, Reference Schucht2023, p. 78).
4.3.4. Documentation obligations and other evidence-creating measures
As previously noted, the AIA also imposes documentation obligations and other requirements designed to facilitate the monitoring of compliance with safety-related provisions. The required measures may also generate evidence relevant to liability cases. For example, Arts. 11 and 53(1) AIA require the drawing up of technical documentation for high-risk AI systems and GPAI models, which may assist in identifying design defects. Similarly, the record-keeping measures prescribed by Art. 12 AIA may make it easier to reconstruct the course of events leading to the damage. However, the breach of such obligations does not necessarily give rise to a defect causing damage (see Section 4.1) or entail a reversal of the burden of proof under Art. 10 PLD. In particular, Art. 10(2)(a) PLD, which establishes a presumption of defectiveness where the defendant fails to disclose relevant evidence pursuant to Art. 9(1) PLD, does not apply in cases of documentation failures: the defendant’s disclosure obligation under Art. 9(1) PLD extends only to evidence “at the defendant’s disposal.” In situations involving documentation failures, such evidence is usually lacking. The (redundant) presumption in Art. 10(2)(b) PLD does not apply either, as it requires that the violated safety requirements are intended to protect against the risk of the damage suffered by the injured person and not merely to facilitate the control of compliance with substantive requirements (see Section 4.1).
In light of this omission in the PLD,Footnote 56 national legislators and courts may want to consider whether the resulting gap can be filled by providing national evidentiary facilitations in cases involving missing documentation or similar sources of potential evidence. German courts, for example, generally recognise such facilitations in situations involving the spoliation of evidence.Footnote 57 Despite the full harmonisation of EU product liability law, a national reversal of the burden of proof is generally regarded as permissible in such cases; it is classified as falling within the Member States’ procedural autonomy (see Seibl, Reference Seibl, Gsell, Krüger, Lorenz and C.2026, mn. 143). However, rules on the burden of proof can, if at all, be classified only as mere procedural sanctions that may be left to the Member States where a concrete legal dispute is at least foreseeable (Mayrhofer, Reference Mayrhofer2024, p. 498). In other situations, a reversal of the burden of proof would ultimately serve to alleviate evidentiary difficulties faced by the injured party irrespective of any specific procedural context, which is an issue exhaustively regulated by Art. 10 PLD. National evidentiary facilitations of this kind would therefore risk undermining the effectiveness of the harmonised rules.Footnote 58
Nevertheless, difficulties in establishing the facts due to missing documentation and similar omissions that hinder the creation of evidence may lead to situations where it becomes excessively challenging for the injured party to prove defectiveness. In such cases, pursuant to Art. 10(4) PLD, defectiveness is presumed if the product is likely to be defective.
5. AIA and defences under Art. 11 PLD
The AIA may also become relevant in assessing whether an economic operator is exempt from liability for damage caused by a defective product pursuant to Art. 11 PLD, not only with respect to the regulatory compliance defence (see Section 5.1) but also in relation to the development risk defence (see Section 5.2) as well as the later defect defence (see Section 5.3).
5.1. Regulatory compliance defence, Art. 11(1)(d) PLD
Under Art. 11(1)(d) PLD, liability is excluded when the defect in the product arises from compliance with legal requirements. This provision continues the approach established in Art. 7(d) 1985 PLD (Wagner, Reference Wagner2024a, pp. 196–197). It is designed to protect manufacturers from facing a dilemma between compliance with legal obligations and liability.Footnote 59 However, as previously explained (see Section 2), the binding legal requirements of the AIA generally do not prescribe specific technical measures; rather, they are formulated in open terms and may be complied with in a variety of ways. Voluntary standards, including those giving rise to a presumption of conformity, remain outside the scope of the regulatory compliance defence.Footnote 60 As a result, the practical relevance of this exclusion is likely to be limited (see Graf von Westphalen, Reference Graf von Westphalen, Foerste and Graf von Westphalen2024, p. 897).
5.2. Later defect defence, Art. 11(1)(b) PLD
Art. 11(1)(b) PLD allows economic operators to exonerate themselves where it is probable that the defect did not exist at the time the product was placed on the market or put into service. This defence protects economic operators against liability for post-market changes of the product and partially mitigates the extension of the relevant point in time for assessing the applicable safety standard (see Section 4.1.2) (Mayrhofer, Reference Mayrhofer and Messner-Kreuzbauer2026, pp. 98–99). Unlike the 1985 PLD, however, the new PLD contains an exception in Art. 11(2)(c): where defectiveness is due to a related service, software, a lack of software updates or upgrades necessary to maintain safety, or to a substantial modification of the product, the economic operator is not exonerated, provided that the relevant event falls within the manufacturer’s control within the meaning of Art. 4(5) PLD (see Section 4.1.2). This exception to the defence complements the extension of the temporal reference point for assessing the safety standard (see Section 4.1.2) and allows manufacturers to be held liable for certain – though not all – violations of post-market obligations (Wagner, Reference Wagner2025, pp. 188–189; Mayrhofer, Reference Mayrhofer and Messner-Kreuzbauer2026, pp. 97–99, 104–105). In this context, safety regulation may play an important role in determining both whether the absence of an update or upgrade renders a product defective and whether such an update or upgrade was “necessary” to maintain safety. Reference may be made to the earlier discussion of defectiveness (see Section 4.1.2). While the AIA does not expressly establish update obligations, such obligations may nonetheless arise from its more general requirements.Footnote 61
5.3. Development risk defence, Art. 11(1)(e) PLD
Art. 11(1)(e) PLD excludes liability where the manufacturer could not have discovered the defect in light of the scientific and technical knowledge available at the time the product was placed on the market or put into service, or during the period in which the product was under the manufacturer’s control within the meaning of Art. 4(5) PLD (see Section 4.1.2). Substantively, the development risk defence continues Art. 7(e) 1985 PLD; temporally, however, the scope of liability is expanded (Kapoor & Sedlmaier, Reference Kapoor and Sedlmaier2023, p. 12; Mayrhofer, Reference Mayrhofer and Messner-Kreuzbauer2026, pp. 99–100, 105–106). Where the defect results from a breach of mandatory legal requirements, the defence is generally considered unavailable (see Wagner, Reference Wagner, Säcker, Rixecker, Oetker, B. and C.2024b, mn. 57; Kapoor, Reference Kapoor and Kapoor2023, mn. 135). Such requirements are indeed, as a rule, identifiable. However, where product requirements are concretised through harmonised standards or comparable specifications carrying a presumption of conformity (see Sections 2 and 4.3.1), the manufacturer should, in principle, be entitled to rely on compliance with the requirements (Mayrhofer, Reference Mayrhofer2024, p. 499). As previously explained, compliance with these standards does not preclude a violation of the AIA and a resulting defect under Art. 7(1) PLD (see Section 4.2). However, under the view advanced here, it may preclude the detectability of such a violation within the meaning of Art. 11(1)(e) PLD. It is generally held that mere adherence to technical standards does not establish a development risk, as such standards do not necessarily reflect the state of scientific and technical knowledge (see Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 102; Vieweg, Reference Vieweg, Schulte and Schröder2011, p. 380; Wagner, Reference Wagner, Säcker, Rixecker, Oetker, B. and C.2024b, mn. 57).Footnote 62 Yet the special function of the presumption of conformity argues in favour of applying the defence: although rebuttable, it is intended to relieve the manufacturer from having to develop solutions that comply with product safety law in accordance with general engineering or scientific knowledge – as would be required in the absence of standards.Footnote 63 Recital 52 of the PLD, which states that the state of scientific and technical knowledge must be “determined with reference to the most advanced level of objective knowledge,” does not preclude such interpretation. In line with the CJEU’s case law on the 1985 PLD,Footnote 64 Recital 52 also requires that such knowledge be “accessible,” a condition that may not be met where the relevant knowledge is not reflected in the applicable standards. Furthermore, for a defect to be considered detectable, it is not sufficient that a product risk be recognisable; rather, it must be possible to infer the product’s “defectiveness” from that risk. This is doubtful where the manufacturer applies standards that carry a presumption of conformity (Mayrhofer, Reference Mayrhofer2024, pp. 499–500). Acknowledging a development risk in cases of compliance with such standards would give the – disputedFootnote 65 – clause a clear field of application and enhance legal certainty. Manufacturer responsibility vis-à-vis the authorities and liability under national fault-based regimes, particularly in cases involving breaches of post-market surveillance duties, would generally remain possible.
Similar considerations apply when the product has received a certification or a positive conformity assessment. The detectability of a violation of legal requirements is not automatically precluded by such approvals (see Wagner, Reference Wagner, Säcker, Rixecker, Oetker, B. and C.2024b, mn. 57). A development risk may, however, be affirmed insofar as a cybersecurity certificate or statement carries a presumption that the cybersecurity requirements of the AIA have been met (see Art. 42(2) AIA), as this presumption similarly relieves the manufacturer from further verification.
Nevertheless, reliance on compliance with standards is subject to significant limitations for manufacturers. A harmonised standard does not necessarily cover all essential requirements, which may restrict the scope of the presumption of conformity.Footnote 66 Moreover, conformity must relate to the time relevant under Art. 11(1)(e) PLD: if the product has complied with harmonised standards at the time of placing on the market, but no longer does so at a later time while it remains under the manufacturer’s control, the development risk defence does not apply. The same holds true for certificates referring to a specific state of the product at a given time. This limitation is particularly relevant for AI systems, which can usually be updated and thus remain under the manufacturer’s control (Art. 4(5)(b) PLD). Notably, modifications resulting from the system’s ability to learn (see Spindler, Reference Spindler2022, p. 694) will not always be pre-determined at the moment of the initial conformity assessment and may not be taken into account by the applied harmonised standards or by the certification,Footnote 67 with the result that they will not shield the manufacturer from liability for those modifications.
A further limitation concerns cases in which the manufacturer has actual knowledge of the defect; in such cases, the manufacturer is not deserving of protection and should not be entitled to invoke the defence (Mayrhofer, Reference Mayrhofer2024, p. 500).
Finally, it should be noted that even when the defence applies on the basis of a presumption of conformity, the injured party is not necessarily left without compensation. In particular, liability of standardisation or certification bodies may come into consideration (see Verbruggen & Van Leeuwen, Reference Verbruggen and Van Leeuwen2018). Moreover, Member States may make use of Art. 8(5) PLD to establish sectoral compensation schemes.Footnote 68 Art. 18 PLD also allows Member States, under restrictive conditions, to derogate from the development risk defence and provide for liability for development risks.
6. AIA and liability for substantial modifications under Art. 8(2) PLD
The new PLD introduces the concept of “substantial modification” into product liability law. In the case of AI products, such a modification may arise, in particular, from a software update or the continuous learning of the AI system (see Recital 40 sentence 2 PLD). The principal consequence is set out in Art. 8(2) PLD: a person who substantially modifies a product outside the manufacturer’s control and subsequently makes it available on the market or puts it into service is to be regarded as the manufacturer of that product. Additionally, a substantial modification triggers a restart of the expiry period pursuant to Art. 17(1)(b) PLD. As noted above (see Section 5.2), the PLD further restricts the later defect defence in cases of substantial modifications within the manufacturer’s control. However, this restriction should also be extended to non-substantial modifications, as there is no convincing reason why the original manufacturer should bear responsibility only for substantial modifications but not for minor modifications within its control (Mayrhofer, Reference Mayrhofer and Messner-Kreuzbauer2026, p. 99; Wagner, Reference Wagner2024a, p. 199).
The concept of substantial modification is derived from product safety law. Under product safety law, an economic operator who substantially modifies a product is, as a rule, responsible for ensuring the product’s compliance with applicable safety requirements (see Recital 39 sentence 4 PLD). This approach is also adopted by the AIA: pursuant to Art. 25(1)(b) AIA, any distributor, importer, deployer or other third party is to be regarded as a provider of a high-risk AI system where it makes a substantial modification to such a system. This paper does not seek to analyse the allocation of responsibilities along the AI value chain addressed by Art. 25 AIAFootnote 69 but rather focuses on specific questions concerning the interplay between the AIA and the PLD: Art. 4(18)(a) PLD provides that a modification “that is considered substantial under relevant Union or national rules on product safety” is likewise to be regarded as substantial under the PLD. The PLD thus aims at a particularly comprehensive alignment of product safety law and product liability law in this regard (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 96). Art. 3(23) AIA defines a substantial modification as
a change to an AI system after its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment carried out by the provider and as a result of which the compliance of the AI system with the requirements set out in Chapter III, Section 2 is affected or results in a modification to the intended purpose for which the AI system has been assessed.
Against this background, three questions emerge: First, it is unclear whether Art. 43(4) subparagraph 2 AIA, which provides that, for high-risk AI systems that continue to learn, changes that were “pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation” are not considered substantial for the purposes of requiring a new conformity assessment, should be generalised and applied in other contexts, such as Art. 25 AIAFootnote 70 or under the PLD. However, the practical significance of this issue should not be overstated, as changes that were “pre-determined” will usually also qualify as “foreseen or planned” (see Kirschke-Biller & Füllsack, Reference Kirschke-Biller, Füllsack, Schefzig and Kilian2025, mn. 330.3).
Second, it may be doubtful under which circumstances the AIA is the “relevant” product safety law (Hacker & Holweg, Reference Hacker and Holweg2026, p. 12). AI products can also be subject to other instruments, such as the GPSR, the CRA or sector-specific rules, which likewise contain definitions of substantial modification. As Art. 4(18)(a) PLD aims to extend responsibility arising under product safety law into the realm of product liability law, it appears necessary to distinguish between the types of defects involved: where a defect results from a violation of the AIA, the definition laid down in the AIA should be applied. Conversely, where only another instrument, such as the GPSR, is violated, the definition contained in that instrument should be used. In cases where multiple legal instruments are violated, one may refer to general principles governing the concurrence of laws, such as the principle that the more specific law (lex specialis) prevails over the more general one. For example, with regard to AI-specific risks, the AIA constitutes lex specialis vis-à-vis the GPSR, with the result that Art. 3(23) AIA should apply (Hacker & Holweg, Reference Hacker and Holweg2026, p. 12). In contrast, for cybersecurity risks, the CRA constitutes lex specialis vis-à-vis the AIA (see Art. 12 CRA); accordingly, Art. 3(30) CRA should take precedence. The distinction based on the type of defect also implies that in cases where a defect does not result from a violation of product safety law but arises from other circumstances, Art. 4(18)(a) PLD will not apply. Instead, Art. 4(18)(b) PLD applies: in the absence of thresholds laid down in product safety law, a modification is considered substantial if it “changes the product’s original performance, purpose or type, without that change having been foreseen in the manufacturer’s initial risk assessment; and changes the nature of the hazard, creates a new hazard or increases the level of risk.”
The third question relates to the scope of application of the AIA’s definition: in principle, the definition of Art. 3(23) AIA concerns only high-risk AI systems. However, it has been proposed to apply this definition by analogy to GPAI models (Hacker & Holweg, Reference Hacker and Holweg2026, p. 10). One might also envisage an analogy in the case of modifiers of non-high-risk AI systems, which, however, have only limited obligations under the AIA (see Section 2). The Commission has nevertheless stated in its guidelines on GPAI models that a downstream modifier of a GPAI model may become a provider “only if the modification leads to a significant change in the model’s generality, capabilities, or systemic risk.”Footnote 71 Ultimately, the exact requirements will need to be determined by the CJEU (Ebers & Vargas Penagos, Reference Ebers and Vargas Penagos2025, pp. 17–18). In any case, the solution approved in relation to the AIA will also have implications for the application of the PLD: an analogy would lead to the application of Art. 4(18)(a) PLD on GPAI models and non-high-risk AI systems. If a distinct approach is adopted, this approach would need to be reflected in the interpretation of Art. 4(18)(b) PLD: in light of the legislator’s aim of alignment, the assessment of whether “the nature of the hazard” is changed, a “new hazard” is created or “the level of risk” is increased should be carried out with regard to product safety law, even where it provides no explicit definition.
7. Conclusion: potential for further alignment between AI safety regulation and compensation
As demonstrated in the foregoing analysis, the new PLD establishes several points of connection with product safety law, leading to a far-reaching alignment of the standards and concepts contained in the AIA and those embodied in the PLD. This interaction may allow both instruments to reinforce each other’s effectiveness: claims under the new PLD can serve as a basis for the private enforcement of the AIA, thereby complementing its public enforcement regime, while the AIA’s requirements may facilitate the assessment of liability for both courts and economic operators (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, p. 109; Mayrhofer, Reference Mayrhofer2024, p. 501). While greater clarity might have been desirable in certain respects, it appears that most remaining questions can be adequately addressed by recourse to general legal concepts, such as prima facie evidence or the lex specialis principle.
Consequently, it is regrettable that the potential of the mechanisms contained in the PLD to align product safety law and product liability law has not been more fully exploited, particularly with regard to AI. As has been demonstrated, the scope of application of the PLD remains limited. In particular, it is unclear whether all AI systems and AI models are covered in every situation, especially with regard to “information” provided by AI. Moreover, gaps remain insofar as the PLD only protects against specific types of damage, excluding economic losses and infringements of personality rights, which are particularly relevant in the context of AI-related damages (Ebers, Reference Ebers, Gsell, Ebers, Mayrhofer and Danda2025, pp. 92, 108). The PLD also continues to focus on the manufacturing and distribution side and does not extend to the entire value chain. In this regard, liability law might have benefited from taking the AIA as a model, as the AIA does not distinguish between products, services and information, is not limited to risks of specific types of damage and also includes the user side by integrating the deployer of AI systems.
One might argue that, in this respect, the broader AIA operates in a complementary manner vis-à-vis the PLD, with AI safety law thus supplementing product liability law and economic operators being protected against “double exposure” through both administrative enforcement and private litigation. Such an argument, however, overlooks the fact that the gaps in the PLD do not result in an exemption from liability. Rather, national law, particularly tort law, steps in, requiring economic operators to navigate a multitude of regimes across the EU, which may diverge, for example, with regard to fault requirements, the allocation of the burden of proof or the treatment of pure economic loss.Footnote 72
Initially, in 2022, the EU intended to complement the PLD and the AIA with an AI Liability Directive that was not limited to products and also covered the user side.Footnote 73 The proposal was withdrawn in 2025.Footnote 74 However, even that instrument would not have filled the existing gaps, as it would have merely introduced selective disclosure and burden-of-proof rules rather than establishing a uniform European liability regime. It would therefore have been more effective to extend the scope of the PLD’s mechanisms, thereby creating a coherent liability system capable of further enhancing the effectiveness of product safety law, such as the AIA. Such a system could also help address problems arising from the fact that it is often unclear to what extent EU legal acts implicitly confer a right to damages or require Member States to provide corresponding national liability rules (see Hornkohl, Reference Hornkohl2024, pp. 946–949; Radtke, Reference Radtke2026, p. 129). Broadening the scope of the PLD would also have allowed liability law to further complement safety law in cases where the AIA – or similar instruments – does not provide any rules. This is particularly relevant for non-high-risk AI systems, for which the AIA contains few provisions, and for AI models, with respect to which the AIA likewise lays down limited substantive requirements.
All in all, while the PLD commendably includes workable mechanisms addressing the interplay between product safety and compensation, it is regrettable that these mechanisms were not further extended beyond the traditional scope of product liability.
Acknowledgements
The author would like to thank Mònica Navarro-Michel and Martin Ebers for organising the “AI Liability Conference” in Barcelona in October 2025, from which this paper originated, as well as all participants of the conference for their valuable comments and insights.
Author contributions
A-K M: Conceptualization, Data curation, Formal analysis, Funding acquisition, Investigation, Methodology, Project administration.
Funding statement
The author declares none.
Competing interests
The author declares none.
Open access
