Software Becomes a 'Product' in the EU on 9 December 2026: What Indian SaaS, AI and GCC Exporters Must Fix in Their Liability Cover

For forty years, EU product liability law was about things: a gas boiler that exploded, a car seat that failed, a drug with an undisclosed side effect. Software sat in a grey zone, and most Indian technology exporters priced their liability on the assumption that a defective release was a contract problem between them and their customer.

That assumption ends this quarter. Directive (EU) 2024/2853, the revised Product Liability Directive, extends the definition of "product" to software, digital manufacturing files and connected or integrated goods, including AI-enabled products. The European Commission's Transition Pathways page, accessed in October 2026, states that the Directive applies from 9 December 2026, and that it applies regardless of where the responsible economic operator is based. Liability can also reach online platforms and fulfilment service providers.

For a Pune SaaS company selling a fleet-telematics module, a Bengaluru AI firm licensing a diagnostic model to a European device maker, or a global capability centre (GCC) in Hyderabad shipping firmware for its parent's connected appliances, this changes the basis on which a claim can be brought. A claimant no longer has to show breach of contract or negligence. They have to show a defect, damage and a causal link, and the Directive gives courts tools to help them do it.

This post maps where a typical Indian tech errors and omissions (E&O) programme fails to respond, and what to renegotiate before the December date.

Two dates circulate, and both are right in context. The Commission's page says the Directive applies from 9 December 2026. A guest post by Reed Smith on the Drug & Device Law blog, dated 10 September 2026, notes that following a correction to the application date, the Directive applies to products placed on the market after 8 December 2026. In practice, a product first placed on the EU market on or after 9 December falls under the new regime, and products placed earlier stay under the old 1985 Directive.

For software, "placed on the market" is the hard part. A physical good is placed once. A SaaS platform or an embedded model is updated continuously, and each significant release can raise the question of whether a new product version entered the market after the cut-off. Exporters should assume that anything they ship to EU customers from December onward, including updates to existing products, will be assessed under the new rules.

Transposition is uneven

A Directive is not directly applicable law. Each member state must transpose it. The same Reed Smith post reported that as of September 2026:

• Hungary, Croatia and Lithuania had completed transposition.
• Germany, Slovakia and the Netherlands were furthest along among states with published drafts.
• Greece, Luxembourg, Malta, Portugal and Spain showed no known public movement.

Uneven transposition does not mean uneven exposure. Courts may interpret national law in light of the Directive, and a claimant can often choose where to sue. An exporter selling into Spain cannot treat the slow Spanish timetable as a reprieve.

Many Indian SaaS and AI firms buy a combined tech E&O and cyber policy, typically written on a claims-made basis and structured around a "wrongful act": an act, error, omission or breach of duty in rendering professional or technology services. The SaaS tech E&O guide in this corpus explains that structure in detail.

An EU product liability claim does not allege a wrongful act. It alleges that a product was defective and caused damage. Three things follow.

1. The insuring clause may not be triggered. If the policy responds to "claims arising from a wrongful act in the performance of technology services", an insurer can argue that a strict-liability claim about a defective product is not a services claim at all.
2. The bodily injury and property damage exclusion bites. Tech E&O wordings commonly exclude bodily injury and physical property damage, on the logic that those belong in a general or product liability policy. Under the new Directive, death, personal injury (including medically recognised psychological harm) and damage to property are exactly the heads of loss a claimant will plead.
3. The product liability policy may not be there. Many software firms carry no product liability cover at all, or carry an Indian public liability policy with a products extension that was written for office premises, not for code running inside European devices.

The result is a gap that sits between two policies, each excluding what the other was assumed to cover. Read the policy wording side by side, not separately.

The revised Directive does more than widen the definition of product. It shifts the procedural balance toward claimants, and those procedural tools change how claims are defended and what they cost.

Article 9 lets courts order the defendant to disclose relevant evidence at its disposal. For a software company, that can mean source code history, test logs, model training documentation, incident tickets and release notes. Article 10 sets out presumptions of defect and causation. The Reed Smith post flags that the Finnish and Swedish transposition proposals drop the word "excessive" from the Article 10(4)(a) presumption, which turns on the difficulty a claimant faces in proving defect or causation because of technical or scientific complexity. Removing "excessive" may lower the threshold a claimant must clear before the presumption applies.

AI systems are a natural target for that presumption. A claimant who cannot see inside a model can argue that proving the defect is too difficult for them, and in member states that adopt the softer wording, a court may be more willing to shift the burden.

