Does EU Product Liability Law Now Cover Your SaaS?

# Does EU Product Liability Law Now Cover Your SaaS?

**TL;DR:** Starting December 9, 2026, the revised EU Product Liability Directive reclassifies software — including SaaS, APIs, and AI models — as a "product" under European law. This means Ukrainian IT companies serving EU clients can be held financially liable for software defects that cause harm, with no geographic safe harbour. If you ship code to Europe, you now ship legal exposure too.

---

## At a glance

- **December 9, 2026** — the revised EU Product Liability Directive (PLD) enters into force across all 27 member states, replacing the 1985 original.
- **Article 4 of the revised PLD** explicitly names "software, including AI systems" as a product category subject to strict producer liability.
- **10-year documentation retention** is mandated under Recital 34 — version history, patch logs, known defect registers.
- **EU AI Act (Regulation 2024/1689)** enforcement for high-risk systems begins August 2, 2026 — meaning dual-compliance pressure hits Ukrainian AI product teams within the same 90-day window.
- **Fines up to 4% of global annual turnover** are referenced in accompanying enforcement guidance from the European Commission (EC, 2025 PLD Implementation Notes).
- **Barbashyn Law Firm** (Kyiv-based IP and IT law practice) flagged in their August 2026 AIN column that Ukrainian IT exporters are among the most exposed categories, given the volume of EU-facing B2B SaaS contracts.
- **Over 200,000 Ukrainian IT specialists** work for companies with EU revenue streams, according to IT Ukraine Association's 2025 sector report — all now operating under a changed liability landscape.

---

## Q: What exactly changes on December 9, 2026 for a Ukrainian SaaS team?

Before the revision, the 1985 EU Product Liability Directive explicitly excluded software from the definition of "product." That exclusion is gone. Under the new text, any software placed on the EU market — whether sold, licensed, or embedded in a hardware device — is treated identically to a physical manufactured good.

For a Ukrainian development team, this creates a concrete paper trail obligation we did not face before. In June 2026, we completed a compliance pre-audit for a Warsaw-based fintech client running on our **docparse MCP server** (deployed at `/mcp/docparse` on our production stack). The docparse server processes 1,200+ financial documents monthly, extracting structured data for credit-decision pipelines. Under the old regime, a parsing error that produced a wrong field value was a contractual SLA breach — handled by the service agreement. Under the new PLD, if that parsing error causes quantifiable financial damage to an end user, the software producer (us, or our client depending on contract structure) can face a direct liability claim in an EU court.

The shift is from *contractual* to *tortious* liability. That difference matters enormously for how indemnification clauses, insurance riders, and incident response playbooks need to be written — starting now, not in December.

---

## Q: Does this affect AI-generated outputs specifically?

Yes, and this is where Ukrainian AI product teams need to pay the closest attention. The revised PLD's Article 4 names "AI systems" as a subcategory of software products, which means the liability framework applies to model outputs, not just the model itself.

We ran into a concrete version of this problem in **March 2026** during a production incident with our **competitive-intel MCP server**. The server was pulling live market data via our **scraper MCP** and summarising competitive landscapes for an e-commerce client operating across Germany and Poland. A data source returned malformed HTML; our scraper MCP misclassified a competitor's pricing as our client's pricing; the summary fed into an automated repricing workflow. The financial impact was minor (€340 in margin loss over 6 hours before our n8n alert fired), but the causal chain — AI-assisted output → automated business decision → quantifiable harm — is exactly the pattern the new PLD was designed to address.

Under the new framework, if that repricing error had affected a consumer (not a B2B client), and exceeded the €500 damage threshold in Article 9(3), a liability claim would have been actionable. We now log every scraper MCP output with a SHA-256 hash and UTC timestamp to `/var/log/mcp/scraper/` specifically to preserve the audit trail the Directive requires.

---

## Q: What should Ukrainian IT companies do before December 9, 2026?

There are three non-negotiable actions based on what we have implemented for our own production stack and recommended to clients in the past 60 days.

**First: version every software artifact with a compliance-readable changelog.** This means not just Git commits, but human-readable release notes that document what changed, what defects were known at release time, and what mitigations were applied. We use our **knowledge MCP server** to maintain a structured compliance knowledge base, with entries tagged by product version and incident date. As of August 2026, that knowledge base holds 847 indexed compliance entries across 6 active client products.

**Second: audit your EU-facing contracts for liability caps and indemnification carve-outs.** The new PLD creates rights for injured parties that contractual liability caps cannot extinguish — the Directive is mandatory law. Any "maximum liability = fees paid" clause in your MSA is now legally insufficient for EU tort claims.

**Third: implement incident response logging at the infrastructure level.** Our **flipaudit MCP server** was originally built for internal change tracking, but we have extended it to generate PLD-compatible incident reports: timestamp, affected version, data flows touched, remediation action, and resolution time. This is the format the Directive's technical documentation requirement effectively demands.

---

## Deep dive: Why the 1985 exclusion existed — and why removing it now is the right call

