Data sovereignty:
what it is and where company data should live

Data sovereignty combines jurisdiction and control

Data sovereignty is the condition in which data is subject to the applicable laws and to the decisions of those with legitimate authority over it. It has two layers:

• Jurisdiction: the country where the data is stored and processed and the law that applies to it, including foreign laws that reach the vendor.
• Control: who decides about the data, who processes it, who may use it for other purposes and who is able to withdraw or delete it.

The second layer usually weighs more in AI projects, because data stored in Brazil may sit under terms that allow retention, review by third parties or model training.

Residency and localisation describe where the data is

Data residency is the requirement, whether legal, contractual or internal, that data be stored in a defined geographic region.

Data localisation is the stricter version: data must be stored and processed inside the country, usually by legal mandate.

Data sovereignty covers both and adds control. A company can meet residency with its data in a local data centre and still depend on a vendor that decides on the retention, access and use of that data.

Generative AI multiplied the routes by which data leaves

Models and agents open new routes:

• Sending to the model: every question carries excerpts of contracts, customer records or code to the service that processes the call.
• Retention and training: depending on the terms and the plan, content may be stored, reviewed by the vendor's staff or used to improve models.
• Conversations and memory: the interaction history and agent memory sit on the tool's infrastructure, often in another jurisdiction.
• Vendor dependence: prompts, indexes and integrations built inside a platform become tied to it.

Each route comes from a design decision, such as turning on memory or indexing a folder. That is why data sovereignty belongs in the design of the architecture.

The data a company has accumulated is a competitive advantage

Customer history, commercial rules, prices and approved exceptions describe how that company sells and decides. Competitors cannot buy this knowledge.

Organised inside a third party's tool, that asset ends up living in an environment the company does not govern. Data sovereignty protects this knowledge in two ways: the data stays out of another company's product, and the company can take it along when it changes vendors.

Loss of data sovereignty shows up as four risks

• Loss of control: the company does not know how many copies exist and cannot confirm deletion.
• International transfer: Brazil's data protection law (LGPD) allows the international transfer of personal data only in defined cases, such as a country with adequate protection or standard contractual clauses approved by the ANPD, the national data protection authority.
• Exposure to third parties: an incident at the vendor, or an order from a foreign authority addressed to it, reaches the company's data.
• Lock-in: a change in price or terms forces the company to rebuild integrations.

In the European Union, the Data Act, in application since 12 September 2025, created rules for customers to switch data processing providers, treating portability as part of control.

Three architectures balance cost, capability and control

Where the model runs determines much of data sovereignty:

• Cloud with an enterprise contract: the highest capability and pay-per-use cost. Sovereignty depends on contract and configuration: region, minimal retention and a ban on training.
• Own cloud: the model runs on infrastructure the company contracts, and operations come to depend on the team.
• Local model: processing happens on the company's servers, with hardware costs and, usually, lower-capability models.

Many companies combine the options and choose the architecture by type of data.

The Company Brain keeps context in the customer's environment

The Company Brain connects CRM, ERP, helpdesk, contracts and documents once and organises that data into a knowledge graph, a business ontology and a semantic layer. The data stays in the customer's systems and environment, with no copy of the data stores sent to the model provider.

For each question, the model receives over MCP, the open protocol that connects models to data sources, only the slice it needs, filtered by the permission inherited from the source. What leaves the environment depends on the chosen architecture: with an external service, the slice for that call leaves, under the contracted terms; with an own cloud or a local model, the slice also stays with the company.

The organised context, with entities, relationships and rules, belongs to the company. Because the model consumes it through an open protocol, switching models does not require rebuilding integrations, and every answer points to the source of each piece of information.

Data sovereignty depends on contract, configuration and governance

Architecture alone does not settle the question. A contract that allows training cancels out the care taken with the slice, and a misconfigured region sends processing to another country. Assessing terms and recording transfers is still the work of legal, security and the data protection officer. Restricting sensitive material to local models can also lower quality on complex tasks.

The first step is to map where each AI flow sends data today

For each AI use in operation, the map records which data goes in, to which service, in which country it is processed, under which retention and training terms, and what it would take to switch vendors.

Flows with personal data or trade secrets and no exit plan are the first candidates for change. For them, connecting the sources to the Company Brain and choosing the model by type of data puts the decision about where context lives in the company's hands.