GDPR-Compliant AI Chat: Hosting and Data Protection

An AI chat assistant answers questions, records concerns and guides visitors to the right offer. In doing so it inevitably processes what people tell it: names, email addresses, order numbers, sometimes even questions about health or contracts. This is precisely why data protection with an assistant is not an afterthought but the foundation on which it may go live at all. The figures show how serious the topic is: from May 2018 to January 2026, GDPR fines totalling 7.1 billion euros (DLA Piper) were imposed across Europe, and for a single violation the regulation provides for up to 20 million euros (GDPR, Art. 83) or four percent of global annual turnover. At the same time, customers expect careful handling: in a survey commissioned by the Federation of German Consumer Organisations in October 2025, it was very or rather important for 87 percent (vzbv) of the consumers surveyed to be able to trust a company to handle their personal data before using its services. This article explains, factually, what matters for a data-protection-compliant AI assistant: hosting in Germany, the data-processing agreement, data sovereignty without sharing, a robust deletion concept and the question of where the language model generates the answers. No one can promise absolute legal certainty, but a considered concept makes the difference between a risk and a reliable tool.

Enlarge graphic

Labels in the illustration

• We only use your details to
• handle your request.
• And where is it stored?
• On servers in Germany, GDPR-
• compliant, with a processing
• agreement and automatic deletion.
• EU hosting
• DPA
• TLS
• Handover to a human available
• Write a message ...
• Four Data-Protection Layers
• 1
• Hosting in Germany
• Stored data under EU law
• 2
• Data-processing agreement (DPA)
• Contract under Art. 28 GDPR
• 3
• Encryption and access control
• Encrypted in transit, access control
• 4
• Deletion concept and rights
• Retention and data-subject rights
• No sharing. No training on your data.
• Data sovereignty stays with you: transfers outside the EU only under standard contractual clauses
• Hosting in Germany, a processing agreement and a deletion concept as the foundation

GDPR-Compliant AI Assistant

Why Data Protection Decides With AI Assistants

As soon as an assistant accepts questions in a chat window, personal data arises. That starts with an email address voluntarily given for a callback and extends to details that make a person clearly identifiable. A business that uses such an assistant is responsible under data protection law, regardless of whether the technology is operated in-house or provided by a service partner. This responsibility cannot be delegated away, but it can be made viable through the right technical and contractual setup. Those who consider this from the outset save themselves later corrections and reduce the risk of complaints, access requests or fines.

Data protection is not only a duty but also a selling point. Visitors notice whether a website handles their details carefully, and a visible, honest approach to the topic lowers the barrier to making an enquiry at all. An assistant that gives a clear answer to the question of storage feels more trustworthy than a form without explanation. This is especially true for sensitive sectors such as medical practices, law firms or online shops with payment data. How an assistant ties its answers closely to your own, checked content instead of speculating freely is described in our article on the knowledge base and training.

Hosting in Germany

The place where data is processed and stored is one of the most important levers. If chat data is processed in data centres outside the EU, additional requirements for transfers to third countries apply, whose legal basis has shifted several times in recent years. Hosting in Germany keeps the application and stored conversation data within the scope of the GDPR. If the language model is operated by a provider outside the EU, that transfer needs safeguards of its own, as a rule standard contractual clauses under Art. 46 GDPR. For many companies this is no detail: for 97 percent (Bitkom) of companies in Germany with 20 or more employees, the server location plays a role when choosing a cloud provider.

Technically, an AI assistant consists of several building blocks: the application that runs the chat, the storage for conversations and knowledge content, and the language model that formulates the answers. For clean data protection, it must be clear for each of these building blocks where it runs and on what basis data goes there. XICBOT runs assistants with hosting in Germany, so the application and stored conversation data fall under EU law; the answers are generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses. How an assistant additionally addresses connected systems (Custom package) such as a calendar, inventory management or ticketing system only through clearly defined, approved actions is shown in the article on tool control.

The Data-Processing Agreement as the Foundation