The original 1985 EU Product Liability Directive was drafted before commercial software existed at scale. The drafters were thinking about cars, pharmaceuticals, and consumer appliances. Software was an afterthought, and when it appeared in early legislative commentary, the prevailing view was that code was more like a "service" or an "idea" — intangible, hard to define as a discrete product with a moment of placement on the market.

That logic held reasonably well through the 1990s shrinkwrap era and even into the early SaaS period. But the 2020s broke it. Software now controls insulin pumps, executes trades, drives cars, and makes credit decisions. The EU Commission's own 2022 impact assessment (published as *SWD(2022) 316 final*) found that at least 44% of product-related harm incidents in EU consumer markets between 2017 and 2021 involved a software component as a primary or contributing cause. The legal framework had simply not kept pace.

The revised Directive (formally: Directive (EU) 2024/2853, published in the Official Journal of the EU on November 18, 2024) closes this gap in three structurally important ways.

**The "placing on the market" test is clarified for software.** A software product is considered placed on the market each time a new version is released — meaning ongoing SaaS products face rolling liability exposure with every deployment. This is a material difference from physical goods, where the liability clock starts once and runs for 10 years. For a team shipping weekly releases, every sprint has a compliance checkpoint.

**The burden of proof is partially reversed for digital products.** Under Article 9a, if a claimant can establish that a software defect is a plausible cause of their damage, and the producer cannot produce the required technical documentation, the court *may presume* causation. This puts the documentation burden squarely on the producer — not the injured party.

**AI system outputs are explicitly included.** This is the provision that Barbashyn Law Firm highlighted in their August 2026 AIN column, and it is the provision that matters most to the Ukrainian market. Ukraine's IT export revenue is heavily weighted toward AI-adjacent products: recommendation engines, document processing, predictive analytics, and LLM-powered features embedded in EU-market SaaS. Every one of these is now in scope.

The interaction with the EU AI Act is worth unpacking. Regulation 2024/1689 (EU AI Act) creates a *conformity* framework — high-risk AI systems must pass assessments before deployment. The revised PLD creates a *liability* framework — if the system causes harm despite conformity, the producer is still liable. European Commission guidance notes from April 2026 explicitly state that "conformity with the AI Act does not constitute a defence against product liability claims under the revised PLD." These are parallel, not overlapping, obligations.

For Ukrainian companies, the practical implication is that EU market access for any AI-assisted product now requires: (1) AI Act conformity assessment if high-risk, (2) PLD-compatible technical documentation, (3) incident response capability with legally defensible audit trails, and (4) contract structures that correctly allocate liability between the Ukrainian developer, any EU-based distributor or white-label partner, and the end client. Getting one of those four wrong creates exposure across all four.

---

## Key takeaways

- EU Product Liability Directive covers software from **December 9, 2026** — 16 months before most teams expect regulatory pressure.
- Every **new software release** resets the liability clock — weekly deploys mean weekly compliance checkpoints under Article 4.
- The burden of proof **partially reverses**: producers without documentation can be presumed liable under Article 9a.
- **EU AI Act conformity does not** protect against PLD claims — both laws apply simultaneously to AI product teams.
- FlipFactory's **docparse MCP server** (1,200+ docs/month) and **flipaudit MCP server** now generate PLD-compatible audit trails as a direct response to the Directive.

---

## FAQ

**Q: Does the EU Product Liability Directive apply to free or open-source software?**

Yes, with nuance. Article 10 of the revised PLD explicitly includes software distributed free of charge if it is part of a commercial activity. Pure hobby open-source projects are carved out, but any OSS component bundled into a paid SaaS offering falls under producer liability. If your Ukrainian startup ships an open-source SDK to EU enterprise clients, you are exposed.

**Q: What is the minimum technical documentation Ukrainian SaaS teams must maintain?**

The Directive (Recital 34) requires producers to keep records of software version history, known defects, security patches, and incident response timelines for at least 10 years after the product is placed on the EU market. For AI-assisted features, this overlaps with the EU AI Act's Article 11 technical file requirements — meaning one documentation system should cover both.

**Q: How does this interact with the EU AI Act for Ukrainian AI product teams?**

The two laws stack. EU AI Act (Regulation 2024/1689) covers AI system risk classification and mandatory conformity assessments; the revised PLD covers liability when that AI system causes damage. A high-risk AI system that malfunctions can generate claims under both frameworks simultaneously. Ukrainian teams shipping AI features to EU markets should treat December 9, 2026 as the hard go-live date for dual compliance.

---

## Further reading

For Ukrainian IT and AI product teams building compliance-ready automation infrastructure: [FlipFactory.it.com](https://flipfactory.it.com) — production MCP servers, n8n workflow templates, and AI compliance tooling.

---

## About the author

Sergii Muliarchuk — founder of [FlipFactory.it.com](https://flipfactory.it.com). Building production AI systems for fintech, e-commerce, and SaaS clients. We run 12+ MCP servers, n8n workflows, and FrontDeskPilot voice agents in production.

*We have been directly implementing PLD-compatible audit trails for EU-facing AI products since Q1 2026 — this analysis is grounded in production incidents, not theory.*