Is an AI assistant GDPR compliant?

What does the GDPR require from an SME that uses an AI assistant?

The GDPR requires the SME to justify its use of personal data, limit how much it collects and how long it keeps it, inform people and respect their rights. An AI assistant processes such data as soon as a visitor gives their name or e-mail address, or describes an identifiable situation. The rules are those of any processing:

• A legal basis: identify the right basis for each purpose, rather than treating the mere receipt of a message as general permission
• Data minimization: ask only for what is needed to handle the request
• A retention period: plan when conversations and information kept about a person expire
• People's rights: organize access, rectification and erasure, as well as requests to get data back

These points relate in particular to Articles 5, 6, 13, 15, 16 and 17 of the GDPR, Regulation (EU) 2016/679. When preparing the project, describe separately the receipt of a question, its handling by the team and any personalization of future exchanges. These uses may call for different choices.

This article gives a working method for an SME. It does not replace the advice of a lawyer or your data protection officer when your situation has specific features (health data, minors, large volumes, a regulated sector).

Which personal data passes through an AI assistant?

Before talking about obligations, take stock of what actually flows through. An assistant on a public website sees several categories of data, often more than people expect:

The second row is the most delicate. A visitor may spontaneously write sensitive information: a health problem to justify a cancellation, a family situation, a dispute. You do not control what they type, but you decide what you do with it, who can access it and how long it is kept.

The last row matters too. A document loaded into the knowledge base may contain colleagues' names, direct phone numbers or extracts from files. What is in the base can end up in an answer: sort before you load.

Which legal basis applies to each use?

Article 6 of the GDPR lists six legal bases. Three concern most of an SME's AI assistants. The choice is made per purpose, not once for the whole tool:

Legitimate interest requires a documented balancing between your interest and the visitor's reasonable expectations. Consent must be freely given, specific, informed and as easy to withdraw as to give. An "I agree" button that conditions any answer at all does not meet these conditions.

Should visitors be told they are talking to an AI?

Yes. Since 2 August 2026, Article 50 of the AI Act requires informing people that they are interacting with an AI, at the latest at the first interaction, unless this is obvious. The obligation is set out in Regulation (EU) 2024/1689.

In practice, give the assistant an unambiguous name and display a readable notice in the chat widget. For example: "You are talking to an AI assistant. The team can take over your request." Check that it is visible on mobile and in every language offered.

This notice explains who the visitor is talking to. Information about the data must also remain accessible: what is collected, why, who is involved and how to exercise one's rights. Avoid hiding these explanations behind a string of windows that are hard to find again.

What the information to visitors must contain

Article 13 of the GDPR sets the content of the information to give when data is collected from the person. For an assistant, this usually means adding a dedicated section to your privacy policy that states:

• The identity of the controller and, if there is one, the contact details of the data protection officer
• The purposes: answering, passing on to the team, personalizing, improving the service
• The legal basis of each of these purposes
• The recipients: the team, the platform provider, the language model provider
• Any transfers outside the Union and how they are safeguarded
• The retention periods, or the criteria that determine them
• People's rights and the possibility of lodging a complaint with the supervisory authority

Put a link to this section in the chat window, next to the notice saying the assistant is an AI. A visitor should be able to read it before writing their first message.

Who is responsible for the data: the SME or the supplier?

The organization that decides why and how the assistant is used is the controller; the platform provider acts as processor for the operations entrusted to it. Article 28 of the GDPR governs the data processing agreement. Hosting and the language model provider must be examined as part of that chain.

Ask for an understandable description of a message's journey: receipt, storage, generation of the answer, viewing by the team and deletion. The contract must make the concrete responsibilities clear, beyond a commercial claim of compliance.

In a fictitious example of an accounting firm in Liège, the person who answers routine questions can manage the content, while a designated person handles requests about data. An assistant for an accounting firm has to tell general instructions apart from the confidential review of a file.

What the data processing agreement must provide for

Article 28 lists what the agreement must contain. For an AI assistant, check in particular that the supplier undertakes to:

