Chatbot GDPR-Compliant 2026: Duties + AI Act Checklist

Run your chatbot GDPR-compliant: legal basis, DPA, and the new Art. 50 AI labelling duty from Aug 2, 2026. Checklist, copy-ready texts, and a 4-vendor comparison.

You run a GDPR-compliant chatbot when you meet three requirements at the same time: a clean legal basis under Art. 6 GDPR, a data processing agreement with every embedded service under Art. 28, and from August 2, 2026 the AI labelling duty under Art. 50 of the EU AI Act. That third duty is the new one, and it applies to anyone who runs an AI chatbot or voice assistant that talks to end users. It is expressly not covered by the postponement of the high-risk obligations and takes full effect on the deadline.

From that date, your user has to learn clearly and distinguishably, at the latest on the first interaction, that they are talking to an AI. A breach can cost up to 15 million euros or 3% of your worldwide annual turnover (Art. 99(4) AI Act), on top of the GDPR fines of up to 20 million euros or 4%. This article walks you through both regimes: the deadline, the legal basis, a tickable DPA checklist, the consent flow, the storage of RAG data, when you need a data protection impact assessment, and a vendor comparison from the US LLM to the German provider. You also get two copy-ready text blocks for the chat notice and your privacy policy.

The deadline: what applies from August 2, 2026

The EU AI Act is Regulation (EU) 2024/1689. Its Art. 50 governs the transparency duties for providers and deployers of certain AI systems and becomes fully applicable on August 2, 2026. Many companies have heard that parts of the AI Act were postponed. That is true for the high-risk obligations, but it does not apply to Art. 50. The labelling duty for chatbots takes effect on the deadline as planned.

Specifically, Art. 50(1) requires this: anyone who deploys an AI system for direct interaction with natural persons has to design it so that the people concerned are informed that they are interacting with an AI system. There is only one exception, namely when this is obvious anyway from the point of view of a reasonably well-informed, observant and circumspect person. With a text chat on your website you usually cannot rely on that, because many users cannot reliably tell whether they are writing to a human or to an AI.

The timing sits in Art. 50(5): the information has to be given clearly and distinguishably at the latest at the time of the first interaction or exposure, and it has to be accessible. So a sentence buried deep in your privacy policy is not enough. The notice belongs directly in the chat window, visible before the user sends their first message.

Art. 50 goes beyond the chat itself. Para. 2 requires that AI-generated audio, image, video and text content be marked in a machine-readable way as artificially generated. For generative systems that were already on the market before August 2, 2026, the AI Omnibus agreement of May 2026 extended the deadline for this machine-readable marking to December 2, 2026. On June 10, 2026, the EU Commission additionally published a Code of Practice on Transparency of AI-Generated Content. Anyone who signs it is deemed compliant with Art. 50 and thereby gets a workable template for the implementation.

Who is affected: providers, deployers and you

The AI Act distinguishes two roles, and the duty hits both. Providers develop the system and place it on the market, for example Tidio or OpenAI. Deployers, called operators in everyday terms, use it under their own responsibility. As soon as you run a chatbot on your website or in customer service, you are a deployer and fall directly within the scope of Art. 50, even if you only bought the system and programmed nothing yourself.

Who holds the role decides who is liable for the labelling. The provider has to build the system technically so that labelling is possible. As a deployer you have to make sure it actually appears in your deployment and cannot be clicked away. If your chatbot tool makes the greeting message configurable, it is on you to enter the AI notice there.

Watch out for a trap here: the AI Act and the GDPR use two different role models that do not map onto each other one to one. The AI Act knows providers and deployers. The GDPR knows the controller and the processor. In a typical setup you are the deployer under the AI Act and at the same time the controller under the GDPR, while your chatbot vendor is the provider under the AI Act and your processor under the GDPR. The short overview below keeps the two apart.

How widespread the topic has become is shown by the Bitkom AI study 2026: 41% of German companies already use AI actively, up from 17% the year before, with a further 48% planning to adopt it. 42% use AI in customer service. So if you are still weighing up whether a chatbot is worth it at all, read the article on the AI chatbot for your website first. Once you decide to deploy one, the duties described here take effect.

The fine risk: two regimes side by side

