An AI agent in your operations reads customer messages, looks up records, opens documents and writes information into systems. Almost all of that involves personal data. Under privacy laws like GDPR in Europe and LGPD in Brazil, the agent is just another way of processing data, and the responsibility stays with your company.
That’s no reason to stall the project. It’s a reason to ask a few questions before you switch it on. Here we organize the topic into three parts: where the exposure points are, what to ask of your vendor and what needs to be ready on your side.
Why an AI agent changes the privacy conversation
A regular system does what it was programmed to do. An agent decides what to look up and what to do based on what it reads. That brings three practical differences:
- It can access more than it needs. If it has permission to read the entire customer record, it can pull data into the conversation that has nothing to do with the case.
- Data passes through more places. The text goes to the model provider and may end up in logs, conversation memory and search indexes.
- It can make decisions that affect people. Approve, deny, prioritize, classify. GDPR (Article 22) and LGPD (Article 20) both give people rights around decisions based solely on automated processing, including asking for human review.
The law applies the same way to a spreadsheet and to an agent. What changes is the number of paths through which data can leak or be misused.
Where the exposure points are
Before any contract, draw a simple map of the data’s path. The points that come up most:
- Input. What reaches the agent: messages, attachments, voice notes, documents. Customers send more than was asked for, like a photo of an ID, health information or someone else’s data.
- Context sent to the model. Everything the agent sends the model provider in each call: instructions, history, records it looked up.
- Model provider. Where it processes data, whether it stores the content, for how long and whether it uses it for training.
- Tools and integrations. Every system the agent accesses and at what permission level.
- Memory and search indexes. Conversations kept for continuity and documents indexed for lookup. It’s easy to forget these are personal data stores too.
- Logs. Needed for audits, but they often keep full conversation content with no deletion date.
- Output. What the agent replies and to whom. A misidentification can send one customer’s data to another.
If any of these points involves servers in another country, you’re dealing with an international data transfer. GDPR, LGPD and most modern privacy laws regulate this and list the accepted mechanisms, such as standard contractual clauses. Ask your legal team which one the contract relies on.
What to ask of your vendor
Whether it’s an off-the-shelf platform or a company building the agent for you, ask for written answers:
- Which model providers are used, in which countries data is processed and whether content is used to train models.
- How long each type of data is kept (conversations, logs, memory, search indexes) and how deletion works.
- Who inside the vendor can see conversation content, in what situations and with what record.
- How the agent accesses your systems: under which identity, with which permissions and whether access can be restricted by role.
- What record exists of each agent action, whether you can access it and in what format.
- How security incidents are communicated and how quickly you’re notified.
- Which subprocessors take part in the processing.
- How the vendor helps you handle data subject requests: access, correction, deletion.
In most of these projects, your company is the data controller and the vendor is the processor. The contract, usually a data processing agreement, needs to reflect that and spell out the processor’s obligations. A vague answer like “we follow best practices” isn’t an answer.
If the vendor can’t tell you where the data goes and how long it stays, they’re not ready for production yet.
What needs to be ready on your side
Part of governance can’t be outsourced. Before switching the agent on, check:
- Purpose and legal basis. What the agent processes each type of data for, and on what legal basis. If the use is new, check whether your current basis covers it.
- Records of processing. GDPR (Article 30) and LGPD (Article 37) require controllers and processors to keep these records. The agent needs to be in them.
- Impact assessment, where required. If processing involves sensitive data, large volumes or significant automated decisions, prepare a data protection impact assessment with your data protection officer.
- Data minimization. The agent accesses only the fields it needs. If it checks deliveries, it doesn’t need to see the customer’s financial data.
- Notice to individuals. People talking to the agent know they’re talking to an AI and know how to reach a person.
- A path to human review. If the agent makes or recommends decisions that affect someone, there’s a clear way to ask for review.
- An owner for the agent. One person responsible for monitoring how it runs, approving changes and answering when something goes wrong.
Controls that make a difference day to day
Documents alone don’t protect anyone. The controls that reduce risk most in practice:
- Role-based permissions, with read-only access wherever there’s no reason to write.
- Human approval before actions that send data outside or can’t be undone.
- Masking of data the model doesn’t need to see, like full ID and card numbers.
- Defined deletion periods for conversations, memory and logs, enforced automatically.
- A record of every agent action, protected against tampering and with controlled access.
- Testing with hard cases before launch: a customer asking for someone else’s data, a message with a hidden instruction, a document with sensitive data nobody asked for.
- A quick way to switch off the agent, or a specific tool, if something goes wrong.
When something goes wrong
Even with all of this, an incident can happen. Data shown to the wrong person, unauthorized access or a leaked log. Privacy laws set tight deadlines: GDPR requires notifying the supervisory authority within 72 hours of becoming aware of a breach (Article 33), and in Brazil the ANPD’s rules set three business days to notify the authority and affected individuals.
That’s very little time if you have to figure out from scratch what happened. So before going into production, have these defined:
- Who gets notified first and who decides to switch the agent off.
- Where the logs are that show what the agent accessed and did.
- Who at the vendor responds, and how quickly.
- How your data protection officer gets involved.
With that in place, an incident becomes a known procedure instead of a scramble.
Good governance is what lets you trust the agent with important work. And it’s usually what decides whether the project reaches production.