Placing an AI workload in Saudi Arabia means satisfying three authorities at once: SDAIA, which supervises the Personal Data Protection Law and publishes the Kingdom's AI guidance; the NCA, the National Cybersecurity Authority, whose cybersecurity controls — including cloud-specific ones — bind government and critical-sector entities; and CST, the communications and technology regulator, which licenses cloud providers operating in the Kingdom. The practical consequence is that "which cloud can we use for this model?" is not an infrastructure preference in Saudi Arabia. It is a compliance outcome determined by what data the workload touches, how that data is classified, and which providers hold the licences and assurances your sector requires.
This article maps the stack at the level of durable fact — who does what, and what that means operationally — and is deliberately explicit about its limit: the control frameworks themselves are versioned documents that change, so the specific controls applying to you must be read from the current NCA and SDAIA publications, not from any summary, this one included.
Who regulates cloud and AI in Saudi Arabia?
Three bodies, three distinct jobs.
| Authority | What it is | What it decides for an AI workload |
|---|---|---|
| SDAIA | The Saudi Data and AI Authority — national data and AI strategy, PDPL supervision, AI ethics and generative-AI guidance | Whether your data processing is lawful, and the standard of care for AI use |
| NCA | The National Cybersecurity Authority — national cybersecurity controls, including controls specific to cloud usage | How securely, and under what conditions, regulated entities may run workloads in the cloud |
| CST | The Communications, Space and Technology Commission — telecoms and technology regulation, including cloud provider licensing | Which providers are licensed to offer cloud services in the Kingdom |
SDAIA is the authority most AI teams meet first, because the PDPL governs any personal data the workload touches and SDAIA's AI guidance sets expectations for responsible use — the working detail of that regime is covered in AI compliance in Saudi Arabia and India. The NCA matters most if you are a government entity, a critical-infrastructure operator, or a supplier into either, because its control frameworks — an essential baseline set plus cloud-specific controls for both cloud customers and providers — define what compliant cloud usage looks like for entities in scope. CST sits underneath as the licensing layer: the register of who may lawfully sell cloud services in the Kingdom.
The clean division of labour: SDAIA governs the data and the AI, the NCA governs the security of where it runs, CST governs who may run it.
What do the NCA cloud controls mean for AI workloads?
Three operational consequences, stated at the durable level.
Scope is about who you are, not what the technology is. NCA controls bind categories of entity — government bodies, critical national infrastructure, and organisations designated within scope — rather than "AI" as a category. An AI workload inherits obligations from the entity running it and the data it processes. A private company outside those categories faces a lighter direct burden, but meets the same controls contractually the moment it supplies in-scope customers.
Requirements scale with classification. The cloud control frameworks tie what is permitted — including hosting location and provider assurance level — to how the data and system are classified. This is why classification is not paperwork; it is the input that determines your eligible infrastructure.
The specifics are versioned. The NCA publishes and updates its frameworks, and the correct control set for your case depends on current versions and your scoping. Treat any specific control quoted outside an NCA document as a pointer, and build your compliance register from the source publications — with counsel or a qualified assessor where scoping is ambiguous.
How does data classification drive AI hosting decisions?
The working method is classification-first, and it is refreshingly mechanical.
- Classify what the workload touches — training data, prompt flows, retrieval stores, outputs, and logs. Saudi practice distinguishes government and sensitive data from ordinary commercial data, and the classification schemes for government data are published; use the current ones.
- Let classification shortlist the hosting. Higher classifications and government data point at in-Kingdom hosting on assured platforms; ordinary commercial data leaves more options open, subject to PDPL transfer rules for personal data. The general shape of this decision — and why "keep it in-country" is often simpler than a clever transfer argument — is the subject of AI data residency.
- Check the provider's standing. For the shortlisted platforms: CST licensing, relevant NCA-aligned assurances, and where support and administration actually happen — remote administration from abroad can undo an in-Kingdom hosting decision.
- Decide the deployment model. Classification also drives whether a shared API, a dedicated in-Kingdom deployment, or a fully sovereign arrangement is appropriate — the trade-offs are worked through in private vs sovereign AI deployment, and what "sovereign" actually requires is defined in what is sovereign AI.
What are the in-Kingdom hosting options for AI?
The landscape has been built deliberately, and it now has real depth.
- SITE Cloud. SITE — the Saudi Information Technology Company, owned by the Public Investment Fund — operates sovereign cloud infrastructure positioned for government and regulated workloads, the clearest expression of the Kingdom's in-country-by-design approach.
- DEEM. The government cloud service, which has been publicly reported to run IBM's watsonx.ai platform and to host SDAIA's Arabic large language model ALLaM for government use — a signal that in-Kingdom hosting now extends to serious AI tooling, not just storage and compute.
- Global providers with Saudi regions. Several international cloud providers have announced or launched in-Kingdom regions. Whether a given region and service is eligible for a given classification is a question of current licensing and assurance status, verified with the provider and against current NCA and CST positions — not assumed from a press release.
What should you ask an AI or cloud vendor before committing?
Vendor assurance for Saudi workloads reduces to questions with checkable answers.
- Where — physically and legally — will our data be processed, stored, and backed up, including logs and support access?
- What CST licensing and which NCA-aligned assurances do you hold, at what level, and can you evidence them?
- Who administers the platform, from where, and how is remote access from outside the Kingdom controlled?
- Can you contractually commit that our data will not be used for training, and that deletion is complete and demonstrable?
- What happens on exit — can we take the data, the fine-tuned models, and the logs, and run elsewhere?
A vendor that answers these crisply is a partner; one that answers with adjectives is a risk.
Where to start
Start with classification, because everything downstream is determined by it: one honest pass over what your intended AI workload actually touches, classified against current schemes, tells you whether you are in easy territory or NCA territory. Then check scope — whether you or your customers bring NCA obligations — and only then evaluate platforms, using the vendor questions above. Verify specifics against the current NCA, SDAIA, and CST publications at each step, and record that you did; in this market, the audit trail of checking is itself a control. The same classification-first discipline applies across the region's regimes, as the wider AI adoption guide for India and the GCC sets out — Saudi Arabia is simply the market where the stack is most explicit about it.