Data Sovereignty and AI in Brazil: What Your Company Decides

Data Sovereignty and AI in Brazil: What Your Company Decides

Where your company data goes when you use foreign AI in Brazil, what LGPD requires, and which hosting and contract choices reduce vendor dependence.

•

Want to apply this in your company?

Book a call with Juan →

When a company uses AI from a foreign vendor, the text, files and context sent to the model are usually processed on the vendor's servers, which may be outside Brazil. Under LGPD (Brazil's general data protection law), that is personal data processing and, depending on the case, an international data transfer. In practice, data sovereignty in Brazil does not mean keeping everything inside the country. It means knowing where your data sits, who can access it, for how long and under which contract, and having a real path to switch vendors.

Key takeaways

  • For a company, data sovereignty is verifiable control: processing location, retention, access and exit, not just the address of a server.
  • LGPD does not forbid foreign AI, but it requires purpose, necessity, security and, when data crosses borders, a legal basis that supports the transfer.
  • The biggest risk is usually what the company sends to the model and the records left behind, not the technology itself.
  • Hosting in a Brazilian region, a local model, a well-written contract and minimized data are different levers, and each solves one part of the problem.
  • Dependence is reduced by architecture: your own layer between the business process and the model, so the vendor can be replaced without rebuilding the process.

What does data sovereignty mean for a company?

The public debate on sovereignty tends to focus on the state, infrastructure and large models, and it often gets mixed up with the conversation about superintelligence. For someone running a business, the question is more practical: if the vendor changes a rule, raises its price, goes offline or suffers an incident tomorrow, what happens to our data and our operation?

That question separates three things that are often confused:

  • Location: in which country the data is processed and stored.
  • Control: who can access the data, use it for other purposes, and how long it stays around.
  • Portability: the ability to take prompts, knowledge bases, histories and workflows to another vendor.

A company can keep data on Brazilian soil and still depend entirely on one vendor, with no control over retention. The reverse also happens. That is why the decision is not binary (foreign cloud versus everything local). It is a combination of choices by type of data and type of process.

Where does your data go when you use a foreign AI vendor?

The most common mistake is to think only about the message the user types. In a production AI system, data passes through several places:

  • The prompt and attachments sent to the model, which may include names, phone numbers, documents and conversation history.
  • The vendor's records: some keep logs for a period for security and abuse prevention. Retention periods and conditions vary by contract and plan, and should be read in the vendor's own documentation.
  • The agent's knowledge base, such as indexes and vectors generated from internal documents, stored in a database chosen by the company or the integrator.
  • Connected tools such as CRM, spreadsheets, calendar and order systems, which receive and return data on every call.
  • The customer service channel. On WhatsApp, for example, messages pass through the messaging platform and the API provider's infrastructure before reaching the agent.
  • The company's own logs and monitoring tools, which often store entire conversations in plain text.

Each of these points has an owner, a location and a retention rule. If the company cannot answer that for each point, it does not yet have sovereignty over the process, even if the main server is in Brazil.

There is also the question of using data to train models. This depends on the product and the contract: consumer interfaces and business APIs can follow different rules. The right move is to check the official documentation and the terms of the plan you actually pay for, and to record the result instead of assuming.

What does LGPD require in this scenario?

LGPD is neutral about technology. What it looks at is the processing of personal data. For companies using AI, a few points carry the most weight:

  • Roles: usually the company is the controller and the AI vendor acts as the processor, handling data on its behalf. The contract must make this clear.
  • Purpose and necessity: send the model only what the task requires. An agent that confirms an appointment does not need the customer's full ID document.
  • Legal basis: each processing purpose needs a basis provided by the law, such as contract performance, legitimate interest or consent, chosen carefully and documented.
  • Security: technical and administrative measures proportional to the risk, including access control and incident handling.
  • International transfer: the law provides specific grounds for sending personal data to another country, and the national data protection authority (ANPD) regulates instruments such as standard contractual clauses. Anyone using a vendor that processes data outside Brazil needs to check which ground applies. We cover this in International Data Transfer Under LGPD When Using AI Providers.
  • Accountability: hiring a vendor does not remove the company's responsibility toward the data subject. That is why the contract and due diligence matter.
  • Automated decisions: when AI decides something that affects a person, the right to request review under article 20 applies. See LGPD Automated Decision-Making: The Right to Review (Art. 20).

This is not legal advice, and each case calls for review by whoever is responsible for data protection in the company or by legal counsel. To follow AI-specific regulation as it develops, read Brazil AI Regulation: What Companies Should Watch and Do Now. The ANPD website is the primary source for data protection guidance and regulations.

Which hosting decisions reduce dependence?

