Summary: A programme director promises the first wave of a sovereign AI platform within months, then learns the GPUs are four months out. The way through isn’t choosing between cloud and on-premises. It’s splitting the programme by data class, so Wave 1 starts now and the sovereign estate arrives when it arrives.
The date was already on the wall. A programme director at a federal entity in the UAE had committed to Wave 1 of an agentic AI platform inside a single quarter. Leadership had repeated the date in a town hall. Then the hardware quote came back with a line nobody had priced into the schedule: lead time, 10 to 16 weeks from order.
Add the site survey, the power works, the rack delivery and commissioning, and Wave 1 slips a full quarter before a single user touches it. The promise was broken before the project had started.
The false binary
The obvious escape is cloud. The obvious objection arrives a second later: we’re a sovereign programme, we can’t use cloud.
That sentence stalls more AI programmes in this region than any technical problem does. It treats “sovereign” as a property of the whole programme, when it’s actually a property of specific data. We’ve written before about what sovereignty actually requires in the GCC, and the short version is that the law is precise about which data must stay in-country and silent about the rest. Health records under Article 13 of Federal Law No. 2 of 2019, yes. The staff leave policy, no.
So the programme director was facing a binary that didn’t exist.
Split by data class, not by technology
This is where we came in, and the reframe we brought was one we’d used before: classify first, then place.
Every use case in the programme was sorted by the data it touched. Internal-classification content, meaning policies, standard operating procedures, public documents and internal knowledge, went in one column. Confidential, personal and restricted records went in the other. The first column turned out to cover most of what Wave 1 needed: an employee assistant that answers questions about procedures, a document search across the intranet, a first-line IT support agent.
None of that data carries a residency obligation beyond staying in the UAE. And an in-country cloud region keeps it in the UAE.
That single sort turned the programme from one plan into two, running in sequence. Wave 1 on cloud, now. The confidential use cases on the sovereign estate, when the racks arrive. Same platform, same code, two homes.
Making the cloud phase as controlled as the on-prem one
The objection doesn’t die just because the data classification is right. Security will ask, reasonably, whether “cloud” means “somebody else’s API”. It doesn’t have to.
The Wave 1 environment we designed runs in Azure UAE North, the Dubai region. The production GPU tier is a single reserved ND H200 v5 instance: eight H200 GPUs, 1,128 GB of GPU memory, NVLink between them at 900 GB/s. Non-production GPU capacity is spun up on demand per test window and torn down afterwards, so nobody pays for idle dev hardware.
Every model runs self-hosted on vLLM inside that region. No external LLM API is called, by anyone, for anything. No data leaves the UAE. The landing zone uses private endpoints, identity federated to the entity’s own directory, an egress allow-list so the platform can only talk to what it’s been told to talk to, and log forwarding to the entity’s SOC. In practice that’s a tighter posture than many on-premises estates run.
The one thing outside anyone’s control
Every hero’s story has the ordeal, and in this one it wasn’t security or cost. It was capacity.
ND-class GPU instances are reserved, not conjured. Allocation in any region is subject to provider availability and a quota approval that the customer, not the integrator, has to hold. We put a capacity disclaimer in writing, in the proposal, in plain language: GPU capacity in the selected region is confirmed at deployment time, and the fallback is agreed in advance. Nobody enjoys writing that sentence. Leaving it out is how a programme discovers the problem in week nine.
For availability, the choice was made explicit rather than assumed: either two ND-class instances in separate availability zones, or one reserved instance with on-demand failover held in the same region, using the same degraded-mode routing as the on-premises design. Fixed at architecture sign-off, against the entity’s stated targets, not left to whatever the cloud happened to offer that week.
Two homes, one platform
| Dimension | Wave 1: in-country cloud | Wave 2 onward: sovereign on-premises |
| Data allowed | Internal classification only | Confidential, personal, restricted |
| Time to first user | Weeks | After 10-16 week hardware lead plus site works |
| GPU tier | One reserved 8×H200 instance | Sixteen H200 across four nodes |
| Models | Self-hosted vLLM, in-region | Self-hosted vLLM, in-building |
| External LLM APIs | None | None |
| Data leaves the UAE | No | No |
| Portability | Kubernetes, Helm, infrastructure-as-code: the same deployment, pointed at a different cluster | |
The road back
The migration that everyone fears is the part that turned out to be least dramatic. The platform was built on Kubernetes with Helm charts and infrastructure-as-code from the first day, precisely so that the move to the sovereign estate would be a lift and not a rebuild. When the racks were commissioned, the same deployment was pointed at the new cluster. The confidential use cases, the ones that had been waiting in the second column, activated in Wave 2 on hardware that had never been on the critical path for Wave 1.
The programme director kept the date. Not by cutting scope, and not by bending the sovereignty rules, but by noticing that the rules had never applied to the data Wave 1 needed in the first place.
That’s the pattern worth keeping: classify the data, place each class where it’s allowed to live, build for portability from day one, and stop treating “sovereign” as a reason to wait. If you’re staring at a delivery date and a hardware lead time that don’t fit, talk to 10ⁿ Tech about sequencing it.
Frequently asked questions
Can a sovereign AI programme use public cloud?
For the right data, yes. Sovereignty obligations attach to specific data classes, not to the whole programme. Internal-classification content such as policies, procedures and public documents can run in an in-country cloud region with self-hosted models and no external APIs, while confidential and personal records wait for the on-premises estate.
How do you start an AI platform before the GPUs arrive?
Split the programme by data class. Run Wave 1 on reserved GPU capacity in an in-country cloud region for the use cases whose data has no on-premises obligation, and build on Kubernetes, Helm and infrastructure-as-code so the same deployment moves to the sovereign estate when the hardware is commissioned.
What does Azure UAE North offer for AI workloads?
The Dubai region supports ND H200 v5 instances: eight NVIDIA H200 GPUs per VM, 1,128 GB of GPU memory, NVLink at 900 GB/s and 400 Gbps InfiniBand. Capacity is reserved rather than guaranteed, and allocation is subject to quota approval, so confirm it at deployment time and agree a fallback in advance.
Does self-hosting models in the cloud keep data in-country?
Yes, if it is done properly. Models served on vLLM inside the region, private endpoints, an egress allow-list and no external LLM API calls mean no data leaves the UAE. The region is in-country; the question is whether the architecture actually confines the data to it.
What is the biggest risk in a cloud-first AI deployment?
GPU capacity. ND-class instances depend on provider availability and customer-held quota. Put the capacity condition in writing, decide the availability model at architecture sign-off, and agree the fallback before anyone commits to a date.
Related resources
- Sovereign AI in the GCC: what in-country actually requires
- AI outputs are advisory until someone signs
- Cloud platforms
- Self-hosted cloud AI
Photo credits: Karen Dalton and Denny Müller on Unsplash.
