Directive 2024/2853 and AI Coverage: What the December 2026 Transposition Deadline Changes

The End of Directive 85/374/EEC and What Replaces It

Council Directive 85/374/EEC of 25 July 1985 on liability for defective products was designed for a world of physical goods: cars, pharmaceuticals, household appliances. Courts across member states spent decades debating whether software fell within its scope at all. The prevailing interpretation, in many jurisdictions, was that pure software did not constitute a "product" for the purposes of the directive, meaning that victims of harm caused by defective software faced the substantially higher bar of fault-based negligence claims.

Directive 2024/2853, adopted on 23 October 2024 and published in the Official Journal on 18 November 2024, closes that gap definitively. The new directive explicitly states that "product" includes digital manufacturing files and software, with AI systems named in the recitals as falling squarely within scope. Member states have until 9 December 2026 to transpose the directive into national law. After that date, strict liability for defective AI applies across the EU without the need to prove fault.

The practical shift is considerable. Under fault-based regimes, a claimant injured by an AI system had to demonstrate that the manufacturer acted negligently, a burden that required access to internal documentation, testing records, and design decision trails that are rarely accessible to outside parties. Under strict liability, the claimant need only establish that the product was defective, that harm occurred, and that a causal link exists between the two. The question of intent or negligence on the manufacturer's part becomes irrelevant.

What Counts as Defective AI: The Article 6 Standard

The defectiveness standard under Article 6 of the new directive is built around the concept of safety expectations: a product is defective when it does not provide the safety that persons are generally entitled to expect, taking all circumstances into account. This framework was carried over from the 1985 directive but has been expanded materially for AI systems.

Three elements of the Article 6 standard warrant particular attention for AI deployments. The first is the scope of foreseeable use. The directive evaluates defectiveness against "reasonably foreseeable use," a standard that includes misuse that was objectively predictable. AI systems deployed in consumer-facing or enterprise contexts are increasingly used in ways that exceed the original design scope, and manufacturers who fail to anticipate that scope will not find protection in deployment constraints buried in terms of service.

The second element concerns safety expectations at the time of putting the product into service. This is familiar from the earlier directive. The third element is new and specific to AI: the ability of a product to continue learning after it is placed on the market. Under Article 6, a product may be considered defective if post-deployment learning results in behaviour that falls below the expected safety standard, even if the system met that standard at the moment of initial deployment.

This provision has significant implications for AI systems built on foundation models, reinforcement learning from human feedback, or any architecture that continues to update on production data. The manufacturer's liability does not extinguish once the product ships. Organisations deploying such systems must maintain monitoring and governance frameworks throughout the product lifecycle, because the defectiveness question will be evaluated at the time of harm, not the time of launch.

The Restricted Development Risk Defence

The development risk defence has historically been one of the most commercially significant protections available to technology manufacturers in product liability cases. Under Article 7(1)(e) of Directive 85/374/EEC, a manufacturer could avoid liability by demonstrating that the state of scientific and technical knowledge at the time the product was put into circulation was not such that the defect could have been discovered. In software and AI contexts, this effectively shielded manufacturers from liability for defects that were not detectable under the prevailing methods of the day.

Directive 2024/2853 restricts this defence in two categories of AI. The first is AI systems that are safety-critical, meaning systems whose failure could result in serious physical harm or death. The second is AI systems with significant impact on health, safety, or fundamental rights. This second category aligns closely with the high-risk category under Regulation (EU) 2024/1689, the EU AI Act, which covers systems used in employment, access to essential services, law enforcement, administration of justice, and critical infrastructure.

For AI systems in those categories, the manufacturer cannot escape liability by pointing to the limits of what was technically discoverable at launch. The rationale offered in the directive's recitals is that in sectors where harm is foreseeable and serious, the burden of operating at the frontier of technical capability should not be transferred to victims. Manufacturers who choose to deploy AI in high-stakes domains accept a corresponding level of liability that the development risk defence can no longer fully absorb.

The practical consequence is that product liability insurers writing coverage for AI manufacturers in health, financial services, employment platforms, and critical infrastructure will need to price for claims that cannot be defended on development-risk grounds. The risk previously absorbed by that defence must now sit somewhere: either on the manufacturer's balance sheet or in its insurance programme.

