October 23, 2026 · 30 min read · Product liability

Software and AI become products on 9 December 2026: what the new Product Liability Directive means for lawyers

Product LiabilitySoftwareAI LiabilityLitigation

On 9 December 2026 software becomes a product. For an application, a SaaS platform or an AI system placed on the EU market from that day, the developer can be held liable without proof of fault when a defect in it injures a person, damages property they use privately or destroys their private data. That is the effect of Directive (EU) 2024/2853 on liability for defective products, which replaces the 1985 directive and must be transposed by the same date (1). The national laws are arriving unevenly. The German Bundestag adopted a completely new Product Liability Act on 8 October, the Bundesrat decided on 16 October not to call the mediation committee, and the act is to enter into force on 9 December; its promulgation is pending (2). The Dutch House of Representatives passed the implementing bill on 15 October without a vote; the Senate is set to adopt it as a formality on 10 November unless a senator asks for written preparation (3). In France we have found no transposition bill, and the Ministry of Justice said in May that a dedicated text was envisaged (4).

There is no separate AI liability regime waiting behind it. The Commission's proposal for an AI Liability Directive, which would have adapted national rules on non-contractual civil liability to artificial intelligence, was formally withdrawn in October 2025 (5). For harm caused by AI systems, the Product Liability Directive is the EU's liability instrument.

Lawyers meet the directive on several sides. They advise the developers, integrators, importers and platforms who become liable; they will bring and defend the first claims; and their firms buy AI tools and sometimes supply software to clients themselves. Much of what has been published about the directive overstates its reach. This guide sets out what changes and for which products, which damage the new rules cover and which they do not, how disclosure and presumptions will change litigation, what to review in contracts, and where the Netherlands, Germany and France stand.

The short answer: The new rules apply to products placed on the market or put into service from 9 December 2026; older products stay under the old law, so two regimes will run side by side for at least ten years. Software is a product however it is supplied, including SaaS and AI systems, and software supplied free of charge counts when it is supplied in the course of a commercial activity. The scope of compensation is narrower than most summaries suggest. Only natural persons can claim, and only for death or personal injury (including medically recognised psychological harm), damage to property not used exclusively for professional purposes, and the destruction or corruption of data not used for professional purposes. Pure economic loss is not covered, and information is not a product. What changes most is litigation: courts can order defendants to disclose evidence, a failure to disclose leads to a presumption of defect, and complexity, expressly including the inner workings of AI systems, can lead to presumptions of defect and causation. Liability towards the injured person cannot be excluded by contract. And while a product remains within the manufacturer's control, the manufacturer cannot argue that a defect arose after the product was placed on the market if the defect lies in its software or updates, or in a missing update needed to keep the product safe.

What changes on 9 December 2026, and for which products

The directive applies to products "placed on the market or put into service after 8 December 2026". That is the text of Article 2(1) as corrected on 7 May 2026 (6). The original version said "after 9 December 2026", while Article 21 keeps the 1985 directive applicable to products placed on the market or put into service "before" 9 December 2026, which left the day itself in neither regime. Many summaries still quote the uncorrected wording. The Dutch bill and the German act both use the corrected cut-off.

The cut-off works per product. The relevant moment is when the product was first made available on the Union market or, for a product used before it was ever placed on the market, when it was first used in the Union in the course of a commercial activity (Article 4(8) and (9)). For products placed on the market or put into service before 9 December 2026, Directive 85/374/EEC and the national law implementing it continue to apply (7). Since claims under the old regime expire ten years after a product was put into circulation, courts will be applying both regimes, sometimes in the same dispute, until well into the 2030s. The 1985 directive does not mention software, and the new directive's recitals acknowledge "inconsistencies and legal uncertainty, in particular as regards the meaning of the term 'product'" (1). Software released before the cut-off does not become a product under the new rules merely because the new rules exist.

