How to build AI on data that cannot leave the Kingdom

For most of the past decade, the honest answer to "why isn't our AI in production?" was infrastructure. That excuse is being removed at national scale. HUMAIN — the PIF's AI company, chaired by the Crown Prince — has broken ground on its first data centres in Riyadh and Dammam, 100 MW each and scheduled to come online this year, on a path towards a stated 6.6 GW. 

Its first tranche of 18,000 NVIDIA Blackwell chips has several hundred thousand more behind it; AMD has committed USD 10 billion and 500 MW of compute; AWS is building a first-of-its-kind "AI Zone" with HUMAIN worth more than USD 5 billion, alongside its USD 5.3 billion Saudi infrastructure region due in 2026; and xAI has been reported planning a 500 MW facility in the Kingdom. The models are following the compute: HUMAIN Chat, built on the Arabic-first ALLaM 34B model, is already serving consumers at national scale.

The constraint has therefore moved. It now sits inside the enterprise, and it is regulatory and architectural rather than computational: the data most worth building AI on — transaction histories, patient records, citizen services, industrial telemetry — is precisely the data that PDPL transfer rules, the NCA's cloud controls and sectoral frameworks from SAMA restrict from moving. PDPL has been fully enforceable since 14 September 2024. For a growing share of Saudi enterprise data, the practical position is simple: it stays.

The instinct is to read that as a blocker. The organizations moving fastest read it as a design parameter. If the data cannot travel to the model, the architecture inverts: bring the model, the training process or the computation to the data. Four techniques make that inversion practical, and each fits a different class of workload.

1. Sovereign inference: run the model where the data lives

The most direct approach. With serious GPU capacity arriving inside the Kingdom and Arabic-capable models available, enterprises can serve language models — internal assistants, document processing, customer service — entirely on in-Kingdom infrastructure, so prompts, context and outputs never cross a border. 

The procurement questions matter more than the model choice: where are the weights hosted, where does inference execute, what telemetry and logs leave the environment, and who holds the encryption keys? Sovereign arrangements such as Google Cloud's partnership with local provider CNTXT, which stores encryption keys outside Google's infrastructure under customer and partner control, show what a defensible answer looks like.

2. Confidential computing: process data nobody can see

Hardware-based trusted execution environments keep data encrypted even while it is being processed, and can prove — through remote attestation — that the environment is running exactly the approved code before any record arrives. That closes the gap between "encrypted at rest and in transit" and "protected in use". It is the technique to reach for when sensitive data must be processed on shared or third-party infrastructure, or when two organisations need to compute on combined data that neither may show the other.

3. Federated learning: the model travels, the data stays

When the value lies in training across multiple sites — fraud models across banks, diagnostic models across hospital networks — federated learning sends the training process to each dataset and returns only parameter updates. The records never move. Paired with differential privacy to limit what the updates themselves reveal, it turns multi-entity collaboration from a data-sharing negotiation into an engineering exercise.

4. Synthetic data: statistical twins for the work that can't wait

Generated datasets that preserve the statistical structure of the original without containing real records are the pragmatic answer for development, testing, vendor evaluation and cross-border collaboration. One caveat belongs in every plan: synthetic does not automatically mean anonymous. Poorly generated synthetic data can leak the records it was built from, so validation — of fidelity and of privacy — is part of the engineering and part of the governance case.

Choosing between them: three questions

Match technique to workload by asking three things. Where must this data reside, and under which framework? Who needs to compute on it — your organisation alone, a consortium, or a vendor? And what is permitted to leave — nothing, aggregates, model updates, or synthetic derivatives? 

A single organization with nothing leaving points to sovereign inference on in-Kingdom infrastructure. Multi-party training on immovable records points to federated learning. Third-party processing of sensitive workloads points to confidential computing. Development and external collaboration point to synthetic data. Most large enterprises will end up running all four; the sequencing is what differs.

How to sequence 2026–2027

Start with classification: none of this works without knowing which data falls under which residency obligation — the data-foundations discipline that AI keeps demanding. 

Then pilot sovereign inference on one internal, high-volume, Arabic-heavy workload; stand up synthetic data for development and testing to take the pressure off production datasets; and write confidential computing requirements and attestation rights into procurement now, so the capability arrives with the next infrastructure refresh rather than after it.

Where to get started

The Kingdom is answering the compute question at a scale few economies can match. The competitive question for 2026–2030 is which enterprises can bring regulated data and national compute together safely — and the four techniques above are how. SBM can help. Get in touch to find out more.