There is a common misunderstanding about "data sovereignty." Many people imagine it boils down to a question on a map: which country is the machine in? In practice, for data governance and for the LGPD (Brazil's General Data Protection Law, No. 13,709/2018), the question that matters far more is a different one: who controls the flow of your data? Who decides what is logged, what enters and leaves the model, how long everything is kept, and who the data is sent to. The GPU's map coordinate is a secondary detail next to that.
โ๏ธ Disclaimer
This content is informational and does not constitute legal advice. Every data-processing operation has its own specifics. Consult your data protection officer (DPO) or a qualified attorney before making compliance decisions.
Sovereignty is governance, not location
When you process personal data, the LGPD expects you to be able to answer clearly: why you process it, on what lawful basis, which data you use, who has access, and what happens to it afterward. None of those questions is answered by the server's coordinate. They are answered by how much control you have over the stack that processes the data.
So it is worth separating two concepts that are often conflated:
- Control and governance of the data flow โ you decide what you log, what you retain, what is sent to third parties, and how you demonstrate all of it. This is the heart of LGPD compliance.
- Geographic residency โ the specific requirement that the data physically reside in a given territory. It is legitimate in some contexts, but it is a separate requirement that not every operation has.
Conflating the two leads to poor decisions: companies that "host in-country" but keep dumping sensitive data into closed third-party APIs โ with no control over retention or training โ and believe they are compliant purely because of geography. They are trading the real problem (control) for a metric that does not solve it.
The real risk: sending sensitive data to a third-party API
Every time you paste a contract, a medical record, a customer spreadsheet, or a chunk of proprietary code into the chat or API of a closed provider, you are handing that content to a stack you do not control. And then come the questions you can rarely answer:
| Risk | What it means |
|---|---|
| Opaque retention | You don't always know whether prompts are stored, for how long, or whether they become training data for the model. |
| Logs out of your reach | The records of who sent what live with the vendor, not with you โ which makes audits and incident response harder. |
| Generic processing agreement | Standardized terms of use don't always reflect what the LGPD expects from a controller-to-operator contract. |
| Data-subject rights are hard | Fulfilling access, correction, or deletion requests becomes a black box when processing belongs to a third party. |
Notice that none of these risks is about where the server sits. Every one of them is about control. A provider can be in the same city as you and still retain your prompts to train models โ and an open model you control solves the problem even when it runs somewhere else.
What the LGPD actually requires
The LGPD does not ban artificial intelligence. It imposes duties on how personal data is processed. The pillars that show up most when AI is involved:
- Lawful basis (Articles 7 and 11): every processing activity needs a legal ground โ consent, contract performance, legitimate interest, legal obligation, and so on. Feeding customer data into a model with no defined basis is a problem, regardless of where it runs.
- Purpose and minimization (Article 6): you should process only the data that's necessary, for the stated purpose. Sending an entire document when an excerpt would do already breaks minimization.
- Security (Article 46): technical and administrative measures that protect the data. Controlling your own stack makes it easier to implement encryption, access control, and isolation.
- Processing agreement: when an operator processes data on your behalf, the relationship has to be documented and adequate. The more you control, the simpler it is to demonstrate.
- Data-subject rights (Article 18): access, correction, anonymization, and deletion. You can only guarantee these rights if you know where the data is and who touches it.
All of these duties share one thing: they are easier to meet when you control the stack โ the logs, the retention, the access, and the model version in production. Data governance, under the LGPD, is essentially accountability: being able to show what you do with the data and why.
The answer: an open model on a dedicated instance that's only yours
The alternative that gives control back is running open models (DeepSeek, Qwen 3, Llama 4, Mistral) on a dedicated single-tenant instance that is exclusively yours. With that:
- You control what enters and leaves the model. The data stays on your dedicated instance, without passing through a third-party API that could retain it or train on it.
- You define logging and retention. What gets recorded, for how long, and who has access is your call โ which makes audits and data-subject requests easier.
- You pin the weights version. The production model doesn't change or vanish because a vendor decided to discontinue it; the weights are open and versioned by you.
- Compliance becomes demonstrable. With control over the stack, it's simpler to document lawful basis, purpose, and security measures in your processing records and impact assessment.
๐ Control โ territory: let's be honest
Controlling your data flow is not the same as geographic residency in Brazil. Our GPUs are offshore; if your specific requirement is that the data physically reside in the country, that is a separate requirement that must be assessed on its own. We do have CPU instances in Sรฃo Paulo โ those are in Brazil โ but the GPU instances are not. We'd rather say this plainly than sell a geographic promise that doesn't hold up.
๐ก Recommended architecture
For sensitive data, prefer processing on a self-hosted open model, on an instance that's only yours, where you control logs and retention. Reserve third-party APIs for tasks with no personal data, or with already-anonymized data. Document the decision in your data protection impact assessment and in your contract with the operator.
How to do it on GPUBrazil
In the Console, launch the vLLM template on an on-demand dedicated GPU, and you get an OpenAI-compatible endpoint running 100% on your dedicated instance โ with no prompt sent to any third-party API. We're a Brazilian company: billing is hourly, in reais, via Pix, with no FX or IOF surprises, and support is in Portuguese. No capex and no contract. The RTX A4000 starts from R$1.80/h; for other GPU models, see live pricing in the console.
# Self-hosted endpoint โ data stays on your dedicated instance
from openai import OpenAI
client = OpenAI(
base_url="https://your-instance.gpubrazil.com/v1",
api_key="your-local-key",
)
resp = client.chat.completions.create(
model="Qwen/Qwen3-235B-A22B",
messages=[{"role": "user", "content": "Summarize this record in anonymized form."}],
)
print(resp.choices[0].message.content)
Take control of your data with AI
Spin up an open-source LLM on a dedicated GPU that's only yours, where you control the logs, retention, and what enters and leaves the model.
Get Started Free โFrequently asked questions
Is data sovereignty in AI the same as data being physically in Brazil?
No. Data sovereignty, in the sense of governance and the LGPD, is control over your data flow: who processes it, for what purpose, what is logged and retained, and who the data is sent to. Geographic residency within a national territory is a separate, specific requirement. If your case requires the data to physically stay in the country, that has to be treated as its own requirement. This is not legal advice โ consult your DPO or attorney.
Does the LGPD allow sending personal data to a third-party AI API?
It can, provided there is a lawful basis, a defined purpose, and an adequate processing agreement with the operator. The catch is that with a closed third-party API you do not control retention, logs, or whether the content can be used to train models. Running an open model on a dedicated single-tenant instance gives that control back to you and makes it simpler to demonstrate compliance.
How does a dedicated instance help with LGPD compliance?
On a dedicated single-tenant instance you decide what is logged, which data enters and leaves the model, and which version of the weights runs โ without sending prompts to a third party that could retain them or train on them. That control makes it easier to meet LGPD principles like purpose, minimization, security, and data-subject rights, and keeps processing auditable and documentable.
Conclusion
The LGPD doesn't ask you to abandon AI โ it asks you to be deliberate about how data is processed and able to demonstrate that care. The decisive point is not the machine's coordinate; it's how much control you have over the flow: logs, retention, access, model version, and above all not depending on a third-party API you don't control. Data sovereignty, in practice, is control and accountability. If, on top of that, your case requires national territory, treat that as its own requirement โ with honesty about where each piece of the infrastructure actually sits.
Read next: The sovereignty lesson from the Claude Fable 5 case ยท Plan B when an AI model vanishes ยท How much it costs to run AI in Brazil in 2026