The Dutch Data Protection Authority has released two new resources intended to help organizations develop, purchase, implement, and use generative artificial intelligence without violating the General Data Protection Regulation.
Published on July 13, 2026, the materials include detailed GDPR guidance for organizations developing or introducing generative AI models and a practical implementation checklist for businesses, public bodies, privacy professionals, and project leaders evaluating generative AI systems.
The guidance reflects a broader change in how European regulators are approaching artificial intelligence.
Organizations are no longer being told only to “use AI responsibly.” Regulators are beginning to define what responsible implementation requires in practice: a documented purpose, a lawful basis for processing, data minimization, clear accountability, appropriate retention, data-subject rights, technical safeguards, vendor oversight, and evidence that privacy was considered before deployment.
The Dutch authority, known in the Netherlands as the Autoriteit Persoonsgegevens, or AP, makes one recommendation particularly clear:
Before using generative AI with personal information, determine whether the intended objective can be achieved without processing personal data at all.
That question may sound basic. In practice, it challenges how many organizations are currently adopting AI.
Companies are often purchasing generative AI products first and determining their privacy implications later. Employees begin experimenting with public chatbots. Departments upload internal records to test productivity features. Vendors add AI capabilities to existing software without a new privacy review. Personal information enters prompts, retrieval databases, logs, evaluation datasets, support records, and model-improvement pipelines before anyone has mapped where it goes.
The AP’s new framework reverses that sequence.
The privacy analysis should come first.
The Netherlands Moves From AI Principles to Operational Guidance
The AP has previously published its broader vision for the safe and responsible use of generative AI. The new materials translate those principles into more concrete expectations for organizations that build or use the technology.
One document is directed primarily at developers and organizations responsible for placing generative AI models into operation. It provides the AP’s initial interpretation of how the GDPR applies to the lawful development and deployment of those models.
The second resource is a practical tool for organizations considering the acquisition or use of generative AI. It is structured as a checklist that privacy professionals, project managers, information-security teams, procurement personnel, and other responsible parties can use to evaluate whether the organization wants, is able, and is legally permitted to use a proposed system.
This distinction is important because developers and deployers do not necessarily have the same responsibilities.
A company training or fine-tuning a model may determine what information enters the training process, how long it is retained, whether it is enriched from other sources, and how model outputs are evaluated.
An organization purchasing a generative AI tool may not control the underlying model, but it still determines how employees use it, what information is submitted, which business process it supports, who can access it, and whether its outputs influence decisions about individuals.
Both sides can process personal data. Both sides can create privacy risk. And both need a defensible compliance position.
Generative AI Is Not Exempt From the GDPR
The speed and novelty of generative AI can create the false impression that existing privacy law is unable to address it.
The Dutch regulator rejects that premise.
When generative AI development or use involves personal data, the GDPR applies. The organization must therefore satisfy the same core requirements that govern other forms of personal-data processing, including lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, retention controls, security, and accountability.
What makes generative AI difficult is not the absence of legal principles.
It is the complexity of applying those principles to systems that may process enormous datasets, generate probabilistic outputs, retain prompts, infer personal characteristics, reproduce training information, and involve several layers of developers, cloud providers, model vendors, application providers, and downstream users.
A generative AI system may process personal data through several distinct stages:
- Collection of model-training data
- Cleaning and preparation of datasets
- Labeling, enrichment, and annotation
- Model training
- Fine-tuning
- Model evaluation and red-team testing
- User prompts
- Uploaded files
- Retrieval-augmented generation databases
- Generated outputs
- Conversation histories
- Safety and abuse-monitoring logs
- Customer-support records
- Product analytics
- Model-improvement programs
Each stage may involve a different purpose, legal basis, retention period, data recipient, and risk profile.
An organization cannot conclude that its AI system is GDPR compliant merely because the final chatbot interface contains a privacy notice.
Start With the Purpose, Not the Product
The first practical question should not be, “Which AI tool should we purchase?”
It should be:
What specific problem are we trying to solve?
A clearly defined purpose is essential because an organization cannot properly evaluate necessity, proportionality, legal basis, data minimization, or retention without knowing why the processing is taking place.
“Improving productivity” is unlikely to be sufficiently precise by itself.
A more useful purpose might be:
- Summarizing internal policy documents
- Drafting first versions of customer-service responses
- Extracting defined fields from supplier contracts
- Assisting software developers with nonproduction code
- Translating public marketing content
- Searching an approved internal knowledge base
- Identifying recurring issues in pseudonymized support requests
The more specific the use case, the easier it becomes to determine what information is necessary and what controls should apply.
A general-purpose AI assistant deployed across an entire company creates very different risks from a narrowly configured tool that summarizes public documents.
Without a defined use case, organizations tend to overcollect data, grant unnecessarily broad access, and rely on generic vendor assurances rather than use-specific controls.
Can the Use Case Work Without Personal Data?
The AP advises organizations to begin by examining whether generative AI can be used without processing personal information.
This is one of the strongest practical recommendations in the new materials.
A company may be able to achieve its objective by using:
- Public information
- Synthetic data
- Anonymized records
- Templates with identifying fields removed
- Aggregated information
- Fictional test cases
- Locally processed data
- A closed knowledge base containing no personal information
- Redacted documents
- Pseudonymized records with separately protected identifiers
This does not mean every use of generative AI involving personal data is prohibited.
It means the organization should not process identifiable information merely because the AI system makes it convenient.
Under the GDPR’s data-minimization principle, personal information must be adequate, relevant, and limited to what is necessary for the stated purpose. The Court of Justice of the European Union has also emphasized that controllers may not collect personal data indiscriminately and that even initially lawful processing may become incompatible with the GDPR when information is no longer necessary.
For generative AI, that principle should influence system architecture.
If a model needs to summarize a contract, does it need the signatories’ names, email addresses, bank details, signatures, and home addresses?
If an AI assistant is testing customer-support workflows, does it need real customer conversations?
If a company is evaluating a résumé-screening feature, can it begin with synthetic candidate profiles rather than actual applicants?
Removing unnecessary personal information before it enters the system is generally more reliable than attempting to control every possible use after ingestion.
Developers Must Understand Their Training Data
The AP’s developer guidance addresses the collection, management, enrichment, cleaning, and retention of information used in generative AI development.
Training data creates some of the most difficult GDPR questions because it may be assembled from large and diverse sources.
A developer may use:
- Public websites
- Licensed datasets
- Customer information
- User-generated content
- Partner data
- Government records
- Data brokers
- Open-source repositories
- Internal communications
- Images, audio, video, or code
- Synthetic or machine-generated records
The fact that information is publicly accessible does not automatically remove it from the GDPR.
A name, photograph, online post, professional profile, opinion, location, or other information relating to an identifiable individual can remain personal data even when it was found on the open internet.
Developers therefore need to determine:
- Which personal data categories are present
- Where the information originated
- Whether it was collected directly or indirectly
- What purpose justified the collection
- Which lawful basis applies
- Whether special-category data is involved
- Whether individuals reasonably expected this use
- How inaccurate or outdated data is identified
- Whether data-subject rights can be honored
- How long source datasets and derived records are retained
- Whether training information can be removed or its influence mitigated
A large dataset is not inherently a compliant dataset.
Indirect Collection Creates a Transparency Problem
Generative AI developers often obtain information from sources other than the individuals concerned.
That creates an indirect-collection issue.
An individual may never have interacted with the model developer. The person may not know that a public profile, article, photograph, court document, social media post, or other record was included in a training or evaluation dataset.
The organization must assess what GDPR transparency obligations apply and whether providing individualized notice is possible or would require disproportionate effort.
This is not an invitation to ignore transparency.
When direct notice is not practical, organizations should consider other meaningful methods, including:
- Publicly accessible explanations of data sources
- Clear categories of information used
- Searchable opt-out or objection mechanisms
- Model and dataset documentation
- Contact channels for rights requests
- Explanations of retention and model-improvement practices
- Records supporting any claimed transparency exception
A vague statement that a model was trained on “publicly available information” does not explain what was collected, from where, for what purpose, or with what consequences.
Identifying the Correct Lawful Basis
Every processing operation involving personal data requires a lawful basis.
Generative AI does not create a separate legal basis under the GDPR.
Depending on the facts, an organization may consider consent, contractual necessity, compliance with a legal obligation, protection of vital interests, performance of a public task, or legitimate interests.
The choice cannot be made through a generic policy statement.
For example, a company may wish to rely on legitimate interests to analyze customer-support records for product improvement. It would need to identify the legitimate interest, show that the processing is necessary, and balance its interests against the rights and reasonable expectations of the individuals.
Contractual necessity is also frequently overstated.
Processing does not become necessary for a contract merely because an AI feature makes the service faster or more profitable. The organization must determine whether the processing is objectively necessary to deliver what the individual requested.
Consent presents different problems. It must be freely given, specific, informed, and capable of being withdrawn. In employment, education, healthcare, public-sector, or other power-imbalanced settings, consent may not be genuinely voluntary.
Organizations should document the lawful-basis analysis for each material processing activity rather than selecting one basis for the entire AI system.
Special-Category Data Requires Additional Protection
Generative AI can encounter information concerning health, race or ethnicity, religion, political opinions, trade-union membership, genetics, biometrics, sex life, or sexual orientation.
These categories receive heightened protection under the GDPR.
They may appear explicitly in prompts or source data, but they may also be inferred from seemingly ordinary information.
For example, a model could infer:
- A likely health condition from symptoms
- Religious affiliation from dietary practices
- Political opinions from online activity
- Ethnicity from names or language
- Sexual orientation from relationships or browsing context
- Disability from workplace accommodation records
Organizations must identify not only the fields they intentionally collect, but also the sensitive information the system may generate or infer.
A lawful basis under Article 6 is not sufficient by itself when special-category data is processed. An additional Article 9 condition must generally apply.
This is one reason broad, unrestricted employee use of public generative AI tools creates significant risk. A user may enter sensitive data before the organization has determined whether processing is permitted.
Privacy Must Be Built Into the System
The AP’s materials reinforce the GDPR requirement to implement data protection by design and by default.
For generative AI, privacy by design may involve:
- Preventing sensitive information from entering prompts
- Automatically redacting identifiers
- Separating account data from prompt histories
- Processing information locally where possible
- Limiting the model’s access to approved sources
- Disabling model training on customer inputs
- Applying short retention periods
- Encrypting prompts and outputs
- Restricting administrative access
- Creating tenant-level isolation
- Logging high-risk activity
- Testing for memorization and data leakage
- Providing deletion and correction workflows
- Preventing unauthorized data exports
- Configuring privacy-protective defaults
A policy that tells employees not to enter personal data is useful, but it is not privacy by design.
People make mistakes. They misunderstand classifications. They paste entire documents when only one paragraph is necessary. They use AI tools under time pressure.
Where feasible, technical controls should prevent prohibited processing rather than relying entirely on training and employee judgment.
Buying AI Does Not Outsource GDPR Accountability
The AP’s practical checklist is particularly relevant to organizations acquiring generative AI from outside vendors.
A customer may not have trained the model, but it still needs to understand the service it is introducing.
Before procurement, the organization should determine:
- Whether the vendor acts as a processor, controller, or both
- Whether customer prompts are used to train models
- Whether model improvement is enabled by default
- Which subprocessors receive information
- Where data is processed
- Whether international transfers occur
- How long prompts, outputs, and logs are retained
- Whether data can be deleted
- Whether the vendor supports GDPR rights
- Whether humans review customer content
- Whether the vendor can change its terms or model behavior
- Whether the service creates derived profiles
- Which security certifications and audit evidence exist
- How incidents are reported
- What happens when the contract ends
Vendor claims such as “enterprise grade,” “private,” or “your data is not used for training” should be verified against contractual terms and technical configuration.
Some vendors offer different protections depending on the subscription level, administrative setting, product feature, or region.
A statement that applies to an enterprise API may not apply to a free consumer chatbot operated by the same company.
Organizations Need an Approved AI Inventory
One of the greatest implementation risks is not the formally approved AI project.
It is the AI system that nobody reviewed.
Employees can access generative AI through standalone chatbots, browser extensions, meeting software, search engines, office applications, development tools, customer-service platforms, and features quietly added to existing vendor products.
An organization therefore needs an inventory that extends beyond tools purchased by the IT department.
The inventory should capture:
- Product and model name
- Vendor
- Business owner
- Intended purpose
- User population
- Personal data categories
- Special-category data
- Data sources
- Integrations
- Hosting location
- Retention
- Training and improvement settings
- Applicable lawful basis
- Risk classification
- Assessment status
- Approved controls
- Review date
- Material changes
- Exit plan
Without an inventory, the organization cannot reliably assess risk, respond to incidents, honor rights requests, or prove that approved controls apply.
A DPIA May Be Required
A Data Protection Impact Assessment is required under the GDPR when processing is likely to result in a high risk to individuals’ rights and freedoms.
Generative AI deployments may reach that threshold when they involve large-scale personal data, systematic profiling, sensitive information, vulnerable individuals, employee monitoring, automated decisions, or novel technology combined with significant consequences.
A DPIA should not be treated as a one-time form completed immediately before launch.
It should describe:
- The proposed processing
- Its purpose
- Necessity and proportionality
- Risks to individuals
- Technical and organizational controls
- Residual risks
- Responsible owners
- Consultation and approval
- Reassessment triggers
The assessment should be revisited when the model, use case, data, vendor, user group, integration, or decision-making authority changes.
Generative AI systems evolve quickly. A privacy assessment tied only to the product name may become outdated after a major model upgrade.
Data-Subject Rights Must Work in Practice
People may have GDPR rights involving access, correction, deletion, restriction, objection, and information about the processing of their personal data.
Generative AI can make those rights difficult to operationalize.
The organization may need to locate information across:
- Training datasets
- Fine-tuning datasets
- Prompt histories
- Uploaded documents
- Vector databases
- Logs
- User profiles
- Generated outputs
- Support systems
- Vendor environments
It may also need to determine whether inaccurate personal data can be corrected at the source, removed from a retrieval system, prevented from appearing in outputs, or addressed through another technical measure.
An organization should not wait for the first rights request to determine whether its AI provider can support one.
Rights-response capability should be evaluated during design and procurement.
The Checklist Should Become a Governance Gate
The AP’s implementation tool should not be treated as optional reading for the privacy department.
Its practical value is as a decision gate.
Before an AI system is approved, the organization should be able to answer three questions:
Do We Want to Use It?
Does the use case create genuine value? Is generative AI appropriate, or is a simpler and more predictable system available?
Can We Use It Safely?
Does the organization have the necessary data quality, security, expertise, human oversight, vendor controls, and monitoring?
May We Use It Lawfully?
Is there a defined purpose, lawful basis, transparency process, rights mechanism, retention plan, transfer solution, and appropriate protection for sensitive data?
A “no” or “not yet” answer should not necessarily end the project.
It should prevent deployment until the missing controls are resolved.
What Organizations Should Do Now
Organizations already using generative AI should not assume the AP’s guidance applies only to future projects.
They should review current deployments and identify gaps.
The immediate priorities should include:
- Creating a complete inventory of generative AI use.
- Identifying where personal data enters each system.
- Determining whether that information is necessary.
- Documenting the purpose and lawful basis.
- Reviewing vendor contracts and model-training terms.
- Confirming retention and deletion capabilities.
- Evaluating international transfers and subprocessors.
- Conducting or updating DPIAs where required.
- Restricting unapproved tools and high-risk inputs.
- Establishing recurring monitoring and reassessment.
The objective is not to stop productive AI use.
It is to prevent experimentation from becoming undocumented, uncontrolled processing.
The Captain Compliance Perspective
The Dutch regulator’s new guidance illustrates where AI compliance is heading.
Regulators are moving beyond general statements about trustworthy AI and asking organizations to produce evidence.
A company should be able to show:
- Which AI systems it uses
- Why each system is necessary
- What personal data it processes
- Which lawful basis applies
- What vendor receives the data
- How individuals are informed
- How long the data is retained
- Which controls protect it
- How rights are honored
- Who approved the deployment
- When the system will be reassessed
Captain Compliance helps organizations operationalize these requirements through AI inventories, privacy impact assessments, vendor reviews, control assignments, policy management, evidence collection, data-subject request workflows, and ongoing governance.
The AP’s message is not that generative AI and privacy are incompatible.
It is that organizations must stop treating privacy as a review performed after the technology has already been selected and deployed.
Generative AI can increase productivity, accelerate research, improve services, and support innovation. But the same scale and speed that create those benefits can also magnify privacy failures.
The appropriate response is not to remove innovation.
It is to install the guardrails before the system begins processing people’s information.
Frequently Asked Questions
What did the Dutch Data Protection Authority publish?
The AP published GDPR guidance for organizations developing or placing generative AI models into operation and a practical checklist for organizations seeking to purchase, implement, or use generative AI.
Does the GDPR apply to generative AI?
Yes. When the development or use of generative AI involves personal data, the organization must comply with the GDPR.
Should organizations avoid all personal data in generative AI?
Not necessarily. The AP recommends first determining whether the objective can be achieved without personal data. When personal-data processing is necessary, the organization must establish a lawful basis and apply appropriate safeguards.
Can publicly available information be personal data?
Yes. Information can remain personal data even when it is publicly accessible. Public availability does not automatically authorize its collection or use for AI training.
Is a privacy policy enough for an AI deployment?
No. Organizations also need operational controls involving purpose, legal basis, minimization, security, retention, vendor management, rights requests, and accountability.
Who is responsible when an organization purchases an AI tool?
Responsibility depends on the parties’ actual roles. The vendor may act as a processor, controller, or both. The purchasing organization retains responsibility for its own use of the system and cannot outsource GDPR accountability through procurement.
Does every generative AI project require a DPIA?
No. A DPIA is required when the proposed processing is likely to create a high risk to individuals. Many consequential, large-scale, sensitive, or profiling-related AI uses may reach that threshold.
What should an organization review before approving an AI vendor?
It should review data use, model-training terms, retention, deletion, subprocessors, international transfers, security, incident response, human access, audit evidence, contractual roles, and support for GDPR rights.
How does Captain Compliance support generative AI governance?
Captain Compliance helps organizations inventory AI systems, conduct privacy and AI impact assessments, review vendors, assign controls, preserve evidence, manage data-subject requests, and monitor AI deployments throughout their lifecycle.