Algorithmic bias liability is the legal responsibility an organisation carries when an automated system produces discriminatory outcomes. In the Netherlands that responsibility rests on three foundations that already apply today: the general tort provision of article 6:162 of the Dutch Civil Code, the equal treatment legislation supervised by the Netherlands Institute for Human Rights, and the GDPR rules on fairness and automated decision-making. The EU AI Act adds a further layer, part of which is already in force and part of which starts later this decade.
The practical consequence is straightforward. A company that deploys a recruitment filter, a credit model or a fraud-detection score is answerable for what that system does, whether or not it built the model itself and whether or not anyone intended the outcome. In Dutch discrimination law the effect of a decision counts, not the motive behind it.
What algorithmic bias liability actually covers
Algorithmic bias arises when an automated system treats comparable people differently on grounds that the law protects, or on grounds that act as a substitute for them. It rarely announces itself. A model trained on a decade of the company’s own decisions will reproduce whatever pattern those decisions contained, and it will do so consistently, at speed, across every file it touches. That consistency is what turns a technical defect into a legal exposure: a single biased human decision is an incident, while a biased model is a policy.
Liability follows from three separate sources, and they can be triggered at the same time by the same decision. Civil liability compensates the person who suffered loss. Equal treatment law gives that person a route to the Netherlands Institute for Human Rights (College voor de Rechten van de Mens) or to the civil court, with a burden of proof that shifts towards the organisation once a presumption of discrimination is made out. Data protection law gives the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) enforcement powers that do not depend on any individual bringing a claim at all.
None of this requires a bespoke AI statute. The rules that decide these cases were written before the technology existed and apply to it without amendment.
Where bias enters an automated system
Bias is not a single failure that can be tested away once. It enters at identifiable points in the lifecycle, and each point maps onto a different allegation of negligence.
- The training data. Historic decisions carry historic patterns. A model trained on them learns those patterns as the standard rather than as a problem to be corrected.
- The choice of variables. A feature that looks neutral can correlate closely with a protected characteristic. Postcode standing in for ethnicity is the textbook example, and it produces indirect discrimination even where the protected characteristic itself was never recorded.
- The way the output is used. A model that performs unevenly across groups can be defensible as a research tool and indefensible as the sole basis for rejecting an application. The same score, used differently, produces a different legal result.
- The absence of monitoring. A system that was balanced at launch drifts as the data around it changes. Failing to look is itself the negligent act in many claims.
The distinction that matters legally is between direct discrimination, where a protected ground is used openly, and indirect discrimination, where a neutral criterion disadvantages a protected group. Indirect discrimination can be justified if the aim is legitimate and the means are appropriate and necessary, but that justification has to be evidenced, and an organisation that cannot explain why its model uses a given variable will not get there.
The Dutch foundation: tort law and equal treatment law
Two bodies of Dutch law do most of the work in a bias claim, and they answer different questions. Tort law asks whether the organisation acted carelessly and what the loss is worth. Equal treatment law asks whether the outcome was discriminatory, and it does so with a burden of proof that is deliberately claimant-friendly.
Negligent deployment as an unlawful act
Article 6:162 of the Dutch Civil Code makes a person liable for an unlawful act (onrechtmatige daad) that can be attributed to them and that causes damage. Deploying an automated system that the organisation did not test, validate or monitor is capable of being unlawful conduct in its own right, quite apart from the discriminatory outcome. The claimant must show the act, the attribution, the damage and the causal link between them; the standard applied is what a careful organisation in the same position ought to have done.
Where the system came from a supplier, the deploying organisation is not relieved of that duty. It may have a contractual claim against the vendor under article 6:74 of the Civil Code for defective performance, but that is a separate action between two commercial parties. It does not answer the claim of the applicant who was rejected.
Equal treatment law and the shifted burden of proof
The Algemene wet gelijke behandeling and the sector statutes alongside it, including the age discrimination act (WGBL) and the act on disability and chronic illness (WGBH/CZ), prohibit direct and indirect distinction on protected grounds. In employment, article 7:646 of the Civil Code adds the gender provisions.
The procedural rule is the one that decides most cases. Once the claimant puts forward facts that give rise to a presumption of discrimination, the burden shifts: the organisation must then prove that it did not breach the prohibition. An organisation that cannot show what its model weighed, on what data, and with what testing, has no way of discharging that burden. This is the point at which poor documentation stops being an internal housekeeping problem and becomes the reason a claim is lost.
Complaints can also be brought before the Netherlands Institute for Human Rights, whose opinions are not binding but are widely followed and are frequently used as evidence in subsequent civil proceedings.
What the GDPR requires of automated decisions
The GDPR governs the same systems from the data protection side. Article 22 gives a person the right not to be subject to a decision based solely on automated processing, including profiling, where that decision produces legal effects or similarly significantly affects them. Recruitment, credit and benefits decisions ordinarily fall within that description.
The word that carries the weight is solely. Human involvement only takes a decision outside article 22 if it is meaningful: a person with the authority and the information to reach a different conclusion, not an operator who confirms whatever the screen shows. Rubber-stamping is treated as automated decision-making.
Two further obligations apply regardless of article 22. The fairness principle in article 5(1)(a) is a free-standing requirement that a discriminatory model breaches by definition, and article 35 requires a data protection impact assessment before processing that is likely to result in a high risk to individuals, which systematic profiling of applicants or customers generally is. The maximum fine for breaches of these provisions is set by article 83(5) of the GDPR at the higher of twenty million euro or four per cent of worldwide annual turnover.
Our overview of data privacy, the GDPR, AI and big data sets out how these duties interact with large-scale data use in more detail.
What the AI Act already requires and what starts later
Regulation (EU) 2024/1689, the AI Act, is no longer a proposal. It entered into force on 1 August 2024 and applies in stages. Since 2 February 2025 the prohibitions in article 5 apply, together with the duty in article 4 to ensure that staff working with AI systems have an adequate level of AI literacy. The obligations for general-purpose AI models have applied since 2 August 2025, as have the governance and penalty provisions.
The high-risk regime is the part that most directly concerns bias, and it is also the part that has been postponed. AI systems listed in Annex III, which include systems used for recruitment and selection, for decisions on promotion and termination, for evaluating creditworthiness and for risk assessment in insurance, now become subject to the high-risk obligations on 2 December 2027. High-risk systems that are safety components of regulated products under Annex I follow on 2 August 2028.
When those obligations bite, they codify much of what careful practice already involves: data governance aimed at representative and error-checked datasets, technical documentation, automatic logging, transparency towards the people affected, human oversight designed into the system rather than bolted on, and a conformity assessment before the system is placed on the market or put into service. Deployers, not only providers, carry duties of their own, including keeping logs and assigning oversight to competent people.
Two points are regularly misstated. The penalty ceilings are tiered rather than uniform: up to thirty-five million euro or seven per cent of worldwide turnover applies to breach of the prohibited practices in article 5, while non-compliance with the high-risk obligations carries a lower ceiling of fifteen million euro or three per cent. And the proposed AI Liability Directive, which would have eased the burden of proof for people harmed by AI systems across the EU, has been withdrawn. There is no harmonised European liability regime for AI damage; a claim in the Netherlands is a claim under Dutch law.
National enforcement is still being built. The Netherlands has not yet completed the implementing act that designates its market surveillance authorities under the Regulation, although the Dutch Data Protection Authority and the Dutch Authority for Digital Infrastructure have taken coordinating roles in the preparatory work. We discuss the framework in more depth in our guide to the legal side of artificial intelligence and the EU AI Act.
How the three frameworks compare
| Framework | Question it asks | Basis for liability | Consequence |
|---|---|---|---|
| Dutch tort law (art. 6:162 BW) | Did the organisation act carelessly and did that cause loss? | Negligent selection, deployment or monitoring of the system | Compensation for the damage suffered, assessed per claimant |
| Equal treatment legislation | Was the outcome a prohibited distinction? | Direct or indirect distinction on a protected ground, with the burden shifting to the organisation | Annulment of the decision, damages, an opinion of the Netherlands Institute for Human Rights |
| GDPR | Was the processing fair, transparent and lawfully automated? | Breach of article 5(1)(a), article 22 or article 35 | Enforcement by the Autoriteit Persoonsgegevens; fines up to the ceiling in article 83(5) |
| AI Act | Does the system meet the requirements for its risk class? | Non-compliance with the prohibitions now, or with the high-risk regime once it applies | Administrative fines, corrective measures, withdrawal of the system from the market |
The frameworks overlap rather than compete. One rejected application can produce a civil claim, a complaint to the Institute, a regulatory investigation and, in due course, an AI Act compliance failure, on the same set of facts.
What the Dutch cases have established
Two episodes shape how Dutch courts and regulators approach automated decisions, and both are about the same failure: an opaque system applied to people who could not see how it worked.
In February 2020 the District Court of The Hague halted SyRI, the risk indication system with which public bodies combined data from a range of sources to detect benefit and tax fraud. The court held that the legislation underpinning the system failed the fair balance test under article 8 of the European Convention on Human Rights. What was fatal was not the use of data analysis as such but the absence of transparency and verifiability: neither the risk model nor the indicators were disclosed, so neither the affected citizen nor the court could check for discriminatory effect. The lesson for private organisations is that a system nobody can explain cannot be defended, because the party running it bears the burden of justifying it.
The childcare benefits scandal (toeslagenaffaire) made the same point through its consequences. The tax administration used automated risk selection that treated indicators such as dual nationality as a signal of fraud, and tens of thousands of parents were wrongly labelled and pursued for repayment. The Dutch Data Protection Authority found the underlying processing unlawful and discriminatory and imposed enforcement action. It also confirmed the principle that matters most here: the defence that the system produced the result carries no weight, because choosing to run the system is itself the act being judged.
Where liability arises in ordinary business use
Most exposure never reaches a landmark ruling. It arises in familiar operational decisions.
A recruitment filter trained on the organisation’s own hiring history will learn whatever preference that history contained and apply it to every subsequent applicant. Because recruitment tools sit squarely in Annex III of the AI Act and touch article 22 of the GDPR at the same time, they attract all three frameworks at once. A credit or insurance model that uses postcode, an employment history gap or a proxy of similar character can produce indirect discrimination even where the data set contains no protected characteristic at all. A workforce management system that allocates shifts, monitors performance or feeds into termination decisions falls into the same category, with the added complication that the works council may have a right of consent under the Works Councils Act before such a system is introduced.
In each case the question a Dutch court asks is the same. What did the organisation know about how the system behaved, what did it do to find out, and what did it do when the pattern became visible?
Vendor and deployer: who answers for what
Buying a system does not transfer the risk with it. Under the AI Act the provider and the deployer have separate duties, and under Dutch civil law the person harmed sues whoever made the decision that affected them, which is almost always the deploying organisation.
What contracts can do is allocate the financial consequences and secure the information needed to defend a claim. A procurement agreement worth having specifies the performance and fairness metrics the system is warranted to meet, guarantees access to documentation, test results and logs, gives an audit right, requires the supplier to notify material changes to the model, and sets out how liability and defence costs are shared if a claim arises. What contracts cannot do is remove a regulatory fine or a statutory duty. Our article on who is liable for errors made by artificial intelligence works through the allocation in more detail.
Controlling the risk before a claim arrives
The defensive position in a bias claim is built long before the claim is made, and it consists almost entirely of records. Because the burden of proof shifts once a presumption of discrimination is established, the organisation that can show what it tested, when, and what it did with the result is in a fundamentally different position from the one that cannot.
A workable programme has four elements. Test before deployment, comparing outcome rates across the groups the law protects and examining the training data and the chosen variables for proxies. Keep testing after deployment, because a model that was balanced at launch will not stay that way. Give one named person or committee the authority to review results and to suspend a system, so that the decision to keep running it is a decision someone made rather than a default nobody owned. And record all of it, including the data sources, the validation, the audit findings and the corrective steps, in a form that can be handed to a regulator or produced in proceedings.
Alongside that, keep the human decision genuinely human where article 22 applies, complete the data protection impact assessment before the system goes live rather than afterwards, check whether the works council has a role, and be able to tell an affected person in plain language why the decision went the way it did. None of these steps is exotic, and the AI Act high-risk regime will make most of them mandatory for recruitment, credit and insurance systems from December 2027 in any event. Organisations that build them now are simply arriving early.
What to do if a decision is challenged
When an applicant, a customer or an employee questions an automated decision, the first task is factual: establish what the system actually did in that case, which inputs it used, whether a person exercised real judgement, and whether the outcome fits a wider pattern. Do that before answering, because an inaccurate first response is difficult to correct later and will be read against the organisation.
Preserve the logs and the model version involved. Assess the claim against all three frameworks rather than the one the complainant happened to invoke, since a data protection complaint and a discrimination claim can follow from the same file. If the pattern is real, correcting it and remedying the affected decisions limits the damage far more effectively than defending it does.
Law & More advises companies on the legal side of automated decision-making: assessing exposure under Dutch tort and equal treatment law, reviewing GDPR compliance for profiling and automated decisions, preparing for the AI Act obligations that apply to recruitment, credit and insurance systems, negotiating vendor contracts, and defending claims and regulatory investigations. Our IT lawyers are happy to discuss how the rules apply to the systems you use.
Frequently asked questions about algorithmic bias liability
As businesses delve deeper into AI, many leaders find themselves asking very specific questions about liability. Below, we tackle some of the most common and challenging queries, offering clear answers to help you navigate this complex legal area.
If our Third-Party AI is biased, who is Liable—the vendor or us?
This is rarely a simple question, and the answer is almost always: it’s complicated. Liability is often shared and depends heavily on the specifics of the situation. The AI developer can be held responsible for delivering a defective or non-compliant product. However, as the organisation using the system, you have your own distinct legal duties.
Under frameworks like the EU AI Act and GDPR, your company is responsible for how the AI is implemented and monitored. This means you have a duty to vet the technology you buy, monitor for biased outcomes, and ensure its application is fundamentally fair.
A well-drafted contract can help allocate financial risk between you and the vendor, but it won't shield your company from regulatory fines or a civil claim if you were negligent in how you deployed and supervised the system.
How do we prove our algorithm is not discriminatory in Court?
Your best defence is built on proactive and thorough documentation. You need to keep meticulous records that cover the entire lifecycle of the AI model. This isn't something you can assemble after a legal challenge arises.
Your documentation should be a living record that includes:
Data Sourcing: Detailed logs of where your training data came from, plus the steps you took to clean it and check for inherent biases.
Model Validation: Hard evidence of the rigorous testing you performed before deployment to find and fix discriminatory patterns.
Regular Bias Audits: Proof that you are continuously monitoring the system to catch and correct any biases that creep in over time.
Decision-Making Logic: Clear, understandable explanations for how the system reaches its conclusions, especially for high-stakes decisions.
For any high-risk AI system under the EU AI Act, this level of technical documentation isn’t just good practice; it's a mandatory legal requirement. This body of evidence is what you'll rely on to demonstrate due diligence and defend against claims of negligence.
Does using explainable AI (XAI) eliminate our liability risk?
No, but it’s an essential part of managing that risk. Explainable AI (XAI) is a critical tool for meeting transparency obligations under GDPR, as it helps make an algorithm's decision-making process understandable to humans. It moves you away from the legally dangerous "black box" problem where no one can say why a decision was made.
However, simply explaining an unfair outcome doesn't make it fair. If the reason for a decision reveals that the model relied on a protected characteristic (for example, using a postcode as a proxy for ethnicity), you are still liable.
XAI is a crucial piece of a good governance strategy, but it is not a complete solution. It must be paired with robust processes to correct biases when they're found and to provide a real remedy for people who have been harmed.
Do these complex AI liability rules apply to SMEs?
Yes, they do. Core legal principles like Dutch tort law and anti-discrimination statutes apply to all businesses, regardless of size. While the EU AI Act includes some provisions to ease the compliance burden on Small and Medium-sized Enterprises (SMEs), these are not blanket exemptions.
If your SME uses AI in high-risk areas—like recruitment, credit scoring, or employee performance reviews—you will face strict compliance duties similar to those for larger corporations. The GDPR also applies across the board. For an SME, ignoring these risks could lead to disproportionately damaging fines and lawsuits, making it vital to assess your AI tools and understand your legal responsibilities from the start.
At Law & More, we provide expert legal counsel to help your business navigate the complex landscape of AI regulation and liability. Our team offers pragmatic, tailored advice to ensure your use of technology is both innovative and compliant. Contact us to build a proactive AI governance strategy that protects your firm. Learn more at https://lawandmore.eu.
