Who is liable when artificial intelligence makes a mistake in the Netherlands?

When an AI system makes a mistake in the Netherlands, liability is decided by the ordinary rules of Dutch civil law: usually the party that supplied or used the system under a contract, or the organisation that deployed it without enough care. The main exception is the producer of a defective product, who can be liable without fault. Below you will find the legal bases that apply, how contracts shift the risk, what the AI Act and the new product liability rules add, and how to handle the problem of proof.

There is no separate AI liability statute. Responsibility follows from the contract between the parties, liability for an attributable failure to perform under Article 6:74 of the Dutch Civil Code (BW), tort under Article 6:162 BW, liability for auxiliaries and for unsuitable objects used in performance, and the product liability rules in Articles 6:185 to 6:193 BW. The EU AI Act imposes public-law duties and fines on providers and deployers, but it does not itself give a victim a claim for compensation.

That is the practical starting point. It explains why most disputes about AI liability in the Netherlands turn on the contract and on the duty of care, not on anything specific to the technology.

Which Dutch legal bases apply to AI damage?

General rules of the Civil Code, written for other situations, which courts now apply to AI. Which one fits your case decides who you can hold liable, what you must prove and how much you can recover.

There is no Dutch AI liability act, and there is no European one either. These are the routes that exist.

• Attributable failure to perform a contract (Article 6:74 BW). The usual route where the parties have an agreement. The supplier promised a system with certain properties and it did not deliver them, or the deployer used it outside the agreed limits.
• Liability for auxiliaries (Article 6:76 BW). A party that uses another person to perform an obligation is liable for that person as for itself. This matters where an AI vendor subcontracts model development or hosting.
• Liability for unsuitable objects used in performance (Article 6:77 BW). If an object used to perform an obligation is unsuitable, the resulting failure is attributed to the debtor, unless that would be unreasonable in the circumstances. Under this provision a hospital or an accountancy firm can be liable for a defective tool it used. The exception is narrower than defendants tend to assume.
• Tort (Article 6:162 BW). The route for anyone outside the contract, such as a patient, a rejected job applicant or a road user. The claimant must show an unlawful act, attributability, damage, causation and relativity (the rule breached must protect against this kind of damage).
• Liability for employees and non-subordinate contractors (Articles 6:170 and 6:171 BW). An organisation answers for the mistakes of the people who work for it. That includes an employee who relied uncritically on a machine output.
• Product liability (Articles 6:185 to 6:193 BW). Strict liability of the producer for a defective product, without proof of fault. Whether pure software counts as a product under the current text is contested. The revised European directive settles that point.

What does the GDPR add?

An AI system that processes personal data must comply with the GDPR (AVG). That gives the person affected an additional claim.

Article 22 GDPR restricts decisions based solely on automated processing that have legal effects or similarly significant effects on a person. Article 82 GDPR gives a separate right to compensation for material and non-material damage caused by an infringement. In practice a claimant with a data protection angle will often plead it alongside the tort claim. The controller then has to show that it complied, which strengthens the claimant’s position.

Why should you start with the contract?

Because between businesses, the answer to who is liable for an AI error is usually written in the agreement long before anything goes wrong. Dutch law gives parties broad freedom to allocate that risk.

AI suppliers use that freedom. Their standard terms typically describe the output as indicative and disclaim fitness for a particular purpose. They cap liability at the fees paid over a limited period and exclude consequential loss entirely.

Do limitation clauses hold up?

More often than clients expect, but not always. A court can set a clause aside where relying on it would be unacceptable by standards of reasonableness and fairness.

That test is in Article 6:248 BW. Dutch courts apply it most readily where the damage was caused by intent or deliberate recklessness on the part of the supplier or its management. In general terms and conditions, a clause can also be voidable as unreasonably onerous under Article 6:233 BW. Consumers have extra protection from the statutory lists in Articles 6:236 and 6:237 BW.

Which contract clauses really decide AI disputes?

The practical clauses, more than the liability cap. They set out who promised what and who had to check the output.

What did the supplier warrant about accuracy, training data and bias testing? Who must validate the output before anyone acts on it? Which party owns the logs, and how long are they kept? Must the supplier report a decline in model performance? Does the supplier commit to keeping the system compliant with the AI Act, and who pays if it does not? A negotiated AI contract that answers those questions is worth more than any clause about the amount of damages.

