A compliant AI chatbot is not a product you buy — it is a setup you can prove. In practice, “compliant” means four things at once: an Article 28 data processing agreement signed by your vendor; a contractual ban on training models on your customers’ conversations; a documented lawful basis for every purpose the bot serves; and, since 2 August 2026, AI disclosure as the chat starts (EU AI Act, Article 50).
This guide turns those duties into a 20-point vendor audit you can run before signing — or on a live chatbot. It is general guidance, not legal advice.
“GDPR compliant” is a setup, not a product
No official certification makes a chatbot compliant. When a vendor advertises “GDPR compliant”, the claim covers only one specific configuration: your contract, your settings, your data flows.
The roles are fixed by the GDPR (Regulation (EU) 2016/679), not by marketing. Your business decides why the chatbot exists and what it may answer, so it is normally the controller; the vendor, processing chat data on your behalf, is a processor. Article 28 allows only processors providing “sufficient guarantees”, under a written contract covering defined points.
One trap matters most: if a vendor uses your chat data for its own purposes — training a shared model on your customers’ conversations, say — Article 28(10) treats it as a controller for that processing. The audit below tests exactly this, because it is where “compliant” chatbots most quietly stop being compliant. Auditing the rest of your AI stack too? Our wider guide to using AI tools without breaking European data law covers governance.
The three legal layers on one chat widget
Layer 1: The GDPR — the data itself
The GDPR governs everything personal in the conversation — names, order numbers, support problems, transcripts. It supplies the controller/processor split, lawful bases, transparency at collection, data-subject rights (access, erasure, objection), Article 32 security, and the Article 33 72-hour breach clock.
Layer 2: The EU AI Act — the “AI” part
Regulation (EU) 2024/1689 entered into force on 1 August 2024 and applies in stages. For an ordinary customer-service chatbot, the duty that matters is Article 50 transparency:
- Article 50(1): providers of AI systems that interact directly with people must ensure users are informed they are interacting with an AI system — unless obvious to a reasonably well-informed, observant person.
- Article 50(5): the information must be provided clearly and distinguishably, at the latest at the first interaction.
- Article 50(2): systems generating synthetic text, audio, image or video must mark outputs in a machine-readable format as artificially generated (narrow exceptions, e.g. assistive standard editing).
The timeline, as amended by the Digital Omnibus (Regulation (EU) 2026/1744 of 8 July 2026):
| Date | What it means for a business chatbot |
|---|---|
| 1 Aug 2024 | EU AI Act in force; prohibited practices apply from 2 Feb 2025 |
| 2 Aug 2026 | Article 50 transparency applies — AI disclosure in chat is already mandatory |
| 2 Dec 2026 | Article 50(2) marking deadline for generative AI systems on the market before 2 Aug 2026 |
| 2 Dec 2027 / 2 Aug 2028 | High-risk duties, Annex III / Annex I (moved back by the Omnibus) |
Note what the Omnibus did not do: it delayed the high-risk regime, not Article 50.
Layer 3 (Germany): §25 TDDDG — the widget before the chat
German businesses face a third layer most English-language guides miss. Section 25 of the TDDDG (renamed from TTDSG on 14 May 2024) regulates storing information on — or accessing information stored on — a user’s device. Under §25(1) that requires consent based on clear and comprehensive information, in line with the GDPR; §25(2) exempts only what is strictly necessary for a service the user expressly requested.
A chat widget that sets cookies or writes to local storage before consent — for analytics or fingerprinting — can breach German law before a single message is sent, whether or not the information is personal data. Ask what the widget stores on page load.
The 20-point vendor audit checklist
Run these in order. Each point names what to ask and what evidence counts as a pass; a vendor that cannot produce the evidence has not passed.
Contract and roles
1. A signed Article 28 DPA exists before any real data flows. Pass evidence: the agreement states the subject-matter and duration of processing, the types of personal data and data subjects, and binds the vendor to process data only on your documented instructions (Article 28(3)).
2. A written no-training commitment covers inputs and logs. Pass evidence: a contract clause, not a help-centre page, stating that your prompts, transcripts and knowledge-base content are never used to train models. A vendor reusing data for its own purposes becomes a controller for that use under Article 28(10) — a fail.
3. The sub-processor list is complete and change-controlled. Pass evidence: a list naming every sub-processor, including the model and hosting providers, plus a promise to notify you of changes with a right to object (Article 28(2)).
4. The breach-notification window is defined in hours. Article 33(2) obliges the processor to notify you “without undue delay”; Article 33(1) gives you, where feasible, 72 hours from awareness to notify your authority. Pass evidence: a clause committing the vendor to notify you within a stated number of hours.
5. Exit terms return or delete everything. Pass evidence: an end-of-service clause matching Article 28(3)(g) — at your choice, all personal data is deleted or returned when the contract ends, with a stated timeline for backups and logs.
Data flows and hosting
6. Every processing location is mapped. Pass evidence: a data-flow list covering widget host, transcript storage, model inference, analytics and support access, each with its country. “Hosted in the EU” that silently excludes US-based support access is not a pass.
7. Each non-EEA flow has a named transfer mechanism. Pass evidence: for US transfers, either the receiving organisation’s active certification under the EU–US Data Privacy Framework (adequacy decision (EU) 2023/1795 of 10 July 2023 — check the entity receiving the data, not a parent company) or signed standard contractual clauses (Decision (EU) 2021/914) with a documented transfer impact assessment.
8. Retention at the model layer is zero or defined. Pass evidence: a setting or contract term showing whether prompts sent to the model are stored, where, and for how long, with any abuse-monitoring retention time-limited. Indefinite default storage fails the GDPR’s storage-limitation principle.
9. Your data is excluded from model training at every layer. Point 2 covers the vendor; this one covers the model provider behind it. Pass evidence: the model tier on your account contractually excludes training on your inputs.
10. The widget passes the §25 TDDDG test (Germany). Pass evidence: the vendor states in writing what the widget stores on or reads from a visitor’s device before consent, and anything non-essential activates only after consent. “Strictly necessary” (§25(2)) covers storage needed to run a chat the visitor opened — not vendor tracking.
Settings and your own duties
11. A lawful basis is documented for each purpose. Support chat usually rests on contract performance or legitimate interests; follow-up marketing needs its own basis, normally consent. Pass evidence: your own record of purpose, basis and retention, kept with your record of processing activities. Consent is one of six Article 6 bases; a vendor insisting it must precede every chat misreads the law.
12. The chat-start notice covers Article 13 information. Pass evidence: as the conversation starts, the widget identifies the controller, purposes, retention and user rights in short form, linking to the full privacy notice.
13. Transcript retention is set, finite and auto-enforced. Pass evidence: a configured retention period with automatic deletion, not a promise to tidy up manually. Keep transcripts only as long as the purpose needs.
14. Access and erasure requests can actually be executed. Pass evidence: you can export and delete one person’s conversations across widget logs, CRM copies and vendor systems, with the vendor bound to assist (Article 28(3)(e)). Test it with a dummy record before go-live.
15. A DPIA screening decision is documented. Article 35(3) makes a data protection impact assessment mandatory for, among other cases, systematic and extensive automated evaluation with significant effects, large-scale special-category data, and large-scale monitoring of public areas. Pass evidence: a written screening — does the bot profile or score people, or touch health data? If possibly yes, complete the DPIA before launch; the vendor must assist (Article 28(3)(f)).
EU AI Act transparency
16. Article 50(1) disclosure is live in the chat itself. Pass evidence: at the first interaction, a new visitor sees a clear statement that they are interacting with an AI system — Article 50(5) sets that timing and clarity standard. A line buried in terms and conditions does not meet it.
17. Provider and deployer roles are assigned in writing. Deploying a vendor’s bot under your brand normally makes the vendor the provider and you the deployer; white-labelling a system as your own product can shift provider duties to you. Pass evidence: the contract states who carries this deployment’s Article 50 duties.
18. Article 50(2) marking status is known. If the bot’s generated text is published to inform the public — help-centre articles, product descriptions — Article 50(4) deployer disclosure and the Article 50(2) provider marking duty apply. Pass evidence: the vendor states how outputs are marked; for systems on the market before 2 August 2026, the marking deadline is 2 December 2026.
Operations
19. Security evidence matches Article 32. Pass evidence: documented measures — encryption of transcripts in transit and at rest, access controls on who can read conversations, security documentation you can file. A logo wall of certifications you cannot inspect is not evidence.
20. Human handoff and review are built in. Pass evidence: the bot routes to a person on request or on low confidence, wrong answers can be corrected, and the audit is re-run when the vendor changes its model, sub-processors or terms — a model swap is a new audit. (Related trap: for services offered directly to a child on a consent basis, Article 8 sets the age at 16 — Germany has not lowered it.)
EU-hosted or US LLM? The decision tree
Hosting location is the question buyers ask first — a transfer question, not a verdict:
START: Does any chat personal data leave the EEA — hosting, model
inference, analytics, or the vendor's support access?
│
├─ NO — processing is EEA end-to-end
│ → Simplest route; no transfer mechanism needed.
│ You still need points 1–5, 8 and 11–20.
│
└─ YES → Is the organisation receiving the data certified under
the EU–US Data Privacy Framework?
│
├─ YES → The transfer can rest on adequacy decision (EU) 2023/1795.
│ Verify it is active and covers that entity and this data.
│ Sign the Article 28 DPA anyway.
│
└─ NO → Will the vendor sign the standard contractual clauses
(Decision (EU) 2021/914) and support a transfer assessment?
│
├─ YES → Lawful route: SCCs + documented transfer impact
│ assessment + any measures it calls for.
│
└─ NO → Do not send personal data through this vendor.
Choose its EEA option, or another vendor.
ALWAYS: a free or consumer tier with no DPA fails at point 1.
Stop there, whatever the model quality.Two clarifications. First, EU hosting removes the transfer question only — the DPA, retention, notice, rights and disclosure duties all remain. Second, a US LLM is not automatically unlawful: with a certified recipient or proper SCCs the transfer can be lawful; what fails is the unexamined default. If the audit pushes you towards rebuilding rather than re-papering, our guide on how to build an AI chatbot for your website covers what follows.
When a support bot stops being “just a chatbot”
Article 50 is the light-touch end of the AI Act. If your bot drifts into its high-risk list (Annex III) — screening job applicants, assessing creditworthiness or eligibility for essential services — the full high-risk regime follows, applying from 2 December 2027 after the Omnibus delay. That is a different project, with professional advice attached.
Two harder boundaries sit closer to everyday setups. Article 22 GDPR gives people rights around solely automated decisions that significantly affect them: a bot may inform or draft, but letting it finally refuse a refund or claim is a legal decision, not a feature toggle. And inferring emotions in the workplace is on the Article 5 prohibited list, so “agent sentiment monitoring” add-ons deserve a hard no.
What non-compliance can cost — honestly stated
The statutory ceilings are large. Under GDPR Article 83, failures around processor contracts and DPIAs sit in the €10,000,000 / 2%-of-worldwide-turnover tier (Article 83(4)); breaches of principles, lawful basis, rights and transfer rules in the €20,000,000 / 4% tier (Article 83(5)). Under AI Act Article 99(4)(g), breaching Article 50 carries a ceiling of €15,000,000 or 3% of turnover (Article 99(6) caps SME fines at the lower of the two).
Treat these as ceilings, not predictions: fines must be proportionate. The realistic small-business cost is a customer complaint, a corrective order, and a chatbot rebuilt under time pressure. The audit costs a few hours instead.
Frequently asked questions
Does a simple rule-based FAQ bot count as an “AI system” under the EU AI Act?
Possibly not. The Act’s definition turns on inference, and its recitals exclude systems based solely on rules defined by natural persons to automatically execute operations. A fixed decision-tree bot may sit outside the AI Act — but the GDPR applies to its data handling in full, and §25 TDDDG still governs the widget.
Do we need consent before every chat starts?
No. A lawful basis is needed for each purpose; for ordinary support it is typically contract performance or legitimate interests. Consent is for optional extras — marketing follow-up is the common one. §25 TDDDG consent for non-essential device storage is a separate question.
We launched our chatbot before August 2026. What do we do now?
Run the audit. The Article 50(1) disclosure duty already applies; the only open transition is Article 50(2) marking for systems on the market before 2 August 2026, running to 2 December 2026. Points 16–18 are your immediate list.
If you would rather have the setup built in
The audit is deliberately tool-agnostic — run it on any vendor, including a bot you already run. If it shows your setup needs rebuilding rather than re-papering, that is the work our AI chatbot development service is structured around: chatbots designed with permission-aware retrieval, retention limits, defined data flows and human handoff from the start. Or book a consultation to walk through your vendor’s answers — or the gaps — first.
General information about GDPR and EU AI Act duties for business chatbots as of November 2026 — not legal advice. For binding decisions (high-risk uses, children’s data, employee-facing tools), consult a qualified data protection professional in your member state.
USA
UK
Canada
Germany
UAE
Australia
S. Africa
France
Netherlands
Ireland
Spain
Italy
Sweden
Switzerland
Belgium