It can come within them through a substantial modification. A product that is substantially modified and then made available on the market or put into service is considered a new product (recital 39). Recital 40 applies this to a substantial modification made "through a software update or upgrade, or due to the continuous learning of an AI system": the modified product counts as made available or put into service when the modification is actually made. The person who substantially modifies a product outside the original manufacturer's control and then makes it available or puts it into service becomes its manufacturer (Article 8(2)), and a new ten-year expiry period runs from that date (Article 17(1)(b)). Ordinary updates that do not amount to a substantial modification do not restart the clock (recital 58). Whether a modification is substantial is determined by product safety law where it sets a threshold, and otherwise by a two-part test: the change alters the product's original performance, purpose or type in a way not foreseen in the manufacturer's initial risk assessment, and it changes the nature of the hazard, creates a new one or increases the level of risk (Article 4(18)).

The directive is a maximum harmonisation measure: Member States may not keep or introduce rules that are more or less protective, except where the directive allows it (Article 3). National courts will therefore be interpreting a common text, and the Court of Justice will have the final word on its terms.

Software, SaaS and AI systems are products; information is not

Article 4(1) defines a product as all movables, even if integrated into or inter-connected with another movable or an immovable, and includes electricity, digital manufacturing files, raw materials and software. Recital 13 explains the breadth of the last word. Software "such as operating systems, firmware, computer programs, applications or AI systems" is a product "irrespective of the mode of its supply or usage, and therefore irrespective of whether the software is stored on a device, accessed through a communication network or cloud technologies, or supplied through a software-as-a-service model". Providers of AI systems within the meaning of the AI Act are to be treated as manufacturers (1) (8).

Price does not matter. Making a product available on the market and putting it into service are defined as acts "in the course of a commercial activity, whether in return for payment or free of charge" (Article 4(7) and (9)). A free app published by a business to win customers is within scope. The one exclusion for software is narrow: free and open-source software "developed or supplied outside the course of a commercial activity" (Article 2(2)). According to recital 14, software supplied in exchange for a price, or for personal data used other than exclusively for improving its security, compatibility or interoperability, is supplied in the course of a commercial activity. And where a manufacturer integrates non-commercial open-source software into a commercial product, the manufacturer is liable for its defects and the open-source developer is not (recital 15).

The directive also reaches "related services": digital services integrated into or inter-connected with a product in such a way that without them the product could not perform one or more of its functions (Article 4(3)). The examples in recital 17 are a navigation system's continuous supply of traffic data, a health monitoring service that relies on a device's sensors, a smart fridge's temperature control service and a voice assistant that controls other products. Such services are treated as components of the product when they are within its manufacturer's control. Internet access services are not related services.

Then comes the exclusion that matters most for anything that produces text. Recital 13 states: "Information is not, however, 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." The software that runs is a product; the content it carries or displays is not. We return to what that means for AI output below.

Who can be held liable

Article 8 lists the economic operators who can be liable. The first is the manufacturer of the defective product, defined broadly: whoever develops, manufactures or produces a product, has it designed or manufactured, or presents itself as the manufacturer by putting its name or trademark on it, and whoever develops a product for its own use (Article 4(10)). A company that builds an assistant on a third-party model and markets it under its own name is the manufacturer of that assistant. Its liability extends to damage caused by a defective component integrated into the product within its control, and the manufacturer of that component is liable alongside it. Those liable for the same damage are liable jointly and severally (Article 12(1)).

For manufacturers established outside the Union the directive makes sure that someone in the Union answers. The importer and the manufacturer's authorised representative are liable, and where neither exists, the fulfilment service provider, a business that offers at least two of warehousing, packaging, addressing and dispatching without owning the product (Article 8(1)(c), Article 4(13)). Where no economic operator established in the Union can be identified, each distributor becomes liable if, within one month of the injured person's request, it fails to identify such an operator or the distributor that supplied it (Article 8(3)). The same rule applies to online platforms that allow consumers to conclude distance contracts with traders and are not themselves economic operators, where the conditions of Article 6(3) of the Digital Services Act are met (Article 8(4)).

