EU AI Act and the new Product Liability Directive: what changes

Does the EU AI Act change what the new Product Liability Directive asks of AI software?

If your team has been told that AI software now carries civil liability, the core change is this: Directive (EU) 2024/2853 treats software and AI systems as products, and it applies to products placed on the market or put into service from 9 December 2026. Under this regime, the evidence you keep for AI Act compliance becomes the main way to rebut a presumption of defect, because a product that does not meet mandatory safety requirements meant to protect against the damage at issue is presumed defective. The AI Act does not create civil damages itself, but it sets many of the safety requirements and record-keeping duties that a court will examine. How much exposure you carry depends on your role in the value chain, your update practices and whether your logs can show what the system did.

Your position in the value chain decides which duties attach. A manufacturer that develops an AI system and places it on the market carries the full exposure, and the AI Act provider obligations become the core evidence set. A company that integrates a third-party model or component into its own commercial product is treated as the manufacturer of the finished product, so it cannot shift the risk to the supplier simply by pointing at them. If that supplier is a micro or small enterprise, the directive allows you to contractually waive recourse against it under Article 12(2), so negotiate and record that term now. Open-source contributors fall outside the directive when they supply software outside a commercial activity under Article 2(2), but a company that builds that code into a paid product does not share that protection. Confirm with counsel how your role maps to these categories before you rely on any of them.

Where AI Act duties feed directly into civil liability

Under the new Product Liability Directive, a court can presume a product defective when it misses a mandatory safety requirement. Several AI Act duties therefore double as evidence in a civil claim, so the records and controls an organization builds for the Act also shape its exposure to damages claims.

Mandatory safety requirements as a presumption

Where a product does not meet mandatory product safety requirements in Union or national law that protect against the damage suffered, courts must presume it defective under Articles 7 and 10 of Directive (EU) 2024/2853. For AI systems, the AI Act's high-risk requirements are a likely source of such rules. Check which AI Act obligations your system must meet before placement, and keep dated evidence that each one was met, because a gap becomes the claimant's starting point.

Safety-relevant cybersecurity requirements

Safety-relevant cybersecurity requirements count when a court assesses whether a product is defective. Article 15 of the AI Act sets accuracy, robustness and cybersecurity expectations for high-risk systems, so weaknesses in access control, input handling or model protection can carry civil consequences. Ask your security team to map each cybersecurity control to the harm it prevents, and record the results of testing that supports the mapping.

Logging duty and missing log records

Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over their lifetime. Recital 111 of the Directive says a product that lacks the means to log information about its operation, where law requires logging, supports a presumption of defectiveness. Confirm that logging is built into the system, that logs capture the events needed to reconstruct a failure, and that retention matches your legal and contractual obligations.

Human oversight and deployer records

Article 19 requires providers to keep logs under their control, and Article 26 sets deployer duties, including human oversight, monitoring and keeping logs for a stated period. These records show how a system was used and who intervened when it produced a harmful output. Define who reviews alerts, how overrides are recorded, and where logs are stored, since a missing oversight record can be read as a missing safeguard.

Updates and continuous learning

A product stays in the manufacturer's control while it can receive software updates or upgrades, and the Directive treats a substantial modification through an update or continuous learning as placing a modified product on the market. Under Article 11, a manufacturer cannot blame a post-market defect if it stems from missing updates needed to keep the product safe. Maintain a versioned change record and a patch schedule that show each update was assessed.

Open-source components and recourse

Directive (EU) 2024/2853 does not cover free and open-source software supplied outside a commercial activity, but a manufacturer that integrates such software into a commercial product can be liable for it. Article 12(2) lets a manufacturer waive recourse against a micro or small enterprise supplier, which affects contract terms. Inventory every open-source component, record its license and maintainer, and confirm with counsel how each one is treated in supplier contracts.

Why updates, upgrades and continuous learning change the liability position

A product stays within the manufacturer's control for as long as it can receive software updates or upgrades. Under Directive (EU) 2024/2853, that continuing control means the manufacturer cannot treat a defect that appears after market placement as someone else's problem, and Article 11 closes the most common escape route. If the defect lies in a lack of software updates or upgrades needed to keep the product safe, including updates against cybersecurity vulnerabilities, the manufacturer cannot defend itself by pointing to the date of placement. For an AI system running in your environment, the practical question is whether you still ship and deploy the fixes the vendor or your own team has committed to, and whether you can show when each fix reached each deployed instance.

Recital 99 adds a second trigger. A substantial modification made through a software update or through an AI system's continuous learning counts as placing a modified product on the market. That matters because the modified product can be judged against the requirements in force at the time of the change, not only the requirements in force when the system was first sold. Whether a particular update is substantial is a legal judgment that depends on the facts, so confirm with counsel which categories of change your team will treat as substantial, how that threshold maps to the AI Act's own concept of substantial modification, and who signs off the decision before a model retraining or configuration change goes live.

