Chatbot GDPR Compliance: What Your Business Needs to Get Right

Summary

The GDPR applies whenever a chatbot processes personal data, including what users type. The deploying business is usually the controller and needs a lawful basis, clear notice before the chat starts, minimal data collection, security measures, and a DPIA where risk is high. The AI Act separately requires users to be told they are talking to an AI.

This guide covers roles, lawful basis, notices, minimisation, retention and rights, DPIAs, children, security, human oversight and the AI Act. It applies to the GDPR, and the UK GDPR follows the same core rules.

Key Takeaways

• A chatbot is processing personal data in the same legal sense as a web form. Every category of data it collects needs a lawful basis, and consent is one of six options, not the default for everything.

• The business that deploys a chatbot is usually the controller, even when a vendor supplies the technology. Article 28 requires a processing agreement, and the deployer stays responsible if the vendor falls short.

• A self-declared age field does not settle the question of children. Article 8 requires reasonable efforts to verify parental authorisation where consent is the basis, and the user is under the age threshold, taking available technology into account.

The GDPR Applies to Any Chatbot That Processes Personal Data

A chatbot that collects a name, an email address, or a health detail processes personal data under the same rules as a sign-up form. The conversational format does not change the analysis.

The chatbot’s purpose doesn’t matter either. A support bot, a lead-generation bot and a wellness or companion bot are all covered. The more sensitive the data, the more scrutiny the setup needs.

Personal data also reaches chatbots indirectly. Users paste in order details, medical symptoms, employer names and other people’s information. A chatbot cannot assume it will only receive what the script asks for, so the design must account for whatever users type.

The Deploying Business Is Usually the Controller

The business that decides why and how the chatbot is used is normally the controller. The platform vendor is usually the processor, acting on the controller’s instructions. Choosing a convenient vendor does not move the compliance duty to it. Our guide to controllers and processors explains how to distinguish the roles.

Article 28 requires a written agreement between them. Check three things in it:

• whether the vendor uses chat content to train or improve its own models, which can make it a separate controller for that use;

• which sub-processors and locations are involved, and how you are told about changes; and

• how the vendor helps with data subject requests and breach notification.

If the chatbot runs on a third-party language model, the questions in our guide to LLMs and the GDPR apply as well. If the vendor or its model sits outside the EEA, you also need a Chapter V transfer route. Our guide to sub-processors covers the contract chain.

Each Purpose Needs a Lawful Basis Before Launch

Article 6 gives six lawful bases. Chatbots most often rely on contract or consent, and sometimes legitimate interests.

• Contract: the data is needed to deliver what the user asked for, such as an order number to look up a delivery.

• Consent: the user makes a genuine, active choice, and knows what they are agreeing to before the chat begins. It suits optional uses such as marketing follow-up.

• Legitimate interests: a documented balancing test supports uses such as security monitoring or service improvement, with the user’s expectations taken into account.

Choose the basis before the chatbot goes live. Working it out after a regulator asks is too late, and processing without an identifiable basis is unlawful, no matter how well the data is protected afterwards.

Special category data also needs an Article 9 condition. A wellness bot that collects health information will usually rely on explicit consent under Article 9(2)(a), because the other conditions rarely fit a consumer service.

A Short Notice Before the Chat Starts Meets the Transparency Duty

Articles 13 and 14 require you to tell people what you do with their data. For a chatbot, a link to a long privacy policy is a weak way to do it.

A short notice shown before or at the start of the conversation works better. It should say:

• who the controller is;

• what data the chat will collect and why;

• whether conversations are kept, for how long, and who can see them; and

• where to find the full privacy notice and how to use their rights.

The same point applies to AI disclosure, covered below. People shouldn’t have to guess who they are talking to or what happens to what they type.

Data Minimisation Shapes the Conversation Design

A chatbot should ask only for what it needs to complete the task. A delivery query needs an order number, not a purchase history. Our guide to data minimisation covers the principle.

Three design choices help:

• ask for details at the point they become necessary, not upfront;

• warn users not to enter sensitive details the bot does not need; and

• set retention periods for chat logs, and delete or anonymise them when the purpose ends.

Keep a record of what the chatbot stores, where it stores it, and who can access it. That record is what you show if a regulator or a user asks.

Chat Data Can Only Be Used for the Purpose It Was Collected For

Under Article 5(1)(b), a support conversation cannot later be used for marketing analysis without a lawful basis for that new use. The same applies to using chat logs to train a model.

Users have the rights in Articles 15 to 22. They can request a copy of their chat history, request corrections, request deletion, and object to certain uses. Where consent is the basis, they can withdraw it, and withdrawal must be as easy as giving it.

Build these routes into the product. A setting inside the chat interface is easier to use than an email address buried in a policy. Our guide to withdrawing consent covers the process.

Chat widgets that set cookies or use similar technologies on the user’s device also fall under cookie rules. See our GDPR cookies guide.

A DPIA Is Required Where the Chatbot Is Likely to Create High Risk

