A chatbot deployed in the Netherlands sits at the intersection of three bodies of law: copyright (the Auteurswet and the EU copyright directives), data protection (the GDPR) and the EU Artificial Intelligence Act, Regulation (EU) 2024/1689. Each of those regimes attaches duties to the organisation that puts the chatbot in front of users, not only to the developer that built it. Chatbots, copyright and compliance are therefore one subject rather than three, and the work starts with a written classification of what your chatbot does, on whose data it was trained, and what it is allowed to decide on its own.
The three legal regimes that apply to every chatbot
There is no single Dutch AI statute. What exists instead is a stack of rules that were mostly written before generative AI became a commodity, plus one regulation that was written specifically for it. For a business in the Netherlands the practical consequence is that you cannot answer the question of whether your chatbot is lawful by looking at one text. You have to run the same system past three separate tests, and a pass on one says nothing about the others.
Copyright governs the material that went into the model and the material that comes out of it. The Dutch Auteurswet, as amended to implement the DSM Directive, contains a specific exception for text and data mining, and that exception is the hinge on which most training-data arguments turn. Data protection governs everything the chatbot learns about the person typing into it, and here the GDPR applies in full the moment a conversation can be traced back to an identifiable individual. The AI Act governs the system itself: what it may be used for, what has to be disclosed, what documentation must exist and who has to be able to switch it off.
These three regimes have different supervisors, different sanctions and different timelines. That matters more than it sounds. A chatbot that is impeccable on privacy can still be unlawful because it was trained on scraped material subject to a valid opt-out, and a chatbot with a clean data lineage can still breach the AI Act if it never tells the user it is a machine.
What each regime actually asks of you
Reduced to its core, each of the three asks a different question. Copyright asks whether you had permission, or a statutory exception, for every act of reproduction. Data protection asks whether you have a lawful basis under Article 6 GDPR, whether you told the data subject what you were doing, and whether you collected no more than you needed. The AI Act asks where the system sits on its risk scale and whether the obligations attached to that tier have been met and documented.
Answering those three questions in writing, before deployment, is what turns an AI project from an open-ended exposure into a manageable one. It is also, in practice, the first document a regulator will ask to see.
Key legal challenges for AI chatbots in the Netherlands
| Legal area | Primary concern | Governing rules |
|---|---|---|
| Data protection | Processing conversational data without a lawful basis, or retaining it longer than necessary. | GDPR, supervised by the Autoriteit Persoonsgegevens |
| Copyright | Reproduction of protected works during training, and outputs that reproduce a protected work in recognisable form. | Auteurswet, in particular the text and data mining exceptions in articles 15n and 15o |
| Transparency | Users not being told that they are dealing with a machine, or synthetic output not being marked as such. | Article 50 of the AI Act, which already applies |
| Liability for outputs | Who answers for advice, statements or decisions the chatbot produces. | General Dutch civil law: contract, tort under article 6:162 BW, and product liability |
The fourth row deserves a word of warning, because it is the one most often misdescribed. The European Commission withdrew its proposed AI Liability Directive, so there is no harmonised European liability regime for AI damage on the horizon. Claims about a faulty chatbot answer will be decided under ordinary Dutch civil law: the contract with your customer, the general duty of care in article 6:162 BW, and the revised product liability rules. We set out how that works in practice in our article on liability for errors in AI-generated content.
Copyright and the data your model was trained on
Training a large language model involves copying protected works on an industrial scale. Under Dutch law that copying is a reproduction within the meaning of the Auteurswet, and it is unlawful unless the rightholder gave permission or a statutory exception applies. There is no Dutch or European equivalent of the American fair use doctrine, and arguments borrowed from United States litigation do not transfer to a Dutch courtroom.
The exception that matters is text and data mining. Article 15n of the Auteurswet permits research organisations and cultural heritage institutions to mine works they have lawful access to, for the purposes of scientific research. Article 15o is the broader one: it permits anyone to carry out text and data mining on lawfully accessible works, but only where the rightholder has not expressly reserved that use. That reservation, commonly called the TDM opt-out, must be made in an appropriate manner, and for material published online it must be machine-readable.
The practical effect is a two-step test. Did the trainer have lawful access to the material, and had the rightholder reserved its use? If the answer to the second question is yes and the material was mined anyway, the exception falls away and the reproduction was an infringement.
Where the deployer picks up the risk
Businesses often assume that training-data problems are the developer’s problem. That is only half right. The organisation that deploys a chatbot and publishes what it produces performs its own acts of reproduction and communication to the public, and it does so in its own name. Three failure points recur.
- Training without a valid basis. The model was built on material covered by a TDM reservation, or on material the developer never had lawful access to in the first place. The exposure sits with the developer, but a claim can follow the output downstream.
- Output that reproduces a protected work. If the chatbot returns text, code or an image that is recognisably a copy of a protected work, publishing it is a fresh infringement by whoever publishes it. Style is not protected; a substantial part of a concrete work is.
- Contracts that do not carry the risk back. Many AI licences cap liability at the annual fee and exclude third-party intellectual property claims altogether. Read the indemnity clause before you read the marketing material.
Ownership of what the chatbot produces is a separate question again. Dutch copyright protects works with an own, original character that bear the personal stamp of the maker, and that requires human creative choices. Purely machine-generated output, produced from a prompt without further human authorship, is unlikely to attract copyright at all, which means neither you nor anyone else can stop a competitor from reusing it. Our guide on when content is considered public under copyright law works through the underlying principles.
The realistic mitigation is contractual and evidential rather than technical. Ask the vendor, in writing, which datasets were used, whether TDM reservations were honoured, and what indemnity is offered for third-party claims. Keep the answers. A vendor that will not put its data sourcing in a contract is telling you something about its own confidence.
How the AI Act classifies a chatbot
The AI Act does not regulate technology; it regulates purpose. The same underlying language model can be minimal-risk in one deployment and high-risk in another, and the classification depends entirely on what you use it for. That is why the first compliance step is a written classification, and why copying a classification from a vendor datasheet is not enough.
The regulation sorts systems into four tiers. Practices in the unacceptable tier are prohibited outright: article 5 bans, among other things, manipulative techniques that materially distort behaviour and cause significant harm, exploitation of vulnerabilities linked to age or disability, social scoring, and emotion recognition in the workplace and in education. These prohibitions have applied since 2 February 2025 and we discuss them separately in our article on prohibited AI practices.
The high-risk tier is the heavily regulated one that remains permitted. A chatbot lands there when it is used in one of the areas listed in Annex III, which include recruitment and selection, decisions on access to essential private and public services such as credit or benefits, education, and law enforcement, or when it functions as a safety component of a product covered by the harmonisation legislation in Annex I. The obligations that follow are set out in our guide to high-risk AI systems under the AI Act.
The limited-risk tier is where most customer-facing chatbots sit. There is no conformity assessment, no registration and no notified body, but there is a transparency duty, and it is not optional. The minimal-risk tier covers everything else and carries no specific obligations beyond voluntary codes.
What already applies, and what has been postponed
The AI Act entered into force on 1 August 2024 and phases in over several years, and the phasing was changed by the European Commission’s digital omnibus package. Three things are true today and are frequently reported wrongly.
First, the prohibitions in article 5 and the AI literacy duty in article 4 have applied since 2 February 2025. Second, the obligations for general-purpose AI models, the layer that most commercial chatbots are built on, have applied since 2 August 2025. Third, the transparency obligations in article 50 apply as well. What the omnibus postponed was the high-risk regime and nothing else: the rules for Annex III systems now start on 2 December 2027, and those for Annex I systems on 2 August 2028.
The postponement covers the high-risk regime only. If your chatbot is prohibited, or falls under the general-purpose model rules, or simply needs to disclose that it is a machine, the deadline has already passed.
Enforcement is backed by fine ceilings expressed as a share of worldwide annual turnover: the highest tier, reserved for breaches of the prohibitions, and a lower general tier for most other infringements. National supervisors set the actual amount within those ceilings.
AI Act risk tiers for chatbot applications
| Risk level | Chatbot example | Key obligation |
|---|---|---|
| Minimal | A bot that answers questions about opening hours or article categories. | No specific obligations; voluntary codes of conduct. |
| Limited | A customer service bot handling returns and order queries. | Disclose that the user is interacting with an AI system, and mark synthetic output. |
| High | A bot that pre-screens job applicants or assesses eligibility for credit. | Risk management, data governance, technical documentation, logging, human oversight and conformity assessment. |
| Unacceptable | A bot that exploits the vulnerabilities of a defined group, or infers emotions of employees at work. | Prohibited; may not be placed on the market or used in the EU. |
The transparency duty in article 50
Article 50 of the AI Act requires that a person interacting with an AI system is informed of that fact, unless it is obvious to a reasonably well-informed user in the circumstances. The disclosure has to be given at the moment of the first interaction, in clear and distinguishable form. A line in a privacy statement three clicks away does not satisfy it.
The same article requires providers of systems that generate synthetic text, audio, images or video to mark that output in a machine-readable way, and requires deployers who publish AI-generated text on matters of public interest to disclose that it was artificially generated, unless the text underwent human review with editorial responsibility. For a business running a chatbot on its own website the practical checklist is short: a visible statement at the start of the conversation, a clear route to a human, and no interface design that implies the user is talking to a named employee.
Transparency also has a Dutch consumer-law dimension. Presenting a machine as a person, or letting a chatbot make claims a salesperson could not lawfully make, can amount to a misleading commercial practice under the rules in Book 6 of the Burgerlijk Wetboek, quite apart from the AI Act.
Personal data in the conversation: the GDPR layer
The GDPR applies to a chatbot as soon as it processes data relating to an identifiable person, and conversational logs almost always do. The lawful basis is the first thing to fix: consent under article 6(1)(a), performance of a contract under article 6(1)(b), or legitimate interests under article 6(1)(f), each with different consequences for what you may then do with the transcript.
Three points cause most of the trouble in practice. Retention is one: transcripts are frequently kept indefinitely because nobody set a period, which breaches the storage limitation principle in article 5(1)(e). Secondary use is another: using live conversations to fine-tune a model is a new purpose that needs its own assessment and, usually, its own information notice. The third is special category data. A chatbot in a healthcare, insurance or HR setting will collect health or other sensitive data whether or not you designed it to, and article 9 prohibits that processing unless a specific exception applies.
Where the chatbot runs on a third-party platform, that platform is normally a processor and a data processing agreement under article 28 is mandatory. Getting the roles right is not a formality; it determines who must answer a data subject request and who is liable for a breach. Our articles on the distinction between controller and processor roles under the GDPR and on using AI in a Dutch business set out the analysis.
A data protection impact assessment under article 35 is required where processing is likely to result in a high risk, and the list published by the Autoriteit Persoonsgegevens makes clear that large-scale automated evaluation of individuals belongs in that category. If your chatbot profiles users, assume you need one. Non-compliance with the GDPR is sanctioned with fines of up to four per cent of worldwide annual turnover under article 83(5), and that ceiling has not changed.
Human oversight and the problem with opaque models
Article 14 of the AI Act requires that high-risk systems be designed so that natural persons can effectively oversee them while in use. The word that does the work is effectively. Oversight means the person can understand the system’s capacities and limits, remain alert to automation bias, interpret the output correctly, decide not to use it, and intervene or stop it.
A human clicking approve on a recommendation they cannot evaluate is not oversight in the sense of article 14, and it will not protect the organisation. The overseer needs the authority to overrule, the competence to judge, and the information required to do both. In practice that means naming the role, training the people in it, giving them access to the reasoning behind an output, and recording when they intervened.
There is a parallel duty in the GDPR that applies regardless of the AI Act tier. Article 22 gives a data subject the right not to be subject to a decision based solely on automated processing which produces legal effects or similarly significantly affects them. If a chatbot rejects an application, refuses a service or sets a price on a purely automated basis, article 22 is engaged and the organisation must offer human intervention, an explanation and a route to contest.
Automated decision-making and meaningful human oversight are separate tests under separate instruments. Passing the AI Act one does not exempt you from article 22 GDPR, and vice versa.
Bias is the failure mode that turns an oversight gap into a liability. A model trained on historical data reproduces historical patterns, and where those patterns track a protected characteristic the resulting decisions can amount to indirect discrimination under the Algemene wet gelijke behandeling. Testing for that before deployment, and documenting the test, is the only defence that works after the fact. We deal with the consequences in our article on liability for algorithmic bias.
What the Dutch supervisors are doing
Supervision of the AI Act in the Netherlands is still being built. The government has proposed a model in which existing sectoral regulators keep oversight of AI within their own domains, the Autoriteit Persoonsgegevens takes the areas where no obvious supervisor exists and runs a dedicated AI unit, and the Rijksinspectie Digitale Infrastructuur has a coordinating role alongside it. The implementing act, the Uitvoeringswet AI-verordening, went out for public consultation in April 2026 and has not yet been adopted, so the formal designation of powers and penalties is not final.
That does not mean there is no enforcement. The GDPR is fully applicable and the Autoriteit Persoonsgegevens has used it against AI deployments for years. The prohibitions in article 5 of the AI Act are directly applicable law regardless of when the Dutch implementing act arrives.
A worked example: voting-advice chatbots
The clearest Dutch illustration of what goes wrong came from the Autoriteit Persoonsgegevens itself. In its AI and algorithmic risks report of February 2025 the supervisor tested generative AI chatbots that were being used to give voting advice and found the results unreliable and skewed: the systems steered users towards a small number of parties and largely ignored the rest, regardless of the answers given. The AP advised the public not to use such chatbots for electoral decisions and pointed out that AI used to influence elections falls within the high-risk category of the AI Act. The findings are set out in the AP report on AI and algorithmic risks.
The lesson generalises beyond politics. A general-purpose model wrapped in a friendly interface does not become neutral because its operator intended it to be. Where the output influences a decision that matters, neutrality has to be tested and the test has to be documented, because after deployment the burden of showing that the system worked as claimed sits with the organisation that deployed it.
Building an AI governance framework that holds up
A governance framework is worth having only if it produces evidence. Regulators, counterparties and courts all ask the same question after something goes wrong: what did you know, when did you assess it, and what did you write down? Four elements do most of the work.
- Classification, reviewed. Record where each AI system sits under the AI Act and why. Repeat the assessment whenever the use case changes, because a customer service bot that starts screening applicants has moved tiers overnight.
- Data governance. Document the provenance of training and retrieval data, the licences behind it, and how TDM reservations were checked. On the personal data side, record the lawful basis, the retention period and the processing agreements.
- Documentation and logging. Keep the model version, the system prompt, the test results and the conversation logs, with retention periods that respect the GDPR. Without logs you cannot reconstruct what the system said on the day that matters.
- Oversight protocols. Name the people responsible, define when they must intervene, and give them the authority to stop the system. Record the interventions.
Contracts carry the rest. The agreement with your AI supplier should address data sourcing, intellectual property indemnities, the allocation of AI Act roles between provider and deployer, security, audit rights and exit. Those are ordinary commercial negotiating points, and they are far easier to win before signature than after an incident. Our IT law guides cover the surrounding contractual landscape.
Chatbots, copyright and compliance are not a one-off exercise. The high-risk regime arrives in stages up to 2028, the Uitvoeringswet will add national procedure and penalties, and the case law on AI outputs is only beginning. A framework that is reviewed annually and updated when the law moves is the difference between a defensible position and an improvised one.
Are you the provider or the deployer
The AI Act allocates almost all of its obligations by role, and the two roles that matter for a business buying a chatbot are provider and deployer. A provider develops an AI system and places it on the market or puts it into service under its own name; a deployer uses one under its own authority. Buying a chatbot off the shelf makes you a deployer, which is by far the lighter set of duties.
The trap is that a deployer can become a provider without meaning to. Article 25 of the regulation provides that a deployer takes on the provider’s obligations for a high-risk system if it puts its own name or trade mark on the system, makes a substantial modification to it, or changes the intended purpose in a way that turns a system into a high-risk one. White-labelling a third-party chatbot under your own brand, or repurposing a general customer service bot to sift job applications, is enough to make the switch.
That reallocation has real consequences. The provider carries the conformity assessment, the technical documentation, the quality management system, the registration in the EU database and the post-market monitoring. None of that can be assumed away by a contract clause, because the obligations are public-law duties owed to the supervisor, not private ones owed to the counterparty. A contract can shift the cost of a breach; it cannot shift the duty.
Deployers of high-risk systems have their own list: using the system in accordance with the instructions, assigning competent human oversight, ensuring input data is relevant, monitoring operation, keeping the logs, and informing workers and their representatives before a high-risk system is put to use in the workplace. That last point is easy to overlook and is exactly the kind of omission a works council will raise.
Confidentiality, trade secrets and professional duties
A risk that sits outside all three regulatory regimes, and causes more concrete damage than any of them, is staff feeding confidential material into a public chatbot. Client data, draft contracts, source code and unpublished financial figures entered into a consumer AI service leave the organisation’s control, and depending on the terms of service may be retained or used for further training.
Under Dutch law that can breach a confidentiality clause in a commercial contract, destroy the reasonable steps requirement that keeps information protected as a trade secret under the Wet bescherming bedrijfsgeheimen, and in regulated professions breach a statutory duty of confidentiality. It can also be a personal data breach requiring notification to the Autoriteit Persoonsgegevens within seventy-two hours of becoming aware of it, under article 33 of the GDPR.
The remedy is dull and effective: a written AI use policy that names which tools are approved, states plainly what may never be entered into an unapproved tool, and is embedded in the employment relationship so that a breach has consequences. Combine it with an enterprise arrangement that contractually excludes training on your inputs, and the exposure largely disappears.
What to do before you launch
Compliance work on a chatbot is sequential, and doing it in the right order saves most of the cost. Classify the system under the AI Act and write the classification down, with the reasoning. Map the personal data it will process, fix the lawful basis and the retention period, and carry out a data protection impact assessment if the processing warrants one. Put the article 28 processing agreement in place with the platform.
Then look at the data behind the model: ask the supplier what it was trained on, whether TDM reservations were respected, and what indemnity is on offer, and record the answers. Build the transparency disclosure into the interface itself rather than the footer. Name the person responsible for oversight and define when they intervene. Finally, test the system against the cases you are most afraid of, keep the results, and set a date to review the whole file.
Organisations that do this find that the exercise is bounded. The uncertainty in AI law is real, but it is concentrated in a few questions, mostly about training data and about liability for output, and the rest is ordinary compliance work that can be finished and filed.
Frequently asked questions
The questions below come up in almost every first conversation about deploying a chatbot. They are answered here at the level of principle; the analysis for a specific system always depends on what it does and who it does it to.
Who is liable if a chatbot infringes copyright?
The question of liability for copyright infringement by a chatbot is a tricky one, and the answer is that it's often a shared responsibility. Typically, the blame falls on both the AI developer who built the tool and the organisation that puts it to use. Under EU and Dutch law, developers can find themselves in hot water for using copyrighted material to train their models without getting the right permissions first.
At the same time, the business using the chatbot can be held accountable for any infringing content the AI churns out and distributes. To sidestep this risk, it’s vital that businesses push for transparency from their AI vendors about training data sources. Another crucial protective layer is securing solid indemnification clauses in vendor contracts.
Does the GDPR apply to data processed by chatbots?
Yes, without a doubt. If your chatbot handles any personal data from individuals in the EU—think names, email addresses, or even conversational data that could identify someone—the GDPR applies in full.
This immediately brings several core duties into play:
- You must have a clear, lawful reason for processing the data.
- You have to inform users exactly how their data is being used.
- You should only collect data that is absolutely necessary (data minimisation).
- You are required to respect user rights, including their right to see or delete their data.
Turning a blind eye to these responsibilities is not an option. Failing to comply can result in huge fines—up to 4% of your company's annual global turnover—and do serious damage to your reputation.
What is the first step to ensure our chatbot is compliant?
The single most critical first step is to conduct a thorough risk assessment based on the EU AI Act's framework. You need to figure out where your chatbot fits based on what it does and the potential harm it could cause. This process will place it into a category, such as minimal, limited, or high-risk.
For example, a simple FAQ bot that just answers basic questions will likely be seen as a low-risk tool with very few obligations. However, a chatbot used to screen job applicants, give out medical information, or offer financial advice would almost certainly be classified as high-risk. This classification is what dictates your specific legal duties around transparency, data governance, and human oversight, essentially giving you a clear roadmap for your entire compliance strategy.
Law & More advises businesses in the Netherlands on the legal side of AI deployment: classification under the AI Act, copyright and data sourcing, GDPR compliance and data processing agreements, governance documentation, and the negotiation of contracts with AI suppliers. If you are preparing to launch a chatbot, or want an existing one assessed against the rules that already apply, we are happy to look at it with you. Please contact us to discuss your situation.
