AI chatbots and GDPR: the four obligations settled in the architecture

An internal chatbot looks harmless, being no more than a text box, a model and an answer, yet it is the one processing whose scope is defined by its users rather than by its designer : which moves compliance from the contract to the architecture.

By QDNA · Published August 28, 2026 · 10 min read

What sets a chatbot apart from other processing

An internal chatbot looks harmless, being no more than a text box, a model and an answer, yet it concentrates three properties that make it considerably more sensitive than an ordinary form.

Users put whatever they want into it, a form constrains its fields; a conversation does not. An employee will paste a contract extract, an appraisal record, the name of an unhappy client, sometimes health data. The scope of the processing is defined by users rather than by the designer, which makes it impossible to document after the fact.

The conversation is retained by default, history improves the experience, so it almost always exists. It is a personal data file in its own right, often missing from the processing register because it was never decided: it appeared as a side effect of the library in use.

The answer can be confidently wrong, a search engine that finds nothing says so. A language model produces a plausible answer in every case, including when it has found nothing. If the chatbot answers about leave, payroll or a procedure, the error has concrete consequences, and the question of human intervention arises.

Obligation 1: say it is a machine

Transparency is the least demanding obligation to satisfy, and yet the one projects botch most often. A footer mention does not satisfy it, since the information must be available at the very moment the person interacts with the system.

In practice three elements must be visible in the interface itself: that the counterpart is an automated system, what happens to the messages sent, and how to reach a human. The European AI regulation reinforces this requirement for any system interacting directly with natural persons, which a chatbot does by definition.

The detail that decides an audit is that the notice must survive integration, because a chatbot embedded in a business tool, an internal messaging app or a widget frequently loses its information banner along the way. It is therefore the component itself that must carry the notice, and not the portal home page hosting it.

Obligation 2: the legal basis, before the tool

For an internal chatbot the most common legal basis is the employer's legitimate interest : not employee consent, whose validity is fragile inside a hierarchical relationship. That choice is not a form detail: it governs which rights you will have to serve and which balancing test you will have to document.

Two drifts recur systematically, and both change the nature of the processing without anyone having decided it.

• Purpose creep, an assistant deployed to answer HR questions becomes, six months later, a source of indicators on team activity. That is a new purpose requiring its own assessment : and if it allows people to be evaluated, it changes the nature of the processing.
• Implicit retraining, using conversations to improve the model is a purpose distinct from answering them. If the provider does it by default, that is processing you did not decide but do answer for.

Obligation 3: limit what remains

This is where architecture decides and where good intentions stop being enough, since a chatbot leaves traces in four distinct places of which most projects document only the first.

The last point in that table is also the most expensive to fix afterwards: if a document is withdrawn because it should never have been indexed, its fragments stay queryable until the index is rebuilt or selectively purged. An erasure request covering that document will therefore not be honoured, even though the team is convinced otherwise. We cover this question more broadly in our enterprise RAG guide, which sets out the retrieval side of it.

Obligation 4: prove it, which means having designed for it

The three previous obligations only count if they can be demonstrated, and four artefacts are enough for that, provided they are built during the project rather than after it goes live.

• The register, including the four retention locations in the table above and not only the visible history.
• The impact assessment, where the chatbot processes sensitive data or allows people to be evaluated. Doubt should lead to doing it: its absence is harder to justify than its content.
• The processor map: which model, hosted where, under which contract, with which retention policy. A model called through an API is a processor, even when the integration took ten minutes.
• Routing decision logs, if several models coexist: the only evidence that sensitive data did not take the wrong path. See the orchestration engine.

What an on-premises model changes

Running the model in your own infrastructure exempts you from none of the four obligations, since transparency, legal basis, retention limits and proof remain owed identically.

What local deployment changes lies in the nature of the demonstration. On an external API you demonstrate through the contract, that is through a non-reuse commitment, a declared location and an announced retention period, which leaves you dependent on a third party for a fact you cannot observe. On-premises by contrast you demonstrate through architecture, since the logs are your logs, the purge is your script, and retraining does not happen because nothing runs it.

The difference appears the day you have to prove it, because a contractual clause describes a provider's intention where an operational trace describes an established fact. It is the same logic as in generative AI and GDPR, applied to the particular case of a chatbot.

The practical corollary, often counter-intuitive: a poorly operated local deployment can be less compliant than a well-contracted API. Local logs kept indefinitely, on a server whose access nobody monitors, are a risk rather than a guarantee. Sovereignty gives you the ability to control; it does not exempt you from doing so.

An implementation sequence

The order set out below avoids costly rework, because it settles the structural questions before anything is written.

1. Write the purpose in one sentence, plus the list of what the chatbot will not do. That explicit refusal is what protects against purpose creep.
2. Decide where the models run according to sensitivity, before writing code. Revisiting it later means redoing the integration.
3. Set retention periods in all four places, and implement the purge immediately. A purge added later does not catch up with data already accumulated.
4. Instrument before opening: without decision logging from day one, the ramp-up period stays a blind spot.
5. Open to a restricted scope, observe what users actually put in, then adjust. It is the only way to learn the real scope of the processing.

This article describes architectural consequences; it is not legal advice. Sources: CNIL recommendations on AI and GDPR, CNIL practical AI sheets, Regulation (EU) 2024/1689, ANSSI security recommendations. Accessed August 28, 2026.

What to remember

The four obligations of a compliant chatbot turn out, on examination, to be architectural decisions dressed as legal ones. Informing is coded in the component; grounding is decided before the tool; limiting plays out in the four places data settles; proving is only possible if the first three left a trace.

The tipping point is where the model runs, because it determines whether your compliance rests on a contract or on an architecture you observe. To frame that choice for your own situation, a no-commitment conversation is enough to settle the first decisions. We also cover the topic by sector, notably healthcare and the public sector.