A year ago the main question about enterprise AI was whether it worked. Now, for many organisations, the first question is where it runs. Which country holds the data? Which provider processes the prompts? Who can be compelled to hand anything over?
Sovereign AI is a broad label for these concerns. In practice it comes down to a set of concrete decisions about location, control and dependency — and they shape the architecture far more than model choice does.
What residency actually covers
Data residency is not one question. For an AI system, data moves through many places:
- Source systems and the data platform
- Embeddings and vector indexes built from documents
- Prompts and context sent to a model
- Model outputs and agent tool calls
- Logs, traces and evaluation datasets
- Backups and disaster recovery copies
Each of these can end up in a different region if nobody plans it. A system that keeps its database in-country but sends prompts to a model endpoint elsewhere has not solved residency.
Know the rules that apply to you
Requirements vary by country, sector and contract. Data protection law, sector regulators, public sector procurement rules and customer agreements can all set limits on where data may be processed and by whom.
Engineering should not guess at these. Legal and compliance teams interpret obligations; architecture turns them into enforceable constraints. Discovery should produce a short, explicit list: which data classes, which permitted regions, which providers, which exceptions need approval.
Deployment options for models
There is a spectrum, and most organisations use more than one point on it:
- Hosted model APIs in a chosen region — fastest to adopt; depends on the provider’s regional availability and data handling terms
- Models in your own cloud tenancy — managed services or self-hosted open-weight models inside your account and region
- On-premise or private data centre — full control of hardware and network, with the operating burden that comes with it
- Air-gapped environments — for the most sensitive workloads, with no external connectivity
The right choice depends on data sensitivity and use case, not on a single company-wide rule. A public-facing FAQ assistant and a system reading health records rarely need the same answer.
Design for portability
Sovereignty is also about dependency. If a provider changes terms, exits a region or becomes unavailable, can you move?
Practical steps:
- Put a thin abstraction between application code and model providers
- Keep prompts, evaluation suites and retrieval pipelines in your own repositories
- Test at least one alternative model against your evaluation set
- Avoid features that only exist on one provider unless the value is clear
Portability is not free, but discovering you have none during an incident is worse.
Controls that make residency real
Policy documents do not stop data leaving a region. Controls do:
- Network egress rules that only allow approved endpoints
- Region pinning on storage, compute and model endpoints
- Customer-managed encryption keys where appropriate
- Classification tags that routing logic actually checks
- Logs that record which model and region handled each request
These are controls designed to support your residency obligations. They also give audit something to verify rather than a statement to accept.
Open questions stay visible
Some details depend on provider documentation, subprocessors or contract terms that change over time. List them, assign an owner and review them when providers or regions change. A residency position that was correct at launch can drift without anyone noticing.
Where to start
- Map every place data goes in the planned AI system, including logs and indexes
- Get a written list of residency and processing constraints from legal and compliance
- Choose a deployment option per use case, not one for everything
- Build provider abstraction and an evaluation suite you own
- Enforce region and egress rules in infrastructure, then test them
Incubics designs AI systems with residency and deployment constraints agreed in discovery and enforced in the build.