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: since 2018, GDPR fines of more than 5.88 billion euros (DLA Piper) have been 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: around 76 percent (Cisco Consumer Privacy Survey) of consumers will not buy from a company they do not trust with their data. This article explains, factually, what matters for a data-protection-compliant AI assistant: hosting in Germany and the EU, the data-processing agreement, data sovereignty without sharing, a robust deletion concept and the question of European or self-hosted language models. No one can promise absolute legal certainty, but a considered concept makes the difference between a risk and a reliable tool.
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.
Briefly explained: when chat data is personal
Hosting in Germany and the EU
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, or at least within the EU, largely avoids this uncertainty, because processing then takes place entirely within the scope of the GDPR. For many companies this is no detail: for around 82 percent (Bitkom Cloud Monitor) of companies the server location is an important criterion when choosing a cloud service.
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, these building blocks should be set up so that the personal data does not leave the European legal area. XICBOT runs assistants with hosting in Germany, so the application and conversation data fall under EU law. How an assistant additionally addresses connected systems such as a calendar, inventory management or ticketing system only through clearly defined, approved actions is shown in the article on tool control.
Server location Germany
The application and conversation data are processed in data centres in Germany, not in undefined regions outside the EU.
EU legal area
Processing stays within the scope of the GDPR, so complex third-country transfers and their changing legal bases are avoided.
Encrypted transfer
Data is protected in transit and at rest, so it cannot be read along the way or while stored.
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.
No clean operation without a DPA
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.
Separate functional use from consent
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 does not flow back into an overarching model that would benefit others. XICBOT does not share your content and the data arising in the chat with third parties and does not use it to train external models. 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.
| Aspect | Generic cloud chatbot | GDPR-compliant XICBOT assistant |
|---|---|---|
| Server location | Often unclear or outside the EU | Data centres in Germany or the EU |
| Contract | Standard terms, sometimes without a DPA | Data-processing agreement under Art. 28 |
| Use of data | Possible training on your content | No sharing, no training on your data |
| Deletion | Indefinite retention | Defined periods and deletion concept |
| Language model | Fixed and predetermined | European or self-hosted on request |
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 works with the shop's session instead of building a parallel world of its own. 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. The assistant places products in the cart and leads to checkout but 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.
The catalogue is not personal
Product cards with image, title, price and availability read from the catalogue and need no details about the person.
Cart in the chat, payment in the shop
The assistant fills the cart and leads to checkout; the payment process stays in the shop system's audited checkout.
Only necessary details
Address and contact data only arise where they are genuinely needed for an order or a query.
Data Protection in Handover and Connected Tools
An assistant rarely stands alone: it hands over to a human or 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 a booking or a handover to support, it stays traceable which data goes where.
Every connected processing needs its own basis
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, the assistant can be lifted onto European or self-hosted models without anything changing for visitors. XICBOT chooses the right path together with you based on your industry and your protection needs, instead of imposing a one-size-fits-all solution. Which package fits is shown in the pricing overview; the technical embedding into your website is described in the article on integration.
Assess the protection need realistically
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 processed in Germany or the EU?
- 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?