Data Protection Officer Role in AI Projects in Brazil: What to Review

Data Protection Officer Role in AI Projects in Brazil: What to Review

The data protection officer (DPO, called the encarregado under Brazil's LGPD) should review an AI agent the way they review any processing of personal data, with a few extra questions: what the agent reads, what it writes, what it executes and who can see the record. A useful review happens before the agent operates, and it fits into a short set of concrete questions: what data comes in, for what purpose, where it goes, who decides, what is stored and how people exercise their rights.

Key takeaways

• An agent changes data processing because it reads free-text messages, queries systems and can act, so the data inventory must include conversations, attachments, audio and logs.
• Purpose and necessity come before technology: if the agent does not need a piece of data to do its task, it should not have access to it.
• Model, hosting and messaging vendors are potential processors or sub-processors, so the contract and the location of the data must be known.
• Actions that affect the data subject need limits, human approval and a way to request review.
• The data subject channel and the incident plan must work before the first real conversation, not after.

What is the DPO's role in an AI agent project?

The LGPD defines the DPO as the communication channel between the controller, data subjects and the ANPD (Brazil's national data protection authority). In an agent project, this has a practical meaning: the DPO needs to be at the table before the architecture decision, not receive a finished document to sign.

The DPO does not need to understand a language model in detail. They need to know what goes into the agent, what comes out, where it is recorded and who is accountable for each step. The people who understand the technology explain the flow, and the DPO translates that flow into obligations and risks.

A good practice is to separate three kinds of statements in the project documentation: what comes from the vendor's official documentation, what was verified in the company's own implementation and what is still a hypothesis. When a vendor says it does not use data for training, for example, that is a claim from official documentation, and the DPO should keep the source and the version consulted, not just a conversation with a salesperson.

For the wider regulatory context, it is worth following what changes under Brazil's AI regulation, but the LGPD already applies today to any agent that handles personal data.

Which data does the agent touch? Start with the inventory

An agent's data inventory is bigger than a form's. A form has defined fields. An agent receives free text, and a customer can write anything: a tax ID, an address, a health condition, a photo of a document, an audio recording with a third party's voice.

Questions for the inventory:

• Which channels feed the agent (WhatsApp, Instagram, email, website, transcribed phone calls)?
• What data does the agent receive from the data subject, and what data does it fetch from internal systems (CRM, ERP, calendar)?
• Can sensitive data or data about children and teenagers arrive, even if the flow never asks for it?
• Are attachments, images and audio processed? If so, by which service? The article on transcribing WhatsApp voice messages covers the privacy questions in that case.
• Is the conversation history resent to the model with every message?
• Is there long-term memory across different conversations?
• Is the data used to evaluate and improve the agent? By whom?

The most forgotten item is data that arrives without being requested. The agent's design should define what it does when it receives data it should not have: ignore it, ask the person not to send it, mask it in the log or hand it to a human. That decision needs to be written down, not left to the model's behavior.

What are the purpose and legal basis of each processing activity?

An agent is often sold as one thing, but it processes data for different purposes: answering a question, checking an order, booking a service, qualifying a lead, measuring quality. Each purpose needs its own legal basis and a description the data subject can understand.

Questions for the DPO:

• Is the purpose of each flow described in one plain sentence?
• Which legal basis supports each flow: contract performance, legitimate interest, consent, legal obligation?
• If it is legitimate interest, is there a documented assessment weighing the company's interest against the data subject's expectations?
• If it is consent, is it specific, recorded and revocable?
• Is the data collected limited to what the task needs (the necessity principle)?
• Is using conversations to evaluate or improve the agent a compatible purpose, or does it need separate treatment?

Outbound messages deserve separate attention. An agent that starts the conversation depends on prior permission and approved templates, which the article on WhatsApp outbound messages, templates and opt-in explains from an operational point of view. For the DPO, the opt-in record is proof of legal basis, not a technical detail.

The ANPD can request a data protection impact assessment. For agents that handle sensitive data or make decisions with a relevant effect on people, it makes sense to prepare one before it is requested.

Where does the data go? Vendors, processors and location

A typical agent involves several vendors: the model provider, the messaging platform, hosting, the logging tool and the CRM. Each one may be a processor or sub-processor, and the DPO needs the complete map.

Questions about vendors:

• Who are all the vendors that see conversation content, including monitoring and logging tools?
• Is there a contract or data processing agreement with each one, with instructions on use, retention and deletion?
• Does the model vendor use the content for training? Is that stated in official documentation or only in a sales promise?
• In which countries is the data processed and stored? Is there an international transfer, and which mechanism supports it?
• What is the retention period at the vendor, and how is deletion requested?
• Does the vendor notify the company of an incident, and within what time?

When data sensitivity is high, running a model on the company's own infrastructure can reduce exposure to third parties. It brings other responsibilities, such as security, updates and capacity. The guide on running Ollama local models in a company covers that path without improvisation. A local model does not remove the LGPD, it only changes who operates the system and who answers for it.

The tools connected to the agent belong on this map too. Each integration is a doorway to data, and the principle is the same as for any system: minimum access, by role, with separate credentials. The OWASP guidance on authorization is a useful reference for the technical team.

What can the agent do alone, and when does a human step in?

An agent that only answers general questions has one risk profile. An agent that looks up customer data, edits records, cancels orders or denies a request has another. The DPO should separate what the agent informs, what it recommends and what it executes.

The LGPD guarantees data subjects the right to request review of decisions made solely through automated processing that affect their interests. The article on automated decision-making and Article 20 of the LGPD goes deeper. In practice, the question is: is there any decision the agent makes that a person cannot review?

A decision guide to classify each agent action:

• Informing data the data subject can already see: can be automatic, after the person is identified.
• Changing registration data: requires the data subject's confirmation through a verified channel and a record of the change.
• Refusing, canceling, charging or restricting something: requires human approval or, at minimum, easy and clearly communicated review.
• Handling health, children, personal finances or legal complaints: route to a trained person.
• Any irreversible action: human approval before execution.

The technical controls behind these rules (input, output and action validation) are described in guardrails for AI agents. For risks specific to language models, such as instruction injection through malicious messages and leakage of sensitive information, the OWASP Top 10 for LLM applications is a good review base to use with the technical team.

How does the data subject reach the company, and what gets recorded?

Data subjects have rights such as confirmation of processing, access, correction, deletion and information about sharing. If the data lives inside conversations, logs and the agent's databases, the DPO needs to know how to find and handle it when a request arrives.

Questions about the data subject channel:

• Does the person know they are talking to an AI agent from the start of the conversation?
• Is there a clear path, inside the conversation itself, to reach a human?
• Does the privacy notice mention the agent, the purposes and the vendors involved?
• How does the company find every conversation and record belonging to a specific person? Is there an identifier that makes this possible?
• How is a deletion request handled when it reaches logs, backups and evaluation datasets?
• Who receives the request, how quickly do they answer and how is that recorded?

Records are a delicate balance. Decision logs are essential for auditing the agent, but logs with the full content of conversations are personal data in large volume. Define what is recorded (action, tool called, result, reason for handoff), what is masked, who has access and how long it is kept. Observability concepts, such as those in the OpenTelemetry documentation, help the technical team record what is needed without storing excess content.

For incidents, the DPO needs a plan that answers: who detects it, who decides whether there is a relevant risk to data subjects, who notifies the ANPD and the data subjects when required, and what evidence from the agent will be available. An agent that sent a message to the wrong person or exposed data in a reply is a security incident, not just a support mistake.

If the agent is also used to track employee performance, the scope changes in nature. The article on measuring AI productivity without surveillance covers the limits of that use.

A step-by-step review plan, with an illustrative scenario

The method we use for agent projects has four moves: map, limit, pilot and hand over. They fit the DPO's routine well, because each one produces a reviewable artifact.

Illustrative scenario: a building materials distributor wants a WhatsApp agent to report order status and reschedule deliveries. The review could follow this outline:

• Map: list the channels, the data customers send, the systems queried (ERP and delivery calendar), the vendors involved and the current process run by people, to have a baseline.
• Limit: the agent only looks up orders tied to the phone number that started the conversation, confirms the data subject before showing an address, has no access to financial data and does not cancel orders. Cancellations and disputes go to a person.
• Define the processing: purpose, legal basis, retention of conversations and logs, and masking of documents sent by mistake.
• Prepare the data subject channel: a notice that it is an agent, an option to speak to a person and an internal procedure for access and deletion requests.
• Pilot: run one real flow, with decision logs and a success metric agreed in advance, reviewing the handoff cases and the messages containing unexpected data.
• Hand over: document what was decided, who monitors, who approves changes, and decide whether the pilot expands, is adjusted or ends.

The central point is that the decision to expand should come only after the DPO has seen evidence from the pilot: examples of messages with unexpected data, handoff records and a test of the data subject request flow. A risk framework such as the NIST AI Risk Management Framework can serve as a shared vocabulary between legal, operations and technology.

Frequently asked questions

Does the DPO need to approve every AI agent in the company? The LGPD does not describe a formal approval for each agent, but the DPO advises the company on data protection practices. In practice, it helps to set an internal rule: every agent that handles personal data goes through a DPO review before operating, with intensity proportional to risk.

Do I need an impact assessment to put an agent into operation? There is no single answer, because it depends on the data and the decisions involved. When the agent handles sensitive data, operates at scale or supports decisions that affect people, preparing the impact assessment is a prudent practice, and the ANPD can request it from the controller.

The model vendor says it does not train on the company's data. Is that enough? Not as the only evidence. Record the official source and the version consulted, check the contract and the data processing terms, verify retention, location and sub-processors, and review that information whenever the vendor updates its terms.

Can the agent serve customers without saying it is an AI? The safest and most transparent path is to say so from the start. Transparency is an LGPD principle, it reduces complaints and makes clear when the person can ask for a human. Hiding that it is an agent usually creates more risk than benefit.

Sources

• ANPD: Autoridade Nacional de Proteção de Dados
• NIST AI Risk Management Framework
• OWASP Top 10 for LLM Applications
• OWASP: Authorization Cheat Sheet