For software supply chains this produces a layered picture. The developer of the finished application is liable as manufacturer. A supplier of a software component is liable as component manufacturer if its component made the product defective. A provider of a related service on which the product depends can be liable as a component supplier. A business that substantially modifies a model or application outside the original manufacturer's control and then offers it becomes a manufacturer itself. None of these roles depends on fault, and none of them can be contracted away towards the injured person.

Which damage counts, and which does not

This is where much of the commentary goes wrong. The right to compensation belongs to "any natural person who suffers damage caused by a defective product" (Article 5). Companies, partnerships, foundations and public bodies have no claim of their own, although a person who has succeeded or been subrogated to the injured person's right, such as an insurer, and a person acting on behalf of injured persons under Union or national law can bring the claim (Article 5(2)).

Article 6 then lists the only types of damage for which compensation is available:

Death or personal injury, "including medically recognised damage to psychological health". Recital 21 requires the psychological harm to be medically recognised and medically certified, affecting the victim's general state of health and possibly requiring therapy or medical treatment.
Damage to or destruction of property, except the defective product itself, a product damaged by a defective component that was integrated into it by or under the control of its manufacturer, and "property used exclusively for professional purposes". Property used for both private and professional purposes is covered.
Destruction or corruption of data "that are not used for professional purposes". Here the professional exclusion is wider: according to recital 22, data used for professional purposes are excluded "even if not exclusively so". Recital 20 adds that compensation includes the cost of recovering or restoring the data, that destruction or corruption does not automatically cause a material loss where the data can be retrieved at no cost, for example from a backup, and that it is distinct from data leaks and breaches of data protection rules, which remain a matter for data protection law.

Compensation covers all material losses resulting from that damage, and non-material losses such as pain and suffering in so far as national law compensates them (Article 6(2)). There is no minimum and no maximum. The old directive provided for a lower threshold of 500 ECU for property damage, and allowed Member States to cap a producer's total liability for death or personal injury caused by identical items with the same defect (7). Dutch law applies the threshold as a EUR 500 deductible (9); German law currently has both a EUR 500 deductible and a cap of EUR 85 million (10). These limits disappear, because the directive prohibits limiting liability by contract "or by national law" (Article 15), and recital 56 names financial ceilings as an example. The German government observed that its deductible and its cap had rarely mattered in practice, because German courts regularly apply producer liability in tort under section 823(1) of the Civil Code, to which neither limit applies (10).

Pure economic loss is not on the list, and recital 24 confirms that it does not by itself trigger liability under the directive. Two examples show what that means in practice.

A law firm's AI drafting tool corrupts a matter file or produces a flawed contract clause that costs the firm a client. The firm has no claim under the directive: it is not a natural person, its matter data are used for professional purposes, and its loss is financial. A client who relies on wrong legal information generated by a consumer chatbot and loses money has no claim under the directive either: the loss is purely economic. Both are left where they were before: with a claim in contract, where there is one, or in fault-based liability under national law, which the directive leaves untouched (Article 2(4)(b)). For lawyers' own exposure when AI goes wrong in their work, see our guide on whether lawyers can be held liable for AI mistakes.

The directive does change matters for consumer-facing software that can hurt people or destroy their private files: health and fitness applications, smart-home controls, vehicle and mobility software, consumer backup and storage products and, subject to the question discussed in the next section, companion and wellbeing chatbots. For those placed on the market from 9 December 2026, a defect carries strict liability for injury, including medically recognised psychological injury, for damage to property used privately and for the destruction or corruption of private data.

AI output: a defect in the product, or information?

The exclusion of information meets an older line of case law. In Krone-Verlag an Austrian newspaper had published a herbal medicine column recommending a grated horseradish poultice for rheumatic pain, to be left on for two to five hours; the article should have said minutes. A reader followed it and suffered a toxic skin reaction. The Court of Justice held in June 2021, under the 1985 directive, that the copy of the newspaper was not a defective product (11). The advice, by its nature a service, was "unrelated to the printed newspaper, which constitutes its medium" and was not part of the newspaper's inherent characteristics (paragraph 36). The liability of service providers and of manufacturers of finished products, the Court said, "constitute two distinct liability regimes" (paragraph 38).

