AI chatbots in business: what data protection requires
Updated on 23 September 2026: references to papers by public authorities that could not be traced to any published document have been removed. The requirements for transfers to third countries now name the EU-US Data Privacy Framework in addition to standard contractual clauses.
AI chatbots process personal data. Which GDPR requirements apply to the legal basis, information obligations, the DPA and deletion? A practical guide.
AI chatbots are everywhere. On company websites they answer customer questions, on the intranet they help employees search for documents, and as virtual assistants they are increasingly taking over first-level support. The barriers to entry are low, and functionality has improved significantly thanks to large language models.
A chatbot on a website processes personal data from day one (names, email addresses, enquiries, sometimes even health or financial data). That is why you need an adapted privacy notice, a data processing agreement with the chatbot provider and deletion routines for chat histories from the start.
This article works systematically through the relevant GDPR articles and shows what companies specifically need to consider when they use a chatbot, whether on their own website, in customer service or internally. No theoretical treatises, but practice that your data protection officer can implement on Monday.
Art. 6 GDPR: the legal basis for chatbot data
Any processing of personal data requires a legal basis under Art. 6(1) GDPR. In practice, three options are possible for chatbots, and the choice has far-reaching consequences for the design of the entire system.
The most common basis for website chatbots is legitimate interest under Art. 6(1)(f) GDPR. The reasoning: the company has a legitimate interest in answering customer enquiries efficiently and improving customer service. In its Short Paper No. 3 the German Data Protection Conference (DSK) set out the requirements for legitimate interest in more detail: a balancing of interests must be documented that weighs the company's interest against the reasonable expectations of the data subjects. For a website chatbot that answers general product questions, this balancing will generally come out in the company's favour. Users expect a communication channel on a company website, and the data processing is limited to the conversation.
The situation is different if the chatbot processes special categories of personal data under Art. 9 GDPR, for example health data in a chatbot for a medical practice or an insurance company. In this case, Art. 6(1)(f) no longer applies, and explicit consent under Art. 6(1)(a) in conjunction with Art. 9(2)(a) GDPR is required. This means: active opt-in before the chat, no pre-ticked checkboxes, clear information about the data processing, and the option to withdraw at any time. Consent that is merely inferred from use of the chatbot is not sufficient for this, because Art. 9(2)(a) GDPR requires explicit consent.
For internal chatbots that process employee data, there is also Art. 6(1)(b) GDPR to consider: processing for the performance of the employment contract. However, this only applies if the chatbot is actually necessary for performing the work and is not merely an optional tool. Documenting the chosen legal basis in the processing register under Art. 30 GDPR is mandatory in any case.
Art. 13/14: what users need to know BEFORE the chat
The information obligations under Art. 13 and 14 GDPR are central when using chatbots. Art. 13 requires the controller to provide a comprehensive list of information at the time the data is collected, i.e. before the user enters the first message. This includes: the identity and contact details of the controller, the contact details of the data protection officer, the purposes and legal basis of the processing, legitimate interests (if Art. 6(1)(f) applies), the recipients of the data, the storage period and the rights of data subjects (access, rectification, erasure, restriction, objection, data portability, complaint to the supervisory authority).
In practice, this means: before the chatbot dialogue begins, the user must have access to this information. A tiered approach has proven effective: a short notice directly in the chatbot window (e.g. "Your data is processed to answer your enquiry. You can find out more in our privacy policy.") with a link to the full privacy policy, which contains all the information required under Art. 13 GDPR. It is important that the link is visible before the first data entry, not only after the first message has been sent.
A particularly elegant solution is a pre-chat form: before the actual chat begins, the user is asked for their name and email address and confirms via a checkbox that they have read the privacy information. This has three advantages: first, the information obligations are demonstrably fulfilled. Second, it allows the chat history to be attributed to a person, which is relevant for responding to access requests under Art. 15. Third, consent for special categories of data can be obtained if required.
Art. 28 Processing on behalf of a controller: the DPA with the chatbot provider
When a company uses an external chatbot service (and this is the case for the vast majority of implementations), this generally constitutes processing on behalf of a controller under Art. 28 GDPR. The chatbot provider processes personal data (chat messages, IP addresses, where applicable names and email addresses) on behalf of and on the instructions of the company. For this, a data processing agreement (DPA) is mandatory, not optional, not "nice to have", but a legal obligation. An infringement can be punished under Art. 83(4) GDPR with fines of up to €10 million or 2 per cent of worldwide annual turnover.
Under Art. 28(3) GDPR, the DPA must cover at least the following points: subject matter and duration of the processing, nature and purpose of the processing, type of personal data and categories of data subjects, obligations and rights of the controller, technical and organisational measures (TOMs), use of subprocessors, assistance with data subject rights, deletion or return at the end of the processing, and obligations to provide evidence. In its Short Paper No. 13 the DSK set out detailed requirements for the DPA that go beyond the bare wording of the law.
You should take a particularly close look if your chatbot provider uses subprocessors outside the EU. If they process the data outside the EU or access it from there, this generally constitutes a transfer to a third country under Chapter V GDPR. In that case, a basis for the transfer is required in addition to the DPA: for example, the recipient's certification under the EU-US Data Privacy Framework or Standard Contractual Clauses (SCCs), for which the Schrems II judgment requires a case-by-case assessment of the level of protection, usually documented as a Transfer Impact Assessment (TIA). Things are simpler with a chatbot provider that keeps the entire processing chain within the EU: European hosting, a European AI model, no US subprocessors.
Art. 17 Right to erasure: deleting chat histories
The right to erasure under Art. 17 GDPR (also known as the "right to be forgotten") applies without restriction to chat histories. If a user requests the deletion of their chat data, the company must delete this data "without undue delay". Art. 12(3) GDPR sets a deadline of one month for responding to such a request, which can only be extended for complex or numerous requests. In practice, it should be much faster. This applies to the chat messages themselves, to metadata (IP address, timestamp, session ID) and to all derived data that the AI model has generated from the chat.
In practice, implementation often fails because of the technical architecture. If chat histories are stored in a database owned by the company, deletion is technically simple. It becomes problematic if the chatbot provider stores the data on its servers, or worse still, if the training of the AI model draws on the chat data. In this case, deletion from the training data may be technically impossible ("machine unlearning" is an active field of research, but not yet a market-ready technology).
When choosing a chatbot provider, companies should therefore pay attention to the following points: first, are chat histories stored exclusively in the company's account and not with the provider? Second, is chat data not used to train the AI model? Third, is there a technical interface (API) for the automated deletion of individual chat histories? And fourth, is the storage period configurable? Because even without an active deletion request from a user, the principles of storage limitation under Art. 5(1)(e) GDPR require chat histories to be deleted once the purpose of the processing no longer applies. Retaining chat histories "forever" or "for quality improvement" without a time limit is not GDPR-compliant.
The practical test: US providers and the Art. 15 right of access
Imagine the following scenario: a customer of your company submits a subject access request under Art. 15 GDPR. They want to know what data is stored about them, including their chat histories with the chatbot on your website. As the controller, you are obliged to provide complete information within one month: what data is processed, for what purpose, who has access, how long it is stored and whether it is transferred to third countries.
If your chatbot is operated by a European provider that stores the data on European servers, this is feasible. You request the data from the provider (the DPA obliges it to assist with data subject rights under Art. 28(3)(e) GDPR) and pass it on to the customer. But what happens if your chatbot runs through US providers instead? The data is then held by a provider that is subject to US law, even if it stores the data in Europe. The CLOUD Act applies to it. Under this act, US authorities can, under certain conditions, demand the disclosure of data, even if it is stored outside the USA.
In the information provided under Art. 15(1)(c) GDPR, you must state the "recipients or categories of recipient" of the data. Are US authorities "recipients" within the meaning of the GDPR if they have access on the basis of the CLOUD Act? In its Recommendations 02/2020 the European Data Protection Board made clear that access by public authorities in third countries must be taken into account in the risk assessment. In practical terms, this means: if you cannot rule out with certainty that US authorities have accessed the chatbot data, you have a problem fulfilling your obligation to provide information, and an even bigger problem ensuring confidentiality under Art. 5(1)(f) GDPR. The simplest way to resolve this dilemma is to choose, from the outset, a chatbot provider whose processing chain lies within the EU and which is not subject to any extraterritorial right of access.
Checklist: a GDPR-compliant chatbot in 7 points
The following seven points summarise the key GDPR requirements for a chatbot. Use this checklist as a starting point for your own compliance review, and discuss each point with your data protection officer.
- 1. Document the legal basis (Art. 6 GDPR): Define the legal basis for data processing by the chatbot. For general website chatbots, this is usually Art. 6(1)(f) (legitimate interest) with a documented balancing of interests. For special categories of data: explicit consent under Art. 9(2)(a). Do not forget the entry in the processing register under Art. 30.
- 2. Fulfil the information obligations (Art. 13/14 GDPR): Make sure that users are informed about the processing before they enter any data. At a minimum: a short notice in the chat window with a link to the full privacy policy. Ideally: a pre-chat form with active acknowledgement of the privacy information.
- 3. Conclude a DPA (Art. 28 GDPR): Conclude a complete data processing agreement with the chatbot provider. Check the chain of subprocessors. Are services outside the EU involved? If so: the transfer needs a basis under Chapter V GDPR, for example the EU-US Data Privacy Framework or SCCs with a TIA. The law to which the provider is subject remains part of the risk assessment.
- 4. Implement deletion routines (Art. 17 + Art. 5(1)(e) GDPR): Define retention periods for chat histories and implement automated deletion. Make sure that individual deletion requests can be implemented technically. Clarify whether the provider uses chat data for model training. If so, that is an exclusion criterion.
- 5. Ensure you can respond to access requests (Art. 15 GDPR): Can you provide complete information on all chat data of a specific user within one month? Is there an export function? Can the chat history be attributed to a user? Clarify these questions before go-live, not when the first access request arrives.
- 6. Review technical and organisational measures (Art. 32 GDPR): Encryption of chat data in transit (TLS) and at rest (AES-256). Access controls: who in your company can read chat histories? Logging of access. Regular review of the measures.
- 7. Check the need for a data protection impact assessment (Art. 35 GDPR): For extensive or systematic processing (for example chatbots in healthcare, at banks or chatbots with profiling functions), a data protection impact assessment (DPIA) is mandatory. Art. 35(3)(c) GDPR expressly names the systematic monitoring of a publicly accessible area on a large scale as a case requiring a DPIA. In addition, in its list of processing operations for which a DPIA must be carried out (version 1.1 of 17 October 2018, often called the “blacklist”) the DSK lists under number 11 the "use of artificial intelligence to process personal data in order to control interaction with data subjects or to evaluate personal aspects of the data subject" and expressly names customer support using artificial intelligence as a typical area of application. A chatbot that advises customers in dialogue therefore falls directly within its scope.