Chatbot GDPR Compliance: What to Configure Before You Launch

A customer asks your chatbot where their order is. To answer, the bot may receive their message, identify their account, retrieve an order record, and pass the conversation to a support agent. Each step can involve personal data.

Before launch, know what data moves through that workflow, who receives it, and how long each copy stays. Your provider’s GDPR statement is a starting point. Your team still needs to decide what the bot collects, who can access it, and how deletion works.

Chatbase, an AI customer support platform, provides website chat settings for privacy notices, domain restrictions, visitor conversation deletion, and identity verification.

What makes a chatbot GDPR compliant?

Chatbot GDPR compliance covers the whole data flow. You need a clear purpose and lawful basis for processing, a privacy notice, limits on collection, security controls, retention rules, and a way to handle people’s rights. Check the contracts with providers that process data for you, too.

Start with who is responsible. If your business decides why and how customer data is used, it will usually be the controller. Providers handling that data on your instructions act as processors. Make sure the contract reflects what each party actually does.

Name the person responsible for the launch review and the team that will handle privacy requests afterward. Give customers one clear place to send a request, even when their records sit in several tools.

Arcadis built a Chatbase agent to answer citizens’ questions using official WSA Rhein project information. Its compliance review for the public-sector project took several months. Include that review in your launch schedule.

Map the data before connecting your chatbot

List the data each task needs. Answering a public FAQ, looking up an account, and arranging a callback each require different information.

For an order-support bot, trace these steps:

1. The visitor sends a message: Record whether the widget also collects identifiers, attachments, or other metadata.

2. The customer is identified: Note which account identifier passes to the chatbot and how its authenticity is checked.

3. An action retrieves an order: List the fields returned from the e-commerce system.

4. A person takes over: Check whether the transcript and account details enter a helpdesk or another support system.

5. The request is closed: Identify the stored records, any exports, and the retention owner for each system.

Add the model provider, hosting services, and any other recipients involved in your deployment.

For each record, note what it contains, why you need it, who receives it, how long you keep it, and how to delete it. Review your knowledge sources too. An uploaded support document can contain personal data before anyone starts a chat.

Collect only what the support task needs

A visitor asking about delivery costs should be able to read an answer without supplying their name and phone number. For an order lookup, use the information needed to locate and verify the right account. A callback request may need a phone number and a short description of the problem.

Review both forms and action outputs. An order-lookup action can return the entire customer record, leaving billing addresses in transcripts even when the customer only asked for a tracking update.

Review attachments too. If screenshots help troubleshoot your product, explain what customers should remove before uploading them. If files have no purpose in the workflow, consider turning attachments off.

Customers can type sensitive information even when you haven’t asked for it. Decide how staff will spot those messages and when to remove the information. If the service intentionally collects special-category data, identify an applicable Article 9 condition as well as an Article 6 lawful basis before launch.

Put privacy information where visitors will see it

Before collecting personal data, explain how you’ll use it. Put a short notice near the chat input and link to your full privacy policy. Describe the purposes and recipients that apply to your setup.

Chatbase’s chat bubble Display settings include a Dismissable notice above the input and a Footer below it. Both support rich text and have a 200-character limit. The footer can link to your privacy policy.

For a demo widget, you could use:

You’re chatting with an AI assistant. Please don’t share passwords, payment details, or sensitive personal information.

A footer could say “How we use your chat data: Privacy policy,” with the policy text linked to your own notice. A short notice doesn’t replace your full privacy policy.

Choose the lawful basis for each purpose

Consent is one possible lawful basis, not a requirement for every support interaction. Record the purpose and lawful basis for each use, including support, marketing follow-up and model development, and explain why that basis applies.

If you rely on consent, make it easy to withdraw. Keep optional marketing choices separate from the information a customer needs to submit for support.

Check cookies and trackers separately

Review what loads before the visitor opens the chat, what loads afterward, and whether any tracker serves an additional purpose.

CNIL’s chatbot guidance explains that a cookie used only to run a chatbot the visitor chooses to open may not need consent. If it also serves another purpose, the rules may change. Check what your widget does and which rules apply to your visitors.

Tell visitors they’re talking to AI. For EU deployments, account for the applicable AI Act disclosure rules alongside your GDPR privacy notice.

Verify customers before returning account information

A visitor who knows an order number may not be the person entitled to see that order. Decide how your website verifies the customer and how your backend checks their access to the record.

Chatbase supports identity verification with server-generated JWTs for logged-in users. Keep the signing secret on the server and include only the user information needed for the workflow. Its identity verification documentation explains the setup.