An AI system is not a newspaper. It is software, and therefore a product, and what it produces is the result of its design, its training and its behaviour, which is exactly what the defectiveness test looks at. Article 7(2)(c) tells courts to consider "the effect on the product of any ability to continue to learn or acquire new features", and recital 32 says that a manufacturer that designs a product with the ability to develop unexpected behaviour "should remain liable for behaviour that causes harm". On the other hand, what a language model generates is information in the most literal sense, and recital 13 says in general terms that information is not a product.

Where the line falls is not settled, and nothing in the directive or the national implementing materials resolves it. The plausible positions are that output which a system was built to produce is part of the product's behaviour and can make the product defective, or that output is information and falls outside the regime, so that harm caused by acting on it must be pursued in fault-based liability or contract. The question is unlikely to be settled until claims about chatbots that injure users reach the courts, and in the end it is one for the Court of Justice. For legal AI tools the question matters less than it seems: the loss a wrong legal answer causes is usually financial, and the directive does not cover that in any event.

Defects that appear after delivery: updates, learning and cybersecurity

Under the 1985 directive a producer could escape liability by showing that the defect probably did not exist when the product was put into circulation. For a physical product sold once that made sense. For software that is updated continually, it does not, and the new directive rebuilds the timing around control.

A product remains within the manufacturer's control as long as the manufacturer integrates, supplies or authorises components and updates, or simply has the ability to supply software updates or upgrades itself or through a third party (Article 4(5), recital 19). Where the manufacturer retains control after placing the product on the market, the moment the product left its control is among the circumstances that determine defectiveness (Article 7(2)(e)). The defence that a defect arose later still exists, but by Article 11(2) it is not available where the defect is due to any of the following, provided it is within the manufacturer's control: a related service; software, including software updates or upgrades; "a lack of software updates or upgrades necessary to maintain safety"; or a substantial modification.

The directive does not impose a duty to provide updates (recital 51). But where a product within the manufacturer's control is defective because it lacks updates necessary to maintain safety, the manufacturer cannot escape liability by arguing that the defect arose after the product was placed on the market (Article 11(2)(c)). There are two limits. Recital 51 states that this liability does not apply where the supply or installation of the update is beyond the manufacturer's control, for example where the owner does not install an update supplied to maintain safety. And an injured person's negligent failure to install updates can reduce or disallow the operator's liability (Article 13(2), recital 55). A third party's intervention, by contrast, does not reduce liability: if an attacker exploits a vulnerability that made the product less safe than the public at large is entitled to expect, the operator remains fully liable to the victim (Article 13(1), recital 55).

Cybersecurity is now part of the defectiveness test. Article 7(2)(f) lists "relevant product safety requirements, including safety-relevant cybersecurity requirements", and recital 32 states that a product can be defective "on account of its cybersecurity vulnerability". The Cyber Resilience Act lays down essential cybersecurity requirements for products with digital elements: its reporting obligations for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026, and the regulation applies generally from 11 December 2027 (12). That does not make every breach of the Cyber Resilience Act a product defect. Defectiveness is presumed where the claimant shows that the product does not comply with mandatory product safety requirements intended to protect against the risk of the damage suffered (Article 10(2)(b)); which cybersecurity requirements meet that test is a question the courts have yet to answer.

Two other defences remain relevant. A manufacturer is not liable if the defect is due to compliance with legal requirements, or if the objective state of scientific and technical knowledge, during the period the product was within its control, did not allow the defect to be discovered (Article 11(1)(d) and (e)). Member States may keep existing exceptions to that development risk defence, or introduce new ones for specific product categories under conditions (Article 18). For self-learning systems the development risk defence will be argued, but the test is demanding: recital 52 measures it against "the most advanced level of objective knowledge accessible", not against what the manufacturer actually knew.

Disclosure and presumptions: how claims will be litigated