The evidence that supports these positions is operational. Keep a patch and change record for every release that touches an AI system: the version identifier, the trigger (vulnerability, bug, retraining, configuration), the risk and safety assessment, the test results, the approver, and the deployment dates by environment. Pair it with the automatic event logs that Article 12(1) requires high-risk systems to technically allow over their lifetime, because a log that can show what the system was doing before and after a change is the best answer to a defect argument. Ask your counsel and your vendors to confirm in writing who holds each record and how long it is kept.

How the open-source carve-out applies to commercial AI products

Directive (EU) 2024/2853 does not apply to free and open-source software developed or supplied outside the course of a commercial activity (Article 2(2)). A developer who publishes code as a hobby or community project, with no sale, no paid support and no commercial benefit tied to the release, sits outside the directive's liability regime. The exclusion protects the software itself, not every later use of it. Once the same code is taken into a product that a business sells, the question moves to the manufacturer of that product.

Record the basis of the release: keep the license, the repository history and any statement that the project is community-maintained, so the claim that it was supplied outside commercial activity can be shown.
Note commercial touchpoints: paid support contracts, sponsorship tied to deliverables, or a company that funds development can weaken the argument, so list them.
Separate project roles: identify who maintains the code and whether maintainers are paid by an organization that sells products using it.
Track forks and derivatives: a fork that a company ships commercially is a different supply chain event, and it should be assessed on its own.
Publish a clear support statement: state what the project does and does not provide, so downstream users know which obligations stay with them.

Confirm with counsel where community work ends and commercial activity begins, because the boundary depends on the facts of each project and on how national law applies the directive.

How to prepare the evidence before December 2026

The sequence builds a single evidence file that shows which software and AI systems reach EU users, whether they can record their own operation, how safety and cybersecurity duties are met, and who answers for defects. Each step closes with a record that a lawyer, auditor or court could review.

Inventory every software and AI product used in the EU
Compile a register of each software product, firmware image, application and AI system that your organization builds, integrates, sells, or puts into service for users in the EU. Include products you modify, configure, or embed from third parties, since a commercial integration can bring open-source code within scope. The product owner and the engineering lead should sign off the list. The step is done when every entry names its version, its market or service date, and the team accountable for it.
Classify each AI system against the AI Act
For every AI system in the register, record its AI Act risk tier, including whether it is prohibited, high-risk under Annex I or Annex III, subject only to transparency duties, or outside the Act. Your legal or compliance lead should review each classification, and the reasoning should cite the articles relied on. The output is a classification memo per system, which determines which logging, safety and documentation duties apply in the next steps.
Confirm logging capability and retention for each system
For systems that may be high-risk, check with the engineering team whether the product can automatically record events over its lifetime, as Article 12(1) of the AI Act requires. Document what is logged, where logs are stored, who can read them, and how long they are kept. Logging also matters for the liability presumption tied to missing logs in recital 111 of the Product Liability Directive. The output is a logging specification and a test record showing that events are captured in a production-like environment.
Map mandatory safety and cybersecurity requirements
List the mandatory product safety requirements in Union and national law that apply to each product, and the safety-relevant cybersecurity requirements that affect defectiveness under Articles 7 and 10 of the Directive. Map each requirement to a control, test, or design decision in your system, and identify gaps. Confirm the list with counsel, since the applicable requirements depend on the product sector. The output is a requirements map with a named owner and evidence reference for each line.
Set update and vulnerability handling records
Document how each product receives security updates, upgrades and patches, who decides when a fix is released, and how vulnerabilities are reported, triaged and closed. Under Article 11 of the Directive, a manufacturer cannot rely on a defect arising after market placement if the cause is a missing update needed to maintain safety. Record the support period you commit to, the release history, and the notices given to users. Keep a dated log of each substantial modification, including changes from continuous learning, since recital 99 treats these as placing a modified product on the market. The output is an update policy and a vulnerability log.
Review supplier contracts for recourse terms
Review contracts with suppliers of software components, models and open-source packages you integrate. Identify where a micro or small enterprise supplied a component, because Article 12(2) of the Directive allows a manufacturer to contractually waive recourse against that supplier. Check warranties on security, logging, documentation, update commitments and cooperation during an investigation. Counsel should confirm each term. The output is a contract register showing recourse rights, waivers and update obligations for each supplier.
Record decisions and obtain legal review
Bring the register, classification memos, logging specification, requirements map, update log and contract register into one controlled repository. Ask legal counsel to review the file, record each decision with its date and approver, and note open risks with an owner. Confirm with your counsel which national transposition measures apply in each Member State where the products are sold. The step is complete when counsel has signed off the file and each open item has an assigned owner and review date.

