Under Dutch and European law an algorithm cannot be criminally responsible. Criminal liability requires a perpetrator that the law recognises as a person, and art. 51 Sr extends that status only to natural persons and legal persons. An AI system is an object, not a suspect. The question that matters in practice is therefore not whether the algorithm is partly responsible, but which human being or which company is wholly responsible for what it did.
That question already has a well-developed answer in Dutch criminal law. The doctrines of functional perpetration (functioneel daderschap) and corporate criminal liability were built for exactly this situation: harm caused through an instrument, an organisation or a process rather than by the defendant own hands. This article sets out how those doctrines apply to AI, how the EU AI Act is changing the standard of care, how algorithmic output is treated as evidence, and what a defence and a compliance programme should look like. For the broader question of allocating responsibility across a supply chain of developers, providers and users, see our companion article on who is responsible when a machine commits a crime.
Why an algorithm cannot be a suspect
A criminal offence under Dutch law requires a human act or omission that fits the statutory definition of an offence, that is unlawful, and that can be blamed on the perpetrator. Each of those elements assumes an actor with a will. An algorithm produces outputs by executing code on data; it has no will to form, nothing to be blamed for, and nothing that a criminal sanction could reach. Art. 51 Sr made room for the company alongside the individual precisely because a company acts through people; there is no comparable provision for software, and creating one would require the legislature to invent a new category of legal person.
Nor would it serve any purpose the criminal law recognises. A sentence exists to punish, to deter and, where possible, to correct. None of those functions can be performed on a model. Deleting the weights of a neural network punishes its owner, not the network. Everything that criminal law wants to achieve when an AI system causes harm has to be achieved through the people and the organisations behind it, which is why Dutch practice does not treat this as a gap in the law.
The table below sets out the mismatch between the elements of a criminal offence and what an AI system actually is.
| Element | What criminal law requires | Position of an AI system |
|---|---|---|
| A perpetrator | A natural person, or a legal person under art. 51 Sr. | Neither. The system is an object owned and operated by someone else. |
| A conduct | An act or a culpable omission attributable to that perpetrator. | An output produced by code. The attributable conduct is the decision to build, deploy or leave it running. |
| Intent or negligence | Opzet, including conditional intent, or culpa in the sense of substantial carelessness. | No mental state at all. Intent and negligence exist, if anywhere, in the humans who configured and supervised it. |
| A sanction | Imprisonment, a fine, a community sentence, or a measure. | None can be imposed on software. Sanctions fall on the operator. |
Who is liable instead: functional perpetration and art. 51 Sr
Dutch criminal law has two mechanisms for holding someone responsible for conduct they did not physically carry out. Both were developed long before machine learning existed, and both fit AI cases without modification.
Functional perpetration
Functioneel daderschap allows a person to be regarded as the perpetrator of an offence that was physically carried out by someone or something else. The criteria the Hoge Raad formulated in the IJzerdraad judgment remain the test: the defendant must have had the power to determine whether the conduct took place (beschikken), and must have accepted it, or habitually accepted conduct of that kind (aanvaarden).
Applied to an AI system, the first criterion is usually straightforward and the second decides the case. Power of disposal is shown by the ability to configure the system, to set its operating limits, to update or retrain it, and above all to switch it off. Very few operators can credibly say they lacked that power. Acceptance is the harder question, and it is where the evidence goes: what did the operator know about the failure modes of the system, what was reported by testing or by earlier incidents, what did the risk assessment say, and what was done about it. Acceptance does not require a wish for the outcome. It is enough that the operator knowingly accepted a considerable risk, which is the ordinary Dutch standard for conditional intent (voorwaardelijk opzet).
Corporate liability and actual leadership
Where the operator is a company, art. 51 Sr applies. The offence can be attributed to the legal person where the conduct took place in its sphere, which the Hoge Raad has explained through the factors set out in the Drijfmest judgment: the conduct was carried out by someone working for the company, it fits within its normal business, it was useful to the company, and the company was able to determine whether it took place and accepted, or habitually accepted, such conduct. An AI system deployed by a company to do its work satisfies most of that list by definition.
Art. 51 Sr also allows prosecution of those who ordered the offence and those who gave actual leadership to it (feitelijk leidinggeven). This is the provision that reaches directors and senior managers personally. It requires more than a place on the organisation chart: the person must have been aware of the prohibited conduct, at least in the sense of accepting a considerable chance that it was taking place, and must have failed to take measures they were competent and reasonably obliged to take. In an AI case, that translates directly into evidence about who received the model validation report, who signed off the deployment, and who decided that a known bias or error rate was acceptable.
Negligence offences do most of the work
In practice, prosecutions involving automated systems are far more likely to be built on negligence than on intent. Where an AI-driven vehicle, machine or medical device causes death, the relevant offence is causing death by negligence under art. 307 Sr; where it causes serious injury, art. 308 Sr. Culpa in Dutch criminal law means substantial carelessness, judged against what a reasonable operator in that position should have done. That is exactly the ground on which an AI case will be fought, because the standard of care for deploying an automated system is increasingly written down: in the AI Act, in sector regulation, in technical standards and in the operator own procedures. A documented departure from a standard the operator itself adopted is the strongest evidence of negligence there is.
Discrimination is the second recurring category. Discriminating in the exercise of a business or profession is a criminal offence under the Wetboek van Strafrecht, and both intentional and negligent variants exist. A model that systematically disadvantages a protected group is therefore not only an administrative problem under data protection and equal treatment law; in a serious case it is a criminal one. Our guide to criminal procedure in the Netherlands explains how such a case would run from investigation to judgment.
The AI Act sets the standard of care, not the sanction
The EU Artificial Intelligence Act is administrative regulation. It does not create criminal offences and it does not make anyone a suspect. Its importance to criminal liability is indirect and considerable: it writes down, in binding terms, what a careful provider or deployer of an AI system is expected to do. Once a standard of care is codified, a departure from it is evidence of negligence, and compliance with it is evidence of care.
The Act sorts systems by risk. A small number of practices are prohibited outright, including social scoring by public authorities, untargeted scraping of facial images to build recognition databases, emotion recognition in the workplace and in education, and, subject to narrow exceptions, real-time remote biometric identification in public spaces for law enforcement. A larger group is classified as high risk, which covers safety components of regulated products and the uses listed in the annex to the Act, among them recruitment, credit scoring, and applications in law enforcement, migration and the administration of justice. Systems that interact with people or generate synthetic content carry transparency duties. The remainder is essentially unregulated.
Provider or deployer: the roles decide the duties
The Act distributes obligations according to role, and getting the role wrong is one of the most common compliance errors. A provider develops a system or has it developed and places it on the market under its own name; a deployer uses a system under its own authority in the course of its activities. Providers carry the heavy design obligations, deployers carry obligations of correct use, human oversight and monitoring. The trap is that a deployer becomes a provider, with all the duties that follow, if it puts its own name on the system, substantially modifies it, or changes its intended purpose in a way that brings it within the high-risk categories. Fine-tuning a purchased model on your own data, and then using it for a purpose the vendor never contemplated, can quietly move an organisation across that line. In a criminal investigation the same distinction reappears as the question of who had the power of disposal, which is why the roles should be recorded in writing and reflected in the contract.
What applies now
The timetable has shifted, and it is worth being precise about where it stands. The prohibitions on unacceptable-risk practices and the obligation to ensure AI literacy already apply. The rules for general-purpose AI models already apply. The transparency obligations of art. 50, including the duty to make clear that content is artificially generated or manipulated, already apply. What has been postponed by the digital omnibus package is the high-risk regime: the obligations for the systems listed in Annex III now start on 2 December 2027, and those for the systems covered by Annex I on 2 August 2028. Separately, the proposed AI Liability Directive has been withdrawn, so civil liability for AI harm remains a matter of national law, which in the Netherlands means the ordinary rules of tort and product liability.
Penalties under the Act are administrative and are set at up to thirty-five million euros or seven per cent of total worldwide annual turnover, whichever is higher, for engaging in a prohibited practice, with lower ceilings for other infringements. Supervision in the Netherlands is being organised around existing regulators, with the Autoriteit Persoonsgegevens and the Rijksinspectie Digitale Infrastructuur in a coordinating role. Our articles on prohibited AI practices and on high-risk AI systems under the AI Act set out the obligations in detail, and our overview of the EU AI Act covers the framework as a whole.
How a prosecutor will use it
Consider a deployer that puts a screening tool into use without checking the training data for bias, without the human oversight arrangement the Act requires, and without the documentation it requires. If that tool then contributes to a criminal outcome, the prosecutor does not have to argue from first principles about what care was owed. The obligations are on the page, the breach is documented, and the acceptance element of functional perpetration follows from the decision to deploy anyway. The reverse is equally true, and this is the point most often missed by boards: a company that can produce its risk assessment, its validation results, its oversight protocol and its incident log has built the core of its own defence before anything went wrong.
Algorithmic output as evidence
The second way AI enters a criminal courtroom is not as a cause of harm but as a source of proof. Facial recognition matches, automatic number plate recognition, network analysis of communications data, fraud risk models, voice comparison and increasingly automated triage of seized data all produce material that the prosecution wants to rely on. Dutch criminal procedure works with a closed system of categories of evidence, and algorithmic output does not form a category of its own. It reaches the court as part of an official report or through the opinion of an expert, and it is subject to the same scrutiny as any other evidence.
That scrutiny is where defence work concentrates. Three questions decide the weight the material can carry. Is the method validated, and by whom? Under what conditions does it fail, and were those conditions present? And can the defence test it, which means access to enough information about the system, its training data, its error rates and its configuration to mount a meaningful challenge. A match presented as a fact, with no error rate and no possibility of verification, is not evidence that a court should convict on, and saying so is a legitimate and often effective defence.
Expert evidence has its own framework. The court can appoint an expert, the defence can ask for one, and the register of court experts exists to provide a quality threshold for the fields it covers. Where an AI method falls outside any recognised field, that in itself is an argument about the reliability of the result. It is also worth noting that the new Wetboek van Strafvordering, adopted by the Eerste Kamer on 24 February 2026 and published in the Staatsblad in March 2026, will enter into force book by book by royal decree; until it does, the current provisions and their article numbers continue to apply.
The data protection angle
Where a decision affecting a person is taken by automated means alone, the GDPR gives that person the right not to be subjected to it, together with the right to meaningful information about the logic involved. In criminal enforcement the parallel rules of the law implementing the police data directive apply. This matters in two directions. For a suspect, it is a route to information about a system that the authorities may prefer not to explain. For a company, deploying automated decision-making without a lawful basis and without the safeguards is a regulatory breach that will be read alongside any criminal allegation.
Defending a case in which AI is involved
The instinctive defence, that the system was a black box and nobody could have known what it would do, is weaker than it looks. It answers the wrong question. Dutch criminal law does not ask whether the defendant foresaw the precise output; it asks whether the defendant had the power to determine whether the conduct took place and accepted the risk that it would. Opacity can cut against the defendant: deploying a system whose behaviour cannot be explained, in a setting where it can cause serious harm, is itself a decision that a court may regard as accepting the risk.
The defences that work are narrower and evidential. The first is genuine absence of control: the system was procured as a finished product, configured and maintained by the provider, and the defendant had neither the information nor the technical ability to intervene. That argument shifts attention up the chain to the provider, and it stands or falls on the contract and on what was actually reported to the deployer. The second is that the operator did what a careful operator does: documented risk assessment, validation before deployment, defined human oversight with a person who had the authority and the competence to override, monitoring after deployment, and prompt action on incidents. The third is causation, which is frequently underused. In a chain running from training data through a model to a human decision to an outcome, the prosecution has to show that the conduct of this defendant caused the result, and complex chains break.
Two practical points follow. Preserve everything early: logs, model versions, configuration, incident reports and the correspondence around deployment decisions are the evidence on both sides, and they are routinely overwritten. And remember that the ordinary safeguards of criminal procedure apply in full to technically complex cases, including the right of a suspect to say nothing; our article on the right to remain silent in criminal matters explains how it works in a Dutch investigation. Where the allegation is one of fraud committed with automated tools, our guide to fraud and financial crime in the Netherlands covers the offences involved.
What the childcare benefits affair actually shows
The toeslagenaffaire, the Dutch childcare benefits affair, is the case every discussion of algorithmic accountability in the Netherlands returns to, and it is usually cited for the wrong reason. Its lesson is not that an algorithm did something criminal. It is that a system of automated risk selection, combined with an institutional unwillingness to question its output, produced years of serious harm to tens of thousands of families without anyone being held criminally responsible.
The Tax Administration used risk classification to select benefit claims for investigation. Indicators that should never have been used, including nationality, found their way into the selection, and a minor administrative irregularity could trigger a finding of deliberate fraud with an obligation to repay the full benefit. Families could not see why they had been selected, officials treated the classification as a conclusion rather than a signal, and the burden of disproving an accusation nobody would explain fell on the accused. The Dutch data protection authority found the processing of nationality data unlawful and imposed a fine, and the government resigned in January 2021.
What did not happen is instructive. No individual was criminally prosecuted. Responsibility was diffused across an organisation, a policy, a piece of software and a legal framework that treated the recovery of benefits as an administrative matter. That diffusion is exactly the risk that functional perpetration and art. 51 Sr are designed to counter, and it explains why the AI Act insists on identifiable human oversight and on documentation. Accountability requires a person who could have stopped it and a record of what they knew.
Three failures are worth naming because they translate directly into legal exposure for any organisation. Decisions were not explainable, so they could not be challenged. Human oversight existed on paper but not in practice, because the people involved had neither the authority nor the information to override the system. And the effect of a flag was to reverse the burden of proof in fact if not in law. Any AI deployment that reproduces these three features is a legal problem waiting to mature, whatever the technology behind it. The government response, including guidance on non-discrimination by design and on algorithm registers for public bodies, is aimed squarely at those three points.
A compliance programme that also works as a defence
Everything a company does to comply with the AI Act also produces the evidence it would need if something went wrong. That dual purpose is the argument for doing it properly rather than minimally, and it makes the following steps worth the effort.
Start with an inventory. You cannot classify what you have not listed, and most organisations discover that AI has entered through procurement rather than through a project: a screening feature in a recruitment platform, a scoring module in a credit application, a monitoring function in security software. Classify each system under the Act, record the reasoning, and revisit it when a system is materially changed, because a change of purpose can move a system into a different category.
Then assign responsibility to named people rather than to departments. Functional perpetration and actual leadership both turn on who could have determined whether the conduct took place. An organisation in which nobody can be identified as responsible does not escape liability; it simply exposes whoever sits at the top of the chart. Say who owns each system, who may authorise deployment, who performs oversight and who may switch it off, and make sure the person named has the authority and the technical competence to do it.
Make human oversight real. The requirement is not a person in the loop but a person who can understand the output, has the standing to reject it, and is not measured on throughput in a way that makes rejection impractical. Record overrides, because a log showing that the oversight function is actually used is worth more than any policy document.
Document the technical position: where the training data came from and how it was checked, what testing was done and what it showed, what the known error rates and failure conditions are, and what was decided about them. Where an assessment of the impact on data protection or on fundamental rights is required, carry it out before deployment and keep it current. Monitor after deployment, log incidents, and act on them in a way that is visible in the record.
Finally, get the contracts right. Where a system is bought rather than built, the allocation of responsibility between provider and deployer determines who carries the risk. Ask for the technical documentation the Act requires, for the instructions for use, for information about known limitations, and for the right to be told about incidents and substantial modifications. Our IT law team deals with those arrangements.
When AI is the tool of the offender rather than the failure of a business
So far this article has dealt with harm caused by an AI system that a company deployed for a legitimate purpose. The other half of the picture is AI used deliberately to commit an offence, and here the answer is simpler: the offence is the offence, and the technology is an aggravating detail rather than a legal problem. Dutch criminal law is drafted in terms of results and conduct, not in terms of instruments, which is why very few new provisions have been needed.
Fraud committed with a cloned voice or a synthetic video of a director instructing a payment is deception under art. 326 Sr, exactly as it would be with a forged letter. A document generated by a model to support a false claim is forgery under art. 225 Sr. Using someone identifying personal data to pass as them is an offence in its own right under art. 231b Sr. Distributing sexually explicit images of a person without their consent is punishable, and the Wet seksuele misdrijven, in force since 1 July 2024, modernised that part of the Criminal Code; a synthetic image does not fall outside it because it was generated rather than recorded. Persistent harassment through automated accounts can amount to belaging under art. 285b Sr, which is prosecuted only on complaint by the victim.
What AI changes is scale, credibility and the difficulty of proof. A convincing synthetic voice removes the friction that used to protect against payment fraud, and evidence that a recording is authentic can no longer be assumed. Two practical consequences follow. For victims and for companies, verification procedures that do not depend on recognising a voice or a face are now a basic control rather than a refinement. For the criminal process, the authenticity of audio and video material has become a question that has to be proved rather than presumed, and the defence is entitled to test it.
Regulation is beginning to help. The transparency obligations of art. 50 of the AI Act, which already apply, require providers to mark synthetic content in a machine-readable way and require deployers to disclose that an image, audio or video has been artificially generated or manipulated where it depicts real people or events. Compliance does not stop a determined offender, but it strengthens the position of everyone else: it makes undisclosed synthetic content a regulatory breach in its own right, and it gives investigators and courts a signal to look for. Our article on proving digital deception in the Netherlands deals with the evidential side of these cases.
Frequently asked questions about AI and criminal liability
Can a company be held criminally liable if its AI discriminates?
Yes, it absolutely can. While you won't see an AI system itself in the dock, the company that put it to use can certainly face criminal charges for discriminatory outcomes under Dutch corporate criminal liability principles. If a company's leadership knew about the AI's potential for bias and did nothing, or if they were grossly negligent in their oversight, criminal charges are a very real possibility. The EU AI Act also sets strict anti-bias rules for high-risk systems. Failing to meet those standards would be powerful evidence of negligence in any criminal case. The legal spotlight will always shine brightest on the human decisions made around the AI’s creation, training, and deployment.
What is the black box problem in AI?
The "black box" problem is a term for complex AI models where even the people who built them can't fully trace how a specific output was reached. This is a massive issue when AI and criminal law collide. In court, this can actually become the cornerstone of a defence. A lawyer could argue that a harmful outcome was completely unforeseeable, meaning the defendant lacked the required criminal intent (opzet). The argument is simple: how could they have intended a result they couldn't possibly predict? But prosecutors have a strong comeback. They can argue that deploying a powerful, unpredictable system without proper safeguards is, in and of itself, an act of recklessness or gross negligence. And that can be enough to satisfy the mental element needed for criminal liability. This sets the stage for a high-stakes legal fight over foreseeability and the duty of care.
What is the best way for developers to limit legal Risk?
The single most effective thing developers can do to shield themselves from legal risk is to keep meticulous, transparent documentation through every stage of the AI's life. Think of it as creating a detailed "audit trail" that can become your most crucial piece of evidence. This documentation really needs to cover everything from start to finish: Data Sources: Where did the training data come from, and how was it checked for quality and bias?; Bias Mitigation: What specific steps were taken to find and remove biases from the datasets?; Design Rationale: What was the logic behind the key architectural choices and algorithms?; Testing Results: A full record of every test run, including failures and how you fixed them.. Putting a clear framework for human oversight in place is just as vital. If an investigation ever happens, this paperwork serves as undeniable proof of due diligence. It helps show that any harm caused was a truly unforeseeable accident, not the result of negligence—and that forms the bedrock of a solid legal defence.
Can an algorithm be found criminally responsible for a crime under current Dutch and EU law?
No. Under current law an algorithm cannot be found criminally responsible. Core legal concepts such as criminal intent (opzet) and legal personhood are reserved for humans and, in certain situations, corporations.
Why can’t an AI system simply be put on trial like a person?
An algorithm lacks the fundamental traits required to stand trial: it has no consciousness, no personal assets to seize, and no liberty that can be taken away, unlike a natural person or a corporation recognised as a legal person.
Does this mean AI is irrelevant to criminal cases?
No, quite the opposite. Even though the algorithm itself cannot be guilty, its actions are becoming central to proving the guilt or innocence of the people who create, deploy, and oversee it.
What legal concept is hardest to apply to AI systems?
Criminal intent (opzet) is particularly difficult, since prosecutors must normally prove a guilty mind such as intent, recklessness or knowledge of wrongdoing, while an algorithm simply operates based on its programming and data inputs and lacks consciousness, beliefs or desires.
How Law and More can help
Law and More advises companies, directors and individuals on criminal liability arising from automated systems. We assess exposure under art. 51 Sr and the doctrine of functional perpetration, build and review AI governance that will stand up as evidence of care, challenge algorithmic evidence in criminal proceedings, and defend companies and their officers in investigations by the Public Prosecution Service and by regulators. If your organisation deploys AI in a setting where mistakes have consequences, contact our office before an incident forces the question.