The penalties from the AI Act and the GDPR apply cumulatively. So you can be pursued for the same chatbot from both directions. The AI Act works in Art. 99 with three tiers: up to 35 million euros or 7% of turnover for prohibited practices, up to 15 million euros or 3% for breaches of the obligations of providers and deployers including the transparency duty under Art. 50, and up to 7.5 million euros or 1.5% for false information to authorities. For chatbot deployers the middle tier is the relevant one. The GDPR sets in Art. 83 up to 20 million euros or 4% of turnover for serious breaches, for example a missing legal basis or violated information duties.

The Italian Garante shows what enforcement looks like. On May 19, 2025 it fined the AI chatbot Replika, operated by Luka Inc. from the US, 5 million euros. The reasoning reads like a checklist of chatbot duties: Luka could not demonstrate a legal basis for the processing (Art. 6), essential details were missing from the privacy policy, among them the processing of EU user data outside the EU (Art. 13), and the protection of minors was inadequate. In the wider AI enforcement landscape, Clearview AI collected around 20 million euros in fines across several EU states between 2022 and 2024, 20 million euros from the Italian Garante alone, for biometric data processing without a legal basis.

The following overview places the maximum fine frameworks side by side. The two middle bars are the realistic risk for a customer service chatbot; the 7.5-million tier is shown in green because it is the least likely to bite. The 35-million prohibited-practice tier is left out, because it does not apply to an ordinary support chatbot. The amount in each case is the higher of the fixed sum and the turnover share, shown here as the fixed sum.

For the classic customer service chatbot the two relevant values are 15 million euros under Art. 50 for missing AI labelling and 20 million euros under the GDPR for a missing legal basis. Both can be avoided with manageable effort if you implement the duties before the deadline.

The legal basis: choosing Art. 6 GDPR correctly

Every processing of personal data in the chat needs a legal basis. Which one fits depends on the purpose. If your chatbot handles orders, bookings or the run-up to a contract, Art. 6(1)(b) (contract) applies. If it answers a customer enquiry, you can rely on Art. 6(1)(f) (legitimate interest), but you have to document the balancing of interests. For anything beyond that, for example marketing, profiling or training a model with the inputs, you need explicit consent under Art. 6(1)(a).

On top of that comes the information duty under Art. 13. At the latest at the time of data collection you have to inform precisely and understandably about the controller, legal basis, purposes, recipients, a possible third-country transfer, storage period and data subject rights, plus a note on the chatbot deployment and the rough way the AI works. This GDPR information is separate from the Art. 50 labelling, but in practice you combine both in the first bot message and the privacy notice linked there. To make that part quick, here is a passage you can adapt and drop into your privacy policy.

A risk of its own are special categories under Art. 9, that is health, religious or biometric data. Your chatbot must in principle not process them, except with explicit consent. The practical problem is called volunteered data: users type sensitive information into the chat unprompted. How serious that is depends on your industry, and the three cases below show how differently the same chat behaves across sectors.

Across all three you need filters and deletion routines that recognise and remove such inputs, plus the visible short note "do not enter sensitive data". All data collected in the chat also has to remain reachable for the data subject rights, that is for access (Art. 15), rectification (Art. 16), erasure (Art. 17) and objection (Art. 21).

The data processing agreement: a tickable checklist

As soon as an external service processes personal data on your behalf, you need a data processing agreement (DPA) under Art. 28(3). That applies to every chatbot SaaS and to the OpenAI API. You are the controller, the service is your processor, and every further service behind it is a sub-processor. It is exactly this chain that many overlook. Open the following points and check your DPA piece by piece.

These four blocks cover the twelve mandatory components of Art. 28. Download every provider's DPA and tick them off. With most SaaS chatbots a pre-prepared DPA is ready; you only have to retrieve and sign it. If you build Custom Tools with your own connection to an LLM, the DPA with the LLM provider belongs in there just as much as the contracts with the vector database and the embedding service.

The consent flow: two layers, the right order