Where organizations usually get the liability position wrong

The Product Liability Directive shifts the question from who signed the AI Act paperwork to whether the product was defective when it left the manufacturer's control. The pitfalls below share one root cause: liability follows the software as it actually runs, updates and learns, so the evidence has to follow it too.

Open-source components inside a product

Directive (EU) 2024/2853 excludes free and open-source software supplied outside a commercial activity, but that exclusion does not follow the code into a commercial product. A manufacturer that integrates an open-source component into a product it sells can be liable for it. Check each component's licence, who supplied it into your product, whether you ship it as part of a commercial offering, and whether you have a record of the version and patch level you relied on. Where a micro or small enterprise supplied a component, the Directive allows a contractual waiver of recourse under Article 12(2), so review those supplier terms before signing.

Logs missing from legacy systems

Article 12(1) of the AI Act requires high-risk AI systems to technically allow automatic recording of events over their lifetime, and recital 111 of the Directive links a missing logging capability to a presumption of defectiveness. Systems built before these rules often log only application errors, not inputs, outputs, model versions or operator actions. Inventory every event the system must record, confirm the logging is enabled by default in the deployed build, and test that logs survive upgrades and are retained where your obligations require. Treat a gap here as a design defect to fix, not a documentation item.

Untracked continuous learning changes

Recital 99 treats a substantial modification made through a software update or an AI system's continuous learning as placing a modified product on the market. A model that retrains on production data can therefore change its own risk profile without any release event that a change board would normally see. Define which changes count as substantial before deployment, record each retraining run with the data window, model version and evaluation results, and gate retraining on a documented check that safety behavior still holds. Without that trail, you cannot show what the product was when it left your control.

Unpatched cybersecurity vulnerabilities

Under Article 11 of the Directive, a manufacturer cannot argue that a defect arose after market placement where it lies in a lack of software updates needed to maintain safety, including protection against cybersecurity vulnerabilities. Safety-relevant cybersecurity requirements also count when courts assess defectiveness under Article 10. Self-hosted AI platforms often pull in frameworks, runtimes and container images that receive security fixes on their own schedule. Set a patch intake process for each dependency, a documented window for applying critical fixes, and a record of when each fix was deployed. Confirm the vendor's support period for every component you ship.

Treating AI Act dates as the liability clock

The AI Act's high-risk dates, as amended in 2026, set when obligations apply, but the Directive sets when liability can arise. Under Directive (EU) 2024/2853, the new regime applies to products placed on the market or put into service from 9 December 2026, and the 1985 Product Liability Directive still governs older products. A system that is compliant with the AI Act on a later date may still face claims about its pre-deadline behavior. Map each product's placement date, then review whether its conduct before and after that date is documented well enough to defend.

Who owns the liability controls and who prepares the evidence

Your organization owns its liability position. Directive (EU) 2024/2853 treats the manufacturer as the party answerable for a defective product, and it can apply to software and AI systems you place on the market or put into service after the transposition date. Decisions about whether a product is defective, what warnings to give, which risks you accept, and how contracts allocate exposure belong to your legal function and product leadership. Nobody else can make those decisions for you, and DeployOpen does not give legal advice on liability.

Product scope and classification: Decide which systems count as products placed on the market or put into service, and which fall under the AI Act high-risk route.
Liability allocation: Set indemnities, warranties and recourse terms with suppliers, including any waiver of recourse against small software makers under Article 12(2).
Update policy: Decide how long you will supply security updates and upgrades, since Article 11 ties a manufacturer's responsibility to that commitment.
Risk acceptance: Record who approves residual risk and on what basis.
Outside counsel: Engage lawyers for interpretation of national transposition laws.

Before you rely on any of these positions, confirm them with qualified counsel in each market where you sell.

Questions buyers ask about AI Act evidence and product liability

Does the new product liability directive apply to our open-source use?

Directive (EU) 2024/2853 does not apply to free and open-source software developed or supplied outside the course of a commercial activity. That carve-out protects the community project, not your company. If you integrate open-source software into a commercial product that you place on the market, you are the manufacturer of that product and can be liable for defects in the software it contains. Ask counsel to confirm whether each component you ship was developed and supplied outside commercial activity, and document where each component came from, which version you pinned, and who maintains your fork. Your engineering team can produce that inventory, but the legal reading of the carve-out belongs with your lawyers.

When does the new liability regime apply to products already on the market?

