Data residency and compliance in the Gulf
PDPL, sector regulators and cloud regions — how residency requirements shape AI architecture across GCC markets.
Residency is the requirement most likely to invalidate an otherwise sound AI architecture, and the one most often discovered late — usually during a security review, after the build.
Establish the rules before the design
Personal data protection law, plus sector-specific rules for financial services and healthcare, plus your customer's own contractual requirements, together determine where data may live and move. Get that written down before choosing a provider.
Residency propagates further than the database
It is easy to place the primary store correctly and leak through everything around it.
Support tooling
Where staff actually view customer records
Error tracking and analytics
Third parties, third regions
Backups and DR replicas
Often in another region by default
Logs and traces
Frequently contain user content
Model inference
Where does the prompt physically go?
Primary database
The part everyone gets right
Residency propagates further than the database
It is easy to place the primary database correctly and then leak data through everything around it.
- Model inference — where does the prompt physically go?
- Logs and traces, which frequently contain user content
- Backups and disaster-recovery replicas in another region
- Error tracking and analytics services
- Support tooling where staff view customer records
It narrows your model choices
Not every model provider offers in-region hosting. If residency binds you, your options are a provider with local presence, a cloud-hosted model in an approved region, or self-hosting an open-weight model. That decision cascades through capability, cost and operations.
Compliance is demonstrated, not asserted
Build the evidence in
- Documented data flows per system
- Per-region logging you can produce
- Access records for staff viewing customer data
- A register of every third party that touches data
Not enough
- A policy document with no telemetry behind it
- "Our provider is compliant"
- Reconstructing flows after the request arrives
- Assuming backups inherit the primary region
Design so it can be proven
Compliance is demonstrated, not asserted. Build the evidence in: documented data flows, per-region logging, and access records you can produce on request. Reconstructing that after the fact is far more expensive than capturing it as you go.