Home / Journal / Compliance, hosting and impact

GDPR and AI agents: what to sort out in practice

Compliance, hosting and impact Published 26 October 2026 11 min read

An AI agent processes personal data as soon as it talks to someone or reads a file. The GDPR then applies with no special regime. Here, in project order, are the decisions to make and the documents to keep, based on the regulation's text and the CNIL.

An AI agent is data processing like any other

As soon as an AI agent reads, produces or stores information about an identifiable person, it processes personal data. The GDPR then applies in full, with no special regime for AI. An agent that answers customers, screens applications, drafts email replies or summarises HR files is covered, even if nobody thought of declaring it as such.

What changes with an agent is where data hides. There is what the user types, what the agent fetches from your systems, what it sends to the model provider, what it writes in its logs, what it indexes in its knowledge base. Each of these flows falls under the same principles: purpose, legal basis, minimisation, retention, security, individuals' rights.

This article follows these principles in the order they arise on a project, based on the GDPR text and publications from the CNIL, the French data protection authority. It does not replace the advice of your data protection officer, whom the CNIL recommends involving early, along with security and business teams.

Who is responsible: you, the provider, the integrator

First question, often poorly framed: who is the controller? In the vast majority of projects we see, it is the organisation deploying the agent. It decides why the agent exists and which data it processes. The model provider, the host and the integrator generally act on its behalf, as processors.

This status has concrete consequences. Article 28 of the GDPR requires using only processors that provide sufficient guarantees, and framing the relationship with a contract. That contract provides in particular that the processor only processes data on documented instructions, that its staff are bound by confidentiality, that it implements the required security measures, that it does not engage another processor without authorisation and that it helps you respond to individuals' requests.

In the CNIL's Q&A on generative AI, two points deserve attention. First, clarifying each party's role with the provider is part of governance work. Second, an organisation that enriches a system with its own personal data, for example by connecting a knowledge base or fine-tuning a model, becomes controller of those operations. In other words: if your agent queries your documents, it is your processing, not the model vendor's.

Point of attention: the provider reusing your data to train its models. The CNIL advises checking this before choosing a solution, and the contract must answer it clearly.

Choose the legal basis before launch

Article 6 of the GDPR lists six legal bases: consent, performance of a contract, compliance with a legal obligation, protection of vital interests, performance of a task in the public interest and legitimate interests. The CNIL stresses that the legal basis must be chosen before any processing starts. You do not pick it afterwards to justify processing already under way.

For an agent, the legal basis depends on its purpose, not on the technology. A few typical cases, to validate with your DPO:

An agent handling an existing customer's request (order tracking, a question about a contract) can often rely on performance of the contract, provided the processing is objectively necessary for that contract.
An internal agent helping teams (document search, drafting replies) generally rests on the organisation's legitimate interest. That interest must then be balanced against the rights of the people whose data goes through the agent, and the balancing documented.
An agent on a public website collecting prospect information may fall under legitimate interest or consent depending on what it does with the data afterwards, notably for marketing.

One application can serve several purposes, hence several legal bases: answering the customer and analysing conversations to improve the service do not necessarily share one. This split by purpose must be set at scoping, alongside the functional scope described in our guide to deploying an agent.

Minimise what the agent sees and keeps

Article 5 of the GDPR sets the data minimisation principle: data must be adequate, relevant and limited to what is necessary for the purposes. With an agent, this translates into very concrete architecture decisions.

Give the agent only the useful fields. An agent answering about a delivery status needs neither the customer's date of birth nor their payment history.
Filter before sending to the model. Identifiers, numbers and sensitive information that do not serve the answer can be masked or tokenised on the server before the text goes to the provider.
Limit the knowledge base. Select useful documents rather than indexing the whole network share, and exclude individual files.
Frame what users type. The CNIL recommends defining a list of authorised and prohibited uses, for example not providing personal data to the system when unnecessary, and training users on these rules.

Minimisation is also a security argument: what the agent does not see, it cannot disclose. This work on flows is as much integration as compliance, and we carry it out with our data and integration profile.

Inform people, including about the agent itself

Article 13 of the GDPR lists what people must be told when their data is collected from them. Among this information: the controller's identity, the DPO's contact details where applicable, the purposes and legal basis, recipients, any intention to transfer data outside the Union, the retention period or the criteria that set it, their rights, the right to lodge a complaint with a supervisory authority, and the existence of any automated decision-making.

For a conversational agent, we recommend two levels of information:

a short, visible message at the start of the exchange stating that the user is talking to an automated system, what it is for and what not to type in, with a link to the full information;
a dedicated section in the privacy policy covering the Article 13 items for this specific processing, including the model provider and the processing location.

For an internal agent, information goes through the usual HR channels. It must state whether conversations are kept, who can read them and why. The EU AI Act adds its own transparency obligations, which we detail in what already applies to your SMB.

How long to keep conversations

The GDPR forbids keeping data longer than necessary. The CNIL describes a three-stage lifecycle: active storage, for as long as it takes to reach the objective; intermediate archiving, when data no longer serves the original purpose but remains useful, for instance in case of litigation, with restricted access; then deletion, or permanent archiving in limited cases. When no text sets a period, the controller must set and justify it.

An agent produces several categories of data, which do not all have the same legitimate lifespan:

the conversation itself, useful while handling the request and possibly resuming it;
technical logs (tool calls, errors), useful for security and troubleshooting;
extracted data saved in your systems (a ticket, a contact record), which follows the retention of the receiving system;
data kept by the model provider, whose retention depends on the contract and must be known.

