LGPD and AI Agents: What Brazilian Companies Should Check

LGPD applies to an AI agent the way it applies to any other system that processes personal data. You need a clear purpose, a suitable legal basis, limited access, named responsibility and a way to answer people about their data. The practical work is answering a short set of questions about what the agent reads, remembers, sends and who reviews it, before it goes live. This article lists those questions as a starting point for a conversation with your DPO or legal counsel. It is not legal advice.

Key takeaways

• Treat the agent as a new way of processing data inside your existing LGPD program, not as a separate category outside it.
• Write down the purpose, legal basis and data categories for each role the agent performs before connecting any tool.
• Memory, logs and drafts are personal data stores too, so they need retention rules and a way to correct or remove entries.
• Map every provider and system the data touches, including where it is processed and who can access it.
• Keep a human approval point wherever the agent's output affects a person, and keep evidence that the control works.

What changes when an agent handles personal data?

LGPD is technology neutral in spirit. It cares about what is done with personal data, for what reason and with which safeguards. An agent does not change that test. It changes the shape of the processing.

A traditional system performs a fixed set of operations on fields it was built for. An agent reads free text, documents and messages, decides what looks relevant, and may draft, update or send something as a result. That has three practical consequences.

First, the data entering the agent is less predictable. A support inbox may contain identification numbers, addresses, health details or information about children, even if nobody planned for that. Second, the agent can keep context between tasks, so personal data can persist in memory or notes unless you decide otherwise. Third, its actions can reach other people: an email draft, a CRM change, a message to a customer.

So the useful starting question is not whether the AI is compliant. It is what exactly this role will do, with which data, and who answers for it. If you want a plain definition of what a business agent is before scoping, what an AI agent for business is covers it without jargon.

Who is the controller and who is the operator?

LGPD distinguishes the controller (controlador), who makes the decisions about processing, from the operator (operador), who processes data on the controller's behalf. In most business deployments your company is the controller for the data of its customers, employees and prospects. A partner that runs the agent for you is usually acting as an operator. A model provider or hosting vendor behind that partner may be a further party in the chain.

Roles depend on the facts and the contracts, so confirm them with counsel rather than assuming. These are the questions to put in writing:

• Who decides the purposes of the agent's processing, and where is that decision recorded?
• Is there a contract that sets the operator's instructions, security duties, incident notice, subprocessors and return or deletion of data at the end?
• Who is your encarregado (data protection officer), and have they reviewed this role before launch?
• Is the agent's processing listed in your record of processing activities?
• Is a data protection impact assessment (relatório de impacto) warranted for this role, given the data and the risk to people?

The ANPD, Brazil's national data protection authority, publishes guidance and regulations that refine these points, and it is the right place to check current expectations: [ANPD](https://www.gov.br/anpd/pt-br).

Which questions should you answer before the agent touches personal data?

This is the core checklist. Go through it per role, not per company, because a scheduling role and a collections role process very different data. Treat any question you cannot answer as a blocker for that role, not as a footnote.

Purpose and legal basis:

• What specific task is the agent performing, and for which data subjects?
• Which legal basis supports each purpose, and does it still hold if the agent also writes summaries or notes for later use?
• Is any processing new compared with the purpose for which the data was originally collected?

Data and minimisation:

• Which categories of personal data can the agent see, and which does it actually need?
• Can sensitive data (health, biometrics, beliefs, data about children) reach the agent by accident, and what happens when it does?
• Can identifiers be removed or masked before the agent reads a document?

Access and actions:

• Does the agent have its own account with the narrowest permissions, or is it borrowing a person's login?
• Is each tool read-only, draft-only or able to send and write? The distinction is explained in read, draft and send as three different permissions.
• Which actions require a person to approve before anything leaves the company?

Transparency and rights:

• Do your privacy notices describe this processing in terms a customer would understand?
• Can you find, correct, export or delete everything the agent holds about one person?
• If the agent contributes to a decision that significantly affects someone, can that person obtain a review, and does a human do it?

Security and incidents:

• What would you notice, and how fast, if the agent exposed data to the wrong person?
• Who decides whether an incident must be reported to the ANPD and to the people affected, and is that path written down?
• Has the agent been tested against hostile content in documents and emails? The [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/) is a useful reference for those risks.

How do memory, logs and deletion fit with people's rights?

Agents are useful partly because they remember context: a customer's preferences, the status of a case, a decision from last week. From a data protection point of view, that memory is a data store like any other. So are conversation logs, draft folders, retrieved document snippets and any notes the agent writes for itself.

For each store, decide four things in advance:

• What may be kept (for example, case status, but not identification document numbers).
• How long it is kept, and what triggers expiry.
• How an entry is corrected when it is wrong.
• How an entry is removed when the person exercises a right or the purpose ends.

Deletion is where many setups fail, because the same fact can sit in memory, in a log and in a retrieval index. A workable approach separates three actions: correct a wrong entry, let an old entry expire, and remove an entry on request, with a record that the removal happened. The article on how to delete AI agent memory walks through those three cases.

Logs deserve the same care. You need enough record to investigate a mistake or an incident, but a log that copies every message in full becomes a second copy of your customer data. Decide what to log and what to leave out, using the guidance in what an AI agent should actually log.

Where does the data go, and who else touches it?

An agent is rarely one product. It is usually a model, a runtime, a set of tools, storage for memory and connections to your mail, CRM or document systems. Each hop is a place where personal data may be processed, stored or logged by someone else.

Map it as a simple chain and ask the same questions at every link:

• Which company operates this component, and under what contract?
• In which country is the data processed and stored?
• Does the provider retain prompts or outputs, for how long, and can retention be limited?
• Is the data used to train models, and can that be switched off in writing?
• Which subprocessors are involved, and will you be told when they change?

If any link sits outside Brazil, LGPD's rules on international transfer of personal data come into play, and the mechanism you rely on needs to be identified with counsel. The business side of this question is covered in AI data residency for business. Also check how credentials are handled: an agent should use scoped authorisation, not a shared password, which is the standard pattern described in [OWASP's authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html).

What does a step-by-step plan look like?

The plan below turns the questions into an order of work. It assumes one role at a time, which keeps the answers specific.

• Define the role in one sentence, including who it serves and what it must never do.
• List the personal data the role will encounter, split into needed, possible and sensitive.
• Record purpose and legal basis for each use, with your DPO or counsel.
• Remove or mask what the role does not need, and decide how sensitive items are routed to a person.
• Give the agent its own identity and the narrowest permissions, starting read-only.
• Set memory and log rules: what is kept, for how long, and how entries are corrected or removed.
• Map providers, locations and contracts, and note anything that needs a transfer mechanism.
• Place human approval at every point where output reaches a person or changes a record. See where your AI agent should stop and ask.
• Test with realistic and hostile examples, and keep the results as evidence.
• Write the incident path, name the owners and rehearse it once before launch.

An illustrative scenario: a services company wants an agent to draft replies in a customer support mailbox. The mailbox sometimes contains tax identification numbers, home addresses and, occasionally, health information in attachments. After walking the list, the company decides the agent may read only the support folder, may only create drafts, and must route any message with an attachment flagged as sensitive to a person without processing it. Its memory keeps case status and the customer's preferred language, but not document numbers, and entries expire when a case closes. The privacy notice is updated, and the DPO signs off on the legal basis. None of this required a new technology, only decisions made before launch.

How does a managed approach keep the answers current?

The answers to these questions drift. Staff change, new tools are connected, a provider updates a service, and a role quietly grows. Be Human designs and operates personalized AI infrastructure for companies, and for each role it fixes the memory, tools, permissions and approval boundaries in writing at the start. Managed operations then include permission review, monitoring, recurring evaluations and controlled changes, so the written boundaries are checked against what the agent actually does. Your company remains the party that decides purposes and legal bases, with its DPO and counsel. The work on our side is to make the agent's behaviour observable and to keep the record accurate. If you want a sense of what to prepare first, the readiness checklist is a good companion to this one, and the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) offers a neutral vocabulary for risk reviews.

Frequently asked questions

Does LGPD apply if the AI agent only drafts and a person sends? Yes. Reading, storing and drafting from personal data are all forms of processing, whether or not a human presses send. The human step reduces risk, but it does not remove the need for purpose, legal basis and safeguards.

Do we need consent to use an AI agent with customer data? Not necessarily. LGPD offers several legal bases, and the right one depends on the purpose and the relationship with the person. Your DPO or counsel should choose it per purpose, and consent is not automatically the best fit.

Can the agent make decisions about people on its own? LGPD gives people the right to ask for a review of decisions based solely on automated processing that affect their interests. The safer design is for the agent to prepare information and for a person to decide when the outcome materially affects someone. Document who reviews and how a request for review is handled.

What should we do first if an agent is already running without this review? Pause any expansion, list what data the agent can reach and what it stores, and tighten permissions to what the role needs. Then involve your DPO or counsel to confirm legal basis, provider terms and retention. Fix the highest exposure first, and keep a record of the changes you make.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.