What this means for cover

Defence costs rise sharply when a case turns on disclosure and expert evidence about code. Check three points in any liability wording:

• Whether defence costs erode the limit or sit outside it.
• Whether the insurer's consent is needed before engaging EU counsel and technical experts, and whether its panel includes firms in the relevant member states.
• Whether costs of complying with a court disclosure order count as covered defence costs.

Indian policies issued to software exporters often carry a worldwide territorial limit and a narrower jurisdiction clause, sometimes excluding the USA and Canada and sometimes limited to Indian courts. A claim brought in a Dutch or German court under transposed national law must sit inside both. Confirm that the jurisdiction clause names "worldwide excluding USA/Canada" at a minimum, and that it applies to judgments obtained in EU courts and to settlements negotiated there.

The second trap is the contractual liability exclusion. European customers will respond to the Directive by pushing liability back up the supply chain. A device maker held strictly liable for a defective connected product will seek recourse against the Indian supplier of the software component, and will rely on an indemnity in the master services agreement to do it. Most liability wordings exclude liability assumed under contract unless the insured would have been liable anyway. Where the indemnity goes beyond what the law would impose, the excess sits uninsured.

The same pattern was discussed for AI warranties in the post on EU AI Act contract exposure for Indian GCCs: the regulation creates the obligation, but the loss arrives through a contract.

The Directive treats software updates, and the failure to supply them, as relevant to whether a product is defective while it remains within the manufacturer's control. For an exporter, the remedy for a defect is often an urgent patch, a rollback or a forced update across thousands of installed devices.

Traditional product recall cover, often bought alongside product liability insurance, was written for physical withdrawal: notification, transport, destruction and replacement of goods. It rarely contemplates the costs of an emergency engineering sprint, over-the-air deployment, customer notification in several EU languages and third-party verification of the fix. Where a software or "digital recall" extension is available, its triggers need close reading. Ask whether cover responds to:

• A decision by the insured, without a regulator's order, to withdraw or patch a version.
• Costs incurred by a downstream customer that the insured is contractually obliged to reimburse.
• Loss of the insured's own revenue while a product is suspended.

The last of these is usually excluded in liability forms and belongs, if anywhere, in a business interruption or contingent business interruption extension.

Indian exporters have roughly ten weeks before the application date. The following steps are ordered by how much they change the insurance outcome.

1. Map the product footprint. List every product, module, model or firmware build sold into or embedded in goods sold into the EU, and the date each version was or will be placed on the market.
2. Buy or extend product liability cover. Add a standalone products liability policy, or a products extension to the tech E&O, that responds on a strict-liability basis and covers bodily injury, property damage and data destruction claims arising from software.
3. Amend the E&O insuring clause. Seek wording that responds to claims "alleging a defect in a product or technology service" rather than only to wrongful acts in services.
4. Align territory and jurisdiction. Worldwide territory with a jurisdiction clause that includes EU courts, and confirmation that transposed national law in any member state is covered.
5. Write back contractual liability. Negotiate a carve-back for indemnities given in customer contracts, up to a defined sublimit, and keep customer contracts within that sublimit.
6. Check the retroactive date. Claims-made policies must have a retroactive date that predates the release history you are exposed for, and that date must survive renewal and any change of insurer.
7. Add software recall costs. Even a modest sublimit for patch deployment and notification costs is better than none.

For an AI firm, add one more step: document model governance now. The disclosure tools in Article 9 mean that training data records, evaluation results and change logs will be evidence. Good records do not prevent a claim, but they reduce the room for a presumption of defect and shorten the defence.

Indian insurers writing tech liability for exporters have historically underwritten on revenue, client concentration and US exposure. EU strict liability will add questions. Expect the proposal form or broker submission to cover:

• Share of revenue from EU customers, and whether the insured's software is embedded in consumer-facing physical products.
• Use cases with bodily injury potential: health, mobility, industrial control, home devices, child products.
• Whether the insured acts as manufacturer of record, supplies a component, or is only a service provider.
• Update and patch governance, including how long a known defect can remain unpatched.
• The EU legal entity, authorised representative or importer, if any, through which products reach the market.

The broader point is that the line between a professional services risk and a product liability risk is being redrawn by law, not by underwriters. An Indian exporter that treats December as a compliance date for its legal team alone will find, at the first EU claim, that its insurance was built for the old line. The firms that renegotiate now get to choose their wording. The ones that wait will have it chosen for them at the next renewal, with the claim already notified.