AI chatbots on your website: do they trigger new compliance obligations?

A website chatbot in 2026 sits at the intersection of three frameworks that did not all exist when the deployment patterns settled. GDPR governs the personal-data side. ePrivacy governs the storage side. The EU AI Act adds transparency obligations and, for some chatbots, conformity assessment. None of these individually is novel; their combination on a single feature is.

GDPR, what chatbots collect

Every chatbot collects at minimum:

• The text the user types (often containing PII volunteered for support).
• A session identifier linking utterances within a conversation.
• Timestamps, page URL, referrer.
• Sometimes: an explicit email or name field the user filled in to start the chat.

All of this is personal data under Article 4. The lawful basis depends on the chatbot’s purpose. A support chatbot generally runs on contract (6(1)(b)) or legitimate interest (6(1)(f)). A lead-generation chatbot is more contested than it is usually presented: Recital 47 GDPR says in terms that processing for direct-marketing purposes may be regarded as carried out for a legitimate interest, so 6(1)(f) is available in principle and a balancing test decides it. Consent is frequently still the right answer in practice — the marketing channel you use afterwards and the storage the widget writes need it anyway — but there is no EDPB position requiring consent for marketing chatbots as such.

Article 22, automated decision-making. Article 22(1) is worded as a right, but the CJEU read it in C-634/21 SCHUFA (7 December 2023) as a general prohibition: it applies of its own force, and the data subject does not have to invoke anything for it to bite. A chatbot answering “what time do you open?” does not trigger it. A chatbot that pre-qualifies loan applicants, screens job applicants, or routes users to different prices based on profile does. Where it applies, the processing is barred unless one of the Article 22(2) gateways is open (necessary for a contract, authorised by Union or Member State law, or explicit consent) — and on the contract and consent routes the Article 22(3) safeguards, human intervention, the right to express a point of view and the right to contest the decision, have to be designed in from the start. They are not a review path you switch on when somebody asks for it.

The EU AI Act, Article 50 transparency

The EU AI Act (Regulation (EU) 2024/1689, phased application 2024 to 2027) imposes tiered obligations based on risk.

For chatbots, the relevant tier is Article 50 (transparency obligations for AI systems intended to interact directly with natural persons), which has applied since 2 August 2026. Users must be informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed, observant and circumspect person taking the circumstances and the context of use into account.

Who owes the duty is easy to get backwards. Article 50(1) binds the provider — the party that develops the system and places it on the market. An SMB embedding an off-the-shelf Intercom or Tidio widget is a deployer, and the design-level disclosure duty sits with the vendor. That is not a licence to relax. Deployers carry their own transparency duties elsewhere in Article 50, your users will not care about the distinction when the bot feels deceptive, and the moment you white-label the bot under your own name and persona you have arguably placed it on the market yourself and become the provider. Read the contract before assuming the vendor has it covered.

The disclosure itself should be:

• Clear, visible, and visible before the widget is opened. The instinctive placement is the bot’s opening message, and legally that is fine. But a disclosure that exists only inside the conversation is invisible to anyone who has not started one — to a visitor scanning the page, and to every automated check including ours (see below). Put it where the closed widget lives: a label or caption next to the launcher, or an aria-label naming the assistant as AI. Then repeat it in the opening message. Doing both costs nothing.
• Provided before interaction. Not buried in terms of service.
• Accessible in the language of the user. Same locale as the chat UI.

The disclosure can be as simple as “Hi! I’m an AI assistant. Ask me about [topic].” Most modern chatbot products ship this by default but a custom-built bot needs to be checked.

The higher-risk tiers of the AI Act apply when the chatbot performs functions in Annex III (recruitment, credit scoring, biometrics, education, essential services). Most SMB marketing or support chatbots are not Annex III. Confirm against your bot’s actual function, “help our customers” can mean very different things.

ePrivacy, the storage question

A chatbot widget typically loads a script that:

• Sets a session cookie or localStorage entry to maintain chat state.
• Stores conversation history client-side for the “continue chat” UX.
• Fingerprints the user for fraud prevention or analytics.

All of this is “storage of information on terminal equipment” under ePrivacy 5(3). The exception for “strictly necessary for the service the user requested” covers the session state once the user has opened the chat. It does not cover the script loading before the user clicks the chat button.

The compliant pattern: the chat widget loads on click, not on page load. Sites that auto-pop the chatbot are firing storage on every visitor, including ones who never engage. That is ePrivacy 5(3) consent territory.

Cross-border data transfers

Most of the large chatbot platforms (Intercom, Drift, Zendesk, HubSpot) are US-based. EU customer chat transcripts transferred to US servers re-engage the Schrems II / DPF analysis. The current state (DPF in force) means transfers are lawful provided the vendor is DPF-certified — but the framework is under challenge. The General Court dismissed Latombe v Commission (T-553/23) on 3 September 2025, and an appeal (C-703/25 P) is pending before the Court of Justice. Nobody should be building a transfer strategy that only works while the adequacy decision stands.

Vendors headquartered and hosting in the EU reduce this surface: Userlike (Germany), Crisp (France), Tidio (Poland). US vendors offering an EU workspace or EU data region, Intercom among them, narrow it without closing it. The trade-off: feature set is typically smaller and integrations with US-hosted CRMs may re-introduce a transfer at the CRM-write step.

