AI agents and the GDPR: what data leaves, and where does it go?

Your data can be protected when you use an AI agent, but that depends on what it can access, which services it contacts, and the safeguards in place. An agent may send your instructions, file excerpts, and tool results to a model provider, then retain copies in its logs or memory. To assess a use case under the GDPR, follow each data flow to its recipient and check its purpose, retention period, and safeguards.

What data can an agent send out?

The scope extends beyond what you type into a conversation. Depending on its permissions, an agent may read emails, retrieve a customer record, extract content from a document, or inspect a screenshot. Some of that content may then become part of the context sent to the model.

Consider a fictional example: you ask an agent to prepare overdue invoice reminders. It checks your accounting system, retrieves customer contact details, and drafts the messages. If it uses a remote model to write those drafts, the information needed for that step may leave your environment, even if your invoicing software remains hosted on your own infrastructure.

In particular, examine:

• instructions, attachments, and conversation histories;
• results retrieved from your files and business applications;
• arguments passed to tools, including identifiers and addresses;
• generated responses, drafts, and exported files;
• technical logs, persistent memory, and backups.

Personal data also includes information that can identify someone indirectly. The CNIL’s guidance on identifying personal data explains that an IP address, a login identifier, or a voice can fall into this category.

In your inventory, distinguish personal data from confidential business information and technical secrets. An access key does not necessarily identify a person, but exposing it could open up an entire customer database. Your safeguards need to address these risks together.

Where the data goes: map the entire chain

The interface you see rarely represents the entire architecture. Between your computer and the final recipient, data may pass through a hosting company, a gateway, a model provider, a search service, and a service that monitors agent runs.

Use the following table as an investigation checklist. It describes possible flows that you need to confirm for your own configuration.

Component	Data that may pass through it	What to check
Agent application	Messages, uploaded files, history	Hosting, administrator access, deletion
Model provider	Submitted context and responses	Use of content, retention, processing locations
Connected tools	Queries, parameters, results	Permissions, recipients, accounts used
Memory and document retrieval	Documents, excerpts, numerical representations	Storage, separation of data, deletion across copies
Technical monitoring	Logs, errors, request excerpts	Masking, access, retention period

For each row, record the legal entity receiving the data, the countries involved, and the evidence available: a contract, documentation, or a verified setting. A general statement from a sales representative is no substitute for these details.

A connector or an MCP server adds another route to examine. Its location alone does not explain the data flows: a server running on your computer can still call a remote service. Our article on protocols and tool calls explains these relationships.

Start with a fictional task and observe outbound requests, retrieved results, and recorded logs. This complements the documentation; it does not, by itself, prove that no other transfers occur, particularly during an error or maintenance work.

Local, self-hosted, or cloud: check every component

An agent installed on your computer can send requests to a remote API. Likewise, hosting the application on your server does not mean the model, document retrieval, and monitoring also run there.

To limit outbound data, check each component separately: model execution, connectors, the creation of numerical representations of documents, telemetry, and backups. The guide to running LLMs locally explains what a local installation actually covers.

The CNIL recommends choosing a deployment approach according to the data and intended use. For personal data or sensitive documentation, it presents on-premises deployment as an option for limiting exposure to a third party; using remote infrastructure requires appropriate safeguards. See its questions and answers on using generative AI.

Even when everything runs within your infrastructure, internal access matters. An overly powerful service account may expose files to employees who should not be able to view them. An inadequately protected backup may retain documents that have been deleted from the interface.

Avoid making a decision based solely on the deployment label. Ask for a description of the components actually enabled, then verify who is responsible for maintenance. Hosting internally gives you more control, but also leaves you responsible for organizing updates, access, and data restoration.

Who is responsible, and what should the contract cover?

In a business, the organization that decides why and how personal data is used is generally the data controller. A provider acting on its behalf and under its instructions may be a data processor. These roles depend on what actually happens, particularly if the provider reuses data for its own purposes.

The CNIL states that a data processing agreement must be specific, clear, and binding. Even a small business dealing with a large provider retains its obligations: signing a contract does not transfer all responsibility. Its page on identifying roles under the GDPR explains this distinction.

At a minimum, request documented answers covering:

• the processing activities covered and the data permitted;
• staff access, confidentiality, and security measures;
• other processors involved and notification of changes;
• assistance with individuals’ rights and incidents;
• data return, deletion, and options for verifying compliance.