With a chatbot two separate layers come into play, and they must not be mixed up. The first is the cookie and consent layer under the GDPR and the ePrivacy rules. If your chatbot loads cookies via a third-party script like Crisp or Tidio, or transfers data to a server before the user becomes active, you need consent in the cookie banner before the widget loads. The clean order: the page loads, the consent banner appears, the user consents, only then does the chatbot script load. Alternatively you load the widget only when the user actively clicks on it, then no tracking starts unprompted.

The second layer is the AI transparency notice under Art. 50. It is independent of the cookie consent. The notice "you are chatting with an AI" has to appear clearly and distinguishably at the latest on the first interaction, visible in the chat window or as part of the greeting, before the user sends their first message. This notice is a piece of mandatory information, not a consent. It must not be clickable away or skippable. Additionally link the privacy policy at the chat window and add the short note not to enter any sensitive data.

If you are setting up the cookie layer anyway, it is worth a look at the mechanics behind it. The article on GA4 Consent Mode v2 shows how to pass consent signals through cleanly instead of simply blocking scripts blindly. You apply the same logic to the chatbot widget.

RAG data: where your company data ends up and how you delete it

Many modern chatbots work with retrieval augmented generation. Here your company documents are stored as embeddings in a vector database and sent to the language model as context at runtime. Three places are critical for data protection: the vector database itself, the embedding service, and the LLM including any logging. Each of these places has to be GDPR-compliant, ideally hosted in the EU, and covered by a DPA. If you overlook just one of them, the data protection hangs on the weakest point.

Hosting is where providers diverge most. OpenAI stores on US servers by default. The transfer is secured via the EU-U.S. Data Privacy Framework, the adequacy decision of the EU Commission of July 10, 2023, and OpenAI is DPF-certified, with SCC applying in addition. This is the Schrems II logic in 2026: the Data Privacy Framework replaced the struck-down Privacy Shield, but the EU authorities still recommend a transfer impact assessment (TIA) on top, in which you check the residual access risk under the US CLOUD Act for the data you actually transfer. Anyone who wants to lower the US risk further has EU-compliant options: the OpenAI API with European Data Residency and Zero Data Retention, where requests are not stored at rest, plus Azure OpenAI in the EU Data Zone or Frankfurt, AWS Bedrock Frankfurt, or the fully sovereign route via Aleph Alpha in Heidelberg with BSI C5 and optional on-premise operation. The last one eliminates the risk from the US CLOUD Act. A sense of the risk picture comes from the US court that, in October 2025, ended the previously ordered duty of OpenAI to retain output logs, with an express exception for requests from the EEA, Switzerland and the UK.

For the deletion concept, purpose limitation plus a defined storage period in the vector database applies. Set a concrete interval, for example 30 or 90 days, and document the deletion routines, also for volunteered personal data that can sit inside embeddings. Activate Zero Data Retention at the LLM and govern deletion or return after the contract ends through the DPA. The most pragmatic protection: do not take any personal data into the RAG index at all, and if you do, then pseudonymised. That shifts the risk before it even arises. Anyone who wants to set up the hosting of the entire application cleanly will find the basics for server location and data processing in the article on GDPR-compliant hosting.

DPIA: when your chatbot needs a data protection impact assessment

For some chatbots a legal basis and a DPA are not enough. Art. 35 GDPR requires a data protection impact assessment (DPIA, in German DSFA) whenever a processing is likely to result in a high risk to the rights and freedoms of natural persons. For chatbots three triggers matter. First, large-scale processing of special categories under Art. 9, for example a health chatbot in a medical practice. Second, systematic and extensive monitoring or evaluation, for example a bot that profiles user behaviour or scores leads. Third, the use of new technology, and the German supervisory authorities count generative AI among exactly that.

The practical entry point is a threshold analysis: you check your chatbot against the criteria above and against the must-list of the German Data Protection Conference (DSK). If two or more criteria are met, a DPIA is the safe assumption. A plain support bot on legitimate-interest basis without special categories and without profiling usually stays below the threshold, but you document that decision too.

If a DPIA is required, you run it in four steps. First, a systematic description of the processing, the data flows and the technology, including the LLM and the RAG chain. Second, an assessment of the necessity and proportionality in relation to the purpose. Third, an assessment of the risks to the data subjects, for example the leak of volunteered health data. Fourth, the measures to address those risks, for example input filters, encryption, EU hosting, Zero Data Retention and short deletion intervals. The DPIA is documentation you keep on file and update when the chatbot changes; it also becomes the backbone of your accountability under Art. 5(2).

