# Are AI chatbots GDPR compliant? The four decisions that decide it

> By Lawrence Dauchy, Founder, DFYe. Published 2026-07-04. 10 min read. Guides.
> Source: https://dfye.com/blog/are-ai-chatbots-gdpr-compliant/
> Language: en

No chat product is compliant or non-compliant on its own. The configuration you choose, and the contract behind it, are what a regulator would actually look at.

**TL;DR.** GDPR does not mention chatbots anywhere. It governs personal data, and a visitor's message is personal data the moment it can be tied to a person, which a support conversation almost always can. Four decisions settle the question: who is the controller, who holds the model key, where the data goes, and what you told the visitor before they typed. Fines reach 20 million euro or 4% of worldwide annual turnover, whichever is higher.

AI chatbots are not GDPR compliant on their own, and they are not non-compliant
either. Compliance describes an arrangement rather than a piece of software, and four
decisions you make at install time decide yours: who the controller is, who holds the
model key, where the messages travel, and what the visitor was told before they
typed. GDPR does not mention chatbots anywhere in its ninety-nine articles. It
governs personal data, and a visitor's message is personal data the moment it can be
tied to a person, which a support conversation almost always can. The ceiling for
getting it wrong is **20 million euro or 4% of worldwide annual turnover**, whichever
is higher.

None of what follows is legal advice. It is the set of questions a competent advisor
will ask you, arranged so you can answer them before you are asked.

## Is a visitor's chat message personal data?

Almost always. The regulation defines personal data as information relating to an
identified or identifiable natural person, and a support conversation identifies
people constantly without anybody deciding that it should. An order number does it.
An email address does it. So does a delivery address, and so, awkwardly, does the
medical detail a customer volunteers while explaining why they want to return
something.

Even a message with none of those is rarely anonymous in practice. A question plus
an IP address plus a timestamp is usually enough to single somebody out, and
singling out is the test.

