Dreistein Media Development Home

Chatbot and GDPR: what operators need to know in 2026

A chatbot on a website processes personal data – at the latest the moment a visitor types a question. From then on the General Data Protection Regulation applies in full: legal basis, information duties, data processing agreements, retention periods. Since August 2026 the transparency obligations of the European AI Act apply on top. This page walks through the requirements in order, names typical mistakes and ends with a checklist. It is not legal advice – it shows which questions to put to your provider and your data protection officer. How our platform dAi Pro solves each point technically is noted along the way.

What data a chatbot processes – often more than you think

Before checking legal bases, a sober inventory pays off. A website assistant typically processes:

  • Free-text input – visitors write whatever they like: names, customer numbers, health details. Free-text fields are why a chatbot never processes "only technical data".
  • Technical data – IP address, timestamps, browser, session identifier. They arise on every request and are personal data.
  • Conversation history – the sequence of questions and answers, often kept across several page views.
  • Attachments and voice – uploaded files, photos and voice recordings, if the assistant offers them.
  • Contact details – as soon as a conversation is handed over to a human, an e-mail address or phone number is added.
  • Data at the AI provider – the question and the supplied knowledge passages travel to the language model. Where it runs and what it stores is the decisive question of the whole review.

Processing does not start at the send button, by the way: if the chat widget loads scripts or fonts from third-party servers on page load, the IP address has already been transmitted.

Legal basis: legitimate interest, contract or consent?

For the basic operation of a website assistant that answers visitor questions from your own content, legitimate interest under Art. 6(1)(f) GDPR is usually the candidate: the visitor asks the question, expects an answer, and processing stays limited to that purpose. The balancing test should be documented. If the conversation prepares a contract – requesting a quote, booking an appointment – Art. 6(1)(b) applies in addition.

Consent becomes necessary when more happens than answering the question: storage on the device that is not technically required (in Germany § 25 TDDDG, the ePrivacy implementation), tracking or profiling, transfers to providers whose level of protection requires consent as the transfer basis, or voice recordings kept beyond mere transcription. Rule of thumb: the less the chatbot stores and links beyond the answer, the more robust the legitimate interest – and the fewer consent banners the website needs.

Information duties: what belongs in the privacy policy

Art. 13 GDPR requires visitors to learn before processing what happens to their data. For the chatbot this means a dedicated section in the privacy policy covering:

  • Purpose and legal basis – answering enquiries, legitimate interest or contract respectively.
  • Recipients – hosting provider, chatbot provider, language model provider and, where applicable, transcription and speech services, each with country of establishment.
  • Third-country transfers – whether data leaves the EU and on which basis.
  • Retention period – concretely in days, not "as long as necessary".
  • Data subject rights – access, erasure, objection, complaint to the supervisory authority.
  • Automated processing – that answers are machine-generated and do not constitute legally binding decisions.

A short notice right inside the chat, reachable via an info icon, has proven itself in addition: what happens to the question, what is stored, what not to enter. The assistant on this website does exactly that – click the question mark in the chat window.

Data processing agreement: the contract with the chatbot provider

If a service provider runs the chatbot for you, it is a processor – and Art. 28 GDPR requires a written data processing agreement (DPA). The special feature with chatbots: behind the provider there is almost always a further service provider, the operator of the language model. The chain must be complete. Points to check:

  • Processing on instructions – data is processed only for your purpose, not for the provider's own purposes.
  • No training – an explicit exclusion of using inputs or your content to train models.
  • Sub-processors – a complete list with country of establishment, changes with a right to object.
  • Erasure – periods for conversation data and return or deletion at the end of the contract.
  • Technical and organisational measures – as an annex, not as a reference to a website.
  • Control and audit rights plus support with data subject requests.

With dAi Pro you conclude the data processing agreement online already for the free demo; for production we supply the documents for your data protection officer – including the contract chain to the language model provider Mistral, described on the page What is Mistral AI?.

Third-country transfers: USA, CLOUD Act and the European alternative

If the language model runs with a US provider, visitor questions leave the EU – or are at least within reach of a US company. Legally this needs a transfer basis: an adequacy decision such as the EU-US Data Privacy Framework, whose validity is being challenged in court, or standard contractual clauses plus an assessment of the destination law. Even a data centre in Frankfurt does not fully solve the problem: the US CLOUD Act obliges American companies to hand over data regardless of where it is stored.

The structurally simpler answer is European providers: if the language model runs at Mistral AI in Paris and hosting is in Germany, no third-country transfer takes place – the entire assessment chain disappears. How a sovereign digital stack is put together is described on European and secure; why "EU servers" alone are not enough is explained on GDPR-compliant AI.

Data minimisation: what may go to the language model – and what may not

