When a customer asks an AI chatbot a question, their data passes through six stages: transmission, a protective layer, the company's environment with the provider, response generation, storage, and finally deletion. If an integration with a CRM or ticketing system is involved, data additionally flows into these systems. Whether a chatbot processes customer data securely is determined at each of these stages individually. This article follows an inquiry step-by-step and highlights the questions that data protection and IT teams should ask at each stage.

At a Glance

• Customer data is generated right from the very first message: content, technical identifiers, and often name, email, or customer number.

• Transmission must be encrypted, and so must storage, including backups.

• The dedicated environment per customer determines whether data from different companies remains reliably separated.

• Response generation is the stage where data can unnoticedly be sent to external AI providers.

• The retention period is defined by the company itself.

What Data Is Contained in a Chatbot Inquiry

An inquiry consists of more than just the text entered by the customer. It also includes technical identifiers such as an anonymous user ID, language and region settings, the timestamp, and the channel. As soon as the chatbot captures an inquiry, it often asks for a name, email address, phone number, or customer number. In a logged-in customer portal, it already knows the user anyway.

All of this constitutes personal data. The company is the data controller within the meaning of the GDPR, while the chatbot provider acts as a data processor.

The Journey of an Inquiry in Six Stages

1. Transmission

The message leaves the customer's browser or app and travels to the provider's platform. Along this path, it must be encrypted; a current version of TLS is standard. For messenger channels like WhatsApp, the message first passes through the messenger operator's infrastructure. This belongs in the company's privacy policy.

Questions for the provider: Which TLS version is used? Which channels route through third parties?

2. Protective Layer

Before the inquiry reaches the actual application, it passes through a protective layer consisting of a Web Application Firewall and a load balancer. It filters attacks and distributes the load. Above all, it is fundamental to security.

Questions for the provider: Is there a Web Application Firewall? How is the service protected against overload?

3. The Company's Environment

Now the inquiry arrives in the environment where the company's chatbot is running. This is where it is determined how effectively data from different customers of the provider is separated from one another. Dedicated environments per customer—separated for development, testing, and production—are the most resilient. A shared instance for all customers is easier to operate, but harder to audit.

Questions for the provider: Does each customer have a dedicated environment? Are testing and production separated? Where is the data center located?

4. Response Generation

The chatbot recognizes the intent, searches the approved sources, and generates the response. This stage carries the greatest data protection risk, which many only notice late: If the chatbot calls a language model via an external AI provider's API to generate the response, the contents of the inquiry are sent there. In that case, data protection also depends on that provider's terms and locations.

Added to this is the question of training. If inquiries are used to improve models, the data deviates from its original purpose.

Questions for the provider: Do the language models run hosted by the provider itself or by a third party? Is customer data used for training, even anonymized or across customers?

5. Storage

Conversation histories are stored so that the team can trace them and analytics can learn from them. They should be encrypted at rest, including backups. Who manages the keys is a separate question: For high-security requirements, the key can be held by the company itself.

Access to stored conversations is restricted to individuals assigned roles by the company, such as live agents or editors. An audit log shows who accessed or changed what, and when.

Questions for the provider: How is encryption at rest handled? Can we bring our own keys? How are roles and access permissions governed?

6. Deletion

The GDPR requires that data is not stored longer than necessary. How long that is depends on the purpose and is decided by the company. A chatbot should therefore support retention periods that the company configures itself—from immediate deletion after input to retention for the duration of the contract. At the end of the contract, a deletion confirmation is essential.

Questions for the provider: Can we configure the retention period ourselves? What happens to the data upon contract termination?

When Data Flows into Other Systems

When the chatbot processes transactions—such as creating a ticket or writing an address change to the CRM—the data leaves the platform and moves toward the company's own systems. This transfer is intentional, but it must be documented: which fields go into which system and on what legal basis. What such integrations look like technically is described in the guide to integration into CRM and ERP.

The same applies to human handoffs. When a live agent takes over a conversation, they see the chat history up to that point. That is the purpose of the handoff and should be stated in the privacy policy. For voice channels, additional questions regarding speech synthesis and recording arise; these are covered in the article on GDPR-compliant AI phone assistants.

How Mercury.ai Secures the Data Path

At Mercury.ai, all stages run on AWS in Frankfurt, with no data transfer to third countries. Transmission is encrypted with TLS 1.3, and storage with AES-256, including backups. Upstream of the application are a Web Application Firewall and a load balancer. Every customer has dedicated environments, separated across development, testing, and production, as well as by language.

Responses are generated using licensed Mistral models hosted and operated by Mercury.ai itself. Inquiries are never sent to external AI providers, and customer data is not used for training—not even across customers. Keys are managed by AWS KMS with HSM; upon request, key management can reside exclusively with the customer. Retention periods are configured by the company within the project, ranging from immediately after input to the end of the contract. For an overview of data processing and security measures, see the Security Paper on the EU AI Act. Why a data center in Germany alone is not yet a complete answer is explained in the article on chatbot hosting in Germany.

Conclusion

Customer data in an AI chatbot is well-protected when each of the six stages provides a clear answer: encrypted transmission, a protective layer, a dedicated environment, response generation without external AI providers, encrypted storage with governed access, and a retention period defined by the company itself. Anyone who asks these six questions before launching has already completed the major part of their data protection audit. The corresponding evidence is outlined in the article on the EU AI Act in chatbot operations.

Would you like to have your chatbot's data path reviewed? Talk to us.