Data residency and localisation
AI that stays inside the jurisdiction your data belongs to
- Deployed where you nominate
- Inference in the same place as storage
- NDA before we see any data
- Your dataImages, video, documents
- Custom modelWeights you own
- Your apps and usersAPI, role-based access
Your access controls, change management and security policies apply.
- Under NDA
- No training on your data without permission
Where the boundary gets crossed
Storage is rarely the stage that breaks the rule
Teams localise the database and consider the matter closed. An AI pipeline has several other stages that can quietly send data somewhere else, and each one needs checking against the same requirement.
Running open-weight models on infrastructure you control removes most of these crossings at once, which is the practical case for sovereign AI rather than a hosted API.
Stages worth auditing
- EmbeddingTurning documents into vectors is processing. A hosted embedding API moves every document you index.
- InferenceThe prompt usually contains the sensitive part. A hosted model endpoint moves it on every single request.
- OCR and pre-processingScanned documents sent to an external OCR service have already left before the model sees them.
- Logs and telemetryPrompt and response logging shipped to a monitoring service carries the content with it.
- Model updatesPipelines that fetch weights or call a licence server at runtime create an outbound path that air-gapped environments cannot allow.
By region
What tends to drive the requirement
Described in general terms, as orientation for an architecture conversation. Rules change, and how they apply depends on your sector and your data.
Gulf states
Saudi Arabia's National Data Management Office set out localisation requirements in 2024 for government and critical-sector data, which must be stored and processed inside the country. National AI programmes across the region are building domestic compute and Arabic-capable models on the same reasoning.Common pattern: in-country processing for public-sector and critical dataEuropean Union
GDPR governs where and how personal data may be processed and transferred. The EU AI Act adds obligations for systems classed as high-risk, with that tier's requirements applying from 2 August 2026. Public funding and certification frameworks are pushing enterprises toward sovereign infrastructure options.Common pattern: EU-region processing with documented transfer basisSoutheast Asia
Vietnam's Law on Artificial Intelligence took effect on 1 March 2026, covering risk classification, transparency and oversight, and requiring foreign providers to appoint a local legal representative. Indonesia's Personal Data Protection Law governs cross-border transfer, and Malaysia has funded a national sovereign AI cloud.Common pattern: in-country hosting for named data categoriesAfrica
South Africa's POPIA restricts transferring personal information abroad unless the recipient offers substantially similar protection, and the National Data and Cloud Policy requires data touching national security to be held on infrastructure inside the country. A national AI policy is still being consulted on.Common pattern: local processing, transfer justified case by caseIndia
The Digital Personal Data Protection Act sets the framework for personal data handling and cross-border transfer, alongside a national AI mission funding domestic compute and models. Sector regulators add their own requirements on top, particularly in financial services.Common pattern: sector rules layered over the national frameworkContractual constraints
Not every limit comes from a regulator. Client agreements, NDAs and sector codes frequently prohibit sending data to third-party services regardless of jurisdiction, and in practice these bind teams just as tightly as legislation does.Common pattern: no third-party processing, whatever the location
This page is not legal advice. We are AI engineers, and what is written here is a starting point for a technical conversation. Your counsel establishes what the requirement is; we design and build a system that meets it.
Architecture options
Four ways to keep a pipeline inside a boundary
Which one fits depends on whether your constraint is about location, about operational control, or about third-party processing at all.
Air-gapped on-premises
Every stage on servers inside your facility, with no outbound route. The strongest answer when the rule concerns foreign legal reach or a contract forbids third-party processing entirely.In-country cloud region
Your own account in a specific region, with models served from private endpoints inside it. Usually the simplest route when the requirement is genuinely about location.Split training and inference
Burst GPU capacity for training where it is available, with inference and storage kept inside the boundary. Useful when local compute is scarce but the live data is restricted.Edge processing
Video and sensor data processed on devices at the site, so only results travel. Often the cleanest answer for camera workloads, and it cuts bandwidth as well.
Where we have delivered
Seven countries, five continents
Our published case studies cover clients across four regulatory regimes, and we build to whichever environment a project requires.
- A clinical decision support system for a medical clinic in Riyadh
- Identity verification for a client in Cyprus, inside the EU
- Three projects in South Africa, including open-source vision infrastructure
- Clients in the United States, the United Kingdom, Australia and New Zealand
Our engineering team works from Lahore, one to two hours from the Gulf working day, with an office in Austin, Texas. How we handle client data is set out on our security and IP page.
How an engagement starts
- Constraints firstBefore any architecture
We establish what your counsel and contracts actually require, and which stages of the pipeline each requirement touches.
NDA on request
- Architecture to match3–5 business days
We map each stage to an environment that satisfies the constraint, and size the hardware that implies before you commit to anything.
A written architecture you can review
Guides from our engineers
Go deeper on private AI
Choosing a model, sizing the hardware, and what each deployment option actually protects against.
- Which Open-Weight LLM Should You Self-Host?Technical
- What GPUs Do You Need to Self-Host an LLM?Hardware
- RAG or Fine-Tuning? The Wrong Answer Is ExpensiveDeep dive
- What Does It Cost to Run Your Own LLM?Cost
- Air-Gapped, Private Cloud or Sovereign Cloud: Which Do You Need?Architecture
- Deploy an Open-Weight LLM on Your Own Server with vLLMTutorial
- Self-Hosted Coding Assistants: What Works Air-GappedGuide
- Data Residency Rules That Shape AI Projects in 2026Regulation
- On-Premises vs Cloud Computer Vision Deployments – An Enterprise GuideDeep dive
FAQ
Questions on residency and sovereignty
No, and conflating them causes real architectural mistakes. Residency is where data physically sits and is processed. Sovereignty is about which jurisdiction's laws and authorities reach it, and who controls the keys, the model and the operations. Data held in an in-country region of a foreign-owned cloud satisfies residency, but whether it satisfies a sovereignty requirement depends on the rule you are trying to meet.
Often it is enough, and it is usually the simplest route. It stops being enough when the rule concerns operational control or foreign legal reach rather than location, or when a client contract prohibits third-party processing outright. Those cases point toward on-premises or air-gapped deployment. Which applies is a question to settle before the architecture is designed, not after.
That depends on the rule, and it is the part teams most often miss. A pipeline that keeps documents in-country while sending them to an embedding or inference API elsewhere is still moving the data. Running open-weight models on infrastructure you control keeps inference in the same jurisdiction as storage, which is usually what the rule is actually asking for.
We deploy into the environment you nominate: your own servers, your cloud account in a specific region, a national or sector cloud you already use, or an air-gapped network. The deployment target is your decision and we build to it. Where you are choosing between options, we can set out the technical trade-offs.
No. We are AI engineers, not lawyers, and this page is orientation for an architecture conversation rather than legal advice. Rules change and their application depends on your sector and your specific data. Your counsel decides what the requirement is; we design and build a system that meets it.
Our published case studies cover clients in the United States, the United Kingdom, Cyprus, Australia, New Zealand and South Africa, and we have built a clinical decision support system for a medical clinic in Riyadh. Our engineering team works from Lahore, with an office in Austin, Texas.
Related
Keep exploring
- LLMs & agentsSovereign AIPrivate LLMs and vision models on your own servers, VPC or air-gapped network.
- CompanySecurity and IPNDAs, IP ownership, data handling and private deployment options.
- Computer visionEdge deploymentModels optimised for NVIDIA Jetson, mobile and on-prem hardware.
- LLMs & agentsPrivate knowledge assistantAn internal assistant that answers from your own documents, with citations, on hardware you control.
Case studies
Book a strategy session
Discuss your residency constraints
Tell us which country's rules apply, what kind of data is involved and where you would like the system to run. An engineer will reply within one business day, under NDA if you need it.
- Send the form, it takes 2 minutes
- We reply within 1 business day, under NDA if you need it
- A 30-minute call to scope feasibility and next steps