EU regulation updates on IT and AI: what this means for business
Barbashyn Law Team
Serhiу Barbashyn — Attorney-at-Law, Managing Partner at Barbashyn Law Firm | Andriу Barbashyn — Acting Head of the IT Law Department at Barbashyn Law Firm, USF Expert
18 August, 2026
7 minutes read
18 August, 2026
7 minutes read
Content of the article
From December 9, 2026, a company whose software or AI product causes harm to a user in the EU may find itself facing court without the need to prove fault, because Directive (EU) 2024/2853 explicitly recognizes software and AI as a “product” under strict liability for the first time. Separately, the AI Act contains deadlines as early as this August. This material does not summarize the directives; it analyzes what specific liability arises and what steps are needed right now.
Revised Product Liability Directive: what and when
The old Directive 85/374/EEC (40 years old) was not written for software. The new Directive (EU) 2024/2853 directly closes this gap.
What changes from a business perspective
2.1. Software and AI = “Product”
Key shift: PLD 2024 explicitly includes software in the definition of a “product” whether embedded, standalone, or as a service (SaaS/cloud), regardless of the delivery method. Integrated digital services (e.g., health monitoring working with a sensor), AI systems, and digital manufacturing files are also covered.
What this means practically: The strict (no-fault) liability regime that previously applied to physical products now extends to any IT or AI product you release on the EU market. There is no need to prove the manufacturer’s intent or negligence—it is enough to prove the defect and the damage.
2.2. Who is liable if the manufacturer is outside the EU
For products manufactured outside the EU, liability is distributed in a cascade: first the importer, then the authorized representative, and if none exist, the fulfillment provider. Separately, the component manufacturer and, under certain conditions, online platform operators.
Practical consequence for Ukrainian IT companies supplying products to the EU: if you do not have an official importer or authorized representative in the EU, a fulfillment provider or even a marketplace may turn out to be the defendant. And then recourse a claim against you.
2.3. What is considered a defect – including cybersecurity
The test is objective: “the safety that the public at large is entitled to expect,” taking into account the product presentation, technical characteristics, reasonably foreseeable use, and safety requirements.
Two new specific sources of defects critical for IT/AI:
Cybersecurity vulnerabilities – if a product has a known and unpatched vulnerability, this may constitute a defect.
Missing updates – if the manufacturer was supposed to provide safety updates but failed to do so, this is also a defect. The update policy becomes a legally significant document.
Autonomous and adaptive behavior of AI – PLD covers damage from post-sale changes via machine learning or OTA updates. If your model learned something harmful after release, liability does not disappear.
2.4. Presumptions – the main shift for plaintiffs
The strict (no-fault) regime remains, but proving damage has become easier. Three automatic presumptions:
Defectiveness is presumed if the defendant fails to disclose “necessary and proportionate” evidence; if the product fails to meet mandatory EU safety requirements; or if an “obvious malfunction” occurred during normal use.
Causal link is presumed if the damage is “typically consistent” with the defect.
In technically complex cases (AI, medical devices), the court presumes defectiveness and/or causality if the plaintiff showed this as “probable,” but proving it is “excessively difficult” due to the technical or scientific complexity of the product.
The last point is especially important for AI: model complexity no longer protects against a claim—it can work against you.
2.5. Disclosure of evidence
New mechanism: a plaintiff with a plausible claim can request judicial disclosure of evidence from the defendant. For continental Europe, this is effectively an element of discovery—an institution that traditionally did not exist there.
Consequence: internal technical documentation, risk assessment reports, incident logs, and correspondence regarding known vulnerabilities—all of this can be requested by the court. If documents are disorganized or contradictory, this will strengthen the plaintiff’s position, not the defendant’s.
2.6. What damage is compensated
Death or physical injury to a natural person—including medically confirmed bodily injuries.
Destruction or damage to property (excluding the defective product itself and property for exclusively professional use).
Medically confirmed psychological harm.
Loss or corruption of data—except for data of exclusively professional use.
The 500 euro threshold for property damage and financial caps for personal injuries have been abolished. This means smaller claims have become economically viable, including as representative (class) actions.
2.7. Limitation periods
3 years from the moment the plaintiff became aware (or should have become aware) of the damage, defect, and defendant.
10 years from the moment the product was placed on the market—general period.
25 years—for personal injuries with latent health damage (replaced the previous 10-year period).
AI Act: what needs to be done now (a brief reminder)
A full breakdown of the AI Act is a separate topic. Here, only what is relevant right now and in the coming months, with an emphasis on transparency requirements that no one has postponed.
Regarding sanctions for violating Art. 50 (transparency): up to EUR 15 million or 3% of global annual turnover, whichever is higher..
Why PLD and AI Act are better addressed together
There is a direct legal dependency between the two acts that is easy to miss.
Non-compliance with AI Act requirements (in particular regarding transparency, documentation, human oversight) and the Cyber Resilience Act provides a presumption of defectiveness under the PLD. In other words, if your AI product violates the AI Act, it automatically strengthens the plaintiff’s position in a future product liability lawsuit.
The chain looks like this:
Therefore, compliance with the AI Act and CRA is not just a regulatory obligation. It is practical protection against product liability lawsuits under the PLD.Checklist: First Steps
Below is a minimum set of actions that reduce risk under both the PLD and the AI Act. Some of them are useful right now, regardless of deadlines.
A. Inventory
☐ Create a register of all software and AI components in the product – proprietary and third-party.
☐ Record who the supplier of each AI component is and what the obligations are along the supply chain.
☐ Determine which systems deployers have on the EU market (they fall under the AI Act regardless of the company’s place of registration).
B. Documentation
☐ Put technical documentation in order: specifications, risk assessments, safety tests.
☐ Establish an update and incident log – including known vulnerabilities and patch dates (needed both for disclosure of evidence under the PLD and for the AI Act).
☐ For high-risk AI systems – launch a self-declaration / AI systems registry with a description of the function, risk, and responsible person.
C. Transparency (deadline: 2 August 2026)
☐ Check all chatbots and AI assistants interacting with users in the EU: is there a notification about AI interaction?
☐ Check the labeling of emotion recognition and biometric categorization systems.
☐ For generative AI content (images, audio, video) – check which system was launched before 02.08.2026 (deadline 02.12.2026) and which after (deadline 02.08.2026).
D. Supplier Contracts
☐ Review contracts with AI component suppliers – is responsibility for defects clearly distributed?
☐ Ensure an authorized representative or importer in the EU is designated (if the product is placed on the EU market without the manufacturer’s direct presence).
☐ Check if the contract contains a supplier obligation regarding security patches – the absence of an update can now be a defect under the PLD.
E. Human Oversight and Data Minimization
☐ For each AI system, determine the human oversight mechanism: who can override or stop an AI decision?
☐ Check whether AI systems process only the data that is truly necessary (minimization is a requirement of GDPR, the AI Act, and reduces risk under the PLD).
Conclusion
The PLD shifts the question from “do you use AI” to “will you be able to prove that your product is not defective if it goes to court.” The AI Act adds: “and have you fulfilled the transparency requirements by August 2, 2026.”
From December 9, 2026, AI/software product documentation becomes court evidence, not just a compliance artifact. Whoever has it in order is protected. Whoever doesn’t may find themselves in a situation where the court itself presumes a defect.
The deadlines are specific, and some were even postponed, but no one has moved the August 2 transparency obligations. Therefore, the first steps are available and useful right now, without waiting for “everything to sort itself out.”
Share
We use cookies to improve the performance of the site and enhance your user experience.
More information can be found in our Privacy Notice