Disclosure Obligations and the Burden Shift

One of the persistent obstacles to successful product liability claims against technology manufacturers has been the information asymmetry between claimant and defendant. The claimant rarely has access to the design documentation, training data, testing records, or internal safety assessments that would establish whether a system was defective. The manufacturer holds all of that material and has no obligation, under the 1985 framework, to disclose it proactively.

Articles 9 and 10 of the new directive address this asymmetry in two ways. Article 9 introduces a disclosure obligation: courts may order manufacturers to disclose relevant evidence when a claimant makes a plausible case that a product caused harm and that the information is held by the manufacturer. Article 10 introduces a rebuttable presumption of defectiveness in cases of technical complexity. Where a claimant would face disproportionate difficulty in establishing defectiveness due to the technical nature of the product, and where the claimant can demonstrate a plausible causal link between the product and the harm, a court may presume that the product was defective. The manufacturer must then rebut that presumption.

This shift is material. In complex AI cases where the claimant cannot trace causation through an opaque neural network, the burden-shifting mechanism means that manufacturers who cannot document their safety processes will struggle to rebut the presumption. The disclosure obligation means that internal documentation which was previously protected from civil discovery now becomes a potential liability. Organisations that have not been maintaining rigorous AI development records should begin doing so now, both to satisfy EU AI Act documentation requirements and to prepare for the evidentiary demands of post-2026 civil litigation.

The Double Exposure: Regulatory and Civil Liability After December 2026

Until the transposition deadline, the two primary EU regulatory instruments affecting AI operate in largely separate channels. Regulation (EU) 2024/1689, the EU AI Act, is a regulatory framework: it imposes obligations on providers and deployers of AI systems, establishes conformity assessment requirements for high-risk systems, and carries administrative penalties for non-compliance. It does not itself create a private right of action for individuals harmed by AI.

Directive 2024/2853 operates in the civil liability channel: it gives individuals a direct cause of action against manufacturers for defective products. After December 2026, both frameworks will be fully operational simultaneously.

The interaction between the two instruments is practically significant. EU AI Act compliance documentation, including the technical file, risk management system records, and post-market monitoring logs required for high-risk systems, will serve as the primary evidence base in civil liability claims under the directive. An organisation with strong AI Act compliance posture will be better positioned to rebut the Article 10 presumption of defectiveness and to demonstrate, under the Article 6 standard, that the system met reasonable safety expectations. An organisation that has treated AI Act compliance as a box-ticking exercise will find that absence of substantive documentation works against it in both regulatory proceedings and civil claims.

This dual exposure also affects indemnification structures in supply chains. Where an enterprise deploys AI built on a third-party foundation model or cloud-based AI service, the question of who bears liability as the "manufacturer" under the directive becomes commercially significant. The directive defines manufacturer broadly to include those who put AI systems on the market under their name or trademark. Cloud service providers who customise models for enterprise deployment are likely to fall within scope. Organisations relying on AI-as-a-service arrangements should review their contractual indemnification provisions before the transposition deadline. For more on how current policies treat these arrangements, see our analysis of AI exclusions in cyber and errors and omissions policies.

The Coverage Gap: Why Existing Policies May Not Respond

The insurance market response to the new directive is constrained by a structural problem: most products liability policies in the European market were written when software was generally excluded from "product" status under the 1985 framework. Standard products liability wordings typically exclude intangible products, software, and digital content. Those exclusions were reasonable when they were drafted, because the liability risk they purported to exclude was either non-existent or substantially limited under the then-applicable legal framework.

After December 2026, the legal premise underlying those exclusions no longer holds. A software exclusion in a products liability policy issued before the directive's transposition may operate to exclude precisely the category of liability that the new directive creates. Policyholders who assume that their existing products liability programme responds to AI-related civil claims risk discovering the gap at claims time.

The position is further complicated by the interaction with technology errors and omissions and cyber policies. Technology E and O policies typically cover financial losses arising from technology failures but are not structured to respond to bodily injury or property damage claims, which are the core harm categories under the new directive. Cyber policies cover data-related harm and system disruption but are generally silent or exclusionary on physical harm caused by AI decision-making. The result is that a claim arising from, say, an AI diagnostic system that fails to flag a medical condition, causing physical harm to a patient, may fall between all three of a manufacturer's traditional insurance towers.

