Data residency describes where data is stored or processed. Data sovereignty concerns the legal and operational authority over that data, including who can access it and under which rules. An AI service can keep its main database in a chosen country while depending on operators or services elsewhere.
The distinction becomes useful when a procurement question moves from “Where is the server?” to “Who can do what with our information?” Answer both before selecting an architecture.
What does residency tell you?
Residency is a location statement. It can apply to stored documents, processing, backups or other copies, but a statement about one category should not be assumed to cover the rest.
For an AI assistant, list the locations of source documents, document fragments, embeddings, prompts, outputs and logs. Include recovery copies and evaluation datasets. If the provider says “data stays in region,” ask which of these categories the statement covers.
A location requirement can be clear and testable: for example, a contract may specify an approved region for a particular dataset. The implementation then needs configuration and operational evidence showing that normal processing and failure recovery respect that requirement.
Do not confuse a regional user interface with regional processing. The address users visit is not enough to establish where the underlying model or monitoring service handles their requests.
What does sovereignty add?
Sovereignty asks about authority and control. Who operates the service? Who holds administrative privileges? Who controls encryption keys? What legal obligations apply to the parties involved? Can the customer continue operating or move its data if the relationship ends?
These questions do not collapse into a single universal score. A public organisation, a multinational business and a research laboratory may have different requirements. Write those requirements down as specific controls and evidence rather than relying on the word “sovereign.”
For example, customer-held keys can be useful, but the phrase alone does not explain who can access plaintext during processing. Local operations can be useful, but the contract and escalation procedures still need review.
The objective is an accurate description of the control arrangement. It should be possible to explain which controls belong to the customer, which belong to a supplier and which depend on another organisation.
How do residency, privacy and on-premises deployment differ?
| Term | Main question | Evidence to request | Common misunderstanding |
|---|---|---|---|
| Residency | Where does processing or storage occur? | Data-flow map and region configuration | A local database means every copy stays local |
| Sovereignty | Who has authority and practical control? | Contracts, operator model, key and exit arrangements | Local hosting removes every external dependency |
| Privacy | Is personal information handled appropriately? | Purpose, permissions, minimisation and rights processes | Encryption alone resolves privacy obligations |
| On-premises | Is infrastructure located at the organisation's site? | Deployment and operating responsibility records | Owning hardware proves complete control |
| Private AI | How is access to AI and its data restricted? | Isolation, identity and data-use arrangements | A private endpoint establishes sovereignty |
These concepts overlap, but none should be used as shorthand for all the others. A procurement checklist works better when each requirement has an owner and an acceptance criterion.
Why do AI workloads make the distinction harder?
An AI application often combines several services. It may retrieve internal documents locally, send selected passages to a model endpoint and export traces to a separate monitoring platform. The user's question can therefore cross boundaries that the source document did not.
Derived data also matters. An embedding, summary or evaluation record may preserve information about the original material. Do not remove it from the inventory simply because it is no longer the original document format.
Model updates introduce another control question. Who decides when the serving model changes, and can the customer retain or restore a prior version? If a regulated workflow depends on a particular behaviour, an unreviewed update can matter even when no data changes location.
Finally, support access may differ from normal application access. A useful review follows both the ordinary request path and the exceptional path used when the service breaks.
Does the law require everything to stay local?
There is no single answer across jurisdictions, sectors and data categories. A location decision should follow a review of the applicable rules and contracts, including any cross-border arrangements.
For the EU, the EDPB's guidance on international transfers helps frame questions about parties and access. The EU AI Act framework raises additional questions about the system and its use; it is not a substitute name for a universal local-hosting rule.
For India, consult the official DPDP Rules publication, applicable commencement provisions and any sector requirements. A generic claim that all Indian data must remain in India is not an adequate workload assessment.
The practical engineering task is to supply an accurate map of processing, access and retention so legal reviewers can assess the actual arrangement.
How should cloud offerings be compared?
Compare named services and deployment options. AWS, Microsoft Azure and Google Cloud offer different products and configurations; a statement about one service should not be extended to another without evidence.
Ask for the selected service's processing locations, administrative access model, subprocessors, retention terms and recovery behaviour. Then ask what happens when a user enables an additional AI feature or an operator activates a fallback.
A self-hosted model from a family such as Llama or Mistral can change the hosting arrangement, but model selection alone does not establish sovereignty. The serving environment, software supply chain, licence terms and operator responsibilities still matter.
Treat a supplier's sovereignty statement as the beginning of the discussion. Request the control matrix behind it and identify any requirement that depends on a contract amendment or a deployment option not included in the initial proposal.
Where can HyperLake fit?
HyperLake supports modular data and AI components in customer environments, including private and on-premises infrastructure. That can help an organisation choose where workloads run and how its platform connects to existing identity and data systems.
The remaining work is specific to the deployment: define operator access, key ownership, outbound connections, backup locations and responsibilities for updates. Customer control is useful only when the operating model makes it practical.
For an initial project, choose a bounded workload and document its complete path. A well-understood document assistant can establish useful operating patterns before the organisation expands into more demanding workloads.
What should the final decision record contain?
Keep the record short enough that an operator will use it. Include the approved locations, permitted parties, external dependencies, retention rules and the person who can authorise changes.
Attach evidence for the difficult cases: remote support, disaster recovery, model replacement and contract exit. A diagram of normal traffic alone will not answer those questions.
Review the record when the architecture changes. Adding a hosted embedding service or a new telemetry destination may alter the control arrangement even when the headline platform and hosting region remain the same.
Frequently asked questions
Is data sovereignty the same as data residency?
No. Residency concerns location. Sovereignty concerns authority and control, including legal relationships, operator access and dependencies. A complete assessment considers both.
Does on-premises hosting solve every sovereignty requirement?
No. Remote administration, external services, software dependencies and contractual obligations can remain. Inspect the full operating model rather than only the physical location.
Are embeddings part of the review?
Yes. Include embeddings and associated metadata, along with source fragments, prompts, outputs and logs. Assess what information each contains and how it is accessed.
What is the best first question for a provider?
Ask for a complete data-flow and access diagram for the exact service configuration you plan to buy, including support and recovery paths. That makes the discussion concrete.
