Liability for defective software and AI: what should companies prepare before December 2026?

01

Facts: when do the new rules apply and to which products?

Directive (EU) 2024/2853 replaces Directive 85/374/EEC and requires Member States to adopt implementing rules by 9 December 2026. A corrigendum published in the Official Journal on 7 May 2026 clarified Article 2(1): the new regime concerns products placed on the market or put into service after 8 December 2026 — in other words, from 9 December 2026.

This does not make every software business automatically liable. A specific case still depends on matters such as the operator’s role in the chain, a defect, damage, causation, the date on which the product was marketed and the final national legislation.

This article was verified on 29 October 2026. It provides operational information, not individual legal advice. Before deciding about a particular product, check the enacted Polish law, contracts, distribution model and the actual extent of control over the software.

02

Facts: software, AI, SaaS and cloud delivery fall within the product definition

The Directive explains that software is a product regardless of how it is supplied or used. This includes programs, applications, operating systems, AI systems and software supplied over a network, through the cloud or in a software-as-a-service model. A developer or provider of an AI system can be treated as a manufacturer.

Information, the content of a digital file and source code as such are not products. A digital manufacturing file containing functional information needed to produce a tangible item — such as a file controlling 3D printing — may be treated differently.

The exclusion for free and open-source software concerns solutions developed or supplied outside a commercial activity. Incorporating an open-source component into a commercial product does not automatically release the manufacturer of the finished product from responsibility for the result of that integration.

03

Facts: a defect may involve an update — or the absence of one

The assessment of defectiveness considers the safety that a person is entitled to expect as well as legal and cybersecurity requirements. Relevant factors may include reasonably foreseeable use, product presentation, the ability to learn after deployment, interaction with other products and the period during which the product was within the manufacturer’s control.

The Directive provides that a manufacturer cannot rely on a defect arising later where it results from a related service, software — including an update or upgrade — the lack of a security update needed to maintain safety, or a substantial modification, where that element was within the manufacturer’s control.

For a digital product, release therefore does not end lifecycle responsibility. Support rules, end-of-update dates, vulnerability handling, compatibility, customer notices and evidence explaining why an update was issued, deferred or considered unnecessary become important.

04

Facts: a court may order evidence disclosure and apply presumptions

Once an injured person presents facts and evidence sufficient to support the plausibility of a claim, a court may order the defendant to disclose relevant evidence at its disposal. Disclosure must be necessary and proportionate, and courts should protect confidential information and trade secrets.

As a rule, the injured person proves the defect, damage and causal link. The Directive nevertheless sets out circumstances in which defectiveness or causation may be presumed — including failure to comply with a disclosure order, breach of mandatory safety requirements, obvious malfunction or excessive technical or scientific complexity once the statutory conditions are met.

This is another reason why documentation should be understandable, available and linked to a specific version. A huge log archive with no owner, context or retention policy is not the same as useful evidence.

05

Facts: Polish draft UC163 is not yet binding law

The legislative-work register of the Chancellery of the Prime Minister lists draft UC163, amending the Civil Code and Code of Civil Procedure to implement the Directive. Its description covers, among other matters, extending the concept of a product to software, rules relevant to AI, a broader group of potentially liable operators, evidence disclosure and presumptions intended to reduce information asymmetry.

The project card scheduled adoption by the Council of Ministers for the fourth quarter of 2026. On the verification date this was a plan and draft, not a basis for presenting final Polish provisions as settled. Text, numbering and procedure may change during the legislative process.

Operational preparation can begin because organising versions, tests, updates and suppliers improves quality regardless of the final act. Legal assessment of a particular business model should follow verification of the enacted text.

06

WEBee recommendation: define the product, version and period of control

Start with a register of digital products, not a generic list of systems. For each product, identify the manufacturer, operators in the chain, users, intended purpose, environment, delivery model, components and related services. Record which elements the company can change after deployment.

Every release should have a unique identifier, date, change scope, supported configurations and support period. If SaaS changes without a customer-side installation, recording the live version and deployment history is particularly important.

• product owner and people approving the release;
• code, configuration, AI model and reference-data versions;
• libraries, APIs, external models and open-source components;
• related services required for safe operation;
• support, update and end-of-life conditions;
• a customer and user change-notification channel.

07

WEBee recommendation: build an evidence pack for every release

An evidence pack should allow someone outside the team to reconstruct what was expected to work, what was tested, which risks were known and who accepted the outcome. It does not have to create heavy bureaucracy: consistent links between requirements, changes, tests and decisions matter most.

For an AI function, record its purpose, data and model version, test scenarios, results, known limitations, human oversight and behaviour when quality boundaries are crossed. Merely stating that a model is an external service does not explain the quality of the complete product.

• functional, safety and privacy requirements;
• risk analysis and reasonably foreseeable misuse scenarios;
• test plan, results, defects, deviations and release decision;
• component, dependency and material supplier-change list;
• instructions, warnings, limitations and user information;
• deployment, monitoring, rollback and version-recovery plan.

08

WEBee recommendation: connect vulnerabilities, updates and communication

Create one intake route for vulnerabilities, defects and incidents. Each report should receive an owner, impact assessment, decision, deadline and release link. Record issued fixes and reasoned decisions not to issue one.

Define how the company tells customers about a security update, required action and the consequence of not installing it. For SaaS, record deployment time, affected users, post-change monitoring and safe rollback. For on-premises software, also control whether and how the customer can obtain the fix.

09

WEBee recommendation: control suppliers, open source and AI models

For critical components, retain source, version, licence, support conditions, change history and supplier contact details. Contracts should help the business obtain information needed for defect, patch and incident analysis, but they do not replace integration tests performed by the finished-product manufacturer.

Changing an AI model, library, API or parameter can alter the behaviour of the whole application. Introduce change assessment, regression testing, approval and rollback. Do not assume that an open-source component or external service automatically transfers responsibility away from the company.

10

A 60-day preparation plan

In the first two weeks, create the product register and appoint owners. In weeks 3–4, choose one high-impact product and reconstruct the evidence pack for its latest release. In weeks 5–6, organise updates, vulnerabilities and suppliers. Use the final two weeks for a rehearsal: from receiving a defect report through preserving records to a decision and communication.

WEBee can help map the product lifecycle, structure version and dependency records, design approval, testing and update workflows and connect data from repositories, ticketing and monitoring systems. The purpose is an efficient, measurable quality process — not automated legal advice.

• appoint a process owner and backup;
• define the minimum evidence pack and retention;
• test restoration of the version from a specific date;
• verify component sources and support terms;
• rehearse defect handling and evidence preservation;
• schedule a reassessment after the Polish act is enacted.