What data residency requires of an AI system

Data residency is usually discussed as a question about where the servers are. For an AI system that is the least informative part of the answer. What matters is the whole path the data takes: into the model, into the index that retrieves it, into the logs that record each request, into the vendor’s telemetry, into the backups and, if anyone fine-tunes, into the weights themselves. Running the compute inside the Kingdom settles one of those places. Residency is a claim about all of them, and the places nobody drew on the architecture diagram are where the claim usually fails.

Start with the inventory, which is longer than most teams expect. A retrieval-augmented system keeps a vector index, and that index is a copy of the source documents in another form; if the embedding model is a hosted API, every chunk of every document has been sent to it. Application logs and traces usually store the full prompt and the full response, because that is what makes debugging possible, and they are shipped to wherever the observability tool lives. Error trackers capture the request that failed, payload included. Model vendors collect usage telemetry under terms that vary by contract and change over time. Backups replicate to whichever region the storage account was set to on the day it was created. Support tooling gives a vendor’s engineers a path to the data whenever a ticket is opened. For personal data, each of these is a transfer in substance, and the law is concerned with what happened to the data rather than with whether anyone intended it.

The frameworks are clearer than the marketing around them. PDPL restricts the transfer of personal data outside the Kingdom to defined purposes and conditions, and SDAIA’s regulation on transfers outside the Kingdom sets out when those conditions are met, including the assessment a controller is expected to make before some transfers; health data and credit data are among the categories the law treats as sensitive. The NCA’s Essential Cybersecurity Controls place explicit requirements on the use of cloud and hosting services by the government and critical infrastructure entities in their scope, including where an organisation’s data may be held. Sector regulators add their own layer: a bank answers to the Saudi Central Bank’s frameworks as well. None of these texts mentions embeddings or trace logs, and none needs to. They regulate the data, and the data is in the embeddings and the trace logs.

None of this means everything has to run on hardware you own. Classification decides the tier. Government entities have the classification levels defined in the national data management standards issued through SDAIA’s National Data Management Office; for everyone else, PDPL’s categories do most of the work. Internal drafting, research that involves no personal data and public content can defensibly run through a hosted API under contractual terms someone has read. Citizen records, patient data, credit files and anything a regulator could ask you to produce need a design in which the whole path, including the places listed above, stays inside a boundary you control. The useful question for a review is which tier each dataset sits in, and whether every component that touches it meets that tier.

A residency review is therefore an exercise in tracing, done with the engineers rather than with the vendor’s compliance presentation. Follow one record from ingestion to inference and list every system it enters: the ingestion pipeline, the storage bucket and its replication settings, the embedding model and where it runs, the vector store, the model endpoint, the application log, the trace store, the error tracker, the analytics script, the backup target, the support portal. For each, record the region, the retention period, and who at the vendor can read it under what terms. What fails the check is remarkably consistent: a logging integration left on its default region, an embedding API that was temporary during the pilot, a backup policy nobody revisited, and an analytics script added for a demo.

Fine-tuning changes the inventory again. Once a model has been trained or adjusted on your data, some of that data is now expressed in the weights, and the model file is itself a data artefact. Where it is stored, who can download it, whether the training run touched hardware outside the boundary even briefly, and what happened to the intermediate checkpoints all become residency questions. The same applies, less obviously, to evaluation sets built from production records and to the prompt libraries that accumulate examples from live use. These usually sit in the least controlled place in the whole system, a shared drive or a notebook, because nobody classified them as data.

A system whose data stays in the Kingdom can show that it does. That means an audit log, kept inside the boundary, of which data moved to which component and when, in a form that answers a regulator’s question in an afternoon rather than a fortnight. SDAIA’s AI ethics principles ask for accountability and transparency from deployed systems, and NCA controls ask for logging and monitoring; a residency log is where those requirements and the residency requirement meet. If the only way to answer "when did this system last send data outside the Kingdom" is to open five dashboards and write to two vendors, the answer is that nobody knows.

The deployment pattern that answers all of this cleanly is an open-weight model served on infrastructure inside the Kingdom, on the organisation’s own hardware or in one of the in-country cloud regions now available, with the retrieval index, the logs and the backups held in the same boundary and vendor access limited to what a support contract explicitly grants. It costs more to operate than a hosted API. The evaluation that precedes it should say so, and should say equally when a hosted API is the better answer for a workload whose data permits it. Sovereign deployment is a tool for a classification level, and it is worth paying for where that level applies.

None of this stays settled. Vendors move regions and change terms, integrations are added by people who were not at the original review, and a contract that was compliant when signed can be undermined by a product update on the other side. Residency is an operating discipline with a re-verification cadence, a named owner, and a trace that is repeated whenever a component changes. Treated that way it becomes unremarkable: a review that runs on a schedule, a log that already exists, and an answer that is ready before the regulator asks for it.