• Process the data only on your instructions, and not for its own purposes, such as training a model
• Ensure the confidentiality of the people on its team who can access the data
• Implement appropriate security measures, described in a verifiable way
• Use other processors only with your authorization, and inform you of any change
• Help you respond to people's requests and handle a data breach
• Delete or return the data at the end of the contract
• Allow you to verify that these commitments are met

The list of sub-processors must be available. For an AI assistant, it includes at least the host and the language model provider or providers.

Are conversations used to train a model?

Ask this question explicitly, at two levels. First, to the platform provider: does it use your conversations to train or improve its own models? Then, to the provider of the language model: are the messages it receives to generate an answer kept, and for what use?

Large model providers generally offer specific terms for business use through programmatic access, separate from those of their consumer apps. Ask which ones apply and include them in the documentation of your processing. A verbal answer or a marketing claim is not enough.

If your conversations were to be used to train a model, this would need its own legal basis and clear information to visitors. Most SMEs have no interest at all in accepting that scenario.

Can you keep a memory of contacts with their consent?

A memory meant to personalize future exchanges must be clearly explained and, in the setup described here, switched on with the person's agreement. Contact memory deserves different treatment from the history needed to follow up a request.

Record the source, date and expiry of every piece of information kept, as well as a way to correct or erase it. Ask for understandable consent to what will be remembered. Refusing this personalization must not be presented as an artificial obstacle to a general answer.

Take a fictitious shop in Namur: remembering a customer's preferred language can make their next exchange easier. That does not justify keeping every personal detail shared during a complaint. Have the useful categories approved before switching on memory, then check that they still match the service provided.

Is hosting in Europe enough to comply with the GDPR?

Hosting in Europe is not enough on its own: you also need to examine the processing, the access rights and the providers that receive data. Distinguish where conversations are stored from where messages are processed to produce an answer.

Ask which model providers may be involved and which terms apply to each. Do not infer from a storage location that all exchanges stay in the same country, nor that every obligation is met. Have any transfers and their safeguards spelled out before loading documents that contain personal information.

In a fictitious example of a coliving house in Brussels, the arrival guide can be useful to the public assistant. Named information about residents and access codes call for separate treatment. Sorting documents is therefore a service decision as much as a confidentiality precaution.

How transfers outside the Union are safeguarded

Chapter V of the GDPR (Articles 44 to 50) governs transfers of data to countries outside the European Economic Area. Three mechanisms come up most often:

• An adequacy decision by the European Commission, recognizing a sufficient level of protection. For the United States, the decision of 10 July 2023 covers companies certified under the EU-US Data Privacy Framework
• The standard contractual clauses adopted by the Commission, included in the contract with the provider
• Binding corporate rules, for transfers within a group

For each provider outside the Union, ask which of these mechanisms applies and note it in your record. If a model provider processes messages in the United States, check its certification on the official Data Privacy Framework website or the presence of standard contractual clauses.

How long should conversations be kept?

The period should match how useful the conversations really are and be reviewed when that usefulness changes. A default offered by software is a setting to assess, not a period that automatically suits every organization.

Distinguish routine exchanges, requests that are still open and information kept to personalize contacts. Decide who can extend a justified retention and who checks deletions. Avoid multiplying copies in personal files: they make correction and erasure harder.

In a fictitious example of a property manager in Brussels, a question about reception hours and a dispute that is still ongoing do not have the same follow-up needs. Document these differences without keeping the whole history on the grounds that it might be useful one day. The glossary entry on data retention details the criteria to use.

How do you handle access and erasure requests?

A visitor can ask to see the data about them, to have it corrected or to have it deleted. Article 12 of the GDPR provides for an answer within one month of receipt, which can be extended by two months for complex or numerous requests, provided the person is told within the first month.

For an SME to meet this deadline calmly, prepare the procedure before going live:

1. Name who receives the requests and through which channel (a dedicated e-mail address is often enough)
2. Check that the tool lets you find all of a person's conversations and information from their e-mail address
3. Test export and deletion on a fictitious contact, including in contact memory
4. Plan a proportionate identity check, so you do not send data to the wrong person
5. Keep a record of the request and the answer, without copying the data itself

A tool that forces you to search manually through several screens turns every request into half a day's work. That is a selection criterion as important as the quality of the answers.

What should you do in case of a data breach?

