A practical guide to the four questions procurement always asks about an AI support tool: what the DPA has to cover, where the data goes, how long transcripts live, and how you answer an access or erasure request across every channel.
Also available in Dutch: AVG en AI-klantenservice: verwerkersovereenkomst, doorgifte, bewaartermijn en verzoeken
Adding an AI assistant to your support stack does not change a single GDPR obligation. It changes where personal data turns up. A chat box collects what a contact form never does: order numbers, addresses, payment complaints, whole life stories typed at midnight because the customer is annoyed. That content is then retrieved, summarised, sent to a model, stored as a transcript and counted in your analytics. None of it is unlawful. All of it is yours to account for.
Most arguments about AI and GDPR get shorter once the roles are said out loud. You decide why and how your customers' data is processed, so you are the controller. Your support platform processes it on your instructions, so it is a processor. The model provider behind the AI answers sits below that as a sub-processor. Three parties work on one chat message, and only one has a relationship with the customer: you.
| Party | Role | What it typically sees |
|---|---|---|
| You (the merchant) | Controller | Everything: the conversation, the customer record, the order behind it, the decision about what happens next. |
| The support platform | Processor | Conversations, contact details, connected order metadata and the knowledge-base content used to answer. |
| The model provider | Sub-processor | The text sent for one answer — question, retrieved passages, context. Not your database. |
| Your connected shop or channel | Usually your own controller relationship | Whatever the integration reads, governed by your agreement with that provider rather than your vendor's DPA. |
That last row catches people out. A shop platform or messaging channel you connect yourself is a service you directed, not a sub-processor your vendor engaged — and nobody else will put it in your record of processing activities.
Article 28 of the GDPR — see the text of Regulation (EU) 2016/679 — sets out what a processor contract must contain. Most published DPAs cover it. The useful reading is not whether the clauses exist but whether anything specific sits underneath them.
Two things that are not clauses matter as much. How you are told about a sub-processor change — a mailing list you must remember to join is weaker than a contractual notice period. And whether your support content trains general models, which should be a plain sentence rather than an inference. Ours says no; the sub-processor tables, the transfer mechanism and the 30-day change notice are in the DPA and the privacy policy.
"Is it hosted in Europe?" is two questions. Where is the primary store, and which individual operations leave the EEA? For us, primary hosting is in the EU, every workspace's data is stored separately from every other customer's, and it is encrypted in transit and at rest. Some AI processing runs through sub-processors outside the EEA under the European Commission's standard contractual clauses and the UK addendum, written down where you can check it.
Read every other vendor the same way. One that answers "EU hosting" and stops has described its database, not the model call. Ask in writing which processing leaves the EEA, under which mechanism, and whether a configuration exists where it does not happen at all.
Transcripts accumulate because nobody decided they should not. They are genuinely useful — quality review, content gaps, the awkward moment a customer says they were promised something — and every month of them is also a month of personal data you would have to search, export and erase on request. Storage limitation is not a suggestion.
In our product these are workspace settings an owner or admin controls: retention for conversations, a separate period for detailed AI decision logs, and a toggle that redacts customer contact details when a conversation is resolved. Whatever tool you use, answer on day one who owns those numbers — the default in most stacks is "keep everything, forever, by accident".
Minimisation in a chat product is four decisions about what the assistant is allowed to need.
Identity matching is the one that becomes an incident when it is missed, and it is where the AI Act and GDPR meet in the same widget. The disclosure side is covered in the EU AI Act chatbot disclosure post.
A subject access request must be answered without undue delay and within one month of receipt, extendable by two further months for complex or high-volume requests if you tell the person inside the first month. Generous — until you try it across four channels and find the same customer three times.
Two vendor questions follow. Can you export and erase one person yourself, or does every request become a ticket with the vendor? And is customer content embedded anywhere erasure does not reach? Our route for individuals is on the data-deletion page, and workspace admins can export and erase a single customer from the compliance settings without asking us.
Usually not on its own. An impact assessment is required where processing is likely to result in a high risk to people's rights and freedoms — large-scale systematic monitoring, special-category data at scale, automated decisions with legal or similarly significant effects. A chatbot that answers documented questions and hands off to a person does not normally clear that bar, and a short documented screening is the right output. That changes as you add things: scoring that routes people differently, health or financial detail arriving routinely, an assistant that decides entitlements rather than describing them, call recording. Check your own supervisory authority's mandatory list before concluding you are outside it — those lists are national and not identical.
Everything above compresses into eight questions. Send them before a trial rather than after procurement stalls — the answers usually come fast, and slowness is data too.
Yes. Article 28 of the GDPR requires a written processor contract wherever a vendor processes personal data on your behalf, and a chat product does that by definition: visitors type their names, email addresses and order details into it. The agreement should also name the sub-processors behind any AI features, because the model provider sits in that chain too.
Not by itself. Transfers outside the EEA are permitted where an appropriate mechanism is in place, most commonly the European Commission's standard contractual clauses plus any supplementary measures needed. What matters is that you can say which processing leaves the EEA and under which mechanism, and that it is written into the data-processing agreement.
There is no fixed number in the regulation. Storage limitation means keeping personal data only as long as it is needed for the purpose you collected it for, so set an explicit period per data type, make expiry automatic rather than manual, state the same periods in your privacy notice, and decide what you keep in aggregate once the detailed transcripts are gone.
Answer without undue delay and within one month of receipt, extendable by up to two further months for complex or high-volume requests if you notify the person inside the first month. The real work is finding every identity that person has across chat, email, messaging and commerce records, including derived data such as tags and AI logs, and verifying the requester before disclosing anything.
It depends how the vendor implemented it, which is why it is worth asking. Many systems irreversibly anonymise rather than delete rows, so financial and analytics records survive without identifying anyone, and encrypted backups are normally left to be overwritten in the ordinary rotation within a stated window. Ask specifically whether customer content sits in any search or vector index.
Usually not on its own, and a short documented screening is the right output. A full assessment becomes appropriate when you add automated scoring that routes or ranks people, routinely handle special-category data such as health details, let the AI decide entitlements rather than describe them, or record calls. Check your national supervisory authority's mandatory list, because those lists differ between member states.
2026-08-04 · 8 min read
Article 50 of the AI Act became applicable on 2 August 2026. What it actually requires from a support chatbot, why the 'obvious' exemption will not save you, and the GDPR questions that were already there.
2026-08-13 · 9 min read
Live chat installs in about ten minutes — one script tag or a CMS plugin. Here is the full setup: install route, knowledge base, office hours and handover.
2026-08-13 · 10 min read
Live chat is a person; a chatbot is software. The honest answer is that you do not have to choose — modern widgets run AI first and hand off to a human.
See how honestly-measured AI resolutions cut your support load — start on the Free plan, no credit card, no sales call to get started.