The changes that will most affect practice are procedural. A claimant who "has presented facts and evidence sufficient to support the plausibility of the claim" can ask the court to order the defendant to disclose relevant evidence at its disposal; a defendant that shows it needs evidence to counter the claim can obtain disclosure from the claimant (Article 9(1) and (2)). Disclosure is limited to what is necessary and proportionate, courts must consider the legitimate interests of all parties concerned, including third parties, and they must be able to protect trade secrets (Article 9(3) to (5)). Recital 42 adds two points lawyers will rely on: the evidence to be disclosed can include documents the defendant has to create by compiling or classifying the available evidence, and access is to be limited so as to protect confidential information, "such as information falling within the scope of legal professional privilege and trade secrets". Courts can also require disclosed evidence to be presented in an "easily accessible and easily understandable manner" (Article 9(6)).

Disclosure is backed by presumptions. The claimant still bears the burden of proving defect, damage and causation (Article 10(1)), but defectiveness is presumed if the defendant fails to disclose relevant evidence, if the product does not comply with mandatory product safety requirements meant to protect against the risk of the damage suffered, or if the damage was caused by an obvious malfunction during reasonably foreseeable use or under ordinary circumstances (Article 10(2)). Causation is presumed once a defect is established and the damage is "of a kind typically consistent with the defect in question" (Article 10(3)). And where, despite disclosure, the claimant faces excessive difficulties "in particular due to technical or scientific complexity", the court presumes defect, causation or both if the claimant shows that they are likely (Article 10(4)). Recital 48 lists the complex nature of the technology used, "such as machine learning", and a causal link that would require the claimant "to explain the inner workings of an AI system" among the factors. Every presumption is rebuttable (Article 10(5)).

The national laws fit these rules into existing procedure in different ways. The Dutch bill ties the non-disclosure presumption to the existing right of inspection in Articles 194 and 195 of the Code of Civil Procedure (13), and the explanatory memorandum points to the safeguards already in those articles: conditions on the request, the court's power to refuse it on the ground of a right of non-disclosure (verschoningsrecht) or for weighty reasons, and its power to set the conditions and manner of disclosure (14) (15). Following recital 48, the memorandum also states that a claimant in an AI-related claim cannot be required, in order to establish excessive difficulties, to explain the specific characteristics of the AI system or how they make causation harder to prove. Germany goes further than the directive requires. Recital 43 leaves disclosure by third parties outside the harmonised field, and section 19 of the new Product Liability Act, as amended on the recommendation of the Bundestag's legal affairs committee, allows a court to order a third party, and not only the defendant, to disclose evidence. A third party need not disclose to the extent that it is entitled to refuse testimony under sections 383 to 385 of the Code of Civil Procedure, which include persons bound by professional secrecy such as lawyers (16) (17). Where the evidence may contain trade secrets, the court can, on a reasoned application, order independent evidence proceedings in which a court-appointed expert reports, the other parties have access only through their counsel, and the court then decides whether the expert's report enters the main proceedings in whole or in part. Article 9(7) of the directive leaves national rules on pre-trial disclosure untouched.

For defendants the lesson is evidence readiness. A manufacturer that cannot produce its technical documentation, risk assessments, test results, update history and logs when a court orders it faces a presumption of defect that it must then rebut, rather than a debate about the evidence. For claimants, the work moves to the plausibility threshold and to framing a disclosure request that a court will find necessary and proportionate. For firms holding clients' technical documents, privilege and professional secrecy become live questions in a way they rarely were in product cases.

Contracts and insurance: what to review now

Liability under the directive cannot, in relation to the injured person, be limited or excluded by a contractual provision (Article 15). The disclaimers and liability caps in end-user licences and SaaS terms therefore have no effect on a natural person's product liability claim. Between businesses the position is different. An operator that has compensated an injured person can pursue the others liable under national law (Article 14), and contracts can allocate that cost through indemnities, recourse clauses and caps between the parties. The directive adds one special rule: a manufacturer that integrates a software component has no recourse against the manufacturer of a defective software component that was a micro or small enterprise when it placed the component on the market, if the integrator agreed by contract to waive that right (Article 12(2)). Small software suppliers can be expected to ask for that waiver, and integrators to price it.

