Liability for AI systems in the Netherlands always lands on a person or a company, never on the software. Two positions matter in practice: the user, meaning the individual or organisation that deploys the system and takes decisions with it, and the producer, meaning the party that developed the system, put it on the market or supplied it. Which of the two carries the loss depends on where the failure sat, what each of them knew, and what the contract between them says. This article works through both positions; the criminal law framework itself, from functional perpetration to corporate liability under article 51 of the Criminal Code, is set out in our companion article on whether an algorithm can be partly responsible.
Why the system is never the defendant
Dutch law recognises two kinds of person: natural persons and legal persons. An AI system is neither. It cannot hold rights, cannot be summoned, cannot be fined and cannot be ordered to pay damages, because it owns nothing and has no legal existence separate from the company that runs it. Proposals to create a third category, sometimes called electronic personhood, have been discussed at European level and have gone nowhere, for a reason that is more practical than philosophical: a liability vehicle with no assets and no capacity to change its behaviour would shift risk away from the parties who can actually prevent harm.
So the question is never whether the machine is liable. It is which human or corporate actor in the chain failed in a duty, and that chain has a predictable shape: the party that built the model, the party that turned it into a product, the party that supplied or integrated it, the organisation that deployed it, and the individual who pressed the button. Liability for AI systems is the exercise of locating the failure in that chain and matching it to a legal basis.
Two of those legal bases dominate. For the user, general tort law and the duty of care that comes with using a powerful tool in someone else’s direction. For the producer, product liability, which does not require fault at all. Everything else, including criminal exposure, is layered on top of these.
The user’s position
Users underestimate their exposure because they think of the system as a black box that someone else built. In law, the person who chooses to deploy a tool, configures it, feeds it data and acts on its output is doing something, and that doing is assessed on its own merits.
When the system is simply the instrument of an offence
The easiest cases are the ones where an AI system is used deliberately. Generating a convincing invoice to defraud a company is fraud under article 326 of the Criminal Code whether the letter was drafted by a person or by a model, and forging a document remains forgery under article 225 regardless of the tool. Using a model to write code that breaks into a system is still computer intrusion under article 138ab. Generating and distributing manipulated images of a real person can amount to defamation, and where the material is sexual in nature it falls under the offences in the Sexual Offences Act that has applied since 1 July 2024. Persistent AI-assisted harassment of an individual can constitute stalking under article 285b, which is prosecuted only on complaint by the victim.
None of this is new law. The technology changes the scale and the plausibility of the deception, not the elements of the offence. What it does change is the evidence: prompts, account logs, model outputs and the timing of file creation are the material that ties the offence to a person, and users who assume that AI-generated content is untraceable are usually wrong.
Negligent use: the more common risk
Far more organisations get into trouble through carelessness than through intent. The pattern is familiar. A system is bought for one purpose and used for another. Its output is treated as a decision rather than as a signal. Nobody checks the cases where it is wrong, because the people operating it were never told what its error rate looks like or where it fails. When the harm materialises, the organisation discovers that it has no record of how the decision was reached.
In civil terms this is straightforward tort: article 6:162 of the Civil Code makes a person liable for an unlawful act attributable to them that causes damage. Breach of a duty of care in society is one of the categories of unlawfulness, and the content of that duty is set by what a careful operator in that position would have done. An employer is in addition liable for the faults of its employees under article 6:170, and a party that uses an auxiliary to perform a contractual obligation answers for that auxiliary under article 6:76, which is the provision that catches an organisation using a supplier’s model to deliver its own service.
The duty of care is no longer left entirely to the courts to invent. The EU AI Act gives deployers of high-risk systems concrete obligations: use the system in accordance with the instructions, assign human oversight to people with the competence and authority to exercise it, ensure that the input data under their control is relevant, monitor operation and suspend use where a risk emerges, keep the logs, and inform workers and their representatives before deploying such a system at work. Those obligations are regulatory, but a court assessing negligence will read them as a description of what careful conduct looks like. An organisation that ignored the instructions for use is not merely non-compliant; it has handed the claimant its case.
Automation bias deserves separate mention because it is where oversight quietly fails. A reviewer who approves nearly everything the system proposes is not exercising oversight, and an organisation that measures its staff on throughput has effectively designed that outcome. The legal question is whether a human decision was genuinely taken, and a rubber stamp does not qualify.
Where the user cannot pass the risk on
Three points regularly surprise organisations that assumed the supplier carried the risk.
First, towards the injured third party the user is the visible party. A customer refused credit, an employee rejected by a screening tool, a patient given the wrong triage: they contract with, or are dealt with by, the deployer, and they will sue the deployer. Whether the deployer can recover from its supplier is a separate question that turns on the contract and does not delay the claim against it.
Second, the general data protection rules apply independently of everything else. If the system processes personal data, the deployer is normally the controller, responsible for the legal basis, the transparency, the impact assessment and the security. A decision taken solely by automated means that produces legal effects or similarly significantly affects a person is separately regulated and gives that person a right to human intervention and to contest the outcome. Our overview of the General Data Protection Regulation sets out that regime.
Third, modification changes your role. A deployer that puts its own name on a system, changes its intended purpose, or substantially modifies it becomes a provider under the AI Act and inherits the provider’s obligations. Fine-tuning a general-purpose model into a screening tool for a regulated decision is exactly the kind of step that crosses that line. Organisations building on someone else’s model should establish which side of it they are on before they launch, not after an incident.
The producer’s position
The producer’s exposure runs along a different track, and it is stricter. Product liability under articles 6:185 and following of the Civil Code makes the producer liable for damage caused by a defect in its product without the injured party having to prove fault. A product is defective when it does not offer the safety a person is entitled to expect, taking into account its presentation, the use that can reasonably be expected of it and the time it was put into circulation. The claimant must prove the damage, the defect and the causal link between them, which in an AI case is where the real fight lies.
The regime has fixed limits. Claims must be brought within three years of the day the injured party became aware, or should have become aware, of the damage, the defect and the identity of the producer, and the right expires ten years after the specific product was put into circulation. Liability under this regime cannot be excluded or limited by contract, and it covers death, personal injury and damage to other property used privately, subject to a lower threshold. The producer has a limited set of defences, including the development risk defence, which applies where the state of scientific and technical knowledge at the time of circulation could not have revealed the defect.
The reform that changes the position for software
Under the current Dutch regime a product is a movable thing, and whether stand-alone software qualifies has been contested for years. That argument is now closing. The revised Product Liability Directive, Directive (EU) 2024/2853, entered into force on 8 December 2024 and must be transposed into national law by 9 December 2026; it applies to products placed on the market or put into service after that date, so the current provisions of the Civil Code continue to govern products circulated before it. Four changes matter for liability for AI systems.
Software, including AI systems and digital manufacturing files, is expressly a product. The circle of liable parties widens beyond the manufacturer to include the party that substantially modifies a product outside the manufacturer’s control, the authorised representative, the importer and, in defined circumstances, the fulfilment service provider and the online platform. Recoverable damage is extended to the destruction or corruption of data that is not used professionally, which is a real category of loss in software failures. And a product can be defective because of what happens after it is put on the market: a defect in a required software update, a failure to supply security updates, or the effects of continued learning where the producer retained control over it.
The reform also attacks the evidential problem directly. A court can order the defendant to disclose relevant evidence at the claimant’s request, and if the defendant does not comply, defectiveness is presumed. Rebuttable presumptions of defectiveness and of causation apply where the claimant faces excessive difficulty in proving them because of technical or scientific complexity, provided the claimant makes the likelihood plausible. For a claimant confronted with a model nobody can fully explain, that is the difference between an arguable case and an impossible one.
Contract, conformity and the limits of exclusion clauses
Between businesses the first battleground is usually the contract rather than the statute. A supplier of an AI system owes what it agreed to owe: the delivered system must correspond to the contract and possess the qualities the buyer was entitled to expect. Where a supplier promised an accuracy level, an availability level or compliance with the AI Act, failure to deliver it is breach of contract, and the ordinary remedies of performance, damages and dissolution follow after a proper notice of default.
Suppliers respond with limitation and exclusion clauses, and those clauses are usually effective between commercial parties. They are not unlimited. A clause can be set aside where reliance on it would be unacceptable according to standards of reasonableness and fairness, which is the route courts take in cases of deliberate recklessness or serious fault on the supplier’s side, and where the clause is in general terms it may fail if the other party was never given a genuine opportunity to take note of them. Liability under the product liability regime cannot be contracted away at all as against the injured party. In practice the negotiation is about caps, carve-outs for data breaches and IP infringement, indemnities for regulatory fines, and the supplier’s obligation to provide the documentation and logs the customer needs to defend itself. Our page on claims for damages sets out how those claims are built.
What the AI Act does and does not do
The AI Act is a regulatory instrument. It tells providers and deployers what to do and gives supervisors powers to enforce it; it does not create a right to compensation for a person harmed by an AI system. The proposed AI Liability Directive, which would have harmonised civil claims and introduced disclosure and presumptions across the board, has been withdrawn. What remains is the combination described above: national tort and contract law, plus the reformed product liability regime.
That does not make the AI Act irrelevant to liability. It matters in three ways. It fixes the standard of care, so that non-compliance is evidence of negligence. It generates documents, because the technical documentation, the instructions for use, the logs and the post-market monitoring file all exist by law and can be demanded in proceedings. And it allocates roles, so that the question of who is the provider and who is the deployer, which used to be a matter of argument, now has a legal answer. Our IT law practice deals with those classification questions before they become disputes.
Where user and producer meet
Most real incidents are not caused by a single failure at one end of the chain. They are caused by a model trained on data that did not represent the population it was applied to, integrated by a supplier that did not test it in that context, deployed by an organisation that used it for a purpose the instructions did not cover, and operated by staff who were never told what its limitations were. Dutch law has no difficulty with that: multiple parties can be liable for the same damage, each is liable for the whole of it towards the injured party, and they settle the internal apportionment between themselves afterwards according to their respective contributions.
The table below sets out where responsibility typically sits and on what basis.
| Party | Typical basis of liability | What decides the outcome |
|---|---|---|
| Provider or manufacturer | Product liability without fault; contractual liability towards the customer. | Whether the system offered the safety that could be expected, and what the documentation and instructions actually said. |
| Party that substantially modifies | Steps into the producer’s position for the modified product. | Whether the change went beyond the intended purpose or was made outside the original producer’s control. |
| Deploying organisation | Tort, breach of its own duty of care, liability for employees and auxiliaries. | Use within the instructions, quality of human oversight, input data, logging and monitoring. |
| Individual operator | Personal liability is rare; criminal exposure where the system is used deliberately. | Intent, or serious fault, and whether the employer is answerable instead. |
The Dutch childcare benefits affair is the reference point every Dutch discussion returns to, and it illustrates the pattern rather than a rule of law: an opaque risk classification system, decisions taken on its output without a real individual assessment, and consequences that fell entirely on the people at the receiving end. Its legal aftermath was administrative and political rather than criminal, and we discuss what it does and does not show about criminal responsibility in our article on AI and criminal law.
The evidence problem, and how it is shifting
Whoever brings the claim has to prove it, and in AI cases proof is the hard part. The claimant has to show what the system did, why that was wrong, and that the wrong caused the loss. The information needed to do that sits with the defendant, and in a complex model it may be genuinely difficult to reconstruct even internally.
Three developments are changing that balance. Logging is now a legal requirement for high-risk systems, so the record that used to be optional has to exist. Disclosure of evidence in product liability claims becomes available under the reformed regime, backed by a presumption of defectiveness where the defendant does not comply. And Dutch civil procedure already allows a party to demand production of specific identified documents in which it has a legitimate interest, which is regularly used to obtain test reports, incident logs and internal risk assessments.
For a defendant the practical conclusion is uncomfortable but clear: the documentation you keep is the documentation that will be read out against you, and the documentation you failed to keep will be held against you as well. Complete, dated, honest records of testing, known limitations, incidents and their handling are the strongest available defence, because they show that the organisation exercised judgement rather than hoped for the best. Where the incident also has a criminal dimension, for example unauthorised access to systems or manipulation of data, the criminal framework for computer crime and cyber crime in the Netherlands applies alongside the civil claim, and a criminal investigation will seize precisely the same material.
Autonomous systems in the physical world
Where an AI system steers a vehicle, flies a drone or moves a robot arm, a further layer of liability applies, and it is generally stricter than anything discussed so far. Physical harm attracts risk liability, which does not ask whether anyone was careless.
For motor vehicles, article 185 of the Road Traffic Act 1994 makes the owner or keeper of a motor vehicle liable for damage caused to pedestrians and cyclists unless there was force majeure, a standard that is very hard to meet. That rule is indifferent to whether a human or a driver assistance system was steering: the keeper answers first, and any recourse against the manufacturer of the software follows afterwards. Testing genuinely self-driving vehicles on public roads requires a permit under the dedicated Dutch experimentation legislation, and the conditions attached to that permit, including the presence and role of a supervisor, become part of the standard of care.
Unmanned aircraft are governed by the European drone regulations, with operator registration and category-dependent requirements administered in the Netherlands by the Rijksinspectie Digitale Infrastructuur. An operator flying outside its category, or without the required competence, is not only in breach of aviation rules; it has also stepped outside the conduct a court would call careful, which resolves the negligence question before the technical debate about the autopilot even starts.
Alongside these regimes stands the general rule on defective objects. The possessor of a movable thing that does not meet the standards that may be set for it, and that thereby creates a particular danger, is liable for the damage that danger causes. That rule reaches the physical machine even where the underlying fault is in its software, which is one reason why the owner of an industrial robot or an automated warehouse system cannot simply point at the vendor. Where the product liability regime applies, the two systems interact, and the injured party will normally pursue whichever route is easiest to prove.
The practical consequence for organisations operating machinery with autonomous functions is that insurance and contract have to be arranged around the strict liability, not around the fault-based analysis. Recourse against a supplier is worth having, but it does not stop the claim arriving at your door first.
Reducing exposure on both sides
The measures that reduce liability for AI systems are the same measures that make the systems work properly, which is why they are worth doing regardless of the regulatory calendar.
For a deploying organisation, start with the inventory: which systems are in use, who supplied them, what they decide or influence, and who operates them. Establish your role for each one, because provider and deployer duties differ. Then write down the intended purpose and stay inside it; the single most common cause of avoidable liability is using a tool for something it was not validated for. Give the people operating the system real authority to override it, and measure them on judgement rather than volume. Keep the logs, and keep them long enough to be useful in a dispute. Record the incidents, including the near misses, and record what was done about them.
For a producer or supplier, the equivalent list runs through the lifecycle: documented risk management, data governance that can be explained to a regulator, testing against the population the system will actually be used on, instructions for use that are honest about limitations and error rates rather than reassuring, a channel for customers to report problems, and an update policy that says who is responsible for security patches and for how long. The reformed product liability regime makes that last point sharper than it used to be: a failure to supply updates you undertook to supply can itself make the product defective.
Both sides should treat the contract as a risk allocation exercise rather than a formality. The clauses that matter are the description of the intended purpose, the warranties about compliance and performance, the obligation to hand over documentation and logs, the incident notification duties in both directions, the liability cap and its carve-outs, the indemnities for third-party claims and regulatory fines, and the exit arrangements that determine what happens to the model and the data if the relationship ends. A cap that is negotiated in the abstract, without reference to what the system actually decides, protects nobody.
Finally, keep the criminal exposure in view even where the immediate risk is civil. Prosecution of a company over an AI failure is still unusual, but the elements are ordinary ones: a duty, a breach, a foreseeable harm and an organisation that can be shown to have accepted the risk. Where a system is used for something plainly unlawful, or where a company continues to operate a system it knows to be causing harm, the criminal route is open, and the analysis is set out in full in our article on Dutch criminal law and the companion piece on algorithms and criminal responsibility.
Frequently asked questions
Can an AI serve as a witness in Court?
The short answer is no, at least not in the current legal landscape. The concept of a witness is fundamentally human. To be a witness, a person must be able to take an oath, promising to tell the truth. They also need to have personal knowledge of the events in question and be able to withstand cross-examination, where their memory, perception, and credibility are scrutinised.
An AI simply doesn’t meet these criteria. It has no consciousness, can’t swear an oath, and doesn’t possess personal memories in the human sense. At best, it can present data it has processed. This makes it much more like a piece of evidence, such as a CCTV recording, than an actual witness. The AI’s output can certainly be presented in court, but it would be a human expert explaining that data who actually serves as the witness.
What is the difference between Civil and criminal Liability for AI?
This distinction is crucial whenever an AI causes harm. While both civil and criminal cases involve legal responsibility, their purpose, the burden of proof, and the penalties are worlds apart.
Here’s a straightforward way to think about it:
- Civil Liability: This is about making a victim whole again. The focus is on compensation for damages, like financial losses from a faulty algorithm or injuries from an autonomous vehicle. The standard of proof is lower—often a “balance of probabilities.”
- Criminal Liability: This is about punishing a wrong against society itself. It requires proving guilt “beyond a reasonable doubt”—a much higher hurdle—and can lead to severe penalties like imprisonment or hefty fines.
When an AI is involved, a company might face a civil lawsuit to pay for damages caused by its product. But for criminal charges to stick, a prosecutor must prove a human actor had a “guilty mind” (mens rea). This is precisely why liability is traced back to a person, not the machine.
How can my organisation prepare for the EU AI act?
With regulations like the EU AI Act already in force and applying in stages, waiting until the last obligations take effect is a risky strategy. Proactive compliance is the only way to effectively mitigate your legal risks.
Here are a few key steps to get you started:
- Classify Your AI Systems: First, you need to determine which risk category your AI applications fall into—unacceptable, high, limited, or minimal. This classification will dictate your specific compliance obligations.
- Conduct Risk Assessments: For any high-risk systems, you must perform thorough assessments to identify and address potential harms to fundamental rights. This isn’t just a box-ticking exercise; it’s a deep dive into your system’s impact.
- Ensure Transparency and Documentation: Keep meticulous records of your AI’s design, the data sets used for training, and its decision-making processes. This documentation is essential for demonstrating compliance and accountability if an incident ever occurs.
Law & More advises organisations that build AI systems and organisations that use them, on the allocation of risk in contracts, on classification and duties under the AI Act, and on defending or bringing claims when a system has caused loss. If an AI system in your organisation has produced a decision that is now being challenged, contact us so we can assess the position quickly.