Where the deployer is a professional firm acting for clients, there is a second layer. A firm that uses an AI tool in its own services remains liable to its client for the result. Under Article 6:77 BW, the unsuitability of the tool is in principle attributed to the firm, not to the client. Whether the firm can pass that risk on to its supplier depends entirely on the supply contract. That is why the two sets of terms should be read side by side.

What duty of care does an organisation that deploys AI have?

It must act as a reasonably careful deployer would. Outside a contract, liability turns on that question.

Dutch courts assess this the way they assess any duty of care. How likely was the harm? How serious would it be? How burdensome were the precautions? What did the state of the art allow? Applied to AI, a recognisable standard has emerged in practice.

• Fitness for the actual use. A system validated for one population, dataset or country is not automatically fit for another. Using it outside the conditions in which it was tested is a classic breach of the duty of care.
• Meaningful human oversight. The person reviewing the output needs the information, the time and the authority to depart from it. Oversight that exists only on paper, where a reviewer approves hundreds of outputs an hour, offers no protection.
• Monitoring after go-live. Model performance drifts as the world changes. An organisation that never measures accuracy after launch cannot show that it was careful.
• Transparency towards the person affected. Telling people that AI was used, and how, is an AI Act obligation in defined cases. It is also a factor when a court decides whether conduct was unlawful.
• Documentation. Logs, version records, test results and the reasons for accepting or overriding an output. Without them, the organisation cannot rebut a claim, whatever actually happened.

The reverse is also true. An organisation that overrides a correct AI output, or ignores a warning the system gave, is exposed under the same duty of care. The question is never whether AI was used. It is whether the decision-making around it was sound.

How does product liability apply to AI, now and from December 2026?

Today the producer of a defective product is strictly liable under Articles 6:185 to 6:193 BW, but it is unclear whether stand-alone software is a product. The revised EU directive makes software, including AI, expressly a product for products placed on the market after 9 December 2026.

What are the current rules?

The producer is liable for death, personal injury and damage to property for private use, without the injured party having to prove fault. A product is defective if it does not offer the safety a person may expect.

That expectation takes into account the product’s presentation, its reasonably expected use and the moment it was put into circulation. The injured party must prove the defect, the damage and the causal link. Under Article 6:191 BW, the claim is time-barred three years after the injured party knew, or should have known, of the damage, the defect and the producer. It lapses in any event ten years after the product was put into circulation.

For AI, the weakness of this regime is structural. It was written for tangible goods. It is unclear whether stand-alone software counts as a product. And a system that changes its behaviour after it was put into circulation fits awkwardly with a defect that is assessed at the moment of circulation.

What changes under the new Product Liability Directive?

Directive (EU) 2024/2853 of 23 October 2024 replaces the 1985 directive and answers most of these objections. Software, including AI systems, is expressly a product.

More parties can be liable. Besides the manufacturer, the directive covers importers, authorised representatives, fulfilment service providers and, in defined cases, a party that substantially modifies a product already on the market. When assessing a defect, a court may take into account the effects of learning after deployment and the ability to supply updates. The minimum threshold for property damage disappears. Recoverable damage expressly includes the destruction or corruption of data and medically recognised psychological harm.

Crucially for AI, a court may order a defendant to disclose evidence it holds. Rebuttable presumptions of defectiveness and of causation apply where technical or scientific complexity makes proof excessively difficult for the claimant.

When do the new rules take effect in the Netherlands?

Member States must transpose the directive by 9 December 2026, and it applies to products placed on the market after that date. The Dutch implementing bill has not yet been adopted.

The bill (Implementatiewet richtlijn herziening productaansprakelijkheid, bill 36906) amends Books 6 and 7 of the Civil Code. It was submitted to the House of Representatives (Tweede Kamer) on 2 March 2026. The date of entry into force will be set by royal decree. Until then, the current Articles 6:185 to 6:193 BW continue to apply. Products already on the market when the new rules take effect stay under the old regime. For several years the two systems will therefore run side by side, and the date a system was placed on the market will decide which one applies.

What does the AI Act do, and what does it not do?

The AI Act sets product safety and supervision rules and is enforced with administrative fines. It does not create a right to compensation: a victim who wants damages still has to claim under the Civil Code.

The AI Act, Regulation (EU) 2024/1689, classifies systems by risk and prohibits a small number of practices outright. It imposes obligations on providers of high-risk AI systems on design, documentation, data governance, human oversight, accuracy and monitoring after the system is on the market. It adds lighter transparency duties for systems that interact with people or generate synthetic content, and separate rules for general-purpose AI models. Supervisory authorities enforce it.