The mistake this leads to is specific and common: treating chat logs as a technical
artefact rather than as a record of people. The transcripts sit in a vendor's
dashboard, nobody writes them into the
[record of processing activities](https://gdpr-info.eu/art-30-gdpr/) that Article 30
asks for, and the first time anybody looks at them closely is during a subject
access request.

## Who is the controller and who is the processor?

You are the controller. The vendor is a processor. That is the arrangement in nearly
every chatbot installation, and it matters because it decides who carries which
obligation.

| Role | Who that usually is | What they owe |
|---|---|---|
| Controller | You, the site owner | The lawful basis, the notice, the retention decision, answering data subjects |
| Processor | The chat vendor | Acting only on your instructions, security, an Article 28 contract |
| Sub-processor | The model provider behind the vendor | The same duties, passed down, with your authorisation |
| Joint controllers | Rare here, and worth spotting | A shared arrangement, published, saying who does what |

You are the controller because you decided to run a chatbot, you decided which pages
it reads, and you decided what happens to the transcripts. That is what the
regulation means by determining the purposes and means, and no contract can move it
onto somebody else.

The practical consequence is that the
[Article 28 agreement](https://gdpr-info.eu/art-28-gdpr/) with your vendor is the
document carrying the weight. It has to exist in writing, it has to bind them to act
only on your instructions, and it has to say what happens to the data when you stop
paying. If a vendor's answer to "where is your DPA" is a link to a marketing page,
you have learned something.

## What is your lawful basis?

One of the six in [Article 6](https://gdpr-info.eu/art-6-gdpr/), and the reflex
answer is usually the wrong one.

Most people reach for consent. For answering a question somebody deliberately typed
into a support widget, consent is a poor fit: they have already asked, the
processing is what they wanted, and a consent banner in front of a support tool is
friction protecting nobody. Legitimate interest, or performance of a contract when
the visitor is an existing customer asking about their order, usually describes it
better.

Consent becomes the right basis the moment you do something with the transcript that
the visitor did not ask for. Marketing from it. Training a model on it. Enriching a
CRM profile with it. Those are separate purposes, and a purpose the visitor did not
come for is the one that needs asking.

Write down which basis you chose and why, once, in a paragraph. Doing that takes ten
minutes and is the difference between a considered position and a guess you will be
asked to defend later.

## Where do the questions actually go?

Further than most site owners assume, and the chain is worth drawing before you
install rather than after.

| Step | What is sent | What to ask your vendor |
|---|---|---|
| Visitor types | The message, an IP, a session id | Is the IP stored, and for how long |
| Widget to vendor | The message and your site id | Which region is it processed in |
| Vendor to model | The message plus retrieved passages | Whose account and key, and is it used for training |
| Answer stored | The full transcript | Retention period, and who can read it |

Row three is the one that decides most of this. If the vendor holds the model key,
your visitors' questions pass through the vendor's account before reaching the model
provider, and the list of parties holding a copy is longer than the pricing page
suggests. If you hold the key, the vendor is not in that path at all and your chain
is one party shorter.

Any hop outside the EEA is a transfer under
[Chapter V](https://gdpr-info.eu/art-44-gdpr/) and needs a basis. That is not a
prohibition and it is not rare; it is a thing you have to be able to describe. The
useful test is not whether a vendor says they are compliant. It is whether they can
tell you, without a sales call, which sub-processors are in the chain and where each
one sits. Our own position on that is on [the privacy page](/privacy/), and what you
are permitted to do with the software is in [the licence](/eula/).

## What do you have to tell the visitor?

Enough that opening the chat is an informed act, which
[Article 13](https://gdpr-info.eu/art-13-gdpr/) sets out in detail: who you are, what
you are doing with the data, the lawful basis, how long you keep it, who else sees
it, and the rights they have.

In practice this does not mean a wall of text in the chat window. It means the
privacy policy actually covers the chatbot, which is the part that gets skipped. A
policy written before you installed one does not mention transcripts, does not name
the vendor, and does not give a retention period, and a policy that omits a
processing activity is not a policy that covers it.

Add a line in the widget that links to the policy, then add a chatbot section to the
policy with the four facts: what is collected, why, for how long, and who it is
shared with. That is a short job and it is the single highest-value thing on this
page.

## What happens when somebody asks for their transcripts?

You have a month to answer, and the answer has to include the chat logs, which is
where the arrangement is tested for the first time.

Two capabilities decide whether that month is comfortable. The first is search: can
you find one person's conversations without reading a year of them? If the vendor's
dashboard only sorts by date, you are about to do that by hand. The second is
deletion that actually propagates. A delete button that clears the dashboard while
the transcript survives in the model provider's logs has not deleted anything, and
you are the one who told the visitor it had.

Ask both before you install, in those words, because both are cheap to answer
honestly and awkward to answer otherwise. Ask also what the export looks like: a
subject access response is a document you hand to a person, and a CSV of internal
identifiers is not one.

None of this is exotic. It is the ordinary operational cost of holding conversations,
and it is smaller than it sounds as long as somebody has thought about it once,
before the first request rather than during it.

## When is a chatbot the wrong thing to install under GDPR?

Three cases, and the first is not a close call.

If your visitors routinely tell you things that fall under
[special category data](https://commission.europa.eu/law/law-topic/data-protection_en),
health above all, the bar rises sharply and a general-purpose support widget is not
the tool. A pharmacy, a clinic, a supplement shop where people explain their
symptoms: those conversations attract a stricter regime, and installing something
that logs them by default into a third party's dashboard is a decision that needs an
advisor rather than an afternoon.

If you cannot get a written processor agreement, the arrangement does not work. Not
as a technicality. The contract is the mechanism by which your obligations reach the
people actually holding the data, and without it there is no mechanism.

And if nobody at your company will own the retention decision, the honest answer is
to wait. A chatbot that logs everything forever because no one chose a number is
accumulating a liability quietly, and the accumulation is invisible until somebody
asks for a copy of everything you hold about them.

Set against those, the ordinary case is genuinely fine. A shop answering delivery and
returns questions from its own published pages, with a processor agreement, a stated
basis, a retention window and a policy that mentions it, is doing something
unremarkable. The work is in the paragraph you write once, not in the software. What
that software is, and the four kinds of it, is in
[what an AI chatbot for a website actually is](/blog/ai-chatbot-website/); the
interface in front of it is in
[making a widget that fits your site](/blog/ai-widget-website/).

## Quick answers

### Are AI chatbots GDPR compliant?

No product is compliant on its own, because compliance describes a processing
arrangement rather than a piece of software. The regulation never mentions chatbots.
What decides it is who the controller is, whether a processor agreement exists, what
lawful basis you rely on, where the messages travel and what the visitor was told
first. A vendor can make all five easy or all five hard, which is the real thing to
compare.

### Is a chat message personal data?

Almost always, yes. Personal data is any information relating to an identifiable
person, and a support conversation identifies people constantly: an order number, an
email address, a delivery address, sometimes a health detail nobody asked for. Even
without those, the message plus an IP address plus a timestamp is usually enough.
Treating chat logs as anonymous because no name field exists is the most common
mistake in this category.

### Do I need consent for a website chatbot?

Not necessarily, and reaching for consent by reflex causes more problems than it
solves. Answering a question somebody deliberately typed into your support widget
usually rests on legitimate interest or on performing a contract. Consent becomes the
right basis when you start doing something they did not ask for with the transcript,
such as marketing from it. What you always owe is the information notice, not
necessarily a checkbox.

### Who is the controller, me or the chatbot vendor?

You are, in nearly every arrangement. You decide to run a chatbot, you decide what it
reads and what it keeps, and those decisions are what the regulation means by
determining the purposes and means. The vendor is a processor acting on your
instructions, and the model provider behind them is usually a sub-processor. That
makes the written agreement with the vendor the document that carries the weight.

### Does using OpenAI or another US model provider break GDPR?

Not by itself, but it does put a transfer in your processing chain that you have to
be able to describe. A transfer outside the EEA needs a basis, and you need to know
which one your vendor relies on. The awkward question is not whether it is allowed.
It is whether you can name the parties in the chain, because a vendor who cannot name
them for you has answered the question already.

### Can I just not log the conversations?

You can, and it is the strongest privacy position available to you, but it costs you
something real: no transcript means no way to find out what the bot got wrong. A
middle position is a short retention window measured in days rather than the default
forever, with a documented reason for the number you picked. Retention nobody chose
is retention nobody can defend.

## Sources

- [GDPR Article 28, processor obligations](https://gdpr-info.eu/art-28-gdpr/)
- [GDPR Article 6, lawfulness of processing](https://gdpr-info.eu/art-6-gdpr/)
- [GDPR Article 13, information to be provided](https://gdpr-info.eu/art-13-gdpr/)
- [GDPR Chapter V, transfers to third countries](https://gdpr-info.eu/art-44-gdpr/)
- [GDPR Article 30, records of processing activities](https://gdpr-info.eu/art-30-gdpr/)
- [European Commission: data protection](https://commission.europa.eu/law/law-topic/data-protection_en)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*