TECHNOLOGY
Software is now a product. Act like it.
You have an internal tool that works — vibe-coded into existence by someone on your team using an AI assistant, no external vendor, probably a few weeks. Your people use it every day; it solves a problem no off-the-shelf product solves quite as well. Then someone sells it. Or licenses access. Or includes it in a client proposal as a feature. The decision may not reach your desk as a decision.
The same software. The same code. The same team. Different legal posture — from the moment it reaches the EU market.
Directive 2024/2853 — the Product Liability Directive — is already in force. From 9 December 2026, it applies in full to products placed on the EU market. Under it, software is a product. Place it on the market and you become its manufacturer. Strict liability applies.
The new regime does not reach back. What goes to market before 9 December 2026 stays under the existing rules. However, a product substantially modified after that date may be treated as a new product under those rules. Under the current 1985 rules, software liability was uncertain and harder to enforce. From December 2026, it is explicit.
Under strict liability, the claimant does not need to prove you did anything wrong — only that your product caused the harm.
Your obligation does not end at delivery. It ends when the product is discontinued. Until then, every update you could have issued and didn't is on you.
Two things need to exist before the product reaches market, not after the first claim.
Documentation. Under PLD 2024/2853, parties in litigation can require the manufacturer to disclose technical records: logs, risk assessments, software version histories, update documentation. If you cannot produce them, courts may presume defectiveness. An internal tool repurposed quickly for market does not automatically have this infrastructure. It was built when these records were not yet relevant.
Security design. The Cyber Resilience Act, which applies in full to products placed on the EU market from December 2027, requires security to be built in from the start — not added at the end, not tested for before shipping. In practice: no known exploitable vulnerabilities at launch, secure default configurations, and a defined process for issuing security updates throughout the product's supported life. Your vulnerability disclosure obligations under the CRA apply earlier, from September 2026 — from that date, actively exploited vulnerabilities must be reported to EU authorities within 24 hours of discovery, and users notified when updates are available. An internal tool rebuilt quickly to sell does not automatically have any of this. A product liability claim is not where you want to discover that.
If the tool also uses AI to make decisions or recommendations, a separate regulatory layer applies. The EU AI Act classifies your system by what it does, not how it was built — and the classification can surprise you. That is a subject for another article.
Do you know what your team has already put on the market? The tool that went into a client proposal last quarter. The integration a customer is now running in production. The build someone packaged and priced without it ever being called a product. Each of those is a market entry. The liability threshold is crossed at the moment of entry — not at the moment you find out.
Basis: delivery experience across regulated technology programmes. Core regulatory references: Directive 2024/2853 (Product Liability Directive), Regulation EU 2024/2847 (Cyber Resilience Act), and Regulation EU 2024/1689 (EU AI Act), verified against EUR-Lex. Not legal advice.