Every country you operate in writes its own rules, and none of them consult your architecture first. Buyers running across multiple geographies described the same shape repeatedly, with Germany, Denmark, England and Norway each holding a different line. The question arrives already narrowed: can we offer something acceptable to each country’s rules that will not go against their regulations?
Data Residency & Sovereign AI
How Do You Meet Data Residency and
Sovereignty Requirements for AI?
Put the compute inside the border and residency answers itself. What placement alone cannot settle, and the per-country checklist a multinational fills in once.
Built from real buyer questions in our sales meetings
Direct Answer
Put the compute inside the border. Residency is satisfied when the compute that touches the data sits physically inside the jurisdiction governing it. A device-local or in-country on-premises deployment achieves that by construction; a multi-region cloud service achieves it contractually, and only where the region you pick carries every service your design needs. For a multinational, the practical shape is one governed corpus per jurisdiction rather than one global tenant.
The limit: placement is not sovereignty. Sovereignty is a compliance statement about ownership of data and alignment with the laws that govern it. Iternal states the limit plainly rather than softening it: the product secures and protects data and does nothing to help control ownership of that data, so it does not by itself deliver sovereignty. Placement answers where the compute runs. Who owns the data, where a device travels once it leaves the country, where backup copies land and how remote support reaches in all close by contract, never by construction.
Get four things in writing before a regional rollout. Which region carries every service in the design. Which country the engineers who administer and support the system sit in. Where backups, recovery copies and logs land, and under whose law. What changes if your national rules govern encryption keys. Iternal answers the targeted questions below, and names its own footprint: business concentrated in the United States, an expanding European presence run from Spain, and Asia-Pacific coverage it is establishing now.
The phrase carries two altitudes. An enterprise can be sovereign over its own material; national AI sovereignty spans a country’s compute infrastructure, data, models and ecosystem. Settle which one your requirement means before anyone draws a diagram. For more information visit the security review page or the regulated data classes page.
Treat Sovereign AI as a Placement Requirement
What is sovereign AI?
Sovereign AI is artificial intelligence an organization or a country runs under its own law and control: the models, the data and the compute stay where that authority reaches rather than inside a public cloud governed by someone else. In buyer terms it means a private instance, running at the client, on hardware the organization owns.
“Sovereign AI” and “data sovereignty” sit near the top of the vocabulary buyers carry into our meetings, ahead of most product language. The working definition in those rooms is narrow: non-public, non-hyperscale cloud AI, running at the client, offline, on device, as a private instance the organization controls inside its own walls.
The durable argument is continuity. One buyer put it in a line: one provider cutting you off removes an entire agent workforce at once. Iternal builds on the same premise, in-sourcing the intelligence and running open-weight models the customer owns — ownership that survives a decision made in another country.
Sovereign AI, Data Residency and Data Localization Settle Different Questions
Three terms arrive in the same sentence and get handled as one requirement. They are not interchangeable, and a design that satisfies one can still fail the other two. Separate them before the architecture review: each is closed by a different instrument — one by geography, one by classification, one by ownership and contract.
| Term | The question it answers | What actually satisfies it |
|---|---|---|
| Sovereign AI | Who holds authority over the models, the corpus and the infrastructure, and under whose law? | Ownership you can evidence: open weights you run yourself, a corpus your own people administer, and contracts naming every party who can reach in. |
| Data residency | Where does the compute that touches the material physically sit? | A device or an in-country server inside the jurisdiction, by construction; an in-region service where the contract and the service catalog both hold. |
| Data localization | Which classes of material are required to stay inside the border, and which may leave? | A classification decision carried as tags on the corpus, so one pipeline can serve several rule sets without moving everything. |
An organization can hold every byte inside the border and still not be sovereign over it, and the reverse happens just as often: material a company owns outright can sit in a region a later national rule puts out of bounds. Price that exposure before the rollout with the Data Sovereignty Compliance Calculator. For more information visit the private AI page or the page on what air-gapping means.
National Sovereign AI and Enterprise Sovereign AI Are Different Programs
Most published writing on the term describes the national altitude. NVIDIA frames sovereign AI as a nation’s capability to produce artificial intelligence using its own infrastructure, data, workforce and business networks, and the McKinsey explainer of the term describes the same national capacity to build and govern AI with domestic data, compute and talent. Read that way, sovereign AI is industrial policy: national compute, models trained on the country’s own language and records, and a domestic talent base.
The enterprise altitude is the one most buyers mean. An organization asserting the same control over its own material: models it owns, a corpus it administers, inference on hardware inside its own walls, and no dependency another government can switch off. Both altitudes answer the same test — can you keep operating when someone else changes their mind — and they differ entirely in what they cost and who signs for them.
- A national program builds domestic compute capacity, language coverage and the skills to run both. It is set by policy and funded at that level; an enterprise buys from what it produces rather than standing it up.
- An enterprise program buys ownership of what the business already depends on: open-weight models running on its own machines, a governed corpus per jurisdiction, and support arrangements that name every country able to reach the system. For more information visit the AirgapAI page.
- A public-sector program sits between the two, inheriting national policy while procuring like an enterprise, with an authorization regime deciding what may run where. For more information visit the FedRAMP AI page or the public sector AI page.
Settle which altitude a requirement means before anyone draws a diagram. A requirement written at the national altitude and answered at the enterprise one produces a system that satisfies the security team and still misses the rule it was bought for.
One Governed Corpus Per Jurisdiction, or One Global Tenant
Two architectures answer a residency requirement, and they fail in different places. Where the index and the weights sit decides it: an index carries the content it was built from, and an endpoint you do not host is one someone else can move.
| Layer | One corpus per jurisdiction | One global multi-region tenant |
|---|---|---|
| Documents and index | Ingested in-country. Blockify turns them into a JSON data set that stays with its corpus, tagged by regulation and jurisdiction. | Replicated into the tenant region; one index over material governed by several regimes. |
| Model weights | Open weights on the device or in-country server; the customer owns what it runs. | Held by the provider. You consume an endpoint and inherit its location. |
| Inference | On the device or in-country server. Nothing crosses a border to answer. | In the provider region, and only where that region carries the service. |
| Residency rests on | Construction. No data plane for a border to sit across. | Contract and region choice, honored by the provider. |
| A new national rule | Add a corpus and its governance tags. | A separate deployment with its own routing, as a dedicated EU deployment would be built if rules demanded it. |
Governance rides on the corpus: separating material by regulation and jurisdiction through tags and metadata is how Blockify governs a data set, and content owners administer their own jurisdiction with an audit trail behind them.
The Regional Blockers Buyers Raise First
A rollout rarely stalls on the technology. It stalls on three things outside the product, and buyers named all three repeatedly:
- Rules still in motion. Buyers describe European requirements as too ill-defined to design against today. The European Union now requires an organization to hold sufficient AI literacy before rolling a technology out, European rules require telling a user when they are talking to a bot, and European bids can demand proof of European headquarters. Elsewhere the inverse holds: Latin America has no local residency rule, so material can sit in the United States for less.
- Language, which the model decides. Coverage follows the underlying model rather than the application — Qwen suits Asia-Pacific, Mistral suits Europe, Llama covers English. Buyers flag the human half too: customer technical staff may not speak English and may not follow the discussion. For more information visit the languages and voice page.
- Politics, which moves fastest. A model provider barred by a government becomes unusable overnight, whatever accreditation it holds — buyers described exactly that, including a provider whose dispute with a government took it off the table for scoped work. Geopolitics is locking United States headquartered suppliers out of some European sovereign programs, and a design resting on one outside endpoint inherits that risk in full.
Coverage is the part to settle before you sign. Iternal is candid about its footprint: most of the business sits in the United States, the European presence is expanding under a lead infrastructure engineer based in Spain who travels for in-person work, and Asia-Pacific is a region Iternal is entering now. Phone and chat support across all three runs through a global systems integrator, which decouples day-to-day support from any one time zone.
Pin it down: questions for your evaluation
-
Which region carries every service in our design, and which parts are unavailable there?Whether a residency commitment survives the service catalog in your region.
-
Who provides first, second and third line support, and in which country do those engineers sit?Whether remote hands reach across a border your material was promised never to cross.
-
If our national rules govern where encryption keys are held, what changes in the product?A question Iternal has flagged as open for Asian markets, so get the answer early.
-
Where do backups, recovery copies and logs land, and under whose law?The copies that outlive a residency design built only around the primary system.
Residency by Construction: When There Is No Data Plane at All
The cleanest answer to a residency question is the deployment that never raises it. On an AI PC running AirgapAI, the documents, the Blockify JSON data set and the model all sit on the machine, and inference runs on its own silicon. No data leaves the AI PC, so the question collapses into where the hardware physically is. Because processing happens offline, content a cloud assistant is barred from touching can be worked on locally.
One edge still needs policing: the device travels. A laptop that flies to another country carries its corpus across the border, and no software setting stops it. Decide which corpora may be loaded onto machines that leave the jurisdiction, and who approves it.
Where a workload outgrows a device, buy the region deliberately. In one Latin American engagement the São Paulo region was identified as meeting Brazilian residency requirements, at roughly twice the cost of the same workload in Virginia — while no law forced the move. Pay for residency where a rule requires it, and price the alternative where preference is doing the talking. For more information visit the placement decision.
The Per-Country Checklist You Fill In Once
A multinational answers the same seven questions in every market, and a fixed order turns a legal debate into a design decision. Fill the template in once per country and re-use it as each new jurisdiction arrives.
| What to record | Why it decides the design |
|---|---|
| Law, contract or preference? | A statute forces in-country compute. A preference is often met by an in-region service for less. |
| Which data classes it covers | Tags and metadata separate material by regulation, so one pipeline serves several rule sets. |
| Where compute may sit | Device, in-country server, in-region cloud. Only the first two are residency by construction. |
| Where index and weights may sit | An index that leaves the country takes the content with it. Local open weights survive a provider being barred. |
| Who supports remotely, from where | Low-cost delivery models put staff in one region touching another’s material. Name the countries in the contract. |
| Where backups and logs land | The copies are what a residency design misses and an auditor finds. |
| Language of users and support | Model choice drives language coverage, and staff who do not work in English need delivery in their own. |
Certification rarely appears on that list. General data-protection regimes are handled the way health-information rules are: the obligation lands on the organization running the system.
Answered elsewhere
- Which US classification regimes permit a deployment at all — see the regulated data classes page.
- The certificates and evidence a security team asks for — see the security review page.
- For more information on what happens to what a user types — see the data-retention page.
- How statutes, rulings and records duties apply to AI output — see the records and regulation page.
- What keeps working with the network gone — see the disconnected operation page.
- Restricting a corpus by role, with sign-in and audit logging — see the access control page.
FAQ
FAQ: Data Residency and Sovereign AI
In buyer conversations it means non-public, non-hyperscale cloud AI: intelligence running at the client, offline, on device, as a private instance the organization owns and controls inside its own walls. Sovereignty itself is the broader compliance statement about ownership of data and alignment with the laws governing it.
No. Residency is a question of geography — where the compute that touches the material physically sits — and it is settled by putting a device or an in-country server inside the jurisdiction. Sovereignty is a question of authority: who owns the models and the corpus, and whose law governs them. A deployment can satisfy residency and leave sovereignty open.
They are different programs. NVIDIA and the McKinsey explainer both describe the term at the national altitude: a country’s own compute capacity, models trained on its own language and records, and the skills to run both. An enterprise program is narrower — models it owns, a governed corpus per jurisdiction, and inference on hardware inside its own walls. Settle which altitude a requirement means before designing to it.
One governed corpus per jurisdiction handles it better than one global tenant. Keep the documents, the data set built from them and the model inside the country that governs them, with tags and metadata separating material by regulation and jurisdiction. A new national rule then adds a corpus instead of forcing a migration.
They shape it more than they block it. Buyers describe European requirements as still moving and too ill-defined to design against today, and European bids can demand proof of European headquarters. Running the compute inside the country takes residency off that list.
No. Latin America has no rule requiring local residency, so material can sit in the United States, where it costs less. Where a customer prefers in-country hosting the region exists: São Paulo was identified as meeting Brazilian requirements in one engagement, at roughly twice the Virginia cost.
Anything built on that provider stops, whatever accreditation it held. Buyers described exactly that, including a provider whose dispute with a government put it out of reach for work already scoped around it. Open-weight models on hardware you own are the hedge: weights you already run cannot be withdrawn.
It settles residency and leaves sovereignty partly open. With AirgapAI on an AI PC no data leaves the device. Iternal states the limit plainly: the product secures and protects data and does nothing to help control ownership of that data, so it does not by itself deliver sovereignty.
Put the Compute Inside the Border
Geography is the one part of a residency requirement you settle with a decision rather than a negotiation. Run the compute inside the jurisdiction, keep the corpus and the weights with it, and what remains is a short list you close in writing: ownership, traveling devices, backups, remote hands. Fill in the checklist for your largest market first, and the second market takes an afternoon.