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 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 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, 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 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, and what you are permitted to do with the software is in the licence.
What do you have to tell the visitor?
Enough that opening the chat is an informed act, which Article 13 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, 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; the interface in front of it is in making a widget that fits your site.
What people ask next
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.