These topics fall, in particular, within the GDPR framework for data processors. Check that the agreement specifically covers your plan and the features you use.

A statement that your data will not be used for training answers only one question. It does not automatically explain whether content is logged, accessible to support staff, or retained for security purposes. Ask the provider to distinguish these uses in its answers.

Is European hosting enough for GDPR compliance?

A European storage location is useful information, but it does not establish that the processing complies with the GDPR. You also need to examine where computation takes place, where backups go, and which countries providers can access the data from.

Transfers outside the European Economic Area are not prohibited in principle. They must be covered by the applicable mechanism, such as an adequacy decision or appropriate safeguards. Depending on the circumstances, a transfer assessment and supplementary measures may be necessary. The CNIL provides guidance on safeguards for international transfers.

For your agent, request a separate answer for:

• storage of conversations and documents;
• processing of model requests;
• logs and backups;
• support activities and subprocessors.

Also check what happens when a service becomes unavailable. A fallback feature that switches to another provider may change the recipients or countries involved. Include it in your data flow map before allowing its use.

Encryption in transit protects the connection. It does not mean the receiving service cannot read the content it needs to process. Ask who can access decrypted data, under what circumstances, and what records of that access are kept.

Minimize data before granting access

The most direct measure is to send less information. To draft a payment reminder, the model may not need the customer’s complete transaction history. You can restrict the fields retrieved and add the recipient’s address only when the message is ready to send.

Replacing a name with an identifier can reduce exposure. However, this remains pseudonymization if a lookup table or the surrounding context can identify the person. The CNIL clearly distinguishes this from irreversible anonymization.

Next, apply the principle of least privilege: a dedicated folder, a separate account, read-only access where possible, and tools limited to what the task requires. For outgoing messages, require an approval step that displays the recipient, content, and attachments.

That approval does not protect data already sent to the model while preparing the message. Filtering must happen before transmission. Simply instructing the agent to keep information confidential therefore cannot replace controls over access and outbound data.

Finally, examine memory. Deletion needs to account for conversation history, document indexes, and logs, according to the applicable retention rules. The article on AI agent memory helps identify these copies; the guide to securing an AI agent covers technical controls.

Before deployment: document the decision

Start by defining the precise purpose and legal basis for the processing. Identify the people concerned, the information you need to give them, and how you will handle requests for access, rectification, or erasure. The agent’s operation must allow you to locate the relevant data.

Next, assess whether a data protection impact assessment, or DPIA, is required. It is mandatory when processing is likely to result in a high risk to individuals’ rights and freedoms. The CNIL’s overview of DPIAs links to the applicable criteria and lists. The involvement of an agent does not, by itself, settle the question.

Involve the person responsible for data protection and the security lead, where those roles exist. Also establish who can suspend the agent, revoke its access, and contact providers if a data leak is suspected.

Before allowing real data to be used:

• The necessary data and permitted uses are defined.
• Every recipient and processing location is documented.
• Contracts, transfers, and retention periods have been checked.
• Access, outbound data flows, and deletion have been checked using fictional data.
• A procedure exists for handling individuals’ rights and incidents.

The AI agent security assessment complements this technical review. Keep the supporting evidence and reassess the decision after adding a connector, memory, or provider: each change may alter which data leaves your environment and where it goes.

Frequently asked questions

Can a free AI agent process customer data?

The price alone cannot answer that question. You need to review the terms of the specific plan, who receives the data, and the contractual safeguards available. If these do not provide an adequate framework for processing, restrict the tool to content without personal data or confidential information.

Do I need consent before using an AI agent?

Consent is not the only legal basis available under the GDPR. The appropriate basis depends on your purpose and the circumstances of the processing. An employee's permission to connect their account does not, by itself, resolve the requirements for processing customer data held in that account.

Is an AI agent installed on my computer necessarily private?

Installation tells you where part of the software runs. It does not tell you where model requests, backups, or diagnostic data go. You still need to check outbound connections.

Can I send pseudonymized data to a remote model?

Pseudonymization can reduce exposure, but the information remains personal data if reidentification is still possible. Appropriate safeguards for the provider and any transfers are therefore still required. You must also check whether details within the document could identify the person.