Art. 5 GDPR requires processing only the data necessary for the purpose. For chatbots this translates into three rules:

  • Only relevant passages, never the whole knowledge base. With retrieval-augmented generation only the matching text excerpts travel to the model per question – a privacy advantage described in depth on RAG and CAG explained.
  • No customer data in the prompt. The assistant answers questions from public or released content; customer databases, ticket systems or mailboxes do not belong in the context window unfiltered.
  • Notices instead of hope. Anyone offering free text should ask visitors not to enter health or payment data – and not keep inputs that arrive anyway longer than necessary.

Purpose limitation also means: chat logs serve answering and quality control, not the building of advertising profiles.

Retention and deletion concept

"We delete as soon as the data is no longer needed" is not a period. A chatbot needs a deletion concept with concrete numbers:

  • Conversation logs – a short period, say 30 to 90 days, sufficient for quality control and abuse prevention. Then automatic deletion, not a manual reminder.
  • IP addresses – do not store them at all or truncate immediately; for rate limiting against abuse a hash for a few hours is enough.
  • Attachments and voice recordings – process transiently only: extract text or transcribe, discard the original.
  • Handovers to humans – end up in the e-mail or ticket system and follow its periods.
  • Test data – delete demo and test instances including their content after completion and confirm the deletion.

Remember backups: periods must apply there too. And data subject rights: whoever requests access or erasure must be attributable – pseudonymous session identifiers in the log make that possible without storing real names. dAi Pro deletes conversation logs on this website automatically after 90 days and removes demo instances after seven days together with all data.

No training with your data – and why a ChatGPT account is not enough

The most common mistake in practice: a chatbot is set up on a consumer account of an AI service. Consumer terms apply there, inputs may be used to improve the model, and no data processing agreement exists. For business use, therefore:

  • Access only via business or API contracts that contractually exclude use for training.
  • Where available, use options without data retention at the provider ("zero data retention").
  • The assurance must sit in the contract chain – from the chatbot provider to the model operator.

With dAi Pro, requests run by default through the business interface of Mistral AI in France; neither your content nor your visitors' questions are used for training. Which model works is your decision per knowledge collection – documented and changeable at any time.

Technical and organisational measures

Art. 32 GDPR requires security "in line with the state of the art". For a website chatbot this includes at least:

  • Encrypted transmission between browser, chatbot and language model.
  • Access control in the backend: roles and rights defining who may read logs and change knowledge sources.
  • Tenant separation when several knowledge bases sit on one system.
  • Logging of every AI call – for traceability and cost control.
  • Abuse protection through rate limiting and data-sparing bot detection; methods that themselves collect data extensively only move the problem.
  • A release process for knowledge sources: the assistant knows only what was deliberately released – document by document, not "everything on the server".

The measures belong in an annex to the data processing agreement. With on-premises operation the responsibility lies with you – dAi Pro runs entirely on your infrastructure if desired.

Data protection impact assessment: when a chatbot needs a DPIA

A data protection impact assessment under Art. 35 GDPR is mandatory when processing is likely to result in a high risk for data subjects. For chatbots this is typically the case with:

  • processing of special categories – health, finances, religion – for instance assistants of clinics, insurers or counselling services,
  • systematic evaluation or profiling of users,
  • use towards vulnerable groups, such as children or patients,
  • new technologies with large data volumes or the linking of several data sources.

An assistant that answers questions from public website content, profiles nothing and keeps logs briefly usually does not need a DPIA – but the assessment itself should be documented, and the entry in the record of processing activities under Art. 30 is mandatory in any case. In doubt, the data protection officer decides, not the provider.

AI Act: labelling duty since August 2026

Alongside the GDPR, Article 50 of the European AI Act has applied to chatbots since 2 August 2026. The core of the transparency duty: people must be able to recognise that they are interacting with an AI system – unless this is obvious from the circumstances. In practice this means:

  • The assistant carries a clear AI label, for instance "AI assistant" in its name and welcome text – not just in the small print.
  • AI-generated texts published as content must be labelled in a machine-readable way.
  • The chatbot must not pose as a human and must enable handover to a person where it matters.

A website assistant that answers product questions is not a high-risk system under the regulation; operator duties remain manageable. What else the regulation means for companies is summarised on European and secure. dAi Pro assistants carry the AI label in their display name and point out machine generation in the help text.

Hallucinations are a privacy and liability issue too

A chatbot that invents answers is not merely embarrassing. If it invents statements about people, that violates the principle of accuracy (Art. 5(1)(d) GDPR). If it makes false promises about prices or conditions, the company may be bound by them – in 2024 an airline in Canada had to honour a refund rule its chatbot had made up. The remedies are technical:

  • Strict grounding – the model may answer only from released content and says openly when it does not know something.
  • Source citations – every answer points to where it was found; visitors can verify.
  • Handover to humans – for everything that has to be binding.
  • Logging and rating – so that wrong answers get noticed and corrected.

What an assistant with sourced answers looks like in practice is shown on GDPR-compliant AI chatbot for your website.

Special cases: voice bots, file uploads, logged-in users