The contract review that the directive calls for is concrete:

Release records. The regime depends on the date each product or version was placed on the market or put into service. Clients should be able to prove those dates.
Update and support commitments. While a product remains within the manufacturer's control, a missing update needed to keep it safe removes the defence that the defect arose after the product was placed on the market. Support periods, end-of-life notices and the allocation of update duties between developer, integrator and reseller need to be written down.
Documentation and logs. Disclosure orders will ask for them, and failure to disclose leads to a presumption. Retention periods should reflect the ten-year expiry period, and the 25 years that apply to latent personal injury.
Cooperation in disclosure. Component suppliers and model providers hold evidence the manufacturer will need. Supply contracts should oblige them to provide it, with a procedure for trade secrets.
Recourse and indemnities. Clauses written for the 1985 regime may not cover software, data loss or psychological harm. The Article 12(2) waiver needs a deliberate decision.
Open-source components. The integrator bears the liability for non-commercial open-source software it builds in. That belongs in its risk assessment, not only in its licence compliance.
An EU operator for non-EU suppliers. Importers and authorised representatives, and failing both the fulfilment service provider, are liable when the manufacturer is outside the Union, and should negotiate accordingly.
Insurance. Policies bought while it was unclear whether software was a product were not written with strict liability for code in mind. Clients should check, with their broker, whether their policies respond to strict liability claims by individuals for injury and private data loss caused by software.

One drafting habit has to change. Warnings and instructions remain part of a product's presentation, but recital 31 states that warnings or other information cannot make an otherwise defective product safe, and that liability "cannot be avoided simply by listing all conceivable side effects". A long disclaimer in an AI product's terms is no substitute for a design and testing record.

Where the Netherlands, Germany and France stand

The Netherlands: a bill passed by the lower house

The Dutch implementing bill, the Implementatiewet richtlijn herziening productaansprakelijkheid (parliamentary papers 36906), rewrites the product liability section of Book 6 of the Civil Code (13). The current text defines a product as a movable thing and electricity, without mentioning software, and limits property damage to things ordinarily intended for private use and mainly used privately by the injured person, subject to a EUR 500 deductible (9). The bill adds a definitions article, Article 6:184a, which includes software in the definition of product and excludes non-commercial open-source software, replaces the "producer" with the "economic operator", introduces the presumptions in Article 6:188 and sets out the new types of damage in Article 6:190. It moves the ten-year expiry period, now in Article 6:191(2), to a new Article 6:191a and adds the 25-year extension for latent personal injury. The deductible disappears. A transitional provision in the Transitional Act for the new Civil Code keeps the old text for products placed on the market or put into service before 9 December 2026. The explanatory memorandum states that the Netherlands will not derogate from the development risk defence, although the Dutch consumers' association had asked for an exception for sensitive product categories, and confirms that information is not a product (14).

The House of Representatives adopted the bill without a vote on 15 October 2026. In the Senate, unless a member asks for written preparation by 3 November, the Justice and Security committee will report without comments and the bill will be adopted as a formality, without debate or vote, on 10 November (3). The act will then enter into force on a date set by royal decree.

Germany: a new act, due to enter into force on 9 December

Germany is replacing its 1989 Product Liability Act completely. The Act on the Modernisation of Product Liability Law and the Amendment of Other Provisions was adopted by the Bundestag on 8 October 2026 in the version recommended by its legal affairs committee, and the Bundesrat decided on 16 October not to call the mediation committee; promulgation was still pending on 23 October (2) (16). The new Product Liability Act is to enter into force on 9 December 2026, and its transitional provision keeps the old act for products placed on the market or put into service up to and including 8 December 2026. Section 2(1) no. 3 names software, except free and open-source software developed or supplied outside a commercial activity, as a product; the government's explanatory notes confirm that this covers SaaS and that information, such as the content of media files or e-books, is not software (10). The committee's main change concerned disclosure, described above. The Bundestag also asked the government to examine compulsory insurance for authorised representatives of non-EU manufacturers and a privately funded compensation fund.