Article 35 requires a DPIA for processing likely to result in a high risk to individuals. Article 35(3) lists three cases: systematic and extensive evaluation of personal aspects based on automated processing, including profiling; large-scale processing of special category data; and systematic monitoring of a publicly accessible area on a large scale.

A chatbot that profiles users, scores them, or handles health or other sensitive data at scale will usually meet one of those. Supervisory authorities also publish lists of processing that needs a DPIA, so check the list for your country. Many chatbots processing ordinary support data will not need one, though an internal risk review is still good practice.

Where a DPIA is needed, it should cover:

• what data the chatbot collects and why;

• whether the collection is proportionate to the purpose;

• the risk of false or harmful outputs about people;

• how age checks work in practice; and

• the safeguards in place, with a review whenever the chatbot’s functions change.

Our guide to the data protection impact assessment explains the steps.

Children Need Reasonable Age Checks, Not a Single Form Field

Article 8 sets the rule for consent-based services offered directly to children. The default age is 16, and Member States can lower it to no less than 13. Below the threshold, the holder of parental responsibility must give or authorise consent. The controller must make reasonable efforts to verify that, taking available technology into account.

A self-declared date of birth, with no check and no barrier to re-entering a different one, is a weak control, particularly for chatbots that handle emotional or behavioural data. The GDPR standard is reasonable efforts that fit the risk, so a stronger check is expected where the service is more likely to reach and affect children.

The EDPB adopted Statement 1/2025 on age assurance on 11 February 2025. It sets out age assurance principles that respect data protection, including proportionality and data protection by design. Use the least intrusive method that works for your risk level.

Practical steps include:

• stopping a stored date of birth from being edited without re-verification;

• designing the chatbot’s content and defaults for the youngest likely user; and

• deciding whether the service should be open to children at all.

See our guides to children’s data and the digital age of consent.

Security Measures Must Match the Risk

Chat conversations often contain sensitive details volunteered informally. Article 32 expects measures appropriate to the risk. For chatbot data, that normally means:

• encryption in transit and at rest for stored conversation logs;

• access controls limiting who inside the organisation can read chat histories;

• logging and monitoring of access to chat data; and

• regular security testing, not a single review at launch.

Regulators assess whether the combination of measures fits the risk, not whether any single measure exists. Staff and vendors with access need confidentiality duties and training. If chat data is exposed, our guide to data breach reporting covers the notification steps.

Human Oversight Matters Where Chatbot Output Affects People

Article 22 gives people the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects. Where a decision is based on contract or explicit consent, the controller must at least provide the right to human intervention, to express a point of view, and to contest the decision.

A chatbot that decides eligibility for a service, a price or a claim can fall within that. A chatbot that only answers questions usually does not. Where output could affect someone’s rights or wellbeing, such as spotting a user in distress, put a human in a position to review and override it.

Generative chatbots need extra care because their outputs are less predictable than a scripted flow. Test them for false statements about real people, and keep a route for users to report errors.

The AI Act Adds a Disclosure Duty for Chatbots

Article 50(1) of the AI Act requires providers to design AI systems that interact directly with people so those people know they are interacting with an AI system, unless this is obvious to a reasonably well-informed, observant, and circumspect person in the circumstances. Under Article 113, the Regulation applies generally from 2 August 2026.

The disclosure duty rests with the system provider. If you build or white-label a chatbot, you may be the provider. If you only deploy a vendor’s product, check what the vendor does and make sure the chat shows a clear AI notice anyway. Include the disclosure in the same short notice that covers data use.

Law-firm commentary says the 2026 AI omnibus left Article 50(1) in place and only delayed machine-readable marking of AI content for existing systems. Check the final text if that point affects you.

A Review Schedule Keeps Compliance Current

Chatbot compliance changes when the product, vendor, or law changes. Set a review at least once a year, and after any change to the model, vendor, data use, or audience. At each review, check the notice, the retention period, the vendor agreement, the DPIA, and the AI disclosure. Our GDPR consultants can run that review for you.

Conclusion

A compliant chatbot has a lawful basis for each use, a short notice before the chat starts, a vendor agreement that matches how the tool is used, and controls on what it collects, keeps and says. Children, sensitive data and automated decisions need extra care, and the AI Act adds a disclosure duty.

We are updating this guide to correct how the GDPR treats age checks and DPIAs, and to add the AI Act duty to tell users they are talking to an AI. Review your live chatbot against these points before your next release.

Frequently Asked Questions

Is the Chatbot Vendor Responsible for GDPR Compliance Instead of the Business?

No, not by default. The business deploying the chatbot is usually the controller and carries the main responsibility. The vendor is usually a processor under an Article 28 agreement, and choosing a reputable vendor does not remove the deployer’s own duties.

Does a Chatbot Need Consent for Every Conversation?

No. Consent is one of six lawful bases, and many support and transactional chats can rely on contract. Consent is needed for uses beyond the immediate request, such as marketing, and explicit consent is usually needed for special category data.

What Should a Chatbot Privacy Notice Say?

It should state who the controller is, what data the chat collects, why, how long it keeps it, and how to exercise data subject rights. Show it before or at the start of the chat, in plain language, with a link to the full privacy notice.

Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.