Three features deserve a second look:

  • Voice input and read-aloud. A voice recording can contain biometric data if it is used for identification. For pure transcription: process the recording transiently, reuse only the text, choose a provider established in the EU and mention the process in the privacy policy. On this website a French service handles transcription; the audio data is not stored.
  • File and photo uploads. Visitors happily upload more than necessary – invoices, ID cards. Files should only be turned into text transiently and neither stored nor carried into answer caches.
  • Logged-in users. Personal answers for customers in a login area are possible if the identity is verified server-side and only the attributes needed for the answer reach the prompt. The legal basis is then usually the contract with the customer.

The checklist: 12 points for a GDPR-compliant chatbot

  • 1. Data flow documented – which data goes where, to which providers, into which country.
  • 2. Legal basis determined – legitimate interest with a documented balancing test, contract or consent.
  • 3. Privacy policy extended – a dedicated chatbot section under Art. 13, plus a short notice in the chat.
  • 4. DPA concluded – with the chatbot provider, including a complete sub-processor chain.
  • 5. Training excluded – contractually, all the way to the model operator.
  • 6. Third-country transfers resolved – or avoided through European providers.
  • 7. Widget loads sparingly – no connections to third-party servers before the first interaction.
  • 8. Retention periods concrete – logs in days, IP addresses not at all or truncated, attachments transient.
  • 9. Access and logging regulated – roles in the backend, every AI call traceable.
  • 10. AI label visible – Article 50 AI Act: name, welcome message, help text.
  • 11. Grounding and sources – no invented answers, handover to humans possible.
  • 12. DPIA checked and processing record created – assessment documented, record of processing activities updated.

Typical mistakes from practice

  • Consumer chat as backend – a private account with an AI service, without a DPA and with training use.
  • Widget with pre-connections – scripts, fonts or images are loaded from US servers on page load before anyone opens the chat.
  • Gap in the contract chain – a DPA with the chatbot provider, but no arrangement for the language model behind it.
  • Logs without end – conversation histories are kept indefinitely "for analysis".
  • The whole database in the prompt – the customer base is sent along as context so the bot "knows everything".
  • No AI notice – the assistant is called "Lisa" and answers in the first person, without labelling.
  • No handover – visitors with complaints or contract questions go round in circles instead of reaching a human.
  • Privacy policy forgotten – the chatbot is live, the section about it is missing.

How dAi Pro implements the requirements

Our platform dAi Pro is built for European requirements, not adapted afterwards:

  • Hosting in Germany, on request entirely on your infrastructure.
  • European language models first – Mistral AI (Paris) as default; US models only where you consciously decide so.
  • Only relevant passages go to the model, never the whole knowledge base; no use for training.
  • Data processing agreement online – already for the free demo, with documents for your data protection officer.
  • Deletion built in – logs automatically after the period, demo instances after seven days together with all data.
  • Labelling and help text – AI label in the display name, privacy notice one click away in the chat.
  • Grounding, sources, handover – every answer sourced, an honest "I do not know", forwarding to your team including the history.
  • Logging and cost control – every AI call traceable, answers rated by visitors.

Try it: the GDPR-compliant AI chatbot for your website is ready in about 15 minutes as a free demo with your real content – data processing agreement included. All features in detail are shown in the feature overview.

Frequently asked questions about chatbots and the GDPR

For merely answering questions from your own content, usually not – legitimate interest carries this if processing stays limited to that purpose. Consent becomes necessary as soon as the chatbot stores data on the device that is not technically required, tracks users or transfers data to providers for which consent is the transfer basis.

Not advisable for business use: consumer accounts offer no data processing agreement, inputs may be used to improve the model, and processing takes place in the USA. Use business or API contracts with a training exclusion – or European providers such as Mistral AI.

Yes. Since 2 August 2026, Article 50 of the AI Act requires that people can recognise when they are interacting with an AI system. A label in the name and welcome message of the assistant fulfils this; a notice only in the privacy policy does not.

The GDPR names no period but demands a concrete one: as short as necessary for quality control and abuse prevention. In practice 30 to 90 days with automatic deletion have proven themselves. Anyone wanting to analyse histories longer should anonymise them.

Usually not directly – but your chatbot provider must name it as a sub-processor in its DPA and pass the obligations on. Check the sub-processor list: if the model operator is missing, the chain has a gap.

No, but more laborious: you need a transfer basis, must assess access under the CLOUD Act and document the result. For sensitive content or public bodies the European route is usually the simpler one. What matters is where the model operator is established, not just the server location.

An assistant that answers questions from public content and profiles nothing usually does not. It is different for health, finance or public-authority topics, for profiling or for vulnerable user groups. Document the assessment in any case.

The recording should only be transcribed transiently and not stored; the transcription service belongs in the privacy policy and the sub-processor list. If the voice is used for identification, it constitutes biometric data with considerably higher requirements.

By attributing conversations to a pseudonymous session identifier the visitor can quote, without you having to store real names. Short retention periods shrink the problem further: what is deleted after 90 days anyway no longer has to be disclosed.