AI chatbot GDPR compliance: the complete guide for 2026

Lawful basis, notices, retention, removal requests, DPAs and the AI Act disclosure rule: a practical GDPR guide for website AI chat.

Picture a support manager at a mid-sized software company, opening the shared inbox on a Monday morning. One email stands out. A visitor who used the website chat three weeks ago writes: "Please delete everything I typed into your chatbot, and tell me what you kept." She mentioned a health issue in that chat, while asking about accessibility features.

Who handles that? Where is the transcript? Did it go to the CRM, the AI provider, a Slack channel? How long do you have to answer? If nobody on your team can answer those questions in five minutes, this guide is for you.

I build AI chat agents for a living, so I have a stake in this topic, and I'll be clear about where our product fits and where it doesn't. I'm not a lawyer, and this isn't legal advice. What follows is a practical map of AI chatbot GDPR compliance, built from the regulation itself and regulator guidance, as of October 15, 2026.

Does this apply to you?

If you're in the EU, yes. If you're outside it, probably, as soon as EU visitors use your chat. Article 3(2) of the GDPR covers organisations outside the Union that offer goods or services to people in the EU, or monitor their behaviour there.

A website chat collects personal data almost by default. Names, emails and phone numbers, obviously. But also whatever people choose to type: their job, their employer, an order number, a complaint about a colleague. You can't fully control what visitors write. You can control what happens to it next.

1. Pick a lawful basis for each purpose

Article 6 lists six lawful bases. For website chat, three come up most: consent, steps taken at the person's request before a contract, and legitimate interests. Choose per purpose, not per tool.

• Answering a question someone asked you. Many companies rely on legitimate interests here, or on pre-contract steps when the visitor is asking about buying. If you use legitimate interests, write down the balancing test.
• Remembering a visitor for next time. This goes beyond what the visitor needs today. Asking them first is the cleaner route.
• Adding them to marketing. Treat this separately. A sales question is not a newsletter sign-up.
• Using transcripts to improve the bot. This is a separate purpose too, and it needs its own basis and its own line in your privacy notice.

This is the part where your lawyer earns their fee. The mistake I see most is one vague basis stretched over five purposes.

2. Tell people at the chat, not three clicks away

Article 13 says you must give people certain information "at the time when personal data are obtained". That includes who you are, why you process the data and on what basis, who receives it, any transfers outside the EU, how long you keep it, and their rights.

For a chat, the moment data is obtained is the first message. So a short notice in the chat window, with a link to your full privacy policy, does a lot of work. Something like: "This chat is recorded and may be processed by AI and our service providers to answer you." Then name the categories of providers in the policy: the AI vendor, your CRM, your live chat tool.

3. Tell people they're talking to an AI

This is the EU AI Act, not the GDPR, but it lands in the same chat window. Article 50(1) says providers must ensure that AI systems "intended to interact directly with natural persons" are designed so that people "are informed that they are interacting with an AI system". The exception is when it's obvious to a reasonably well-informed person. Article 50(5) adds that this must be "clear and distinguishable" and given "at the latest at the time of the first interaction".

When does it apply? Article 113 sets a general application date of 2 August 2026, and Article 50 isn't listed among the exceptions. The European Commission's AI Act overview confirms the transparency rules come into effect in August 2026. So, as of today, the chatbot disclosure duty is already in force.

One nuance. Law firm McCann FitzGerald notes that the Digital Omnibus on AI moved only the Article 50(2) deadline, which is about marking AI-generated content, to 2 December 2026 for systems already on the market. The chatbot disclosure in 50(1) kept its August date.

Strictly, 50(1) is a duty on the provider of the AI system. In practice, the visitor doesn't care who built it. Name the assistant as an AI in its greeting, and don't give it a human name and photo that suggest otherwise.

4. Collect less, and expect sensitive data anyway

Article 5(1)(c) requires personal data to be "adequate, relevant and limited to what is necessary". For chat, that means asking only for what the conversation needs. A product question rarely needs a phone number. A demo request might need a work email and a company name, not a home address.

Then there's the data you didn't ask for. Article 9 sets stricter rules for special categories, including "data concerning health", religious beliefs, trade union membership and sexual orientation. Visitors volunteer this all the time. Someone asking an HR assistant about leave may mention a diagnosis. Someone asking a retailer about returns may explain why.

You can't stop that entirely, but you can design around it. Tell the bot not to ask follow-up questions about health or similar topics. Don't feed transcripts into marketing tools without filtering. Limit who on your team can read full conversations. And be careful what you connect the bot to. A shared sales inbox used as a knowledge source can surface private details in answers.

5. Decide how long you keep chats, and enforce it

Article 5(1)(e) says personal data should be kept "for no longer than is necessary for the purposes". Article 13 then requires you to tell people the period, or the criteria used to set it.

Few companies write this down for chat. Pick a period per data type: transcripts, contact details, saved visitor profiles, CRM records, exports on someone's laptop. Then check that the tools actually delete on schedule. A retention policy that lives only in a PDF is not a retention policy.

6. Build a removal request process before you need one

This is the search that brought many of you here, so let's be concrete. Article 17 gives people the right to erasure in several situations, for example when the data is "no longer necessary" or when they withdraw consent. It has exceptions, such as keeping data "for the establishment, exercise or defence of legal claims". Article 15 gives a right of access, including "a copy of the personal data undergoing processing".

Under Article 12(3), you must respond "without undue delay and in any event within one month". You can extend by two further months for complex or numerous requests, but you must tell the person within the first month and explain why.

A workable process looks like this:

