EU Product Liability Directive 2024/2853: What Romanian Tech Businesses Must Know About Software As a Product

The EU Product Liability Directive 2024/2853 fundamentally redefines what counts as a “product” under European strict-liability law, and software is now squarely within scope. Adopted on 23 October 2024 and published in the Official Journal on 18 November 2024, Directive (EU) 2024/2853 repeals the decades-old Council Directive 85/374/EEC and gives Member States until 9 December 2026 to transpose its provisions into national law. For Romanian technology companies, from SaaS providers and embedded-software developers to AI start-ups, this is not a distant regulatory exercise: it is an imminent operational reality that demands action now. At Olawru, we are already advising clients on how to restructure compliance programmes, renegotiate supply-chain contracts and prepare litigation-readiness frameworks before the transposition deadline arrives.

In my view, many Romanian tech businesses still underestimate how radically this Directive changes their exposure. The inclusion of software, AI systems and digital manufacturing files as products subject to strict liability, combined with new disclosure orders, evidentiary presumptions and an expanded catalogue of recoverable damages, creates a legal environment that no technology company operating in or exporting to the EU can afford to ignore.

What the EU Product Liability Directive 2024/2853 Means for Software

Legislative basis and key objectives

Directive (EU) 2024/2853 was adopted by the European Parliament and the Council on 23 October 2024 under the ordinary legislative procedure (procedure reference 2022/0302(COD)). Its core objective is to modernise the EU’s strict-liability framework so that it adequately addresses risks created by digital products, artificial intelligence and circular-economy business models. The European Commission described the reform as bringing “product liability rules in line with the digital age and circular economy,” recognising that the previous framework, designed in 1985 for tangible goods, was structurally unfit to address harm caused by intangible software and autonomous systems.

Scope: software, AI systems and digital manufacturing files defined as products

The Directive explicitly classifies software as a product. This includes both integrated software (embedded in physical devices) and stand-alone software (distributed independently), as well as AI systems and digital manufacturing files such as 3D-printing blueprints. The scope covers both embodied software, code running on a physical product, and non-embodied software delivered purely as a digital service or download. Critically, free and open-source software developed or supplied outside the course of a commercial activity is excluded, but any commercially distributed open-source component falls within scope. For Romanian SaaS companies, this means that cloud-delivered applications, mobile apps and AI-driven analytics platforms are now treated as software products under EU strict-liability rules.

When it applies: timeline and territorial reach

The legislative timeline is clear. The Directive was adopted on 23 October 2024, published in the Official Journal on 18 November 2024, and entered into force twenty days after publication. Member States have a twenty-four-month transposition window, which means national implementing legislation must be in place by 9 December 2026. Romania has not yet published its transposition act in the Monitorul Oficial as of July 2026, but the deadline is binding regardless of national legislative progress. Businesses should not wait for the Romanian implementing statute, the substantive obligations are clear from the Directive text, and any delay in preparation will compress an already tight compliance window.

The Directive applies to products placed on the market or put into service after the transposition date, meaning that product liability software Romania businesses develop or distribute from December 2026 onward must comply from day one.

What “Defect” Means for Software and AI Under the EU Product Liability Directive 2024/2853

Traditional defect tests versus software

Under the old Directive 85/374/EEC, defectiveness was assessed by reference to the safety a person is entitled to expect, considering presentation, reasonably foreseeable use and the time the product was put into circulation. That framework assumed a static, tangible product. Software, by contrast, evolves continuously, through updates, patches, configuration changes and, in the case of AI, autonomous learning. The new Directive retains the “entitled to expect” test but adapts it to account for the dynamic nature of digital products.

Concrete defect examples: software defect, cybersecurity updates and AI drift

The Directive makes clear that a software product can be defective if it fails to deliver the level of cybersecurity that the public is entitled to expect, or if the manufacturer fails to provide necessary security updates after deployment. In practice, this creates several concrete categories of software defect:

• Cybersecurity vulnerability. A connected medical device ships with a known, unpatched vulnerability in its communication protocol. An attacker exploits the flaw, causing the device to deliver incorrect dosage readings. The failure to patch a known vulnerability before market release, or within a reasonable timeframe after discovery, constitutes a defect.
• Failure to update or patch. An IoT home-automation platform ceases issuing security patches eighteen months after release while the product is still in active consumer use. If a breach occurs because of the unpatched software, the manufacturer’s failure to maintain the product’s safety through updates makes the software defective.
• Inadequate model training. An AI-powered credit-scoring tool is trained on a dataset that systematically underrepresents certain demographic groups, resulting in discriminatory and financially harmful decisions for affected consumers.
• Emergent post-deployment behaviour. A machine-learning system deployed in an autonomous logistics robot modifies its navigation parameters through reinforcement learning, producing unforeseeable collision patterns not present during initial testing.

How courts will assess defectiveness for ongoing and learning systems

A key challenge for Romanian courts, and for courts across the EU, will be determining the relevant moment at which defectiveness is assessed for a product that continuously evolves. The Directive addresses this by requiring courts to consider whether the manufacturer retained the ability to control the product after placing it on the market, including through software updates, AI model adjustments or ongoing data feeds. Where a manufacturer maintains such control, defectiveness can be assessed at the time the damage occurred, not only at the time of initial market placement.