There is no single right option for everyone. Use this guide to choose by type of data:

  • Direct vendor API with minimized data: suits low-risk tasks, such as drafting generic text or classifying messages without personal data. It needs a reviewed contract and a clear usage policy.
  • The same model through a cloud that offers a Brazilian region: this reduces the location question, when the provider offers that option for the model you want. Confirm in the official documentation, because not every model is available in every region, and confirm where logs and copies are kept as well.
  • Local model or your own server: keeps data inside the company's infrastructure. In exchange, the company takes on operations, updates, capacity and security. Running Ollama Local Models in a Company: A Practical Guide explains what to consider.
  • Hybrid architecture: sensitive data goes through a local model or an anonymization step, and only content with identifiers removed moves on to a more capable external model.
  • No external AI for certain data: for some categories, such as health data, minors' data or information under professional secrecy, the right decision may be not to send it, or to send it only after a specific analysis.

Whichever option you choose, one architectural decision reduces dependence more than any other: placing your own layer between the business process and the model. Prompts, rules, knowledge base and logs stay under the company's control, and the model becomes a replaceable component. Without that, switching vendors means rebuilding the system. For a deeper look at this idea, see Company Superintelligence Layer Architecture.

What should you review in the AI vendor contract?

A checklist of questions to bring to the contract and technical review:

  • In which countries is data processed and stored, including backups?
  • How long are prompts, responses and attachments retained, and can that retention be reduced or switched off?
  • Can the data you send be used to train or improve models? Does this differ by plan?
  • Who are the subprocessors (other vendors your vendor relies on), and how is the company notified of changes?
  • How does the vendor notify security incidents, and within what contractual deadline?
  • Which instruments support the international transfer, such as the standard clauses provided in ANPD regulation?
  • How does the company request data deletion at the end of the contract, and is there written confirmation?
  • Is there a way to export histories, settings and knowledge bases in an open format?
  • Which security certifications or reports does the vendor make available for audit?

Keep the answers together with the version of the terms you consulted. Terms change, and the company needs to know on what basis it decided.

On the technical side, the risk of sensitive information leaking through AI systems is cataloged in resources such as the OWASP Top 10 for LLM applications, which is useful as a checklist for whoever builds the agent.

Illustrative scenario: customer service at an aesthetics clinic

Imagine an aesthetics clinic that wants a WhatsApp agent to answer questions and organize appointments. This is an illustrative scenario, not a real case.

In the first design, the agent would send the entire conversation to the model, including full name, photos and any health notes the client mentioned. When mapping the flow, the clinic notices three things: health data is not needed to book an appointment, photos do not need to leave the internal system, and the platform's logs store everything in open text.

The revised design limits the agent's scope: it handles only time slot, procedure and first name. Messages that mention a health condition or include an image are routed to a team member, without passing through the external model. Logs mask phone numbers and documents, and the retention period is defined in writing. The vendor contract is reviewed before the pilot, and the clinic keeps its texts and rules in its own repository, so changing the model does not force a rebuild of the service flow.

How we apply the method: map, limit, pilot, hand over

The method we use in AI projects applies directly to this topic, with no promise of results:

  • Map: document the current process, the data that moves through each step, the systems involved and where each piece of information is stored. Without this map, any discussion about sovereignty stays abstract.
  • Limit: define which data the agent can receive, which actions it can perform and what always goes to a person. This is also where you decide hosting by type of data and choose the model.
  • Pilot: run a real flow, with logs and a success metric agreed in advance, to check that the limits work and that the contract and configuration behave as the documentation says.
  • Hand over: give the team the documentation, access, decision records and review plan, then decide whether to expand, adjust or stop. The goal is for the company to operate and switch vendors without depending on whoever implemented the system.

For internal rules, combine this with a Company Policy for Employee ChatGPT Use, because a good share of data leakage happens outside the official agent, when someone pastes customer data into a personal tool. As a risk management reference, the NIST AI Risk Management Framework offers a recognized structure for governing AI systems.

Frequently asked questions

Is using ChatGPT or another foreign AI illegal under LGPD? Not in itself. LGPD requires the company to have a purpose, a legal basis, security and, when there is an international transfer, a ground provided by law. Problems usually come from sending personal data without assessment, without a proper contract and without an internal rule.

Does hosting AI in Brazil solve the data sovereignty question? It solves part of it, the location part, when the vendor really processes and stores data in a Brazilian region. You still need to check retention, subprocessors, use for training and portability. Sovereignty depends on control over the whole process, not only the server address.

Is a local model always safer than a cloud service? Not necessarily. It keeps data inside the company's infrastructure, but the company becomes responsible for updates, access control, capacity and monitoring. For teams without an operations routine, a well-contracted and well-configured service can be safer than a poorly maintained server.

Where should a company start if it already uses AI without this analysis? Start by mapping which AI tools are in use, by whom and with what data. Then classify the data by sensitivity, review the terms of the vendors already in use and define a simple rule for what can and cannot be sent. With that map in hand, hosting and contract decisions become much more objective.

Sources

data sovereigntyLGPDAI in Brazildata privacyvendor lock-in