The LLM-backed chatbot question

Chatbots powered by GPT-4 / Claude / Gemini introduce a second layer: the prompt-plus-context sent to the LLM provider is itself a transfer. EU customer messages flowing to OpenAI’s servers are subject to the same transfer analysis as any other US-bound data.

Two mitigation patterns:

• Use an EU-region endpoint where your provider genuinely offers one. Mistral and Aleph Alpha host in the EU. The large US providers offer EU data residency to varying degrees and on varying contract terms, so check the specific product rather than the brand, and check the endpoint rather than the marketing page — eu-west-1, for instance, is an AWS region name, not a model provider’s endpoint. Also: EU hosting reduces the transfer surface, it does not eliminate it. Remote access to EU-stored data from a third country is itself a transfer under Chapter V, so who can reach the data matters as much as where it sits.
• Get explicit consent for the LLM hand-off. Disclose in the chatbot intro and the privacy policy that messages are processed by a third-party LLM provider, named explicitly, with the DPF status disclosed. This is what CNIL has signaled it expects for the LLM era.

Practical 2026 checklist

1. Does the bot identify itself as AI? Required by AI Act Article 50 from August 2026.
2. Does the bot make any decision with legal or significant effect? If yes, Article 22(1) prohibits it outright unless one of the Article 22(2) gateways applies. If one does, build the human-intervention and contest path into the flow by default rather than waiting for a request.
3. Does the bot load before user interaction? If yes, gate it behind consent.
4. Is conversation data stored beyond the session? If yes, disclose retention period in the privacy policy and offer deletion.
5. Is the bot powered by an LLM hosted outside the EU? If yes, ensure DPF certification of the provider and disclose the transfer.
6. Add the chatbot vendor and the LLM provider to your subprocessors page.

What Veracly actually checks, and where it will be wrong

The Article 50 check has shipped — the widget at the top of this post runs it. Here is what it does, in detail, because the limits matter more than the feature.

When a scan’s country scope touches the EU or EEA, Veracly runs a separate AI Act transparency assessment against the homepage. It matches third-party request URLs against 17 chat-widget vendor signatures — Intercom, Drift, Crisp, Tidio, Zendesk Chat, HubSpot Chat, LiveChat, Tawk.to, Freshchat, Olark, Gorgias, Kustomer, Userlike, Smartsupp, Chatra, Front Chat and Help Scout Beacon. Two checks are emitted:

• Check A — chatbot disclosure, Art. 50(1). Widget detected and an AI-disclosure phrase found in the page text: pass. Known vendor and no phrase: fail, high severity, with a copy-paste disclosure snippet. Generic widget pattern with no identifiable vendor: warn, not fail — because the disclosure may live in a runtime message we cannot observe, and manufacturing alarm is the thing we most want to avoid.
• Check D — AI-use clause in your policy. Advisory, low severity. It only warns when AI is actually detected on the site; a site with no chatbot and no clause comes back not applicable, not as a gap.

Checks B (labelling of AI-generated content, Art. 50(2)) and C (deepfake and synthetic-media disclosure, Art. 50(4)) exist in the type union and the database constraint, and the report renderer accepts them. They are not emitted. Nothing in Veracly detects AI-generated content or synthetic media, and we are not going to guess at it.

Four limits to hold in mind before you read a result:

• The widget is never opened. We do not click the launcher and we do not send it a message. A disclosure delivered only as the bot’s first runtime reply — the placement most vendors ship by default — is invisible to the check, so a genuinely compliant site can score a fail. That asymmetry is exactly why the placement advice earlier in this post says to put the disclosure on the closed widget as well.
• The disclosure search is page-wide, not widget-scoped. The word “chatbot” anywhere on the homepage, including in a blog teaser, turns a fail into a pass. The check errs generous in that direction, and you should not read a pass as proof the disclosure is where a user would see it.
• Homepage only. A custom in-house bot with no matching vendor signature or widget selector returns not applicable rather than a verdict.
• The readiness score is its own number. It runs 0 to 100 and never touches your compliance score or any jurisdiction verdict. Article 50 is a transparency-readiness question, not an accessibility or privacy grade, and averaging it into the others would overstate what a scan can prove.

One structural point about how this interacts with the cookie side of a scan. The AI Act vendor signature list and the tracker registry are two separate tables, and they only partly overlap. Nine of the seventeen chat vendors also carry a tracker-registry entry — Intercom, Drift, Crisp, Zendesk Chat, HubSpot, LiveChat, Tawk.to, Olark and Userlike — so if one of those widgets loads before consent, it normally also surfaces on the tracker side as a pre-consent finding, filed under the vendor’s tracker name rather than as anything labelled “chatbot”. The other eight — Tidio, Freshchat, Gorgias, Kustomer, Smartsupp, Chatra, Front Chat and Help Scout Beacon — have no tracker entry at all, so their pre-consent loading is invisible to that half of the scan. It is no less a problem for being invisible; you just have to find it in the storage and request evidence, or in DevTools, yourself.

See also: Is Google Analytics 4 illegal in Europe? · Tracking pixel audit