Why does the AI Act still matter for civil liability?

Because it supplies the written standard against which a court can measure the duty of care. Breaching it points towards liability; complying with it provides your defence.

An organisation that ignored a documentation, oversight or monitoring obligation has, on the face of it, fallen below the standard a careful deployer meets. Compliance evidence works the other way with equal force. The technical file, the risk management records and the logs are exactly what a defendant needs when a claim arrives.

Which AI Act dates apply now?

The timetable changed in 2026. Many compliance plans were built on the original dates, so it is worth stating them precisely.

The regulation entered into force on 1 August 2024. The prohibited practices and the AI literacy duty have applied since 2 February 2025. The rules on general-purpose AI models, governance and penalties have applied since 2 August 2025. The bulk of the regulation, including the transparency duties, became applicable on 2 August 2026.

The Council gave its final approval to a simplification package (the “digital omnibus”) on 29 June 2026, and it entered into force in July 2026. It defers the obligations for stand-alone high-risk systems listed in Annex III to 2 December 2027. High-risk systems embedded in products already covered by EU product legislation follow on 2 August 2028. The deadline for national regulatory sandboxes moved to 2 August 2027. Systems already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking duty for AI-generated content. The package also softened the AI literacy duty and added new prohibitions on AI systems that generate child sexual abuse material or non-consensual intimate imagery.

Deferral is not repeal. The prohibitions, the transparency duties and the rules for general-purpose models apply now. The deferred high-risk obligations describe conduct that a court can already treat as the applicable standard of care. Organisations that pause their programmes until 2027 may find that civil law catches up with them first.

Who will supervise the AI Act in the Netherlands?

That is being arranged in a separate Dutch implementing act, which is not yet in force. Because the AI Act is a regulation, it applies directly regardless.

On 20 April 2026 the government put the draft Implementation Act for the AI Regulation (Uitvoeringswet AI-verordening) out for public consultation. The draft gives the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) and the Dutch Authority for Digital Infrastructure (Rijksinspectie Digitale Infrastructuur) a central role. Existing sector supervisors keep oversight in their own fields. What is still missing is the national enforcement and sanctions framework.

How do you prove that an AI system caused the damage?

That is the hardest part of an AI liability claim, much more than the legal basis. You must show that this system, and not the person who used it or some other cause, produced the damage.

Imagine a model that is opaque, that has been retrained since the incident, and whose logs were kept for thirty days. For a claimant, that is an evidential wall.

What happened to the AI Liability Directive?

It was withdrawn. The European answer was going to be a presumption of causation, but that proposal never reached agreement.

The Commission proposal for an AI Liability Directive, presented in September 2022, would have introduced a presumption of causation and a right to order disclosure of evidence about high-risk systems. The Commission formally withdrew it, and the withdrawal was published in the Official Journal on 6 October 2025. Nothing has replaced it.

Which Dutch procedural tools can you use?

A request for inspection of data, and an expert examination ordered by the court. Together with the presumptions in the revised Product Liability Directive, these are the tools that remain.

Since 1 January 2025, the right to inspect data held by another party is in Articles 194 to 195a of the Dutch Code of Civil Procedure (Rv). These provisions replaced the old Article 843a Rv. The threshold is lower than before: you must make plausible that you have an interest in inspecting certain data. You can also ask the court to appoint an expert or to order a preliminary expert examination (voorlopig deskundigenbericht).

In practice, an early and precise request for logs, model versions, validation reports and incident records does more for a claim than any argument about the burden of proof. On the defence side, the same point cuts the other way. An organisation that cannot produce those records will find the court drawing conclusions from their absence.

Retention policy is therefore a liability question, not only an IT question. Where the AI Act applies, providers and deployers of high-risk systems must keep automatically generated logs for a defined minimum period. Where it does not, the limitation periods for the underlying claim are the better guide. Thirty days is not enough.

How does this work out in the sectors where it matters most?

The same rules apply everywhere, but each sector has its own additional layer. Here are the five where we see the most questions.

Healthcare. A diagnostic support system does not take responsibility away from the doctor. The treatment relationship stays with the care provider under the medical treatment agreement in Articles 7:446 and following BW. The standard is that of a reasonably competent professional. Where the tool itself is unsuitable, Article 6:77 BW attributes that to the care provider unless attribution would be unreasonable, and courts apply that exception restrictively. Software that qualifies as a medical device has its own obligations under the Medical Devices Regulation, on top of the AI Act.