Vendor comparison: location, DPA and sub-processors

The choice of provider decides how much compliance work is left on your plate. The following overview compares four common options along the three criteria that tip the balance in the DPA: data location, availability of a DPA, and the location of the sub-processors. Green stands for the most data-sovereign option, red for the one with the highest review effort.

The practical consequence: for maximum data sovereignty at public bodies or critical sectors, Aleph Alpha is the safest choice, though more expensive and more involved than a SaaS widget. Crisp and Tidio offer a solid EU profile for small and mid-sized businesses, you only have to check whether their AI answers run via OpenAI, because then OpenAI enters your chain as a further sub-processor. The OpenAI API directly is powerful for your own chatbots, but GDPR-suitable only with EU Data Residency and Zero Data Retention activated, or with consistent pseudonymisation. If you integrate a chatbot into your shop, the article on the WooCommerce AI chatbot shows what matters in practice for the connection.

Implementation checklist: GDPR and AI Act in one audit

Instead of two separate lists you merge both regimes in one pass. Work through the following points before August 2, 2026. The first three are prerequisites and quickly done, the later ones need more lead time because contracts and hosting decisions hang on them.

Once you have ticked off these nine steps, your chatbot is legally sound on the deadline. The first three cost you an afternoon, the later six depend on how many services sit in your chain and where they host. It is exactly this architecture, from the consent flow to the EU-hosted RAG index, that we build at zenku.studio as Custom Tools, so that compliance is built in from the start instead of bolted on afterwards.

Frequently asked questions

Is a chatbot GDPR-compliant and what duties apply from 2026?

A chatbot is GDPR-compliant when you have a legal basis under Art. 6, meet the information duty under Art. 13 and conclude a DPA under Art. 28 with every embedded service. From August 2, 2026 the AI labelling duty under Art. 50 of the EU AI Act is added: the user has to learn clearly, at the latest on the first interaction, that they are talking to an AI. Only all duties together make the chatbot legally sound.

Do I need consent before users chat with the chatbot?

That depends on the purpose. For simply answering a customer enquiry, the legitimate interest under Art. 6(1)(f) is usually enough, so you do not need consent for the chat itself. But if the chatbot widget loads cookies via a third-party script or transfers data before the user becomes active, consent in the cookie banner is needed beforehand. So load the widget only after opt-in or only when the user actively clicks on it.

Does a chatbot have to be labelled as AI from August 2026?

Yes. Art. 50 of the EU AI Act requires from August 2, 2026 that every chatbot with end-user contact informs users that they are interacting with an AI system. The notice has to appear clearly and distinguishably at the latest on the first interaction, that is visible in the chat window or in the greeting, before the first message is sent. It does not belong in the terms of service and must not be clickable away.

When does a chatbot need a data protection impact assessment?

A DPIA under Art. 35 GDPR is needed when the processing is likely to cause a high risk, for example large-scale processing of special categories under Art. 9, systematic profiling of users, or the use of new technology such as generative AI. Run a threshold analysis against the criteria of the German Data Protection Conference; if two or more apply, carry out a full DPIA in four steps: description, necessity, risk assessment and mitigating measures.

May I use a US provider like ChatGPT or OpenAI in a GDPR-compliant way?

Yes, under conditions. You need a DPA, which for EEA customers is concluded with OpenAI Ireland Ltd., and a safeguard for the US transfer via the EU-U.S. Data Privacy Framework, under which OpenAI is certified, or via standard contractual clauses plus a transfer impact assessment. Additionally activate European Data Residency and Zero Data Retention so that requests are not stored in the US. Without these settings you should not transfer any personal data without pseudonymisation.

What fines apply for a chatbot that is not GDPR- or AI Act-compliant?

Both regimes apply cumulatively. From the AI Act a breach of the transparency duty under Art. 50 risks up to 15 million euros or 3% of worldwide annual turnover (Art. 99(4)). From the GDPR up to 20 million euros or 4% is added, for example for a missing legal basis. The Italian Garante already imposed a 5 million euro fine on the AI chatbot Replika in May 2025.