What does GDPR actually require for chatbots?
GDPR requires a lawful basis for every processing activity, and a chatbot that captures a name, email, or phone number is a processing activity under Article 6. For most lead-capture chatbots, the relevant bases are consent (the visitor explicitly agrees) or legitimate interests (you have a genuine business reason that does not override the visitor's rights). Consent is easier to demonstrate to a regulator because it is documented.
Beyond the lawful basis, Article 13 requires transparency: at the moment you collect data, you must tell the visitor who you are, why you are collecting the data, how long you will keep it, who it may be shared with, and what their rights are. For a chatbot, this means a pre-chat privacy notice — not a buried hyperlink in the footer.
Data subjects also hold enforceable rights: access, correction, portability, restriction, objection, and erasure. If a visitor asks what data you hold or requests deletion, you have one calendar month to respond. Failing to honour these rights falls under the higher fine tier.
| Article | What it covers | Practical obligation for chatbots |
|---|---|---|
| Art. 3(2) | Territorial scope | Applies to any business targeting EU residents, regardless of where it is based |
| Art. 5 | Principles — minimisation, storage limitation | Collect only what you need; delete when the purpose ends |
| Art. 6 | Lawful basis | Identify and document a basis (consent or legitimate interests) before going live |
| Art. 13 | Transparency at collection point | Show a pre-chat privacy notice with controller identity, purpose, retention, and rights |
| Art. 17 | Right to erasure | Delete transcripts and captured data within 30 days of a valid erasure request |
| Art. 46 | Cross-border transfers | Use SCCs or rely on the EU-US Data Privacy Framework for US-based vendors |
| Art. 83 | Fines | Up to €20M or 4% of global turnover for violations of core principles and data subject rights |
What is the GDPR compliance checklist for chatbot operators?
The five controls below address the most common gaps regulators find when auditing conversational AI on websites. Each maps to one or more GDPR articles.
- 1
Choose and document a lawful basis
Before you embed the chatbot, decide whether you are relying on consent or legitimate interests under Article 6. Document the decision in a processing record (your Record of Processing Activities, or RoPA). If you choose consent, implement a pre-chat opt-in that is separate from your cookie banner — bundling the two is not valid consent under GDPR.
- 2
Show a pre-chat privacy notice
Trigger a brief notice before the chat opens. It must state: your company name and contact, the purpose of data collection (e.g., "to respond to your enquiry and follow up"), how long you keep the data, and a link to your full privacy policy. Under Article 13, this notice must appear at the moment of collection — not after the visitor has typed their email.
- 3
Set a data retention schedule and enforce it
Article 5(1)(e)'s storage limitation principle requires you to delete data when it is no longer needed. For lead-follow-up purposes, a 12–24 month window after the last contact is defensible. Add a quarterly or annual purge job to your calendar, and document the schedule. Do not keep transcripts indefinitely.
- 4
Map your third-party data flows and add SCCs or DPF coverage
Every vendor who processes the chat data — the AI model provider, your CRM, your email platform — is a data processor under GDPR. List them. For vendors outside the EEA, confirm they are either EU-US Data Privacy Framework certified or that you have Standard Contractual Clauses (SCCs) in place. Without one of these, the transfer is unlawful under Article 46.
- 5
Build a subject-request handling process
Any visitor can request access, correction, or deletion of their data. Establish a documented process: how requests arrive (email, chat, or web form), who receives them, how identity is verified, and how you respond within 30 days. Log every request. Regulators treat an absence of process as evidence of systemic non-compliance.
When does your chatbot need a cookie banner vs. a separate consent layer?
Cookie banners and chatbot consent are two distinct obligations, and conflating them is a common mistake. A cookie consent banner addresses the ePrivacy Directive requirement for cookies and tracking scripts. If your chatbot sets a session or analytics cookie, the banner covers that specific cookie.
But GDPR consent for personal data collected in the chat — names, emails, phone numbers — is a separate legal requirement under Article 6. You need a pre-chat notice with a clear opt-in action (a button tap, a checkbox) that is distinct from the cookie layer. Presenting them as a single banner creates ambiguity about what the visitor is consenting to, which makes the consent invalid if challenged.
The practical split: the cookie banner handles the script load; the pre-chat notice handles the data collection. Both must be granular, freely given, and withdrawable.
How long can you keep chat transcripts under GDPR?
Article 5(1)(e) requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary." There is no universal number in the regulation — the retention period must be justified by the purpose.
For a lead-capture chatbot, the purpose is sales follow-up. A defensible retention window is 12–24 months after the last meaningful contact (a reply, a purchase, a support interaction). After that, with no ongoing relationship and no other legal basis, the transcript should be deleted or anonymised. Document your chosen period in your privacy policy and your RoPA, and build an automated deletion job rather than relying on manual reviews.
One exception: if a legal dispute arises, you may need to retain records under a "legal claims" basis. But this is a narrow carve-out — it applies to specific disputes, not a blanket reason to hold everything forever.
How do cross-border data transfers work after Schrems II?
If your chatbot sends EU visitor data to a US-based AI model, CRM, or email platform, that is a restricted international transfer under Chapter V of GDPR. Since the Court of Justice invalidated Privacy Shield in 2020 (Schrems II), two mechanisms cover most US transfers:
- EU-US Data Privacy Framework (DPF): The European Commission adopted an adequacy decision on 10 July 2023 (Commission Implementing Decision (EU) 2023/1795). US companies that self-certify to the DPF can receive EU data without additional safeguards. Verify your vendor's certification at the official DPF list before relying on this.
- Standard Contractual Clauses (SCCs): The 2021 SCCs issued by the European Commission remain valid. If your vendor is not DPF-certified, you need SCCs in place. Most major cloud vendors offer these in their data processing addenda — check their DPA, do not assume it is automatic.
For UK transfers, the UK International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs serve the same function post-Brexit. The ICO publishes guidance on which version to use. The US-UK Data Bridge (effective October 2023) provides a UK-side equivalent to the DPF for DPF-certified US organizations.
What does the EU AI Act require for chatbots?
Most business chatbots are not classified as high-risk under the EU AI Act (Regulation (EU) 2024/1689). A lead-capture or FAQ chatbot does not fall into the high-risk categories (health, education, employment, critical infrastructure). It is a "limited-risk" AI system.
Article 50 of the AI Act creates a transparency obligation for limited-risk conversational AI: deployers must inform users that they are interacting with an AI system "at the latest at the time of the first interaction," unless the AI nature is obvious from context. This requirement becomes mandatory on 2 August 2026, two years after the Act entered into force.
In practice, this means adding a clear disclosure in your chatbot's opening message — for example, "Hi, I'm an AI assistant for [Company Name]." A disclosure buried in a privacy policy does not meet the "at the time of first interaction" standard. Note that this is an AI Act obligation on the deployer (you, the business), not just the model provider.
Does GDPR apply to US businesses with no EU presence?
Yes, if you are targeting EU residents. Article 3(2) extends GDPR to any controller offering goods or services to EU data subjects or monitoring their behaviour — regardless of where the business is established. A US plumbing company that only serves one city has a reasonable argument that EU traffic is incidental. A US SaaS with a multilingual website, EU pricing, or a ".eu" domain does not.
Two paths for US businesses that receive EU traffic:
- Accept GDPR scope: Implement the controls in this guide, appoint an EU representative under Article 27 if you have no EU establishment, and document your compliance posture.
- Geo-block EU visitors: Some small businesses choose to block EU IP ranges rather than build GDPR infrastructure. This is a legitimate risk-management decision, but it comes with its own implementation overhead and eliminates any EU growth opportunity.
Geo-blocking is not a GDPR workaround — if EU residents can still access your site (VPNs, travel), you retain some exposure. Most legal teams advise accepting scope and complying rather than relying on an imperfect technical block.
How does Knobot handle GDPR for chatbot operators?
Knobot is a RAG-grounded chatbot that captures lead data (name, email, phone) to email and webhook delivery. For operators running Knobot on EU-facing websites, the relevant controls are:
- Pre-chat disclosure: Knobot's opening message is editable — add the AI disclosure required under EU AI Act Article 50 and a link to your privacy policy directly in the welcome text.
- Data minimisation: Configure Knobot to collect only the fields your follow-up process requires. If you do not need a phone number, do not ask for one.
- Transcript retention: Knobot stores conversation transcripts in your dashboard. Export and delete old conversations in accordance with your documented retention schedule.
- Data processor relationship: Knobot acts as a data processor when it handles EU visitor data on your behalf. Review the Knobot data processing terms and confirm they cover your SCC or DPF obligations before going live with EU traffic.
- Subject erasure requests: When a visitor requests deletion, remove their lead record and conversation transcript from the Knobot dashboard and from any downstream CRM or email platform where the webhook sent the data.
These steps do not substitute for legal advice. For businesses with significant EU revenue or sensitive data (health, financial), a data protection officer (DPO) review before deploying any chatbot is prudent.