What GDPR actually requires for AI chatbots
Before evaluating vendors, get the legal frame right. The General Data Protection Regulation (Regulation (EU) 2016/679) does not contain a section titled "AI chatbots." It contains a set of duties that attach to whoever decides why and how personal data is processed (the controller) and whoever processes that data on the controller's behalf (the processor). For a typical AI chatbot deployment on your website, you are the controller and the chatbot vendor is the processor. That split is the single most important fact on this page, because every contractual obligation flows from it.
As controller you owe data subjects (visitors who chat with the bot) several things. You must identify a lawful basis under Article 6 for processing their data. For a customer-service chatbot that is usually either consent (Article 6(1)(a)) or legitimate interests (Article 6(1)(f)), depending on what data is collected and what the bot does with it. You must give visitors a privacy notice that meets the Article 13 information requirements, which is normally satisfied by a link to your privacy policy from the chat widget. You must honour data-subject rights, including the right of access (Article 15), the right to rectification (Article 16), and the right to erasure (Article 17, commonly called the right to be forgotten). You must keep a record of processing activities under Article 30 if you are not a micro-enterprise.
The processor (your chatbot vendor) owes you a written contract that meets Article 28(3). That contract is the Data Processing Agreement (DPA). Article 28 specifies what the DPA must contain: subject matter and duration, nature and purpose of processing, type of personal data, categories of data subjects, the processor's obligations to act only on documented instructions, confidentiality, security measures under Article 32, sub-processor controls, assistance with data-subject requests, breach notification, deletion or return of data at end of contract, and audit rights. A vendor who will not sign a DPA that contains those clauses is not a viable processor for GDPR-regulated work, full stop.
Two further pieces sit on top of the controller/processor split. First, if the chatbot vendor processes personal data outside the European Economic Area, you need a valid Chapter V transfer mechanism. For US-based vendors the practical answer in 2026 is the EU-US Data Privacy Framework (DPF) where the vendor is certified, or Standard Contractual Clauses (SCCs) where it is not, plus a transfer impact assessment. Second, if the chatbot processes special-category data under Article 9 (health, religion, ethnicity, biometric, etc.) you need a stronger lawful basis under Article 9(2). Most retail and SaaS chatbots avoid Article 9 territory by design; healthcare and HR-adjacent deployments do not get that luxury.
The four buyer checklist items
There is a long list of things a thorough buyer might ask a chatbot vendor. In practice four of them carry almost all of the compliance weight. If a vendor meets these four, the rest is paperwork. If it misses any of these four, the rest of the paperwork is not enough.
One: a signed Data Processing Agreement under Article 28. The DPA must be specific to the chatbot product (not a generic master agreement) and must include the sub-processor list, the security measures the processor commits to, and the deletion-and-return clause at end of contract. Watch for vendors who treat the DPA as a one-line addendum or who refuse to disclose the sub-processor chain. Both are red flags.
Two: EU data residency available. "Available" is the operative word. Many vendors will keep all data in their US region by default and offer EU residency only on a higher tier, on request, or as a paid add-on. Ask explicitly which region your chat transcripts, vector embeddings, and lead-capture data will live in, and ask for that answer in writing inside the DPA's processing-locations clause. "We use AWS, which has EU regions" is not an answer; the answer is the specific region the vendor has provisioned your tenant in.
Three: the processor does not train shared models on your data. This is the question most buyers underweight. If the chatbot vendor uses your conversations to improve a model that is then used to serve other customers, you have a controller-to-controller data flow that you almost certainly did not document and that visitors did not consent to. Ask for a written term in the DPA stating that customer data is not used to train shared or foundation models, and that any per-tenant fine-tuning happens only inside your tenant. Most reputable vendors will agree to this; the ones who will not are telling you something important.
Four: deletion on request within 30 days. Article 17 gives data subjects the right to erasure. As controller you have to be able to act on a verified erasure request, which means your processor has to be able to delete the underlying data on your instruction. The thirty-day window is the Article 12(3) deadline for responding to data-subject requests (extendable by two further months in complex cases). Ask the vendor how a deletion is executed, what the SLA is, and whether logs and backups are included.
If a vendor meets all four, you have a workable foundation. The remaining diligence (SOC 2, ISO 27001, penetration test reports, breach-notification procedure, sub-processor flow-through) is real work but is no longer the gating decision.
Cookie consent and the chatbot widget
The chatbot widget is technology. The cookies and similar identifiers it drops are governed by the ePrivacy Directive (Directive 2002/58/EC) as transposed into national law, and the GDPR sits underneath where personal data is involved. The practical question is when consent is required before the widget loads.
The answer depends on what the widget actually stores. A widget that only stores a session identifier needed to maintain the conversation across page navigations is strictly necessary and falls under the ePrivacy exemption for cookies "strictly necessary to provide a service explicitly requested by the user." Consent is not required for that subset. A widget that also stores analytics identifiers, sets marketing cookies, or links chat conversations to a cross-site advertising profile is not strictly necessary and requires prior, informed, freely given consent before those cookies are set.
The defensible pattern in 2026 is to load the chatbot widget with only its session cookie, gated behind your consent banner's "necessary" bucket, and to gate any analytics or marketing-cookie behaviour behind explicit consent. EDPB guidance on consent (Guidelines 05/2020) is the reference point. If your widget vendor cannot tell you which cookies it sets and what each one is for, you cannot configure consent correctly, and you should treat that as a compliance defect.
ChatRaj's specific compliance posture
We will not claim ChatRaj is "GDPR compliant" because compliance is a property of your deployment, not of our software. What we can commit to in writing:
- DPA available from all paid tiers. Our DPA is published, contains the Article 28(3) clauses described above, and is signable by countersignature without a sales-call requirement.
- EU data residency on request. Pro and Growth tenants can be provisioned in our Frankfurt region (eu-central-1) on request at no additional charge. The default region is US for new accounts; we are working on a self-serve regional selector for the second half of 2026.
- No training on customer data. Customer conversations are never used to train shared models. Any per-tenant retrieval index is scoped to that tenant and not shared.
- Deletion on cancellation, and on request within the Article 12 window. Closing your account triggers deletion of conversation logs, embeddings, and lead-capture data within thirty days. Per-conversation or per-visitor deletion is exposed via the dashboard for handling Article 17 requests.
- Sub-processors published. Our current sub-processor list is on the privacy page and updates trigger a thirty-day notice before any new sub-processor handles customer data, in line with the Article 28(2) standard.
None of those points is a substitute for your own privacy notice, your own lawful-basis analysis, or independent legal review. They are the inputs you can plug into that analysis.
Competitor compliance comparison
A short read of the public compliance posture of the major AI chatbot vendors as of May 2026, based on each vendor's public trust or privacy pages. Verify before contract.
Intercom Fin publishes SOC 2 Type II and ISO 27001 reports, offers a DPA, and supports EU data residency on its higher-tier enterprise plans. Sub-processor list is public. Documentation is mature, which reflects Intercom's longer enterprise track record.
Chatbase publishes a DPA available to paid customers and states that customer data is not used to train shared models. EU data residency is referenced as available on enterprise plans; verify the specific region commitment in your DPA.
SiteGPT publishes a privacy policy and DPA. Smaller operation with fewer public security attestations than Intercom; ask explicitly about sub-processor flow-through and breach notification SLAs.
None of this list is a regulatory ranking and none of it constitutes legal advice. Vendor compliance posture changes; pull the live trust page before you sign.
Common operator mistakes
The most common GDPR failures we see in AI chatbot deployments are operator mistakes, not vendor failures.
Using the chatbot for advice without a disclaimer. A general-purpose website chatbot answering "what should I take for this headache" is making a medical statement, and a chatbot answering "is this tax-deductible" is making a tax statement. Add a scoped disclaimer in the welcome message and a topic-restriction prompt that refuses out-of-scope advice. This is not strictly a GDPR issue, but it intersects with consumer-protection law in most member states.
Not honouring deletion requests within 30 days. Article 12(3) gives controllers one month to respond to data-subject requests, extendable by two months where the request is complex. Operators who do not have a documented runbook for handling Article 17 requests against their chatbot transcripts routinely miss the window. Build the runbook before you launch.
Treating the privacy policy as the consent record. Linking a privacy policy from the widget is an Article 13 information disclosure, not a consent record. Where your lawful basis is consent, you need an actual record of what was consented to, when, and how. Most consent-management platforms do this; the chat widget on its own does not.
Ignoring children. If your audience can include under-16s (under-13s in some member states), Article 8 adds a parental-consent layer for consent-based processing. Most chatbot deployments either restrict to adults via the terms of service or shift to a legitimate-interests basis where compatible.
EU AI Act implications for chatbots in 2026
The EU Artificial Intelligence Act (Regulation (EU) 2024/1689) sits alongside GDPR, not on top of it. The two laws ask different questions: GDPR asks "is the processing of personal data lawful," and the AI Act asks "is the AI system itself safe and appropriately disclosed."
For a typical website chatbot, the AI Act treats the system as limited-risk under the transparency obligations in Article 50. The relevant duty is that the provider must design the system so that natural persons are informed they are interacting with an AI system, unless this is obvious from the context. The notification must be given at the latest at the time of first interaction.
The applicability date for Article 50 transparency obligations is 2 August 2026. Practical implications:
- Add a clear "You are chatting with an AI assistant" line in the widget welcome message or the first bot turn. A pre-chat disclaimer modal also satisfies this.
- Do not design the bot to impersonate a named human agent. "Hi, I'm Sarah from support" without an AI disclosure is the pattern Article 50 was written to address.
- AI-generated content the bot produces (drafted emails, summaries, etc.) may fall under the marking obligations in Article 50(2) depending on use. Most conversational replies will not, but generated documents the visitor downloads may. Review the use case.
Non-compliance with Article 50 can attract administrative fines of up to EUR 15 million or 3 percent of worldwide annual turnover, whichever is higher, under Article 99 of the AI Act. The number is real; the enforcement posture in 2026 is still developing.
Practical compliance checklist
A short list to keep next to your procurement file. None of this is a substitute for legal counsel; all of it is the kind of thing your counsel will ask about.
- Identify the controller and processor for each data flow involving the chatbot.
- Pick a lawful basis under Article 6 and document it.
- Sign an Article 28 DPA with the vendor before any customer data flows.
- Confirm EU data residency in writing if your buyer base or your own establishment requires it.
- Confirm in writing that the vendor does not train shared models on your conversations.
- Build a documented Article 17 deletion runbook with a thirty-day SLA.
- Configure cookie consent so that only strictly necessary widget cookies load before opt-in.
- Update your privacy notice with Article 13 disclosures specific to the chatbot.
- Add the Article 50 AI-interaction disclosure before 2 August 2026.
- Re-review at every major vendor change (region, sub-processor, model provider).
Run that list, keep the receipts, and you have a defensible position. Skip any single item and you are betting on enforcement priorities, which is a bet we do not recommend.