An AI agent project usually stalls at the same door: the security and privacy review. And it stalls late, with the pilot finished and the launch date set, because the conversation about data protection only started after the demo worked.
The good news is that the list of things to resolve is short and well known. Brazil's LGPD (Law 13.709/2018, the country's general data protection law) does not treat artificial intelligence separately: it treats the processing of personal data, and an agent is one more processing agent. What changes is where the exposure shows up. This text maps the five places and the control that resolves each one.
This is a guide for engineering and for a purchase decision, not a legal opinion. The lawful basis, the purpose and the risk assessment for your case are analysis for your legal team and your data protection officer.
The five points of exposure
1. What goes into the prompt
To answer a question about an order, the agent needs the order. In practice the team assembles the context with the customer's entire record, because that is simpler than choosing field by field. Tax ID, address, phone number and history leave your database and go to the model provider, often without anyone having decided that explicitly.
It is the point that shows up most in an audit, and the cheapest to fix: the principle of necessity (art. 6) asks for the minimum, and in most cases the model does not need the identifier in order to write the answer. It needs the balance, the date and the status.
2. Retention by the model provider
What happens to the text after it reaches the provider depends on the contract and the configuration, not on reputation. The questions that need an answer in writing: is the content retained, for how long, who accesses it, and is it used to train a model. Enterprise contracts usually allow zero retention, but that is rarely the default on an account opened with a credit card.
3. International transfer
Most frontier models are processed outside Brazil, and the international transfer of personal data has its own regime under the LGPD (art. 33). It is not forbidden, it is conditional, and the condition has to be documented beforehand rather than afterwards. It is worth mapping the processing region of every provider the agent uses, including the supporting ones such as transcription and vector search.
4. Automated decisions
This is the point specific to agents, and the most often forgotten. Art. 20 gives the data subject the right to request a review of a decision taken solely on the basis of automated processing that affects their interests. An agent that approves, denies, scores risk or sets commercial terms is squarely in that territory.
Two practical consequences: there has to be a human review path accessible to the data subject, and it has to be possible to reconstruct the decision. "The model decided" is not an answer.
5. The log becomes a personal data store
To operate an agent responsibly you have to record inputs, outputs, tools called and decisions. That record contains personal data and is itself processing: it belongs in the inventory, it has a retention period, it needs access control, and it has to be reachable when a data subject requests erasure (art. 18).
This is the point that catches well-intentioned teams most often. The observability that exists to make the operation safe creates, with no warning, a second store of personal data that nobody inventoried.
The controls that resolve them
| Exposure | Control |
|---|---|
| Personal data in the prompt | Sanitization before sending: mask the identifier and send only the field that changes the answer. |
| Retention by the provider | A contract with zero retention, or your own model on your infrastructure for the sensitive case. |
| International transfer | A map per provider, including the supporting ones, with a documented basis and a chosen processing region. |
| Automated decisions | Mandatory human approval where the decision affects the data subject, and a trail that allows the path to be reconstructed. |
| Logs containing personal data | Inventory, retention period, restricted access and erasure that also reaches the agent's history. |
On the first one: sanitizing does not mean deleting everything. An agent that receives "customer with an invoice of R$ 3,480 overdue by 12 days, Enterprise plan" answers just as well as one that receives the full name, tax ID and address, and the exposure drops to near zero. The question that guides the cut is always the same: does this field change the answer?
The checklist before go-live
Take this list into the internal review. It usually brings forward by weeks the conversation that would otherwise block the launch.
- Purpose and lawful basis defined per use case, and not for "the AI project" as a whole.
- An inventory of the fields that actually leave your environment and go to the model, with the justification for each one.
- A contract with each provider stating the retention and training policy in writing.
- A map of international transfers, including the supporting providers.
- A human review path for decisions that affect the data subject, documented and accessible.
- An audit trail with a defined retention period and restricted access.
- A procedure for handling data subject rights that reaches the agent's history, and not only the main database.
- An incident response plan that covers an improper answer by the agent, and not only a database breach.
- The data protection officer aware and involved, before the pilot rather than after.
Three mistakes that cost dearly
- Treating the pilot as out of scope. A pilot with real customer data is processing of personal data, with the same obligations. "It is only a test" is not a legal category.
- Confusing encryption with compliance. Protecting data in transit and at rest does not answer purpose, lawful basis, retention or the right to review. Those controls are necessary and they are not sufficient.
- Leaving governance for phase two. Rebuilding the architecture under audit costs far more than building with the control in place from the start, and it usually arrives together with deadline pressure.
What to ask any vendor
- Is the data isolated per client, end to end? How is that guaranteed?
- Do you train models on customer data? Is that in the contract?
- Can I choose the model provider and the processing region, or run my own model on my infrastructure?
- Is sensitive data sanitized before the information reaches the model?
- Can I require human approval by type of action, rather than only globally?
- Does the trail record which tool was called with which parameters, and is it reproducible?
- Can I erase a specific data subject's history without wiping the whole store?
A vendor that answers all seven in writing has been through the compliance conversation before. A vendor that answers "we are compliant" has answered none of them.
How Runflow handles this
The platform was built with these controls as part of the product, not as optional configuration: per-client data isolation end to end, sanitization of sensitive data before it reaches the model, human approval where the risk demands it, and an audit trail of every execution, decision and tool call, reproducible for an audit.
Runflow does not train models on your data, and you decide where it goes: providers with no retention, or your own model on your infrastructure. The platform runs managed by us or in your own cloud (AWS, Azure or GCP), with your keys and your environments, when your sector's bar requires that the data never leaves the house.
