GDPR and AI in the Netherlands come together at one point: as soon as an algorithm processes information about an identifiable person, the General Data Protection Regulation applies in full, whatever the technology and whoever built it. That means a lawful basis for every processing operation, information to the people concerned about the logic of the system, a right to human intervention where a decision is taken by the machine alone, and a documented risk assessment before deployment. The Autoriteit Persoonsgegevens enforces those obligations, and the EU AI Act adds a separate product-safety layer on top of them without replacing any of it.
This article deals with the operational side: what an organisation has to do when personal data actually flows through an AI application. The prior question of how to justify assembling a large dataset in the first place, and how the compatibility test works when data collected for one purpose is reused to train a model, is covered separately in our article on GDPR and big data.
When an AI system falls within the scope of the GDPR
The regulation is technology-neutral. It does not ask whether a system is a decision tree, a statistical model or a large language model; it asks whether personal data is processed. That threshold is crossed at three separate moments in the life of an AI application, and each of them needs its own analysis.
The first is training. If the training set contains information relating to identifiable people, assembling and using it is processing, and the fact that the output is a model rather than a database changes nothing about that. The second is inference. Every prompt, query or input record that contains personal data is a processing operation, and so is the output where it says something about an identifiable person. The third is logging. Inference logs, feedback records and evaluation datasets frequently hold more personal data than the training set, and they are routinely forgotten in the record of processing activities.
A common misconception is that a trained model is by definition anonymous. It is not. A model may retain personal data in a form that can be extracted, and whether it does is a question of fact to be assessed for each model. The European Data Protection Board reached that conclusion in its opinion on AI models at the end of 2024, and added a point that matters commercially: where a model was trained on unlawfully processed personal data, that unlawfulness can affect the lawfulness of deploying the model, unless it can be shown that the model itself is genuinely anonymous. The foundations of the regulation are set out in our introduction to data protection law and in our overview of the General Data Protection Regulation.
Who is responsible, and for which part
Responsibility follows the decision-making, not the technology. The party that determines the purposes and means of the processing is the controller; a party that processes only on documented instructions is a processor. In an AI chain these roles shift from step to step: the vendor of a model is usually a controller for its own development and a processor for the customer's use, and where both parties determine a purpose together they are joint controllers and must record how the resulting obligations are divided. The distinctions and their consequences are explained in our article on the roles of controller and processor, and the contractual side in our guide to the data processing agreement.
Two clauses decide most of these questions in practice. If the supplier is permitted to use customer input to improve its own model, it is acting as a controller for that purpose and you are disclosing personal data to it. If it relies on sub-processors or infrastructure outside the European Economic Area, the transfer rules in Chapter V of the regulation apply and a transfer mechanism plus an assessment is needed. Neither point can be resolved after go-live.
Automated decision-making and the right to human intervention
Article 22 of the GDPR is the provision that bites hardest on AI applications. It gives every person the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning them or similarly significantly affects them. Read as a prohibition rather than as a right to object, which is how the Court of Justice reads it, this means such decisions are not permitted at all unless one of three exceptions applies: the decision is necessary for entering into or performing a contract, it is authorised by Union or Member State law with suitable safeguards, or it is based on the explicit consent of the person concerned.
Three elements decide whether the article applies. The decision must be based solely on automated processing, which is not defeated by a token human sign-off; the person involved must have real authority and must actually weigh the outcome. The effect must be legal or similarly significant, which covers refusal of credit, rejection of a job application, termination of a service, refusal of an insurance claim and automated fraud flags that block a customer. And the decision must be about the individual, which is why generic pricing rules fall outside the article while individualised scoring falls inside it.
The Court of Justice has extended this further than many organisations assume. Where a company calculates a score about a person and a third party draws strongly on that score in deciding whether to enter into a contract, producing the score is itself an automated decision within the meaning of Article 22. In other words, the scoring provider cannot hide behind the fact that the formal decision is taken by its client. For Dutch organisations that buy in credit, fraud or risk scores, this changes the compliance question from whether they take automated decisions to whether their supplier does.
Where one of the exceptions applies, the safeguards are mandatory and specific: at minimum the right to obtain human intervention, the right to express one's point of view and the right to contest the decision. That means a working, staffed and documented procedure, not a mailbox. Special category data may only be used in such decisions on the basis of explicit consent or substantial public interest, and decisions of this kind may not be taken in respect of children.
What human oversight actually has to look like
Meaningful human involvement is the point at which most systems fail. A reviewer who sees only the model output and a recommendation, who has no access to the underlying data, who is measured on throughput and who overrides the system in a negligible share of cases is not exercising oversight in the sense the regulation requires. Effective oversight means the reviewer has the competence and authority to reach a different conclusion, sees the information the model used, records the reasons for confirming or departing from the outcome, and is monitored on how often and why departures occur. Those override statistics are also the first thing an investigator will ask for.
Transparency: what you must tell people about an algorithm
Where automated decision-making within the meaning of Article 22 takes place, the information duties in Articles 13 and 14 and the right of access in Article 15 require you to disclose the existence of the automated decision-making, meaningful information about the logic involved, and the significance and envisaged consequences of the processing for the person concerned. That obligation applies at collection and again on request.
Meaningful information about the logic does not mean publishing source code or model weights, and it does not mean a mathematical description that no lay person can follow. The Court of Justice has held that the person is entitled to an explanation of the procedure and the principles actually applied, described concretely enough to allow them to understand which of their personal data was used and in what way, so that they can check the accuracy of the data and challenge the decision. A description of the categories of data used, their relative weight, the thresholds applied and the effect that different values would have had is the kind of explanation that satisfies this.
Commercial confidentiality is a factor but not a trump card. Where a controller considers that giving the explanation would reveal a trade secret or the rights of others, it cannot simply refuse: it must provide the allegedly protected information to the supervisory authority or the court, which then balances the interests and determines what has to be disclosed. Building a system whose logic cannot be explained at all therefore creates a legal problem rather than a technical excuse. The scope of the access right itself is discussed in our article on the right of access under Article 15.
Transparency also has a plainer dimension. Privacy statements that describe purposes in language broad enough to cover anything are treated by the Dutch supervisory authority as a breach in their own right, and a significant part of its recent enforcement has concerned exactly that. Our guide to a privacy policy in the Netherlands sets out how to describe algorithmic processing in terms that are both accurate and readable, and the same principle applies to internal notices, for example where systems are used for employee monitoring or for camera surveillance in the workplace.
The data you feed the system, and the data it produces
A lawful basis is needed for each processing operation in the chain, and the basis for training is not automatically the basis for deployment. Consent, necessity for a contract and legitimate interests are the three realistic candidates, and each has to be assessed and recorded before processing starts. Where legitimate interests is relied on, the three-step assessment of interest, necessity and balancing has to be written down; a purely commercial interest can qualify, as the Court of Justice confirmed in a Dutch case in 2024, but only if the processing is genuinely necessary and the balance holds.
Two categories of input deserve separate treatment. Special categories of personal data, which include health data, biometric data used for identification, and data revealing ethnic origin, political opinions, religious belief, trade union membership or sexual orientation, may not be processed unless a condition in Article 9 applies; the practical routes are explicit consent and, in narrow cases, a substantial public interest laid down in law. The trap is inference: where a model derives a protected characteristic from ordinary data, the stricter regime applies even though nobody collected that characteristic. The specific rules for biometrics are set out in our article on biometric data and GDPR compliance.
The second category is scraped or publicly accessible data. The fact that information can be found online does not make its use lawful. You still need a basis, and the balancing test has to take account of the fact that the individual has no relationship with you, was not informed, and did not expect their data to be used for this purpose. Where data is obtained from a source other than the individual, the information duty in Article 14 applies, with only limited exemptions.
Output is where organisations most often go wrong. An inference produced by a model about an identifiable person is personal data about that person: a risk score, a suitability rating, a predicted diagnosis or a generated statement all fall within the regulation. It follows that such outputs must be accurate, must be corrected or completed where they are not, and are covered by the right of access. A model that produces incorrect statements about a named individual is not merely a quality problem; it is a rectification obligation, and where the incorrect statement is disseminated it can also give rise to a claim outside data protection law. The practical minimisation measures that reduce this exposure are the familiar ones: strip identifiers that are not needed, keep development and production data separate, restrict who can query the system, set retention periods for training data, feature stores and logs alike, and test whether the model can be made to reveal its training data. Where email traffic is used as an input, the specific issues are covered in our article on email and data protection under the GDPR.
Bias, discrimination and equal treatment
Data protection law and equal treatment law overlap here, and an organisation can comply with one while breaching the other. The GDPR requires processing to be fair and accurate and, through the impact assessment, requires the risk of discriminatory outcomes to be identified and mitigated. Dutch equal treatment legislation goes further: it prohibits direct and indirect distinction on grounds including race, nationality, religion, sex, sexual orientation, disability, chronic illness and age, in areas such as employment, the supply of goods and services and education. An algorithm that produces a systematically worse outcome for a protected group makes an indirect distinction, which is unlawful unless it can be objectively justified by a legitimate aim pursued through appropriate and necessary means.
The Netherlands Institute for Human Rights assesses complaints under that legislation and has published guidance on algorithmic discrimination in recruitment and selection. Its starting point is uncomfortable but correct: the burden of showing that a distinction is objectively justified rests on the party using the system, so an organisation that cannot explain why its model reaches different outcomes for different groups is in a weak position from the outset.
Bias enters through familiar routes. Training data reflects historical decisions that were themselves biased; the dataset under-represents part of the population; a feature acts as a proxy for a protected characteristic, as postcode frequently does for ethnicity; and optimisation for accuracy across the whole population conceals poor performance for a minority within it. There is a genuine tension in the law here, because testing for discriminatory effect often requires processing precisely the special category data the regulation restricts. The way through is to test on a controlled basis, with a documented legal basis, strict access limits and aggregated results, rather than to avoid testing and hope the question is never asked.
The Dutch experience with the risk indication system used to detect benefit fraud shows what happens when this is neglected. The court held the underlying legislation to be contrary to the right to respect for private life under the European Convention on Human Rights, because the system was insufficiently transparent and verifiable and could not be checked for discriminatory effect. The lesson that survives that judgment is that opacity is itself a legal defect, not a neutral technical characteristic. Where an algorithmic error leads to damage, the question of who answers for it is a separate one, discussed in our article on liability for errors made by artificial intelligence, and the criminal law dimension in our article on AI and criminal law.
Who supervises AI and algorithms in the Netherlands
The Autoriteit Persoonsgegevens is the supervisory authority for the GDPR in the Netherlands and applies the regulation together with the national implementing act, the Uitvoeringswet AVG, which fills in the choices the regulation leaves to Member States rather than adding a separate regime. Its powers run from a warning and a reprimand to an order subject to a penalty payment, a ban on the processing and an administrative fine of up to twenty million euros or four per cent of total worldwide annual turnover, whichever is higher. Beyond the GDPR it maintains a dedicated unit for the coordination of algorithm supervision and publishes periodic reports on algorithmic risks in the Netherlands, which are the clearest available statement of its expectations. What the authority does and how it works is described in our article on the Dutch Data Protection Authority.
Supervision of AI is deliberately shared. The Rijksinspectie Digitale Infrastructuur and the Autoriteit Persoonsgegevens act together as coordinating supervisors for the AI Act, while sectoral regulators keep their own competences: the financial supervisors for models used in banking and insurance, the healthcare inspectorate for medical applications and the media authority for platforms. The Netherlands Institute for Human Rights covers the equal treatment dimension. For an organisation this means one system can be assessed by several authorities on different grounds, which is an argument for a single internal file that answers all of them rather than for separate compliance tracks.
Public bodies carry an extra layer. Government organisations register the algorithms they use in the national algorithm register, and administrative decisions supported by an algorithm still have to satisfy the general requirements of Dutch administrative law that a decision be prepared with due care and be properly reasoned. A reasoning that amounts to the statement that the system produced this outcome does not meet that standard.
How the AI Act sits on top of the GDPR
The AI Act regulates AI systems as products, classified by risk, with obligations for providers and deployers. It is not a data protection instrument: it does not create a legal basis for processing personal data, and compliance with it says nothing about compliance with the GDPR. Where an AI system processes personal data, both regimes apply in parallel and in full.
The phasing matters for planning. The prohibitions on unacceptable practices, including social scoring by public authorities and untargeted scraping of facial images to build recognition databases, already apply, as do the obligations for general purpose AI models and the transparency duties for systems that interact with people or generate synthetic content. Deepfakes and AI-generated text published to inform the public have to be labelled. The high-risk regime was postponed by the digital omnibus package: obligations for the high-risk systems listed in Annex III, which include recruitment and selection, creditworthiness assessment, education and access to essential services, now apply from 2 December 2027, and obligations for AI that is a safety component of a product regulated under Annex I from 2 August 2028. The separate proposal for an AI Liability Directive has been withdrawn, so damage caused by an AI system is dealt with under ordinary Dutch contract and tort law and the European product liability rules.
For a system that both takes decisions about people and falls into the high-risk category, the two regimes reinforce each other: the GDPR requires a data protection impact assessment and human intervention on request, and the AI Act requires a risk management system, data governance, technical documentation, logging, human oversight by design and, for certain deployers, a fundamental rights impact assessment. Building them as one exercise is considerably cheaper than building them twice. The classification rules are set out in our guides to the EU AI Act, to high-risk AI systems, and in our practical guide for businesses; the wider background is covered in our article on the legal side of artificial intelligence in the EU.
The other digital rules that apply at the same time
Three further regimes are relevant to algorithmic systems. The Digital Services Act imposes transparency and risk obligations on online platforms that use algorithms for content moderation and recommendation, including an obligation to explain the main parameters of recommender systems and, for the largest platforms, to offer an option not based on profiling; we cover it in our articles on the Digital Services Act and Digital Markets Act and on what businesses must know about them. The Cyber Resilience Act sets security requirements for products with digital elements, phased in over the coming years, and requires security by design and vulnerability handling. And the Cyberbeveiligingswet, the Dutch implementation of NIS2 in force since 15 August 2026, imposes registration with the NCSC and incident notification within twenty-four and seventy-two hours on the entities within its scope, alongside and independently of the GDPR breach notification duty; see our overview of NIS2 and the Dutch Cybersecurity Act.
Governance: what has to be in the file
Accountability is an obligation of proof. It is not enough to be compliant; the controller must be able to demonstrate compliance, which in an algorithmic context means a file that matches the system as it is actually built and used. Five documents do most of the work.
The record of processing activities has to describe the data flows behind each model, including the training data, the inference inputs and the logs, rather than the departments that happen to own them. The lawful basis for each operation is recorded next to it, with the legitimate interests assessment attached where that ground is used. A data protection impact assessment is mandatory where the processing is likely to result in a high risk, which the regulation presumes for systematic and extensive automated evaluation of personal aspects on which decisions with significant effects are based, for large-scale processing of special categories, and for systematic monitoring of publicly accessible areas; the Dutch supervisory authority also publishes a list of processing operations for which an assessment is always required. Where a high residual risk cannot be mitigated, the authority must be consulted before the processing starts.
Alongside those sit the internal register of algorithms, which even private organisations increasingly keep because it is the only practical way to answer a supervisory request, and the procedures for handling requests from individuals: access, rectification, erasure, objection and the request for human intervention, each with a named owner and a deadline. A data protection officer is mandatory for public bodies and for organisations whose core activities involve regular and systematic monitoring on a large scale or large-scale processing of special categories, which covers a great many AI deployments.
None of this works as a paper exercise. The people who build the models and the people who assess the risk have to work on the same document, and the file has to be updated when the model is retrained or repurposed, because a materially changed system is a new processing operation. How this fits into a wider compliance structure is discussed in our articles on types of legal compliance and on the corporate governance framework, and the Dutch data protection landscape as a whole in our guide to Dutch data privacy laws.
Protecting the system itself: IP and trade secrets
The rules that protect an algorithm run in the opposite direction to the rules that require it to be explained, and the two have to be reconciled deliberately. Computer programs as such are excluded from patent protection, but an AI application that provides a technical solution to a technical problem can in principle be patented under the Dutch Patents Act and the European Patent Convention. Copyright protects the source code and other original expression under the Auteurswet, but not the underlying idea, method or mathematical technique. In practice the most valuable protection is the law on trade secrets: the Wet bescherming bedrijfsgeheimen, which implements the European trade secrets directive, protects information that is secret, has commercial value because it is secret and is subject to reasonable steps to keep it secret. That covers training data, model parameters and architecture, provided those reasonable steps are actually taken and documented. Enforcement runs through the civil courts, which can order prohibitions, the surrender of infringing goods and damages; it is not a matter for the competition authority.
Training data raises its own copyright question. The text and data mining exceptions in Dutch copyright law, which implement the European directive on copyright in the digital single market, permit mining of lawfully accessible works, but rightholders may reserve their rights, and providers of general purpose AI models are required under the AI Act to have a policy for complying with EU copyright law and to respect such reservations. Scraping is therefore constrained by two separate regimes at once, data protection and copyright, and clearing one says nothing about the other. Our guide to intellectual property law in the Netherlands and our article on the protection of trade secrets deal with these questions in detail.
The limit is the one noted earlier: confidentiality does not relieve you of the duty to explain an automated decision. Where the two collide, the supervisory authority or the court decides what must be disclosed, so the sensible design goal is a system whose logic can be described at the level of principles and factors without exposing anything that is genuinely secret.
Frequently asked questions
The questions below come up most often when Dutch organisations put personal data through an algorithm. Further material on related subjects is collected in our Dutch IT law guides.
What are the requirements for AI systems under the GDPR when processing personal data in the Netherlands?
Your AI systems must comply with all GDPR obligations when they process personal data in the Netherlands. You need to establish a lawful basis for processing, such as consent, contract performance, or legitimate interest.
You must ensure that personal data collection is limited to what is necessary for your specified purpose. Your AI applications cannot process more data than needed to achieve their stated goals.
The Dutch Data Protection Authority expects you to maintain comprehensive documentation of your data processing activities. You need to record what data you collect, why you collect it, and how long you keep it.
How does GDPR impact the development and deployment of AI algorithms that handle sensitive information?
You face stricter requirements when your AI systems process sensitive personal data categories. These include information about health, race, religion, political opinions, or biometric data.
You must obtain explicit consent or identify another valid legal ground before processing sensitive data through your algorithms. General consent is not sufficient for these data categories.
Your development process needs to include additional safeguards and security measures for sensitive information. You should implement encryption, access controls, and regular security assessments throughout your AI system’s lifecycle.
What measures must be taken to ensure transparency in AI decision-making involving Dutch residents’ personal data?
You must provide clear information about how your AI systems make decisions that affect individuals. Your users need to understand what data you collect and how your algorithms use it.
You should document your AI model’s logic and decision-making processes in plain language. Technical explanations alone do not satisfy GDPR’s transparency requirements.
When your AI system makes automated decisions, you need to inform affected individuals about the processing. You must explain the significance and potential consequences of these decisions for them.
What rights do individuals in the Netherlands have in relation to automated decision-making under GDPR?
Individuals have the right not to be subject to decisions based solely on automated processing that produces legal or similarly significant effects. You must offer human involvement in your decision-making process when these conditions apply.
Your users can request human intervention to review automated decisions that affect them. You need to establish procedures for handling these requests and providing meaningful human oversight.
Data subjects can challenge automated decisions and request explanations about the logic involved. You must be prepared to provide information about how your AI system reached specific conclusions about individuals.
In what ways does the GDPR require AI systems to be designed for data protection by default and by design in the Dutch context?
You must integrate data protection into your AI systems from the earliest development stages. Privacy considerations cannot be an afterthought added once your algorithm is complete.
Your default settings should provide the highest level of data protection possible. Users should not need to adjust settings to achieve basic privacy protections.
You need to implement technical measures like pseudonymisation and data minimisation throughout your system’s architecture. Your AI should only access and process the minimum data required for each specific function.
How can organisations demonstrate compliance with GDPR’s accountability principle when using AI in the Netherlands?
You must maintain detailed records of your data processing activities and AI system operations. Documentation proves that you have considered and addressed GDPR requirements.
You should conduct Data Protection Impact Assessments before deploying AI systems that pose high privacy risks. These assessments identify potential problems.
Your organisation needs to implement appropriate policies, training programmes, and oversight mechanisms for AI use. You should be able to show the Dutch Data Protection Authority evidence of your ongoing compliance efforts at any time.
How Law and More can help
Law and More advises Dutch and international organisations on the data protection side of AI: assessing whether Article 22 applies to a system, designing human oversight that stands up to scrutiny, drafting the explanation that has to be given to the people affected, carrying out impact assessments, negotiating processing agreements with model and platform providers, and responding to the Autoriteit Persoonsgegevens or to complaints and claims from individuals. If you are deploying an algorithm that takes or supports decisions about people, our privacy lawyers are available to review the file with you before a regulator does.