When a service partner operates an assistant on behalf of a company and processes personal data in doing so, the GDPR requires a data-processing agreement, DPA for short, under Article 28. This contract sets out in writing which data is processed for which purpose, which technical and organisational measures apply, how sub-processors are handled and how deletion is regulated. Without such a contract, the collaboration is not clean under data protection law, even if everything runs flawlessly technically. The DPA is therefore not a formality but the legal foundation on which operation rests.

A robust DPA names concretely which categories of data the assistant processes, such as chat content, voluntarily provided contact data and technical connection data. It describes the protective measures taken, imposes a duty of confidentiality and stipulates that the processor handles the data solely on the instruction of the company. Equally important is transparency about the sub-processors used, that is, further service partners who may be involved in the processing. The clearer this chain is documented, the easier it is to demonstrate to supervisory authorities and data subjects that the processing runs in an orderly way. XICBOT provides a corresponding contract for every project.

Legal Basis and Consent: Building on the Right Ground

Every processing of personal data needs a legal basis under Article 6 GDPR. With a chat assistant, a clear distinction pays off: when the assistant answers a question a visitor asks on their own initiative, this happens within the use of an offered service and often serves the initiation or performance of a contract. It is different as soon as the assistant uses optional extra functions, for example evaluating behaviour beyond the session, setting cookies that are not technically necessary, or reaching out proactively for advertising purposes. Such functions generally require explicit consent. Those who keep the two apart operate the assistant on a traceable basis and do not have to burden visitors with another consent dialog just to ask a simple question.

Closely linked to this is the principle of data minimisation from Article 5 GDPR: an assistant should only collect the details it genuinely needs for the respective purpose. In practice this means not asking for an email address before it is needed, but only recording contact data once a visitor wants a callback or a quote. A short, understandable notice in the chat and a link to the privacy policy create the necessary transparency under Article 13 GDPR. XICBOT embeds the assistant so that technically necessary and optional functions are separated and your website's consent management is respected. How lead capture records exactly the data needed for an enquiry, and how the integration implements this technically, is shown in the respective articles.

Data Sovereignty: No Sharing, No Training on Your Data

Data sovereignty means that your company remains master of its own data and decides itself what happens to it. With an AI assistant, two questions are decisive: is the chat content and customer data shared with third parties, and is it used to train external AI models? Both should be ruled out. Your product data, your customer enquiries and your internal content are a business asset that must not flow into external systems unasked. A data-protection-compliant assistant processes this data solely for the agreed purpose, that is, for answering enquiries and the agreed actions, and not as raw material for others.

The distinction between the individual knowledge base and the general language model is important. The assistant is trained on your content so that it knows your business, but this content stays in your context, and XICBOT does not build an overarching model from it that would benefit others. XICBOT does not share your content and the data arising in the chat with third parties and does not train any model with it itself; the answers are generated by a specialised model provider, also outside the EU on the basis of standard contractual clauses. This keeps the value of your data with you. In addition, the anonymized conversation analytics provide only aggregated insights into frequent questions and gaps, without exposing individual people.

Deletion Concept, Retention and Data-Subject Rights

Data may only be stored for as long as it is needed for the defined purpose. For a chat assistant this means: conversation data should be deleted or anonymized automatically after a defined period, unless another reason, such as an ongoing enquiry or a legal retention obligation, justifies longer storage. A clean deletion concept sets these periods in advance and implements them technically instead of accumulating data indefinitely. This reduces not only the legal risk but also the attack surface, because data that no longer exists cannot leak either.

The deletion concept also includes data-subject rights. Among other things, the GDPR gives people the right to information about the data stored on them and the right to have it deleted. An assistant must be set up so that these requests can be fulfilled, that is, so that stored chats can be attributed to a person and removed in a targeted way. In practice this means a manageable, well-documented data holding instead of scattered copies in many places. XICBOT sets up assistants with defined retention periods and a traceable deletion path and supports the handling of access and deletion requests. How an assistant hands over to a human early on sensitive topics instead of handling delicate cases itself is described in the article on the support assistant.

Data Protection in the Shop: Product Cards and Cart

