- One governed front door for generative AI instead of scattered pilots and shadow use
- Prompts, documents and outputs kept on in-country infrastructure by design
- Every request attributable to a user, a use case and a model version
- New use cases onboarded through a repeatable review and evaluation path
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A UAE government entity had the usual pattern: enthusiasm for generative AI in every department, a handful of disconnected pilots, and a security team quietly worried about staff pasting documents into public chatbots. Policy said sensitive data could not leave national infrastructure. Nobody wanted to say no to AI; they wanted a safe way to say yes.
The national direction supports that stance. The UAE Charter for the Development and Use of Artificial Intelligence puts privacy, data security and compliance with local law alongside innovation as guiding principles2.
What had to be true
- In-country by design: models, prompts, retrieved documents, logs and evaluation data all hosted on national infrastructure.
- One front door, so identity, redaction and audit are enforced once rather than reimplemented by each team.
- Known applicable rules, mapped to controls before the first use case went live.
- Measured quality: no use case in production without an evaluation set and an owner.
- Operable by the internal team after hand-off.
The rules question needed care. The federal Personal Data Protection Law sets aside several categories from its scope, including government data and government entities1. That does not mean anything goes: it means the entity's own data classification, emirate-level policy and sector rules carry the weight, with PDPL principles a sensible baseline. We confirmed the applicable regime with legal counsel first. More context in UAE PDPL and AI architecture and the federal authority for AI and data.
Architecture
Serving used vLLM, whose PagedAttention design manages the KV cache in pages to reduce memory waste and raise throughput on shared GPUs3. That matters when a fixed, in-country GPU budget has to serve many departments. See LLM inference serving with vLLM and where to run models in the UAE.
The data flow, end to end
- RequestUser or app calls the gateway with an identity and a registered use case
- RedactDetect and mask personal data the use case is not cleared to send
- RetrieveFetch only from collections the caller's department may read
- RouteChoose the model pool approved for that use case and classification
- LogRecord request, model version, sources and latency in the audit store
- EvaluateSample responses into the use case's evaluation and review queue
The hard part: one platform, many trust levels
The engineering was not the hard part. The hard part was that a single shared service had to respect different data classifications, department boundaries and risk appetites. The OWASP Top 10 for LLM applications lists prompt injection and sensitive information disclosure among the leading risks4, and on a shared platform both translate into one question: can a user see something through the model that they could not see directly?
- Retrieval inherits the caller's permissions; the model never sees a document the user couldn't open.
- Each use case is registered with a classification ceiling, an owner and an approved model list.
- Redaction is configurable per use case, not one global rule that is either too loose or too strict.
- Tool access for agent-style use cases is explicit and minimal. See prompt injection defence for agents.
Sovereignty is not only where the GPUs sit. It is whether every prompt, document and answer can be accounted for, on infrastructure you control.
How the engagement ran
- Propose use case
- Supply evaluation examples
- Own outcomes in production
- Register and classify
- Configure redaction and routing
- Run evaluation gate
- Confirm applicable rules
- Review controls
- Approve go-live
The governance loop followed the NIST AI RMF functions of govern, map, measure and manage5, adapted to the entity's own approval structure.
- Applicable rules
- Use case inventory
- Data classification map
- GPU cluster and serving
- Gateway and redaction
- Audit logging
- Staff assistant
- Document search
- Evaluation sets
- Onboarding process
- Runbooks
- Capacity planning
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Open-weight models in country | Hosted frontier APIs | Data residency without exceptions; full control of versions |
| Central AI gateway | Per-app integrations | Controls enforced once; consistent audit |
| Permission-aware retrieval | One shared index | No leakage across department boundaries |
| Evaluation gate per use case | Platform-wide benchmark | Quality depends on the task, not the model alone |
| Model routing by use case | One model for everything | Right-size GPU use; smaller models for simple tasks |
Routing and evaluation patterns are covered in LLM model routing and evaluation sets that predict production.
What I'd do again, and differently
Again: put the gateway and the audit log in before the first use case, and make departments bring their own evaluation examples. Differently: start capacity planning earlier. In-country GPU capacity is finite and slow to expand, so demand forecasting deserves the same attention as the architecture.
If you're planning sovereign AI in the region, the UAE page describes how I work there, or analyse your challenge and bring the result to a call.
- 1Federal Decree by Law No. 45 of 2021 Concerning the Protection of Personal DataUAE Legislation portal
- 2The UAE Charter for the Development and Use of Artificial IntelligenceThe UAE Government portal (u.ae)
- 3Efficient Memory Management for Large Language Model Serving with PagedAttentionKwon et al. (arXiv; SOSP 2023) · 2023
- 4OWASP Top 10 for LLM Applications 2025OWASP GenAI Security Project
- 5