Deployment and data flows
AI Agent Data Residency in Saudi Arabia
Verify where an agent’s data is stored, processed and accessed across models, indexes, logs, support and recovery. Includes a residency register and Saudi regulatory distinctions.
“The agent is hosted in Saudi Arabia” describes a location, but may leave most of the data journey unexplained. The application could run locally while sending document excerpts to a model elsewhere, forwarding traces to a global monitoring service or allowing support personnel in another country to inspect a diagnostic export.
For a Saudi architecture or procurement team, residency needs an object and an operation: which data, stored where, processed where, accessed by whom, and under which conditions? This guide provides a flow-by-flow method for answering those questions. Regulatory references were checked on 22 October 2026; the applicable decision depends on the organisation, data classification, sector and processing activity.
Keep four questions separate
Storage location concerns where copies persist. Processing location concerns where computation uses the data, even if the copy is temporary. Access and control concern who can retrieve, administer or disclose it. Legal authority for a transfer concerns the applicable conditions for sending or disclosing data across borders. One answer does not establish the others.
A local database does not prove that model processing is local. Encryption does not by itself make a transfer lawful. A domestic vendor office does not establish the location of its subprocessors. Conversely, the existence of an overseas technical service is not enough to conclude that the whole architecture is prohibited. The assessment needs the actual data and applicable rules.
What the Saudi sources establish
Article 29 of the Personal Data Protection Law provides purposes and conditions for transferring or disclosing personal data outside the Kingdom. The transfer regulation published in Umm Al-Qura addresses protection levels, specified safeguards and exemptions, onward transfers and risk assessment. Do not interpret a generic supplier data-processing agreement as satisfying every applicable transfer condition. The privacy owner should identify the relevant route and evidence for each flow.
The NCA’s current Cloud Cybersecurity Controls page identifies CCC 2:2024 and its localisation-related update. Annex D of the controls document removes the earlier specified localisation subcontrols and directs entities to NDMO on localisation matters. Its scope covers defined government and critical-national-infrastructure cloud tenants and the providers serving them; it does not make every private business subject to an identical cloud-control regime.
Apply other relevant sector, classification, contractual and organisational requirements as well. A control can be mandatory for a particular entity or dataset without being a universal rule for every Saudi agent. Keep a requirements register with the authority, version, applicability rationale and decision owner. The PDPL implementation guide covers the wider personal-data review; this article concentrates on location and flow evidence.
Map a knowledge assistant beyond its chat window
Consider an illustrative multi-branch business that wants a staff assistant to answer questions from approved operating manuals and case records. Its security policy calls for specific classes of information to remain in approved environments. Before selecting a deployment pattern, separate public manuals, internal process documents and personal case information. They need not all travel through the same processing path.
For each path, trace ingestion, extraction, embedding or indexing, retrieval, model inference, tool execution, logging, support and recovery. Include failed requests and troubleshooting modes. A design can comply with the intended boundary during normal operation but cross it when an engineer enables verbose tracing or a provider automatically fails over.
| Flow | Question to resolve | Evidence to obtain |
|---|---|---|
| Document ingestion | Does extraction or OCR send files to another service? | Endpoint configuration and a representative network trace |
| Embeddings and index | Where are chunks, vectors and identifiers processed and retained? | Service-region terms, index schema and retention settings |
| Model inference | Which endpoint handles prompts, retrieved text and outputs? | Model service, deployment type, processing commitments and exceptions |
| Business tools | Can a tool forward data to a downstream provider? | Tool contract, recipient list and request sample |
| Logs and monitoring | Are full prompts, identifiers or tool arguments exported? | Telemetry schema, collector destination and access policy |
| Support access | Who can inspect production data and from where? | Support agreement, approval workflow and access record |
| Backup and recovery | Where are replicas stored and where can failover run? | Backup inventory, recovery configuration and exercise evidence |
Add columns for data class, purpose, controller or processor, retention, onward recipients, contractual basis, approved exception and review date. A row marked “unknown” is a decision dependency. It should not become “Saudi compliant” because the primary application server is local.
Compare deployment patterns against the same boundary
A Saudi application with external model processing
This pattern may keep the case system and application in a Saudi environment while sending selected task context elsewhere. The design question is whether that particular outbound processing is permitted and justified, and whether the provider’s actual terms match it. Reduce transmitted context where possible, but do not assume redaction is perfect or that coded identifiers are automatically anonymous.
Separate workloads if that is useful. Public service information might use one path, while restricted case material uses another approved path or remains with a person. Routing must enforce the distinction before transmission. Asking the model to decide whether it should have received the data comes too late.
Regional managed processing
A region-specific service can simplify some requirements, but the precise product and deployment mode matter. Request commitments covering inference, stored prompts, abuse-monitoring data, diagnostics, backups and support. Check whether related features use different endpoints. A provider’s general map of regions is weaker evidence than terms for the selected service.
Test the configuration that will actually be deployed. Prevent accidental use of a global endpoint through explicit configuration and egress controls where appropriate. Record what happens if regional capacity becomes unavailable. A fallback chosen for availability may cross the boundary that justified the original design.
Self-managed inference in an approved environment
Operating the model in your chosen environment can give more direct control over processing paths. It also gives your team responsibility for capacity, patching, model provenance, evaluation and recovery. Check outbound telemetry, software-update paths and support arrangements. Self-managed does not mean disconnected, and it does not remove privacy, access-control or operational obligations.
Compare the full service using the ownership-cost model. If a strict boundary requires specialist operational work, include that cost rather than comparing only per-request inference prices. The best pattern is the one that meets the requirements and can be supported with the available capability.
Evidence should survive a change of supplier wording
Collect the contractual service description, relevant processing terms, subprocessor list, architecture configuration and observed traces. Date the evidence and identify which release it supports. Provider documentation can explain a capability; it does not prove that your account uses the required configuration.
For the staff assistant, inspect a test request containing a synthetic case identifier. Follow where the identifier appears in the application, model payload, tool request, log collector and backup. Use an approved test method and avoid inserting real sensitive information merely to observe a route. Match observed recipients against the register and investigate differences.
Also test a failure. Make a tool unavailable and inspect whether the error message or support event includes source content. Exercise a recovery to the approved environment and verify that a convenience fallback does not silently activate elsewhere. These are architecture acceptance checks, not a legal determination. The security design guide covers the controls that enforce the agreed boundaries.
Watch the less visible copies
Developer laptops, copied screenshots, evaluation datasets and support attachments can create data paths outside the planned application. Give each a defined purpose, owner and handling rule. Synthetic or appropriately de-identified test data can reduce exposure, but evaluate whether the resulting sample still represents the failure modes you need to test.
For logs, ask whether a reference to a case is enough instead of the full prompt. For evaluation, decide whether a corrected example can be retained without the original identity. For a support incident, restrict the export to the fields needed for diagnosis and record its disposal. The audit-trail article separates durable event evidence from indiscriminate content retention.
Deletion and restoration also interact. If an approved deletion removes a live record but an old backup reintroduces it, the data boundary has not been maintained over time. Specify how restoration reconciles deletion and access changes before the recovered service returns to users.
A procurement decision record you can reuse
- State the intended workload and its data classes.
- List applicable location, transfer, sector and contractual requirements with their owners.
- Attach the complete recipient and processing-flow register.
- Document the selected architecture, rejected alternatives and unresolved dependencies.
- Record the evidence for normal operation, diagnostics, support and recovery.
- Approve any permitted exceptions with a scope, expiry and review trigger.
Use this record in the RFP so each supplier answers the same flow questions. Request notification and review before a material recipient, region, feature or support arrangement changes. The governance policy should name who can approve such changes and when an affected workflow must pause.
Open for AI’s agent development service can be scoped around the deployment and processing requirements you establish. Share a redacted flow map and the requirements your reviewers have identified to discuss a design whose data paths can be explained and checked.