France: no bill yet

French product liability law is in Articles 1245 to 1245-17 of the Civil Code (18). Article 1245-2 defines a product as any movable, including electricity, without mentioning software; Article 1245-1 limits compensation for property damage to amounts above a threshold set by decree; Article 1245-14 allows clauses between professionals for damage to property not mainly used privately. Answering a written question in May 2026, the Ministry of Justice said that these articles must be amended, that an interministerial working group led by its Directorate of Civil Affairs and the Seal was preparing the transposition, that sector consultations would take place in the first quarter of 2026, and that, rather than folding transposition into the wider reform of civil liability raised in the question, a dedicated text was envisaged at this stage (4). On 23 October 2026 no transposition bill appeared among the government bills listed for 2026 (19).

If nothing is enacted by 9 December, the existing articles continue to apply. A directive cannot of itself impose obligations on private parties, so a claimant cannot rely on the directive's wider definition of product directly against a manufacturer. French courts must, however, interpret the Civil Code as far as possible in the light of the directive's wording and purpose, and a Member State that fails to transpose on time can be liable in damages to those who suffer loss as a result. Article 18 adds a French detail: France's existing rule that the development risk defence cannot be invoked where the damage was caused by an element of the human body or products derived from it (Article 1245-11) must be notified to the Commission by 9 December 2026 if France wishes to maintain it.

Across the Union the picture is similar. On 23 October 2026 the EUR-Lex register of national transposition measures listed notified measures only from Croatia and Hungary (20).

The law firm's own position

As a buyer of AI tools. The directive gives a firm almost nothing against its own vendors. A firm is not a natural person, and although a sole practitioner is one, matter data are professional data in any case. What a firm loses when a tool fails is money and time. The contract is what protects it: service levels, data restoration and backup duties, security commitments, liability caps that are proportionate to the risk, and an exit that returns the firm's data. Our vendor due diligence checklist sets out the questions to ask before a tool reaches client work. The directive does change one thing for buyers: vendors now have a stronger reason to document their products, updates and testing, because they will need that record in product claims, and a firm can ask to see it.

As a supplier of software. Firms increasingly put software in their clients' hands: contract generators, calculators, client portals, chatbots that answer first questions. A firm that develops such a tool, or has one built and offers it under its own name, is its manufacturer once it makes the tool available in the course of its business, whether or not it charges for it. The exposure is limited, because the damage covered is injury to natural persons and damage to their privately used property and private data, and a corporate client has no claim of its own. A tool offered to consumers is another matter, and the firm should treat its security updates and data handling as a manufacturer would. Advice given by the firm's lawyers remains a service, and the directive does not apply to services as such (recital 17); Krone-Verlag draws the same line. Whether the output of a chatbot the firm supplies is part of the product is the open question discussed above.

As litigators. The first claims will turn on disclosure. Claimant firms will need technical experts early, to make a request plausible and specific. Defendant firms will need to know where their client's evidence sits, which parts are trade secrets, and which parts are privileged, including communications with the firm itself.

Six weeks to 9 December: an action list

Map the products. For each client, list the software and connected products that will be placed on the market or substantially modified on or after 9 December 2026, and those that remain under the old regime.
Record the dates. Make sure clients keep evidence of when each product or version was placed on the market or put into service, and of what changed in each update.
Decide the update policy. Support periods, security update commitments and end-of-life communication, documented and reflected in customer terms.
Prepare for disclosure. Identify the documentation, risk assessments, test records and logs a court could order, set retention periods to match the expiry periods, and plan the protection of trade secrets.
Review the contract chain. Recourse and indemnity clauses with component suppliers, model providers and distributors; the Article 12(2) waiver for small software suppliers; cooperation duties in litigation.
Check insurance. Confirm that product liability and professional indemnity cover respond to strict liability claims by individuals involving software, psychological injury and data loss.
Name an EU operator. Clients outside the Union need to know which importer, authorised representative or fulfilment provider will answer for their products.
Look at the firm's own tools. List the software the firm supplies to clients or the public and decide who maintains and updates it.
Watch the calendar. The Dutch Senate on 10 November and the royal decree on entry into force, promulgation of the German act, and any French bill.