Identity verification tells the system who the customer is. Your backend must still check which records that customer can access or change. Before enabling account lookups, try requesting a record that belongs to another demo customer.

Restrict embedding and staff access

The Website bubble deployment panel also has a Specific domains setting. Use it to limit where your bot can load. It doesn’t verify the visitor’s identity.

Decide which staff members need to read conversations, view contacts, export data, or change integrations. Make sure the platform’s roles let you grant those permissions as needed. Update access when someone changes roles or leaves.

What to confirm with your chatbot provider

Ask how the provider handles data for the channels, integrations, and models you plan to use. Save its answers and the documents supporting them with your launch checklist.

Chatbase’s DPA describes processor responsibilities, subprocessors, transfer safeguards, and deletion commitments. Its primary processing operations are in the United States. Its privacy policy states that customer data is not used to train AI models. Compare those terms with your requirements, including hosting location and transcript retention.

GDPR does not require every chatbot to store data only in the EU. Sending data outside the European Economic Area (EEA) needs a valid transfer mechanism, plus any required checks and protections. Look at where data is stored, which other services receive it, and where staff can access it.

SOC 2 evidence can help you evaluate security controls, but it does not settle the lawful basis, notice, or retention choices for your deployment. If you are still choosing a provider, compare those differences in our GDPR platform comparison.

Set retention by purpose and plan deletion across systems

Choose how long to keep each type of record and document why you need it for that period. A brief FAQ exchange and an unresolved customer complaint may need different retention periods. There is no single GDPR retention period for all chatbot transcripts.

Decide how you’ll enforce each rule. Check whether the platform has a retention setting, your team needs a deletion schedule, or the provider must handle the request. Do not promise automatic deletion until you have confirmed the mechanism and its scope.

Understand the visitor’s delete control

Chatbase’s Delete conversations capability lets visitors delete their own conversations from the recent chats screen. The control is in Chat bubble → Display → Capabilities.

Before describing this option to customers, check what it deletes. Look for copies in helpdesk tickets, downloaded exports, and contact records, and confirm how to remove those too.

Build a process for access and erasure requests

Assign someone to handle each request. They’ll need to find the records, verify who made the request, decide what it covers, and contact the processors holding the data. Include chat history, contacts, collected submissions, attachments, and connected support systems in that search.

When a conversation becomes a ticket, check the helpdesk’s treatment of attachments, private notes and archived records. Our GDPR helpdesk comparison shows how providers handle those records if you’re still choosing one.

The EDPB’s individual rights guidance explains that controllers generally must respond to rights requests within one month. An extension can apply to complex requests, with notice within the first month. Some rights and erasure exceptions depend on the circumstances.

Chatbase’s DPA commits to deleting all or a specified portion of customer personal data within 30 days of a written deletion request or termination, subject to legal-retention exceptions. It includes backups and requires deletion by authorized subprocessors. Account for that deadline when handling deletion requests. It is not an automatic 30-day retention setting for every chat.

Check the deployment before launch

Use demo records for these checks and save the results. If a check needs input from a developer, privacy lead, or provider, leave it pending until you have their answer.

If your planned use of data is likely to create a high risk to people, you need a data protection impact assessment (DPIA), a review of privacy risks and how to reduce them. Assess sensitive data, vulnerable users, and decisions with serious effects against the rules for when a DPIA is required. A public FAQ bot and a bot deciding whether someone qualifies for a service raise different risks.

Give customers a way to reach a person when the chatbot cannot handle their request. Review the data flow again when you add a channel, model provider, knowledge source, or action that changes what the bot processes.

FAQs

Does every chatbot need GDPR consent?

No. The appropriate lawful basis depends on the processing purpose and circumstances. Check consent requirements for cookies and marketing too. A privacy-policy link does not itself obtain consent.

Must a GDPR-compliant chatbot be hosted in the EU?

No. GDPR has no universal EU-only hosting rule. Review storage and access locations, downstream processors, and safeguards for international transfers.

How long can a chatbot retain conversations?

Choose a retention period based on why you need the record, then set up a way to delete it when that period ends. Explain the period or the criteria used to determine it. Avoid adopting a generic 30-, 60-, or 90-day rule without considering your use case.

Does deleting a chat remove all the customer’s data?

It depends on what the delete control covers. Check whether it includes contacts, submissions, attachments, connected tickets, exports, and copies held by providers. Use your rights-request process to handle any records left behind.

To set up a website support bot, create a Chatbase agent, add your privacy notice, and check what it collects before connecting customer accounts.