Saudi Arabia POC readiness
Saudi AI data residency POC framework: What to verify before cloud or agentic AI touches a
A Saudi enterprise decision framework for qualifying cloud and agentic AI POCs that may process personal data. Use it to align PDPL, cloud cybersecurity and AI
Executive answer
Do not begin a Saudi AI POC with production personal data simply because a vendor can demonstrate a working model. First establish the intended processing purpose, data categories, controller and processor roles, locations and onward flows of data, and the cloud security responsibilities of both the enterprise and provider. Then decide whether the POC can use synthetic or effectively anonymised data, or whether it requires formal privacy, security and contractual approvals before access is granted. This sequence is important because Saudi PDPL requirements cover processing activities, while the NCA Cloud Cybersecurity Controls assign cloud-go
The decision question: Can this AI POC process Saudi personal data in the proposed cloud architecture?
The first decision is not whether the model is accurate. It is whether the proposed test involves personal data and, if it does, whether the organisation can explain and govern the processing. Saudi PDPL materials define a controller as the entity that determines the purpose and manner of processing, and a processor as the entity processing personal data for the controller. That distinction matters when an enterprise, a platform provider, an implementation partner and model provider all participate in one AI workflow.
For a generative or agentic AI POC, map every point at which information is collected, sent, stored, retrieved, monitored or disclosed. Include user prompts, uploaded files, conversation histories, retrieval indexes, vector databases, application logs, guardrail telemetry, support tickets and human review queues. The map should also state whether information is retained, reused for service improvement or passed to a subprocessor. A workflow is not low risk merely because the original data source remains inside the enterprise network.
- Classify the proposed POC as one of three paths: no personal data, limited personal data, or sensitive, high-volume or continuously monitored personal data.
- For any personal-data path, identify the enterprise controller, every processor and subprocessor, the stated processing purpose, retention period and deletion method.
- Ask whether automated processing will make or materially support decisions about individuals. The PDPL Implementing Regulation contains added transparency expectations for relevant
- Stop the POC at this gate if the vendor cannot provide a complete data-flow diagram and a written processing-role statement.
Gate 1: Prove data minimisation before requesting approvals
Saudi PDPL materials state that personal-data collection should be limited to the minimum needed for the specified collection purpose. For a POC, this means the dataset should be designed around a test hypothesis, not around the largest dataset available. A customer-service summarisation test may need carefully selected and redacted interactions. It does not automatically need full customer history, identity documents or unrestricted access to the customer relationship management system.
The safest first test is usually one that measures workflow value using synthetic, anonymised or tightly minimised data. This does not eliminate the need for security review, but it can keep the early experiment focused on capability, integration feasibility and evaluation quality while the organisation completes the assessments required for a personal-data workload.
- Write one measurable hypothesis, such as whether approved staff can produce a compliant first draft faster while preserving required source references.
- Create an approved data dictionary listing each field, why it is needed, whether it is personal or sensitive, its source and its planned retention period.
- Remove fields that do not change the test result. Do not collect identity documents, free-text attachments or full production histories by default.
- Document how data will be deleted or irreversibly anonymised at POC close.
Gate 2: Turn cloud cybersecurity obligations into vendor evidence requests
The NCA Cloud Cybersecurity Controls apply to cloud service providers and cloud service tenants and describe minimum cybersecurity requirements for secure cloud use. They emphasise defined cybersecurity roles and responsibilities, risk management that considers data and information classification, and cloud-specific governance. Buyers should therefore avoid accepting a generic vendor security presentation as POC evidence.
Instead, ask the vendor to show how the proposed architecture divides controls between the tenant, provider and any third parties. A shared-responsibility diagram should identify who configures identity and access management, encryption, logging, backups, vulnerability management, incident response, network controls and secure integration points. It should also identify which services are operated by another provider within the solution path.
- Request a POC-specific RACI that names the enterprise authorising owner, security owner, privacy owner, vendor delivery lead and incident contacts.
- Request the vendor's architecture diagram, service locations, data-flow diagram, subprocessor list and list of operational support locations relevant to the POC.
- Verify the configuration controls: identity federation, least privilege, privileged access, encryption, key management, audit logs and log retention.
- Require a security-test plan that covers the POC integration, retrieval layer, prompt interfaces, APIs and privileged administration path.
- Define incident escalation, evidence preservation and POC suspension actions before data access is enabled.
Gate 3: Evaluate agentic AI as a third-party and resilience problem, not only a model problem
On July 5, 2026, the NCA opened public consultation on AI Cybersecurity Guidelines intended to help entities adopting AI mitigate cybersecurity risks. The consultation described four domains: cybersecurity governance, cybersecurity defense, cybersecurity resilience and third-party cybersecurity. The consultation closed on August 5, 2026, so enterprise buyers should not present the consultation document as a final binding control set. It is still a useful indicator of the risk areas that a serious Saudi AI evaluation should cover.
This is particularly relevant for agentic systems. An agent may retrieve enterprise data, invoke tools, call external services and take actions under delegated permissions. The POC must test what happens when instructions are malicious, incomplete or conflicting, when retrieval results are inaccurate, when a tool call fails and when an external provider becomes unavailable. Business usefulness without these tests is insufficient evidence for broader access.
- Governance: define the permitted business actions, human approval points, owner for policy changes and a register of model, tool and prompt versions.
- Defense: test prompt injection, unauthorised retrieval, data exfiltration attempts, excessive tool permissions and misuse of service accounts.
- Resilience: test logging, rollback, manual fallback, kill-switch operation, recovery objectives and continuity when the model or external service is unavailable.
- Third-party security: verify subcontractors, support access, contractual security duties, incident notification processes and any onward data disclosures.
- Keep agents read-only during the initial POC unless a business owner approves a narrow, reversible action with human confirmation.
A four-document approval pack for a Saudi AI POC
A POC should move from an informal experiment to an approved enterprise test only when decision-makers can review one coherent evidence pack. This reduces the common failure mode in which privacy, security, procurement and the business sponsor each approve different assumptions.
The pack does not need to be lengthy. It needs to make responsibilities, data use, architecture and exit criteria auditable. For personal-data POCs, the organisation should involve its relevant privacy function early. The PDPL Implementing Regulation establishes responsibilities for personal-data protection officers in specified circumstances, including oversight of impact assessments, audit reports and personal-data processing records.
- 1. Business test charter: use case, hypothesis, users, baseline, expected outcome, prohibited uses and POC end date.
- 2. Data and privacy assessment: data dictionary, lawful processing analysis, controller and processor roles, retention, deletion, transfers and data-subject impact considerations.
- 3. Security and architecture assessment: system diagram, cloud responsibility RACI, identities, access controls, logs, integrations, security tests, incident process and resilience
- 4. Commercial and exit schedule: vendor commitments, subprocessor terms, acceptance criteria, remediation obligations, data return or deletion evidence, and the decision path for
Use a staged approval model instead of a single yes or no decision
A staged model lets the enterprise test value without normalising uncontrolled access. It also gives vendors a fair way to demonstrate capability before the customer commits to a production architecture.
Stage A is a capability demonstration using no enterprise personal data. Stage B is a constrained POC using synthetic, anonymised or minimised data and restricted integrations. Stage C is a controlled personal-data POC only after the data, security and contract evidence is accepted. Stage D is production readiness, which requires operational ownership, monitoring, incident readiness and a documented decision on the production data flow.
- Advance from Stage A only when the vendor can supply the proposed data-flow and architecture evidence.
- Advance from Stage B only when the enterprise has confirmed that the measured business outcome is credible and the access model remains bounded.
- Advance from Stage C only when privacy, security, procurement and business owners sign off on the evidence pack.
- Do not treat POC completion as production approval. Production creates ongoing obligations for access reviews, change control, monitoring, third-party oversight and data lifecycle
Practical questions
Can a Saudi enterprise use a public generative AI service for a POC?
It depends on the proposed data and workflow, not on the label of the service. Start by confirming whether personal data will be processed, where data and logs flow, whether the provider or its subprocessors retain or reuse information, and whether the enterprise can meet applicable privacy and cloud-security responsibilities. A no-personal-data demonstration may be suitable for early capability testing, but it does
Does data minimisation mean a POC cannot use production data?
No. It means the enterprise should use only the data needed for a specific, documented test purpose. If production personal data is necessary, the POC should proceed only after the organisation completes the relevant privacy, security, contractual and access-control reviews.
What should we ask an AI vendor about data residency?
Ask for the exact processing locations for prompts, files, embeddings, backups, logs, monitoring, support and disaster recovery. Also ask for all subprocessors, onward transfers, retention periods, deletion mechanisms and the contractual commitments that govern those flows. Compare those answers with your own data classification, PDPL assessment and cloud-control responsibilities.
Are the NCA AI Cybersecurity Guidelines already mandatory?
The NCA announcement of July 5, 2026 described a public consultation on proposed AI Cybersecurity Guidelines, with feedback requested by August 5, 2026. Treat the four announced domains as a useful evaluation lens, but verify the final regulatory status and any applicable obligations with your legal, compliance and cybersecurity teams before relying on them as binding requirements.
Related research
Keep building the complete picture
Generative AI POC evaluation dataset: How UAE and Saudi enterprises should test a use case
QualifiedPOC Intelligence Report | POC readinessAI agent authorization POC: How UAE and Saudi enterprises should test agent access before
Daily Enterprise Tech Brief | 16 September 2026Top AI Releases: What’s in It for Me and My Business?
Qualify the architecture before the AI POC creates exposure
QualifiedPOC.ai helps serious enterprise buyers turn an AI idea into a decision-ready scope, evidence request and approval path. Complete one deep discovery conversation to assess the use case, data boundaries, vendor responsibilities and measurable POC exit criteria.