The directive applies to products placed on the market or put into service after 9 December 2026, the date by which Member States must transpose it. The 1985 Product Liability Directive is repealed from that date but still governs products placed on the market before it. For a product that spans the change, such as a platform release shipped before December 2026 and then substantially modified through a software update afterward, the placing-on-the-market analysis matters. Recital 99 treats a substantial modification through a software update or an AI system's continuous learning as placing a modified product on the market. Confirm the dating of each product version with counsel before you plan releases around it.

Does compliance with the AI Act itself create civil liability?

The AI Act sets public-law obligations enforced by market surveillance authorities, and it does not create a private right of compensation on its own. The liability question sits in the product liability directive, which lets courts treat non-compliance with mandatory safety requirements in Union or national law as a reason to presume a product is defective. Where the AI Act's high-risk rules are mandatory safety requirements meant to protect against the damage claimed, a missing or weak record can support that presumption. Whether a particular AI Act duty counts as a safety requirement for a given claim is a legal question for counsel and, if the claim is litigated, for the courts.

What logs should we keep for an AI system to support a defect defense?

Article 12(1) of the AI Act requires high-risk AI systems to technically allow automatic recording of events over the system's lifetime, and recital 111 of the directive links a product's lack of required logging to a presumption of defectiveness. Keep records that let you reconstruct what the system did and when. Typical categories include:

Model and software versions deployed, with change and approval records for each release
Input and output events relevant to the system's intended purpose, retained for the period your legal review sets
Human oversight actions, overrides and incident tickets
Update, retraining and continuous learning events, with the data sources and validation results
Security patches applied and the time between vulnerability disclosure and deployment

Your engineers can configure the logging pipeline. Counsel and your quality management function should set retention periods and privacy limits, because logs can also contain personal data.

Do we need an external audit to show compliance with these requirements?

Most Annex III high-risk systems use internal-control conformity assessment under Annex VI, so the law does not in every case require an external auditor. Notified bodies are involved for some biometric systems and Annex I products under Article 43. Even where internal control applies, an independent review can help you test whether your evidence would hold up in a dispute. Only an independent auditor, assessor or certification body issues reports or certificates. An implementation partner can prepare the logs, controls and documentation for that review, but cannot issue the opinion. Ask any assessor to confirm in writing which conformity route applies to your system.

What does preparation require from our internal team?

Preparation depends on your team owning decisions that no outside firm can make for you. Your product owner must define intended purpose and the foreseeable misuse you will guard against. Engineering must agree on logging, versioning and update processes. Security must confirm that safety-relevant cybersecurity requirements are met and that patches reach deployed systems in a documented time frame, because the directive does not let a manufacturer escape liability for a defect that lies in a lack of needed updates. Legal and compliance must own the classification and the reading of the carve-out. A fixed-scope implementation partner can build the technical controls and evidence, but your organization remains accountable for them.

Can a partner or vendor take over our product liability?

No. A partner that prepares systems and evidence does not take on your liability toward customers or the public, and no contract can make the question disappear. The directive places liability on the manufacturer and, for some products, on other economic operators, and it sets rules for recourse. Article 12(2) lets a manufacturer that integrates a component from a micro or small enterprise waive its recourse against that supplier by contract, which is a commercial term to negotiate with counsel. Use contracts to allocate responsibilities for the work, the evidence and the response times, and have counsel review how those terms interact with the directive.

How DeployOpen prepares systems and evidence for this work

DeployOpen works on the technical side of EU AI Act and product liability readiness: the self-hosted platforms, logs, update pipelines and evidence that a defect or conformity question would test. The organization keeps ownership of its controls and legal position, and independent auditors or notified bodies issue any reports or certificates.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which AI systems and embedded software products are in the work and which roles the client holds.
Scope also names the logging, update and cybersecurity evidence that the client needs to show for its products and systems.
A quote follows from the written scope, so the client sees exactly what each part of the work includes.

How we build

We implement and harden self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks.
We configure automatic event recording for AI systems so logs are kept over the system's lifetime, with retention set by the client.
We build update and patch pipelines that record each software change, so the client can show how a product was maintained after release.
We run security testing of applications, APIs, infrastructure and AI systems to find cybersecurity weaknesses before release.

How we hand over

We document configurations, data flows, logging design, update history and test results in a form the client's assessors can review.
We deliver an evidence map linking each product safety, logging and cybersecurity requirement to the artifact that shows it.
We walk the client's engineering, compliance and legal teams through the handover so they can operate and explain the controls.
The client owns all documentation and configurations, and we confirm the final deliverables against the written scope.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover patching, log review, periodic security testing and updates to evidence as the products and laws change.
Ask any provider which parts of the evidence they keep current, who approves changes, and how they record each update to a product.

EU AI Act and the new Product Liability Directive