This is a significant departure from the 1985 framework and has direct implications for lifecycle management: Romanian tech companies must document every update, patch and model retraining event to defend against future defectiveness claims.

Who Can Be Held Strictly Liable Under the Directive

The strict liability standard: no need to prove fault

The Directive imposes strict liability, meaning the injured party does not need to prove that the manufacturer was negligent or at fault. It is sufficient to demonstrate that the product was defective, that damage occurred, and that there is a causal link between the defect and the damage. For strict liability software EU businesses, this is a fundamental shift: product-liability exposure no longer depends on whether the company exercised reasonable care. A defective product triggers liability regardless of intent or diligence.

EU hierarchy of liable actors: manufacturers, importers, authorised representatives and distributors

The Directive establishes a clear liability hierarchy to ensure that an injured party can always pursue an EU-based defendant. The primary liable actor is the manufacturer, the entity that develops, produces or presents a product under its own name or trademark. When the manufacturer is established outside the EU, liability extends in sequence to:

• The importer, the first entity that places the product on the EU market.
• The authorised representative, an entity mandated by the non-EU manufacturer to act on its behalf under applicable EU product-safety legislation.
• The fulfilment service provider, where no importer or authorised representative exists in the EU.
• The distributor, in certain circumstances where the distributor fails to identify the upstream economic operator.

This hierarchy is particularly significant for Romanian companies that distribute, rebrand or integrate software components from non-EU developers. If a Romanian company imports a software module from a US or Asian developer and incorporates it into its own product, it may bear strict liability as the importer or, if it markets the combined product under its own brand, as the manufacturer.

Practical implications for SaaS vendors, cloud providers and marketplaces

SaaS vendors and cloud providers need to map their supply chains immediately. Where third-party libraries, APIs or AI models are incorporated, contractual liability allocation through supply-chain indemnities becomes essential, though, as I discuss below, such clauses cannot eliminate the vendor’s statutory liability toward the injured party. Online marketplaces that facilitate the distribution of software products may also face exposure under the fulfilment-service-provider route if they handle storage, packaging or dispatch of physical media or connected devices.

Damages Covered and Valuation Challenges

Expanded damage categories: psychological harm, data destruction and beyond

The Directive significantly broadens the categories of recoverable damage compared to the 1985 framework. Compensation now explicitly covers:

• Death and personal injury, including medically recognised psychological harm, a category that is entirely new to the EU product-liability framework.
• Damage to or destruction of property, without the previous EUR 500 threshold that applied under Directive 85/374/EEC.
• Loss or corruption of data that is not used exclusively for professional purposes, recognising that consumer data loss caused by defective software constitutes real, compensable harm.

The inclusion of damages for psychological harm and non-professional data destruction is directly relevant to Romanian technology companies. A defective consumer app that causes data loss, a malfunctioning AI chatbot that delivers harmful medical advice, or a cybersecurity breach that exposes personal data could each trigger claims for these expanded damage categories.

Valuation challenges for data loss and harm from AI decisions

From what I am seeing in practice, quantifying damages for data destruction and AI-driven harm presents genuine challenges. Unlike physical property damage, lost digital data does not have an easily ascertainable market value. Courts will need to develop methodologies for valuing irreplaceable personal photographs, corrupted financial records or destroyed creative works. For AI-related harm, such as a flawed algorithmic decision that denies a consumer access to housing or insurance, the causal chain may involve multiple intermediate steps, making both causation and quantum difficult to establish. Insurers and legal teams should begin developing valuation frameworks now, rather than waiting for the first wave of litigation to define the parameters.

Evidence, Disclosure Orders and Presumptions Under the EU Product Liability Directive 2024/2853

New disclosure powers and presumptions

One of the most practically significant innovations in the Directive is the introduction of disclosure orders and rebuttable presumptions that shift the evidentiary balance in favour of claimants. Under the new rules, a court may order the defendant to disclose relevant evidence in its control, including technical documentation, source code, update logs, model-training data and cybersecurity incident records. If a defendant refuses to comply with a disclosure order, or fails to comply adequately, the court may presume that the product was defective. Similarly, where a claimant demonstrates that a product does not comply with mandatory safety requirements, or that the damage was caused by an obvious malfunction, defectiveness may be presumed.

These provisions on disclosure orders product liability EU-wide will fundamentally alter the dynamics of product-liability litigation.

Protecting trade secrets and legal privilege

The Directive acknowledges that disclosure orders must be proportionate and may engage legitimate interests in protecting trade secrets and confidential business information. Courts are required to apply proportionality tests and may impose confidentiality orders, restrict access to disclosed materials, or use in-camera procedures. However, the existence of trade secrets does not constitute an absolute bar to disclosure, Romanian defendants should expect courts to balance transparency against commercial confidentiality on a case-by-case basis.

Litigation checklist: documents to preserve and how to respond to disclosure orders

In my experience advising technology clients, the single most valuable step a company can take now is implementing a systematic document-preservation policy. The following records should be created, maintained and securely stored:

• Software update and patch logs, version history, deployment dates and scope of each update.
• Cybersecurity incident records, vulnerability reports, remediation actions and timelines.
• AI model training and validation logs, datasets used, training parameters, validation results and retraining events.
• Change-control documentation, records of design decisions, risk assessments and testing protocols.
• Distribution and deployment records, which versions were distributed to which markets, and when.

Contracts, Warranties and Limitations: Drafting for New Product Liability Software Romania Rules

Which contractual clauses will not exclude PLD claims

A critical point that many businesses overlook: the Directive’s strict-liability regime is mandatory and cannot be excluded or limited by contract. Contractual liability caps, limitation-of-liability clauses and disclaimers that purport to waive product-liability claims against the manufacturer are ineffective insofar as they conflict with the rights granted to injured parties under the Directive. This does not mean that contractual risk allocation is irrelevant, but it means that such allocation operates only between commercial parties in the supply chain, not as a shield against end-user claims.

Recommended clauses: supply-chain indemnities, update schedules and authorised-representative provisions

While contractual clauses cannot eliminate statutory liability, they remain essential tools for allocating risk within the supply chain. I recommend that Romanian software businesses incorporate the following provisions into their commercial agreements:

• Supply-chain indemnity. “The Supplier shall indemnify and hold harmless the Buyer against any and all claims, damages and costs arising from product-liability claims attributable to defects in the Supplier’s software component, including claims brought under national legislation transposing Directive (EU) 2024/2853.”
• Mandatory update and patching schedule. “The Supplier shall provide security patches for Critical and High-severity vulnerabilities within [X] business days of discovery and shall maintain update support for a minimum period of [Y] years following initial market placement.”
• EU authorised-representative clause. Where contracting with a non-EU software developer, require the appointment of an authorised representative within the EU and specify that the representative’s details must be communicated to the buyer and to relevant market-surveillance authorities.
• Notice and cure provisions. Establish clear timelines for defect notification and remediation, with escalation mechanisms if the supplier fails to cure within the agreed period.
• Insurance requirements. Require suppliers to maintain product-liability insurance with coverage adequate to respond to claims under the transposed Directive.

Practical Compliance Checklist for Romanian Businesses

Based on my work with Romanian technology companies, I recommend the following prioritised action items, ordered by implementation urgency:

• 1. Audit your product portfolio. Identify every software product, AI system and digital component your business manufactures, imports, distributes or integrates. Determine which products fall within the Directive’s scope.
• 2. Map your supply chain. For each in-scope product, identify the manufacturer, any non-EU suppliers and the applicable EU-based economic operator (importer, authorised representative or fulfilment service provider).
• 3. Implement a document-retention policy. Establish systematic retention of update logs, patch records, cybersecurity incident reports, AI training data, change-control documentation and distribution records.
• 4. Appoint an EU authorised representative (if applicable). If your business manufactures software outside the EU and distributes it within the EU, ensure an authorised representative is appointed and their details are disclosed.
• 5. Update terms and conditions. Review and revise end-user agreements, warranty terms and supply-chain contracts to align with the Directive’s mandatory liability provisions and to incorporate the recommended contractual clauses outlined above.
• 6. Review insurance coverage. Assess whether existing product-liability insurance policies cover software-related claims, including claims for data loss, psychological harm and cybersecurity-related defects. Adjust coverage limits as needed.
• 7. Establish an incident-response framework. Create or update your incident-response plan to ensure that potential product defects are identified, documented and remediated within timeframes that will withstand judicial scrutiny.
• 8. Train your teams. Ensure that product managers, developers, QA teams and legal/compliance personnel understand the new strict-liability standard and their respective roles in maintaining compliance.

Timeline of Key Legislative Dates

The following table summarises the critical milestones for the EU Product Liability Directive 2024/2853. Romanian businesses should use this timeline to benchmark their own compliance preparations against the binding transposition deadline.

Conclusion

The EU Product Liability Directive 2024/2853 represents the most significant expansion of European product-liability law in four decades, and its treatment of software as a product subject to strict liability will reshape the legal landscape for Romanian technology businesses. The 9 December 2026 transposition deadline is not a distant prospect, it is an operational imperative. In my professional view, the companies that act now to audit their product portfolios, restructure their supply-chain contracts, implement document-retention protocols and review their insurance coverage will be materially better positioned than those that wait for the Romanian implementing act to appear in the Monitorul Oficial.

The Directive’s text is clear, its obligations are specific, and its enforcement mechanisms, from disclosure orders to presumptions of defectiveness, are designed to give claimants real teeth. Preparation is not optional; it is the cost of doing business in the EU’s digital economy.

Last reviewed: 27 July 2026. This article will be updated when Romania publishes its transposition act.

Sources

1. Directive (EU) 2024/2853, EUR‑Lex
2. European Commission, Product Liability Directive factsheet
3. European Parliament, Press release on new PLD
4. Council of the EU, Press release on PLD adoption
5. Legislative Observatory (OEIL), Procedure file 2022/0302(COD)
6. Universitatea Babeș‑Bolyai, Liability regime for defective products under Directive (EU) 2024/2853