How LexVera supports this work

The transition is where research goes wrong. For years the same dispute may involve two versions of the same rules: the old text of the Dutch Civil Code for a product placed on the market before 9 December 2026, the new one for its successor. LexVera is built for Dutch and European law: Dutch legislation and case law, EU law and the case law of the Court of Justice, and the case law of the European Court of Human Rights. It reads Dutch legislation in the wording that applied on the date relevant to the matter, and shows when that wording differs from the current text. For German and French product liability law, which LexVera does not cover, it can still help with the directive itself, the Court of Justice's case law and the Dutch implementation in cross-border matters.

Each proposition in LexVera's research stays tied to the passage of the official text it rests on, so the reviewing lawyer opens the provision or the judgment rather than relying on a summary of it. A firm's own documents stay within its workspace, under the access rules it sets for its matters and teams. LexVera supports the preparation; a qualified lawyer decides what becomes advice, which is the standard set out in our editorial policy.

Frequently asked questions

When do the new EU product liability rules apply?

To products placed on the market or put into service after 8 December 2026, that is, from 9 December 2026. That is the wording of Article 2(1) of Directive (EU) 2024/2853 as corrected on 7 May 2026. Products placed on the market or put into service before that date remain under the 1985 directive and the national law that implements it, so both regimes will be applied side by side for at least ten years.

Is software, including SaaS and AI, a product under the new directive?

Yes. Software is a product irrespective of how it is supplied or used: installed on a device, accessed over a network or the cloud, or provided as software as a service. The directive names operating systems, firmware, computer programs, applications and AI systems, and treats providers of AI systems as manufacturers. Software supplied free of charge is covered when it is supplied in the course of a commercial activity; free and open-source software developed or supplied outside such an activity is not. Information, such as the content of digital files or the mere source code of software, is not a product.

Can a law firm claim under the directive if its legal AI tool fails?

Generally not. Only natural persons can claim, and only for death or personal injury, damage to property not used exclusively for professional purposes, and the destruction or corruption of data not used for professional purposes. A firm's losses are usually economic or concern professional data, which the directive does not cover. Its remedies remain the contract with the vendor and fault-based liability under national law.

Can liability be excluded in licence or SaaS terms?

Not towards the injured person. The directive prohibits limiting or excluding liability by contract or by national law, which also rules out financial ceilings. Between businesses, the allocation of the cost remains possible through recourse and indemnity clauses under national law. One special rule applies: an integrator can waive by contract its recourse against a micro or small enterprise that supplied a defective software component.

What happens in France if the directive is not transposed by 9 December 2026?

Articles 1245 to 1245-17 of the Civil Code continue to apply as they stand. A directive cannot by itself impose obligations on private parties, so the directive's wider scope cannot be enforced directly against a manufacturer. French courts must, however, interpret the existing articles as far as possible in conformity with the directive, and a late transposition can engage the liability of the State. On 23 October 2026 no transposition bill appeared among the government bills listed for 2026.

Does the directive cover damage caused by an AI system's output?

This is not settled. An AI system is software and therefore a product, but the directive states that information is not a product, and the Court of Justice held in Krone-Verlag, under the 1985 directive, that inaccurate health advice printed in a newspaper did not make the newspaper a defective product. Where an AI system's output causes personal injury, it is open whether that is a defect in the product or information outside the directive. Where the output causes only financial loss, the directive does not apply in any event.

Sources and methodology

This guide reflects the directive, its corrigendum, the Dutch and German parliamentary records, the French ministerial answer and the other sources listed below as available on 23 October 2026. On that date the Dutch bill had not yet passed the Senate, the German act had not yet been promulgated, and we had found no French transposition bill. Statutory provisions are paraphrased in English; quoted wording of the directive and of the Court of Justice is the official English text. This is general professional information, not advice on a specific matter.