For each, set a period, write it down, and above all automate the purge. A period that lives in a policy and not in the code is not applied. We treat purging as an application feature, tested like any other.

Processors and transfers outside the Union

An agent often relies on several providers: model vendor, host, vector database, monitoring tool. Each is a processor. All must appear in your documentation and be covered by a contract compliant with Article 28.

If any of them processes data outside the Union, the rules of Chapter V of the GDPR apply. The transfer must not undermine the level of protection the regulation guarantees. It relies in particular on a European Commission adequacy decision for the country concerned, or on appropriate safeguards, such as the standard data protection clauses adopted by the Commission or binding corporate rules.

In practice, ask each provider for its list of sub-processors, the processing location of each data category and the transfer mechanism used where relevant. The CNIL's generative AI Q&A points out that the deployment mode matters: a locally hosted system limits risks, a cloud service calls for a processing contract, and API access calls for sending as little personal data as possible. We compared hosting options in hosting an AI project in France.

Individuals' rights when an agent is involved

Articles 15 to 22 of the GDPR give people rights of access, rectification, erasure, restriction, portability and objection, plus protection against fully automated decisions. Article 12 sets the response time: one month from receipt of the request, extendable by two months for complex requests, with the person informed.

With an agent, the difficulty is finding the data. An access or erasure request must cover conversations, logs, data extracted into your systems and, where relevant, documents indexed in the agent's knowledge base.

Three design precautions cover most of it:

link every conversation and log to a person or session identifier that can be found;
provide an export function and an erasure function covering all the agent's storage, including indexes;
check with the model provider how to propagate an erasure to the data it keeps.

Then there is Article 22. It gives everyone the right not to be subject to a decision based solely on automated processing which produces legal effects concerning them or similarly significantly affects them. An agent that screens out an applicant or rejects a file without human involvement enters this zone. Our rule: the agent prepares, a human genuinely decides.

The impact assessment: when it is required

Article 35 of the GDPR requires a data protection impact assessment (DPIA) when processing is likely to result in a high risk to people's rights and freedoms, in particular when using new technologies. The CNIL describes two routes. Either the processing appears on its list of operation types for which it considers a DPIA mandatory. Or it meets at least two of the nine criteria from the European guidelines: evaluation or scoring, automated decision with legal or similar effect, systematic monitoring, sensitive or highly personal data, large-scale processing, matching datasets, vulnerable people, innovative use, exclusion from a right or contract.

The innovative use criterion weighs heavily for agents. In its sheet on impact assessments for AI systems, the CNIL considers generative AI to be innovative use, because its risks are still poorly identified and controlled, whereas established techniques such as regression or clustering are not. An agent built on a generative model therefore often already ticks one criterion. A second one, for example health data, vulnerable people, large-scale processing or scoring, is enough to make the assessment mandatory.

The same sheet lists AI-specific risks to examine: misuse and leakage of data, discrimination from bias, erroneous content about real people, poorly explainable automated decisions, attacks targeting the model, users losing control over their data. We cross it with the agent's security review, led by our AI security and compliance role.

The record and the documentation

Article 30 of the GDPR requires keeping a record of processing activities. For each processing, it states in particular the purposes, categories of people and data, categories of recipients including in third countries, the planned erasure periods where possible and a general description of security measures. The regulation exempts organisations with fewer than 250 employees, but the exemption falls away as soon as the processing is likely to create a risk to people's rights, is not occasional or involves special categories of data. An agent in production, used every day, is rarely occasional.

In practice, an agent leads to one or more record entries, one per purpose. We attach a short compliance file, updated with each change:

the data flow map, from the user's device to the model provider;
the legal basis for each purpose, with the balancing test if it is legitimate interest;
the list of processors, their contracts and processing locations;
retention periods and proof that the purge works;
the information notices for individuals;
the impact assessment, or the note explaining why it was not required;
the procedure for handling rights requests.

This file is what you will pull out the day a customer, an auditor or the CNIL asks questions. It lives with the agent and is part of our responsible AI approach. It also assumes teams know the rules of the game, which we work on in bringing your teams up to speed on AI.

Are you preparing an agent, or running one without being sure it complies? The AI diagnostic reviews your use cases, their data flows and the GDPR points to address before go-live, together with your data protection officer.

Sources

Frequently asked questions

Do we need users' consent to use an AI agent?

Not systematically. Consent is only one of six legal bases, and it is often less suitable than performance of a contract or legitimate interest for a service or internal agent. The choice depends on the purpose and must be made before launch, with your data protection officer.

Can we use an American model and stay GDPR compliant?

The GDPR does not ban foreign providers. It requires a compliant processing contract and, if data leaves the Union, a transfer mechanism under Chapter V. You must also check that the provider does not reuse your data for its own purposes.

Are anonymous conversations with an agent outside the GDPR?

Rarely in practice. Users often type their name, address or a file number during the conversation, and technical logs contain identifiers. Assume by default that conversations contain personal data, and apply a retention period.

Who should write the impact assessment, us or our provider?

Responsibility lies with the controller, usually the organisation deploying the agent. The provider must supply the necessary technical information, and the data protection officer gives an opinion. We often write the technical part with the team, the decision remains yours.

What if the agent is already live without these precautions?

Start by mapping the actual flows and setting retention periods, then purge whatever exceeds them. Next, complete the information notices, the record and the processing contracts. If the agent meets the criteria for an impact assessment, carry it out without delay and adjust the processing according to its conclusions.