Recruitment and HR. A system that selects or filters candidates is high-risk under the AI Act. It is also squarely within the reach of equal treatment legislation. Indirect discrimination through a proxy variable is unlawful even if nobody intended it. We develop that point in our article on liability for algorithmic bias. It is the employer, not the vendor, that faces the candidate. Article 22 GDPR limits purely automated rejection, and the works council (ondernemingsraad) has a say in introducing systems that monitor or assess staff.

Road traffic. Dutch law already has a strict liability rule that applies whatever the level of automation. Under Article 185 of the Road Traffic Act 1994 (Wegenverkeerswet 1994), the owner or keeper of a motor vehicle is liable for damage to unprotected road users, such as pedestrians and cyclists, in a collision on a public road, unless there was force majeure. Case law sets that defence very high. The driver may also be liable in tort, and the manufacturer under product liability if the system was defective. Automation shifts the balance between those routes. It does not remove the first one.

Financial services. An institution that uses models for credit scoring, transaction monitoring or advice remains subject to the duty of care in the Financial Supervision Act (Wet op het financieel toezicht) and to supervision by the regulators. Failures in model governance are treated as governance failures of the institution, not of the vendor.

Content and communications. Generative systems create a different kind of exposure: infringement of intellectual property rights, defamatory or misleading output, and publication of personal data. Liability here follows the ordinary rules for the party that publishes. The fact that a machine wrote the text is not a defence. Our article on liability for AI-generated content sets out that position in detail.

Where an AI error causes bodily harm, for example in healthcare or on the road, the claim for that injury is a personal injury claim. Law & More does not handle personal injury claims; we refer that part to a specialist personal injury lawyer. We do advise on the contracts, the duty of care and the AI Act compliance around it.

How can you reduce your exposure before something goes wrong?

By putting the right documents and arrangements in place now. Most of what protects an organisation consists of records that cannot credibly be created after an incident.

• Map where AI is actually used. Most organisations underestimate this, because AI tools arrive embedded in software the business already licenses. Classify each use under the AI Act and record your reasoning.
• Rewrite the contracts. Deal explicitly with accuracy warranties, the origin of training data, bias testing, update obligations, AI Act compliance, ownership and retention of logs, audit rights and incident reporting. Also check how the supplier’s liability cap relates to your own exposure towards clients.
• Make human oversight real. Give reviewers the information, the time and the mandate to disagree, and record it when they do.
• Log deliberately. Decide what is kept, for how long and by whom. Align that with the limitation periods, not with storage costs.
• Test for bias and drift on a schedule. Keep the results, even when they are unflattering. A documented problem that was fixed is a far better position than an undocumented one that was not.
• Check your insurance. Professional indemnity and general liability policies were not written with autonomous systems in mind. Ask your insurer in writing whether a claim arising from an AI-supported decision is covered, and keep the answer.

In summary

• There is no separate AI liability law: the contract, the duty of care (Article 6:162 BW), Articles 6:76 and 6:77 BW and product liability decide who pays.
• Between businesses, the contract allocates most of the risk; limitation clauses usually hold, but not in cases of intent or deliberate recklessness.
• Directive (EU) 2024/2853 makes software expressly a product for products placed on the market after 9 December 2026; the Dutch implementing bill is still pending.
• The AI Act gives no right to compensation, but sets the standard of care; the Annex III high-risk obligations now apply from 2 December 2027.
• Proof is the real battleground: logs, version records and test results decide most cases.

Frequently asked questions about AI liability

How can we help with AI liability?

The legal position on AI liability is more settled than the public debate suggests. There is no gap in Dutch law. The contract, the duty of care, the rules on auxiliaries and unsuitable objects, and product liability already cover the field. The revised Product Liability Directive settles the remaining questions about software for products placed on the market after 9 December 2026. What changes is not whether you can be held liable, but how easily a claimant can prove it, and how much of your own documentation will be read back to you.

Law & More advises suppliers and users of AI systems on exactly those points. Our IT law team reviews and negotiates AI and software contracts, assesses where a deployment sits under the AI Act and what that means for your duty of care, helps set up governance and logging that will stand up in proceedings, and acts for and against parties in disputes about damage caused by automated decisions. Unsure where you stand? Tell us about your situation. We will let you know your options within one working day.