Sovereign AI deployment in KSA: VPC, self-hosted, and in-Kingdom
In Saudi enterprise procurement, "where does the data live" is no longer a security question asked late. It is a qualification question asked first, and a wrong answer removes a vendor from the list before the product is ever evaluated. Here is what the four postures actually mean.
Published
Posture 1 — Shared cloud
Multi-tenant, regional, fastest to start. Your data is logically isolated from other tenants but shares infrastructure with them. For a pilot on non-sensitive journeys — public product FAQs, order-status lookups — this is usually the right trade.
It is the wrong trade the moment the journey touches personal data your regulator has an opinion about, or the moment procurement asks for a single-tenant attestation.
Posture 2 — Dedicated VPC
Single tenant, running inside your own cloud account. You own the network boundary, the key management, and the audit surface; the vendor operates the control plane inside it.
This is the posture most GCC enterprises land on. It satisfies the isolation requirement without asking your team to run the platform, and it keeps the egress list something your security team can enumerate and approve.
Posture 3 — Self-hosted
The platform runs in your data centre, inside your security perimeter, on your hardware. Nothing leaves unless you route it out.
Choose this when the perimeter itself is the requirement — defence-adjacent work, certain financial workloads, or an internal policy that predates the cloud. Budget honestly for the operational load: you are now running the platform, and upgrades are your calendar, not the vendor's.
Posture 4 — In-Kingdom
Hosted inside Saudi Arabia, with full data residency inside national borders. This is orthogonal to the first three rather than a fourth option in a list — you can be in-Kingdom in shared cloud, in a VPC, or self-hosted.
It is the answer to the residency question specifically, and it is increasingly the answer procurement needs in writing before a technical evaluation is scheduled.
What NCA CCC-2 alignment actually means
The National Cybersecurity Authority's Cloud Cybersecurity Controls define what a cloud service and its customer each have to do. Level 2 covers the tier most enterprise workloads fall into.
"Aligned" is a meaningful claim only when a vendor can show the reference architecture, name which controls sit with them and which sit with you, and hand that split to your security team as a document. A vendor who treats CCC-2 as a logo on a slide has not read it.
Ask for the shared-responsibility matrix by name. The answer, or the absence of one, is diagnostic.
The controls list to ask for
Independent of posture, ask for these in writing before the pilot rather than after:
- Encryption in transit and at rest, and who holds the keys.
- Tenant isolation model, stated at the network and data layer separately.
- SSO and SCIM, so access follows your existing joiner-mover-leaver process.
- PII masking and redaction policy, including what appears in logs.
- Full audit trail of agent actions — every read and every write, attributable and exportable.
- Model exposure: which models see your data, where they run, and whether anything is used for training.
- Data retention and deletion, with the deletion path tested rather than described.
- MSA, DPA, and SOW readiness, so legal is not the thing that delays the pilot.
Sequencing the decision
Pick the posture from the journey you are piloting, not from the most sensitive workload you might ever run. Starting in shared cloud on a public FAQ journey and moving to VPC for the second journey is a normal, defensible path — provided the platform is genuinely the same control plane across postures.
Confirm that before you start. Migrating between postures is cheap when it is one deployment target; it is a re-implementation when the vendor's "self-hosted" is a different product.