For a detailed treatment of where these policies draw their lines, see our article on AI exclusions in cyber and errors and omissions policies. For an overview of what dedicated AI coverage addresses, see what AI agent insurance will cover.

Dedicated AI Policies: The Munich Re and Armilla Positions

The coverage gap between traditional products liability (which excluded software), technology E and O (which excludes bodily injury), and cyber (which excludes physical harm) is precisely the space that dedicated AI liability products are designed to occupy. Two carriers have published substantive frameworks in the European market.

Munich Re's aiSure product is structured as an affirmative AI performance coverage, written to respond to claims arising from AI system outputs that deviate from specified performance parameters and cause measurable harm. The policy is designed with awareness of the new directive's scope: it covers physical harm and property damage attributable to AI defect, and does not carry the software exclusions typical of legacy products liability wordings. Munich Re has indicated publicly that the aiSure framework is intended to evolve in step with the regulatory environment, including the post-transposition civil liability landscape.

Armilla, operating as a Lloyd's coverholder, has developed a coverage framework that provides indemnity for claims arising from AI system failures, including failures attributable to post-deployment model drift. The Armilla structure is notable in the present context because it was designed with the continuous learning problem specifically in mind: it does not exclude harm caused by model behaviour that diverged from launch-time parameters, provided the harm falls within the policy's defined coverage categories.

Both frameworks represent an acknowledgment by sophisticated underwriters that the 1985 framework's exclusion of software from products liability is no longer the operative legal standard. Whether the broader market follows with affirmative AI wording before or after the December 2026 deadline will depend substantially on how quickly claims emerge under the transposed directive in early-adopter member states. Enterprises with material AI deployments should not wait for the market to fully price this risk before initiating coverage discussions. The hardening of terms after the first contested claims is a predictable outcome, and organisations that secure coverage before that point will do so on more favourable terms.

The AI Act compliance posture discussed above is directly relevant to underwriting submissions. Carriers writing dedicated AI coverage are evaluating applicants on the quality of their technical documentation, their risk management governance, and their post-market monitoring practices. An EU AI Act-ready technical file is not just a regulatory requirement; it is the primary evidence submitted to underwriters at placement. For the intersection of certification methodology and coverage eligibility, see Agent Certified's coverage methodology.

Preparing for December 2026: Practical Steps

The transposition deadline is fixed. The practical preparation window is now, before the claims market hardens and before national courts begin interpreting the directive's provisions against the first wave of post-December claims.

Four actions are warranted for any enterprise with material AI exposure. First, conduct a policy audit. Review all existing products liability, technology E and O, and cyber policies for software exclusions, AI-specific exclusions, and bodily injury limitations. Map those exclusions against the harm categories covered by the new directive: physical harm, property damage over EUR 1,000, and compensable psychological harm. Identify gaps and quantify exposure before approaching the insurance market.

Second, begin documentation now. The Article 10 rebuttable presumption and the Article 9 disclosure obligations mean that civil litigation under the directive will be an evidentiary contest. Organisations with well-maintained technical files, testing records, risk assessments, and post-deployment monitoring logs will be better positioned both to rebut presumptions of defectiveness and to satisfy disclosure orders without producing materials that create additional liability. Documentation created after a claim arises will not carry the same evidential weight as contemporaneous records.

Third, assess AI Act alignment. The EU AI Act high-risk categories overlap substantially with the Article 7(1)(e) categories where the development risk defence is restricted. An organisation that has completed or is progressing toward AI Act conformity assessment for its high-risk systems will have a substantially stronger position in both regulatory proceedings and civil claims than one that has not begun that process. The compliance investment is dual-use.

Fourth, engage insurers before the market tightens. The period between now and the December 2026 transposition deadline is the optimal window for placing dedicated AI coverage. Underwriters who are actively writing this risk today are doing so in a market with limited claims history, which generally means more negotiable terms and broader coverage scope than will be available after the first contested civil claims establish pricing benchmarks. See the broader coverage framework for current placement options.

For the regulatory backdrop of how AI Act enforcement and civil liability interact, including the potential schedule shift under the Digital Omnibus trilogue, see the companion analysis at agentliability.eu.

Frequently asked questions