In an online shop it pays to look closely at which data is personal at all. The product catalogue with titles, images, prices and availability contains no personal data in itself. So when the assistant shows product cards in the chat, it reads from an uncritical source and needs no details about the person. It only becomes personal once a cart is created, an order is triggered or an address is entered. This separation is practically useful: product advice, recommendations and comparisons run with minimal data, while the sensitive steps remain clearly delimited. This turns the chat into a shop window without unnecessary data arising.

With the cart in the chat, the assistant assembles a cart in the chat. The actual payment process stays in the shop system's audited checkout, with a Shopware shop (Community Edition) in its checkout designed for payment security. With “Continue” it leads to the shop's address; for the items to sit in the cart there, the shop needs an integration of its own. The assistant does not store payment data such as card numbers itself. Outreach on cart abandonment likewise follows the data protection rules and the visitor's consent. The shop assistant thus combines more advice and conversion with a lean, traceable handling of data, because the most sensitive step stays where it belongs.

Data Protection in Handover and Connected Tools

An assistant rarely stands alone: it hands over to a human or, in the Custom package, triggers something in connected systems through defined actions, for example in the calendar, the CRM, inventory management or the ticketing system. As soon as data flows into such a system, that processing also needs a legal basis, and where a further service partner is involved, its own data-processing agreement. Data minimisation matters again here: an action should only pass on the details it actually needs, instead of forwarding the entire conversation unfiltered. How the assistant addresses such systems solely through clearly defined, approved actions is described in detail in the article on tool control.

When handing over to a human, the conversation context is passed to an employee or into a ticket so that the request can be handled without repetition. The purpose-limitation principle applies here too: the context serves the handling of the concern, not arbitrary further use, and access stays limited to the responsible people. XICBOT defines per action which data is passed to which system or person and works with approvals instead of blanket full access. So even with an appointment request or a handover to support, it stays traceable which data goes where.

European and Self-Hosted Language Models

The language model is the building block that formulates the answers. For data protection, what matters is where this model runs and what happens to the input it processes. For companies with heightened requirements, for example in healthcare, law firms or the public sector, it can make sense to use a European or self-hosted model whose processing is fully controllable. With a self-hosted model, the language processing runs on your own or dedicated infrastructure, so the input does not leave the controlled environment. This increases the effort and is not necessary for every project, but it offers the highest level of data control.

Not every business needs this degree of isolation, and a self-hosted model is not an end in itself. For many uses, a modern assistant with hosting in Germany, a clear DPA and the assurance that no data is shared or used for training is sufficient. Where requirements are higher, European or self-hosted language models are possible with XICBOT as a separate project by arrangement and are not included in standard operation; nothing changes for visitors. Which path fits your industry and your protection needs is something we clarify together with you. Which package fits is shown in the pricing overview; the technical embedding into your website is described in the article on integration.

What Companies Should Concretely Watch For

The points so far result in a manageable list of questions that should be clarified before introducing an AI assistant. It does not replace individual legal advice but provides solid orientation. An honest expectation is important: no one can promise absolute legal certainty, because data protection is an ongoing process and the legal framework keeps evolving. What can be influenced are the factors that demonstrably count: the place of processing, the contractual basis, the handling of the data and the deletion. Those who regulate these points cleanly operate an assistant on a viable foundation.

• Are the application and conversation data stored in Germany or the EU, and is every transfer to third countries safeguarded?
• Is there a data-processing agreement under Art. 28 GDPR that matches the assistant?
• Is it ruled out that your content and chat data are shared or used to train external models?
• Are there defined retention periods and a deletion concept with a traceable deletion path?
• Can access and deletion requests from data subjects be fulfilled in practice?
• Is it clarified whether the protection need requires a European or self-hosted language model?
• Is there a legal basis under Art. 6 GDPR for the processing, and are technically necessary functions separated from those requiring consent?
• Do connected systems and the handover to humans pass on only the data genuinely needed, each with its own basis and, where necessary, its own DPA?

Where you set retention periods per data type and export a single conversation is shown in the documentation. That way every answer to the list above can be checked in the admin area itself.

Frequent questions