
International Data Transfer Under LGPD When Using AI Providers
Sending personal data to an AI API hosted abroad can count as international data transfer under LGPD. See the mechanisms, records and vendor questions to ask.
Want to apply this in your company?
Book a call with Juan →International Data Transfer Under LGPD When Using AI Providers
In many cases, yes: using an AI API hosted outside Brazil is an international data transfer under LGPD whenever personal data is sent to servers or a vendor in another country. When that happens, your company needs a legal basis to process the data, a transfer mechanism under Article 33, and records showing what was sent, for what purpose and with which safeguards. This article is general guidance and does not replace legal advice: the final decision should involve your data protection officer (the encarregado) and legal counsel.
Key takeaways
- LGPD defines international transfer as sending personal data to a foreign country or an international organization. Sending a prompt with a customer's name, phone number or history to an API abroad usually fits that definition.
- The transfer needs a legal basis for the processing and, separately, a mechanism under Article 33, such as contractual clauses, an adequacy decision or specific consent.
- Treating the AI vendor as a processor (operador) requires a clear contract covering purpose, retention, subprocessors and use of data for training.
- Records of operations and a risk assessment are what let you prove compliance. Without them, a company may be doing everything right and still be unable to show it.
- Reducing the data you send is the cheapest control: less personal data in the prompt means less exposure and less documentation.
Why can using an AI API outside Brazil be an international transfer?
Article 5 of LGPD defines international data transfer as the transfer of personal data to a foreign country or to an international organization of which Brazil is a member. The test is not the size of the transfer, and it is not whether the company plans to keep the data. It is enough that personal data leaves Brazil to be processed by someone abroad.
When your company calls an AI API, it sends text to a provider that processes it on its own infrastructure or on a third party's. If that text contains personal data, and in customer service it almost always does, the operation may be an international transfer. Some examples of personal data that end up in prompts without anyone noticing:
- names, phone numbers and emails pasted into a question to the model;
- excerpts of WhatsApp conversations sent for summarizing or classification;
- audio transcripts, which carry voices, names and context (see more in transcribing WhatsApp voice messages with AI);
- PDFs of contracts, reports or registration forms sent for field extraction;
- error logs that include the request body.
Some points depend on facts, so treat them as hypotheses to check, not conclusions. Some providers offer processing in a specific region. Others use subprocessors in countries different from the main region. Others keep content for some period to monitor abuse. Each of these changes the analysis, and the answer lives in the vendor's contract documents, not in assumptions. The practical rule: if you cannot say where the data is processed and by whom, treat it as a possible international transfer until you can show otherwise.
Effectively anonymized data falls outside LGPD, but real anonymization is hard. Removing the name while leaving a CPF, an address or another identifying detail in the text does not solve it.
What does LGPD require before sending data abroad?
There are two layers, and companies often mix them up.
The first is the legal basis for the processing itself. Before thinking about transfer, you need to know why the company processes that data: contract performance, legal obligation, legitimate interest, consent or another ground in Article 7 (or Article 11, if sensitive data such as health is involved). If the processing has no basis to begin with, sending it abroad fixes nothing.
The second is the mechanism that authorizes the transfer abroad. Article 33 lists the options. The ones most relevant to a company contracting AI services are:
- A country or organization with an adequate level of protection, recognized under the established procedure. Check the ANPD website (Brazil's data protection authority) for what has actually been recognized instead of assuming.
- Safeguards offered and demonstrated by the controller, through specific contractual clauses, standard contractual clauses, binding corporate rules, or seals, certifications and codes of conduct.
- Specific and prominent consent from the data subject, with prior information about the international nature of the operation.
- Other grounds, such as compliance with a legal obligation or contract performance, when they apply under the terms of the article.
The ANPD has regulated international transfers and published standard contractual clauses. Because regulations change and come with adaptation periods, check the current version on the authority's website before signing a contract. Large AI vendors often include transfer clauses in their data processing terms, but it is up to your company to confirm they cover what LGPD requires, not just to accept the default terms.
Remember also that your company remains responsible as the controller. Hiring a processor abroad does not shift responsibility for choosing, instructing and supervising it.
Which records and documents should the company keep?
LGPD requires the controller to keep a record of processing operations (Article 37), and the ANPD can request a data protection impact report. For a project using an external AI API, a lean and honest set of documents is usually enough to start:
- A flow inventory: which data goes into the prompt, where it comes from, what it is for and which vendor receives it.
- The legal basis and transfer mechanism chosen, with the reasoning in a few lines.
- The contract or addendum with the vendor, including processor role, purpose, retention, subprocessors, processing location and use for training.
- A risk assessment or impact report, when the processing involves significant volume, sensitive data or decisions about people.
- Minimization rules: what is removed or masked before sending.
- Access and operation logs: who called what, when and for what purpose, and how data subject requests are handled.
- An incident plan that includes the AI vendor as a link in the chain.
The NIST AI Risk Management Framework helps structure the risk assessment of AI systems, even though it is not a Brazilian standard. And the OWASP Top 10 for LLM applications lists sensitive information disclosure as a risk, which reinforces the need to control what goes into and comes out of the model.
If AI takes part in decisions that affect people, such as credit or screening, the right to review also applies: see LGPD automated decision-making.
Illustrative scenario: a WhatsApp support agent
Illustrative scenario: a services company wants an agent that answers questions on WhatsApp and summarizes each conversation for the team. The agent calls an AI API hosted in another country. The prompt includes the customer's message, their name and their recent order history.
During the review, the team notices three things. First, the phone number and name are not needed for the model to summarize the conversation: an internal identifier is enough, and the company's own system reconnects the summary to the customer afterward. Second, customers sometimes send documents and photos, which may contain sensitive data or third-party data, so the agent should decline those attachments and route them to a person. Third, the integration platform's logs store the message bodies, which is also processing that needs to be documented.
With these changes, the flow sends less personal data, the legal basis (performance of the support contract) is clear, the vendor contract is reviewed for retention and training, and the transfer mechanism is recorded. The remaining risk is small and known, instead of large and invisible. For the channel itself, see also how to integrate AI into your company's WhatsApp.
A step-by-step plan to evaluate an AI vendor
The method we use for AI projects fits well here, in four moves: map, limit, pilot and deliver. In privacy terms, they look like this.
- Map: list the flows where AI receives data, which fields go in and who sends them. Include informal use, such as staff pasting text into public tools. A company policy for employee ChatGPT use helps close that gap.
- Limit: remove or mask what is not needed, restrict the fields allowed in the prompt and define what the agent must never receive. Also limit the actions it can take.
- Pilot: run a single real flow, with logs, an agreed success metric and the vendor contract already reviewed. During the pilot, check that what leaves your systems matches what was documented.
- Deliver and decide: at the end of the pilot, hand the operation to whoever will maintain it, with records up to date, and decide whether to expand, adjust or stop. If the risk assessment changed, the transfer mechanism must be reviewed as well.
Before signing, bring direct questions to the vendor:
- In which countries is content processed and stored, including by subprocessors?
- How long is content retained, and can that retention be reduced or turned off?
- Is content sent through the API used to train models?
- Which contractual clauses support the transfer, and how does the vendor help with data subject requests?
- How are incidents communicated, and within what timeframe?
Write down the answers and the date you received them. Vendor documentation changes, and a record of the version you consulted protects the company.
When does a local model or a Brazilian region reduce the complexity?
Not every flow needs a model hosted abroad. There are three ways to reduce or avoid the transfer:
- Use a vendor option that processes and stores content in a region in Brazil, when one exists and when the contract confirms that subprocessors follow the same rule.
- Run a local model, or one on your own infrastructure, for the most sensitive data, accepting the trade-off in quality, maintenance and operating effort. The guide to running Ollama local models in a company shows how to do it without improvising.
- Split the flow: personal data stays in local systems and only text without identifiers goes to the external model.
None of these paths removes the need for a legal basis, records and governance. They only change the size of the problem. To follow how AI regulation is evolving in the country, see the summary of Brazil's AI regulation and what companies should do now.
Frequently asked questions
Do I need customer consent to use an AI API abroad? Not necessarily. Specific consent is one of the grounds in Article 33, but there are others, such as adequate contractual clauses or necessity for contract performance. Consent also has to be specific, prominent and informed about the international nature of the transfer, which is hard to operationalize in customer service. Many companies prefer to rely on another mechanism and another legal basis, validated by counsel.
If the provider says it does not train on my data, is the matter closed? No. Not using content for training reduces one risk, but the transfer still exists if personal data is processed abroad. You still need to assess retention, subprocessors, processing location, the transfer mechanism and records.
Can I send sensitive data, such as health data, to an AI API outside the country? Only if there is a legal basis for sensitive data under Article 11 and a valid transfer mechanism, and the risk is higher. In practice, avoid sending that kind of data or mask it, and look at local alternatives. Always get specific legal analysis before any pilot.
Who in the company should be accountable for this analysis? The data protection officer, together with legal, IT and the team that owns the process. The company remains the controller and answers for these choices, so the decision should not rest only with whoever bought the tool. Recording who approved it, and based on which documents, is part of what makes compliance demonstrable.