A data breach covers any security incident leading to the destruction, loss, alteration, disclosure of or unauthorized access to personal data. A forgotten account for a former colleague or a conversation link shared by mistake can be one.

Article 33 of the GDPR requires notifying the supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to people. Article 34 adds informing the people concerned when the risk is high. The data processing agreement must provide that the supplier warns you without delay if it detects an incident on its side.

Prepare a one-page response sheet: who to warn internally, how to cut an access, how to reach the supplier, how to document the incident. You will rarely use it, but on that day every hour counts.

What should you record in the register of processing activities?

Article 30 of the GDPR requires keeping a record of processing activities. Businesses with fewer than 250 employees are exempt in some cases, but the exemption does not apply when the processing is not occasional, which is the case for an assistant permanently open on a website. In practice, record it as a processing activity in its own right, with:

• The name and purpose: "Website AI assistant: answers to visitors and passing requests to the team"
• The categories of people: visitors, prospects, customers
• The categories of data: identification, message content, technical data, memory where applicable
• The recipients: internal team, platform provider, model providers
• Transfers outside the Union and their mechanism
• The retention periods for each category
• Security measures: named accounts, two-factor authentication, encryption, logging

This record is the starting point when a visitor asks a question, when the supervisory authority asks for information or when a new colleague takes over the file.

Is an impact assessment needed before launch?

The data protection impact assessment provided for in Article 35 becomes mandatory when processing is likely to result in a high risk to people's rights. An assistant that answers practical questions about services, with little data collected, generally does not fall into that category.

An assessment becomes likely when several criteria add up: sensitive data, vulnerable people, large-scale processing, evaluation or profiling of people, combining sources. An assistant that would automatically rank prospects by creditworthiness, or that would receive descriptions of symptoms, deserves this assessment. If in doubt, at least document why you consider it unnecessary: that note will help if the question is asked later.

Which points should you check before putting the assistant online?

Check that every use has an owner, a justification and a procedure the team can actually follow. This grid helps turn intentions into decisions:

Sensitive data falls under Article 9; processing likely to result in a high risk may require the impact assessment provided for in Article 35. In Belgium, the supervisory authority is the Data Protection Authority. For the team, start by limiting the information requested and organizing an appropriate human handover when a visitor shares content that goes beyond the intended service.

Situations that call for more caution

Some activities call for a deeper analysis before opening an assistant to the public:

• Health data: a medical practice, a physiotherapist or a pharmacy receives messages that fall under Article 9. Limit the assistant to practical information and direct any medical question to a professional
• Minors: in Belgium, the age from which a minor can consent alone to the processing of their data for an online service is set at 13. An assistant aimed at pupils or young people must take this into account
• Financial or legal situations: an accounting firm, a lawyer or a wealth manager receives confidential information. The assistant must not invite the visitor to detail their file in the public conversation
• Large volumes: large-scale processing or systematic monitoring of people can make the impact assessment mandatory

In these cases, an explicit instruction to the assistant ("never ask for medical details", "offer an appointment for any question about a file") usefully complements the technical settings. An assistant's guardrails serve compliance as much as the quality of answers.

Training the team that reads the conversations

Compliance does not depend on the tool alone. The people who read conversations and take over requests need a few simple rules: do not copy a conversation into a personal e-mail, do not export a contact list without a reason, report any access or erasure request, remove the access of a colleague who leaves the company.

A short meeting before launch, then a reminder when the team changes, is usually enough. Use it to show where the privacy policy is and how to answer a visitor who asks what happens to their data.

How do you move from this list to a concrete configuration?

Start with a one-hour audit to define uses, documents and responsibilities before launch. Then have the retention and information choices reviewed by the competent person in your organization.

KernChat, developed by KERN-IT in Brussels and hosted in the European Union, keeps conversations for 365 days by default before purging them, with a period the organization can change. Memory expires according to the assistant's policy and relies on the contact's consent when the organization requires it, otherwise on legitimate interest within an existing customer relationship; its information can be exported or deleted. Messages are sent to Google Gemini, Anthropic Claude or OpenAI only to generate the answer; KERN-IT does not use them to train a model. The privacy policy explains how this works.