AI liability in the Netherlands is not governed by a separate statute. When an AI system causes damage, responsibility is allocated by the ordinary rules of Dutch civil law: the contract between the parties, liability for an attributable breach under Article 6:74 of the Civil Code, tort under Article 6:162, liability for auxiliaries and for unsuitable objects used in performance, and the product liability regime in Articles 6:185 to 6:193. 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, and it explains why most disputes about AI liability in the Netherlands are decided on the contract and on the duty of care rather than on anything specific to the technology. This guide sets out which party is exposed in which situation, what changes when the revised Product Liability Directive is implemented, what the AI Act does and does not add after the deferral agreed in 2026, and how a Dutch court deals with the evidential problem that a self-learning system creates.
The Dutch legal bases that actually apply
There is no Dutch AI liability act and there is no European one either. What exists is a set of general rules that were written for other situations and that courts now apply to AI. Knowing which of them fits your case determines who you can sue, what you have to prove and how much you can recover.
- Attributable breach of contract (Article 6:74 of the Civil Code). 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 parameters.
- Liability for auxiliaries (Article 6:76). A party who 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). If an object used to perform an obligation is unsuitable for the purpose, the resulting failure is attributed to the debtor, unless attribution would be unreasonable in the circumstances. This is the provision under which a hospital or an accountancy firm can be held liable for a defective tool it deployed, and the exception is narrower than defendants tend to assume.
- Tort (Article 6:162). The route for anyone outside the contract: the injured patient, the rejected job applicant, the road user. The claimant must show an unlawful act, attributability, damage, causation and relativity.
- Liability for employees and non-subordinate contractors (Articles 6:170 and 6:171). An organisation answers for the mistakes of the people who work for it, including where an employee relied uncritically on a machine output.
- Product liability (Articles 6:185 to 6:193). Strict liability of the producer for a defective product, without proof of fault. Whether pure software qualifies as a product under the current text is contested, which is precisely what the revised European directive resolves.
In addition, an AI system that processes personal data is subject to the GDPR. Article 22 restricts decisions based solely on automated processing that produce legal effects or similarly significantly affect a person, and Article 82 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, because the controller then carries a demonstrable accountability burden.
Start with the contract, because that is where the risk is allocated
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 leaves parties broad freedom to allocate that risk, and AI suppliers use it: standard terms typically describe the output as indicative, disclaim fitness for a particular purpose, cap liability at the fees paid over a limited period, and exclude consequential loss entirely.
Those clauses hold up more often than clients expect, but not always. An exclusion clause can be set aside where reliance on it would be unacceptable by standards of reasonableness and fairness under Article 6:248 of the Civil Code, and Dutch courts apply that test most readily where the damage was caused by deliberate recklessness or by an act equivalent to it on the part of the supplier or its management. In relationships governed by general terms and conditions, a clause can also be voidable as unreasonably onerous under Article 6:233, and consumers enjoy the additional protection of the statutory lists in Articles 6:236 and 6:237.
The clauses that decide real cases are more mundane than the liability cap. What did the supplier warrant about accuracy, training data and bias testing? Who is responsible for validating the output before it is acted on? Which party owns the logs, and for how long are they kept? Is there a duty to notify degradation in model performance? Does the supplier commit to keeping the system compliant with the AI Act, and who bears the cost 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 acting for clients, there is a second layer. A firm that uses an AI tool in its own service delivery remains liable to its client for the result, and Article 6:77 of the Civil Code means the unsuitability of the tool is in principle attributed to the firm rather than to the client. Passing that risk back up the chain to the supplier depends entirely on the supply contract, which is why the two sets of terms should be read against each other.
The duty of care of an organisation that deploys AI
Outside the contract, liability turns on whether the organisation acted as a reasonably careful deployer. Dutch courts assess that in the way they assess any duty of care: how likely was the harm, how serious would it be, how burdensome were the precautions, and 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 jurisdiction is not automatically fit for another. Deploying 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 must have the information, the time and the authority to depart from it. Oversight that exists only on paper, where the reviewer approves hundreds of outputs an hour, offers no protection at all.
- Monitoring after deployment. Model performance drifts as the world changes. An organisation that never measures accuracy after go-live cannot show it was careful.
- Transparency towards the person affected. Telling people that AI was used, and how, is both an AI Act obligation in defined cases and a factor in whether a court finds the conduct unlawful.
- Documentation. Logs, version records, test results and the reasons for accepting or overriding an output. Without them the organisation cannot rebut the claim, whatever actually happened.
The mirror image also holds. An organisation that overrides a correct AI output, or that ignores a warning the system generated, is exposed on the same duty of care. The question is never whether AI was used, but whether the decision-making process around it was sound.
Product liability: the rules now and the rules from December 2026
Under the current Dutch regime in Articles 6:185 to 6:193 of the Civil Code, the producer of a defective product is liable for death, personal injury and damage to property intended for private use, without the injured party having to prove fault. A product is defective if it does not offer the safety a person is entitled to expect, taking into account its presentation, its reasonably expected use and the time it was put into circulation. The injured party must prove the defect, the damage and the causal link. Claims are subject to a three-year limitation period running from knowledge of the damage, the defect and the producer, and lapse in any event ten years after the product was put into circulation.
The weakness of that regime for AI 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 has been put into circulation sits awkwardly with a defect assessed at the moment of circulation.
Directive (EU) 2024/2853 on liability for defective products, adopted on 23 October 2024, replaces the 1985 directive and answers most of those objections. Software, including AI systems, is expressly a product. The circle of liable parties is widened beyond the manufacturer to importers, authorised representatives, fulfilment service providers and, in defined cases, a party that substantially modifies a product already on the market. Defectiveness may be assessed taking account of the effects of learning after deployment and of the ability to supply updates. The threshold for property damage disappears, and recoverable damage expressly includes the destruction or corruption of data and medically recognised psychological harm. Crucially for AI, a court may order disclosure of the evidence a defendant holds, and rebuttable presumptions of defectiveness and of causation apply where technical or scientific complexity makes proof excessively difficult for the claimant.
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, which amends Books 6 and 7 of the Civil Code, was submitted to the House of Representatives (Tweede Kamer) in March 2026 and has not yet been adopted; entry into force will be fixed by royal decree. Until then, the existing Articles 6:185 to 6:193 continue to govern, and products already on the market when the new rules take effect stay under the old regime. In other words, for several years the two systems will run in parallel and the date a system was placed on the market will decide which one applies to it.
What the AI Act does, and what it does not do
The AI Act, Regulation (EU) 2024/1689, is product safety and market surveillance legislation. It classifies systems by risk, prohibits a small number of practices outright, imposes design, documentation, data governance, human oversight, accuracy and post-market monitoring obligations on providers of high-risk AI systems, adds lighter transparency duties for systems that interact with people or generate synthetic content, and sets separate rules for general-purpose AI models. Breach is enforced by supervisory authorities through administrative fines. It does not create a right to compensation, and a victim who wants damages still has to bring a claim under the Civil Code.
That said, the AI Act matters a great deal to civil liability, because it supplies the written standard against which a court measures the duty of care. 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 the claim arrives.
The timetable changed in 2026 and is worth stating precisely, because compliance planning has been built on the original dates. The regulation entered into force on 1 August 2024. The prohibited practices and the AI literacy duty have applied since 2 February 2025, and the rules on general-purpose AI models, on governance and on penalties since 2 August 2025. The bulk of the regulation became applicable on 2 August 2026. Under the simplification package on which the Council gave its final approval on 29 June 2026, the obligations for stand-alone high-risk systems listed in Annex III are deferred to 2 December 2027, and those for high-risk systems embedded in products already subject to EU product legislation to 2 August 2028. The deadline for regulatory sandboxes moved to 2 August 2027, the grace period for the content transparency rules was shortened, and new prohibitions on AI-generated child sexual abuse material and non-consensual intimate imagery were added.
Deferral is not repeal. The prohibitions, the transparency duties and the general-purpose model rules apply now, and 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 will find that the civil law caught up with them first.
Supervision in the Netherlands is being organised through a separate implementing act. The proposal gives the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) and the Dutch Authority for Digital Infrastructure (Rijksinspectie Digitale Infrastructuur) a coordinating role, with a set of existing sectoral supervisors keeping oversight in their own fields. That act had not yet entered into force at the time of writing. Because the AI Act is a regulation, it applies directly regardless; what is still missing is the national enforcement and sanctioning framework.
The evidence problem, and how Dutch procedure handles it
The hardest part of an AI liability claim is almost never the legal basis. It is proving that this system, rather than the human who used it or an unrelated cause, produced the damage. A model that is opaque, that has been retrained since the incident and whose logs were kept for thirty days presents a claimant with an evidential wall.
The European answer was going to be a reversal of the burden of proof. 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. It never reached agreement and the Commission formally withdrew it, publishing the withdrawal in the Official Journal in October 2025. Nothing has replaced it, and no new proposal has been adopted.
What remains are national procedural tools and the presumptions in the revised Product Liability Directive. Dutch civil procedure already allows a party to demand inspection of specific documents held by another party under Article 843a of the Code of Civil Procedure, and to ask the court to appoint an expert or order a preliminary expert examination. In practice, an early and precisely formulated disclosure request for logs, model versions, validation reports and incident records does more for a claim than any argument about the burden of proof. From 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, and thirty days is not enough.
How this plays out in the sectors where it matters most
Healthcare. A diagnostic support system does not shift responsibility away from the clinician. The treatment relationship remains with the care provider under the medical treatment agreement in Articles 7:446 and following of the Civil Code, and the standard is that of a reasonably competent professional. Where the tool itself is unsuitable, Article 6:77 attributes that to the care provider unless attribution would be unreasonable, and the case law on defective medical devices shows that the exception is applied restrictively. Software qualifying as a medical device carries its own obligations under the Medical Devices Regulation on top of the AI Act.
Recruitment and HR. A selection system that filters candidates is high-risk under the AI Act and is squarely within the reach of equal treatment legislation. Indirect discrimination through a proxy variable is unlawful even where no one intended it, a point developed further in our article on liability for algorithmic bias, and the employer, not the vendor, faces the candidate. Article 22 of the GDPR limits purely automated rejection, and the works council has a say in the introduction of systems used to monitor or assess staff.
Road traffic. Dutch law already contains a strict liability rule that operates whatever the level of automation. Under Article 185 of the Road Traffic Act 1994 (Wegenverkeerswet 1994), the owner or holder of a motor vehicle is liable for damage caused to unprotected road users in a collision on a public road unless there was force majeure, and case law sets that defence very high. Alongside it, the driver may be liable in tort and the manufacturer under the product liability rules where 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. Model governance failures are treated as governance failures of the institution, not of the vendor.
Content and communications. Generative systems create exposure of a different kind: infringement of intellectual property rights, defamatory or misleading output, and the publication of personal data. Liability here follows the ordinary rules for the party that publishes, and the fact that a machine produced the text is not a defence; our article on liability for AI-generated content sets out that position in detail.
Reducing your exposure before something goes wrong
Most of what protects an organisation has to be in place before the incident, because it consists of documents that cannot credibly be created afterwards.
- Map where AI is actually used. Most organisations underestimate this, because tools arrive embedded in software the business already licenses. Classify each use under the AI Act and record the reasoning.
- Rewrite the contracts. Deal explicitly with accuracy warranties, training data provenance, bias testing, update obligations, AI Act compliance, log ownership and retention, audit rights, notification of incidents and the interaction between the supplier cap and your own exposure to clients.
- Design the human oversight so it is real. Give the reviewer the information, the time and the mandate to disagree, and record when they do.
- Log deliberately. Decide what is kept, for how long and by whom, and align that with the limitation periods rather than with storage cost.
- Test for bias and drift on a schedule, and keep the results even when they are unflattering. A documented problem that was addressed is a far better position than an undocumented one that was not.
- Check the insurance. Professional indemnity and general liability policies were not written with autonomous systems in mind. Ask the insurer in writing whether a claim arising from an AI-supported decision is covered, and keep the answer.
Frequently asked questions about AI liability
Who is liable if self-driving cars cause an accident?
Dutch law starts with Article 185 of the Road Traffic Act 1994, which makes the owner or holder of the motor vehicle liable towards unprotected road users unless there was force majeure. Alongside that, the driver can be liable in tort and the manufacturer under the product liability rules if the system was defective. The level of automation shifts the balance between those routes rather than removing the first one.
Do different rules apply to medical AI than to commercial AI?
Yes, medical AI is subject to specific regulations such as the MDR (Medical Device Regulation) and has stricter safety requirements. The AI Act also categorises medical AI as “high risk”, which entails additional obligations for transparency and documentation.
What does the EU AI Act mean for liability?
The AI Act introduces new duty of care obligations for high-risk AI systems. Violation of these obligations may lead to increased liability. It also increases transparency requirements, which may facilitate the presentation of evidence in the event of damage.
How do I prove that AI software is defective?
You must demonstrate that the AI system does not meet reasonable safety expectations. This often requires technical expertise and documentation of training data, algorithms and test results. The AI Liability Directive that would have reversed the burden of proof was withdrawn by the European Commission and the withdrawal was published in October 2025; the revised Product Liability Directive instead allows a court to order disclosure of evidence and provides rebuttable presumptions where technical complexity makes proof excessively difficult.
Advice on AI liability from Law and More
The legal position on AI liability is more settled than the debate suggests. There is no gap in Dutch law: the contract, the duty of care, the rules on auxiliaries and unsuitable objects, and the product liability regime already cover the field, and the revised Product Liability Directive closes the remaining questions about software from 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 and More advises suppliers and users of AI systems on exactly those points. We review and negotiate AI and software contracts, assess where a deployment sits under the AI Act and what that means for your duty of care, set up governance and logging that will stand up in proceedings, and act for and against parties in disputes about damage caused by automated decisions. If you are introducing an AI system, or facing a claim about one, contact our IT law team and we will go through the exposure with you.