1. Accept requests anywhere. The UK regulator's guidance on erasure says a request can be made "verbally or in writing" and to any part of your organisation. That includes your chat. Log every request with the date received.
2. Verify identity, proportionately. The ICO says you can ask for more information if you have doubts, but only what you need. Matching the email used in the chat is often enough.
3. Find every copy. The chat platform, the CRM, helpdesk tickets, Slack threads, email notifications, exported CSV files.
4. Delete or send a copy. For access requests, an export of the transcript is a good start. For erasure, check the Article 17(3) exceptions first.
5. Tell recipients. The ICO says that where you've disclosed data, "you must contact each recipient and inform them of the erasure", unless that's impossible or disproportionate.
6. Handle backups honestly. The ICO's view is that backup data should be put "beyond use" until it's overwritten. Tell the person that's what will happen.
7. Confirm in writing, within the deadline.

7. Get a DPA with your chat vendor

For your website chat, you're usually the controller and the chat vendor is your processor. Article 28 requires a binding contract, the data processing agreement. Among other things, it must require the processor to act only on your documented instructions, help you respond to data subject requests, and delete or return the data when the service ends.

It also covers sub-processors. Your vendor needs your authorisation to use them, and with general authorisation you must be told about changes so you can object. For an AI chat, the AI model provider is usually one of them. Ask for the list.

8. Know where the data goes

Transfers outside the EU need a legal mechanism. For the United States, the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework, which covers US companies that participate in it. Elsewhere, the usual tool is the Commission's Standard Contractual Clauses, modernised in June 2021.

Ask your vendor three questions. Where are transcripts stored? Where does the AI processing happen? Which transfer mechanism covers each hop?

9. Keep a human in the loop for decisions that matter

Article 22 gives people the right not to be subject to "a decision based solely on automated processing" with legal or similarly significant effects. Most website chats don't make those decisions. Answering a pricing question isn't one.

But some get close. A chat that pre-screens job applicants, approves credit, or rejects a warranty claim could cross the line. Where it does, the safeguards include the right to get human intervention and to contest the decision. The simplest design rule: let the AI collect and route, and let a person decide.

If you want a deeper reference on risks specific to language models, the EDPB published an expert report, AI Privacy Risks & Mitigations: Large Language Models, with a customer-query chatbot as one of its use cases. Note that the EDPB says it isn't its official position.

The AI chatbot GDPR compliance checklist

1. List every purpose your chat data serves, and a lawful basis for each.
2. Show a short privacy notice in the chat window, linked to your full policy.
3. Say clearly that the visitor is talking to an AI, from the first message.
4. Ask only for the details each conversation needs.
5. Instruct the bot not to probe health or other special-category topics.
6. Set a retention period for transcripts, profiles and CRM records, and check deletion actually runs.
7. Write a removal and access request process, with an owner and a one-month clock.
8. Sign a DPA with your chat vendor, and get its sub-processor list.
9. Confirm where data is stored and processed, and the transfer mechanism for each hop.
10. Keep a person in charge of any decision with significant effects.
11. Restrict who on your team can read and export full transcripts.
12. Review the setup when you add an integration, a knowledge source or a new workflow.

How we handle it at AtomicX

Here's what our chat does today, taken from our own published pages. Where something isn't documented, I've left it out.

Roles and the DPA. Our data processing agreement page says it plainly: "You are the controller of your visitors' data. Atomic Motion Ltd. is the processor." EU data stays in Frankfurt and North-American data in Toronto, and Enterprise plans can pin residency to either region. The sub-processor list is available on request, and you can request a signed DPA by email.

Notice before the first message. The Chat Disclosure setting shows a short notice before a conversation starts. Visitors must click I agree before they can type, and nothing they type is sent until they do. The time and the exact text they accepted are saved, and the conversation shows a Disclosure accepted badge. Our help page is honest that this "doesn't replace your privacy policy or legal advice."

Remembering visitors only with consent. With Remember Returning Visitors, the chat asks before saving contact details, with Yes, remember me or No thanks. A visitor can click Forget my details later, and everything saved for them is deleted right away. If they email you instead, open the conversation and click Delete saved visitor details. Saved details unused for 13 months are deleted automatically. One honest limit: forgetting details never deletes a HubSpot contact. It adds a note so your team can decide.

Answering access requests. On the Conversations page you can search by a visitor's name or email, then use Export CSV or Export JSON. Exports contain message text only, without IDs, timestamps or profile details.

Keeping page data out by default. Use Page Content for AI Answers is off by default for customer widgets. If you turn it on, form values are excluded, and your developer can mark private sections so they're never shared with the AI.

Humans in control. Your team can take over any active conversation from Live monitor, and the AI stops replying.

Security and training. Our security posture page describes AES-256 encryption at rest, TLS in transit, role-based access with least privilege, and annual third-party penetration tests. It also states that we do not use client data to train AI models.

Removal requests. Anyone can use our GDPR removal request page, and we answer within one month. If someone chatted on a customer's website, that business controls the data, so we pass the request on and help them act on it. That's the controller-processor split working as it should.

The bigger pattern

To be fair to every vendor, including us: no chat tool makes you compliant. It can make the right thing easy, or hard. The decisions about lawful basis, retention and who reads what stay with you.

The companies that handle this well treat chat like any other system that touches customers. They map it, write down who owns it, and test the deletion path before a real request arrives.

So try it this week. Ask a colleague to send a removal request about a test chat, and time how long it takes to find every copy. If you'd like to see how our chat handles it, Book a 20-minute demo, or read our DPA first.