Your AI Stack Is a Cross-Border Transfer (PDPL)

A Saudi retailer wires a support assistant to their helpdesk. Tickets go to an LLM API in Virginia, the model drafts a reply, an agent approves it. Ship it on a Thursday, measure the deflection rate on Sunday, and it works.

It is also, under the Personal Data Protection Law, a cross-border transfer of personal data — with no legal basis, no risk assessment, and no contractual safeguard. Nobody in the room called it that, because it did not look like a data transfer. It looked like an API call.

That gap is the most common compliance failure we see in AI projects in the Kingdom, and 2026 is the year it stopped being theoretical. SDAIA's grace periods have expired. The authority has issued 48 formal enforcement decisions across multiple sectors, with administrative fines reaching SAR 5 million per violation and doubling on repeat.

Why an API call is a transfer

PDPL does not care about your architecture diagram. It cares about whether personal data relating to individuals in the Kingdom left it.

Article 3 gives the law extraterritorial reach that is broader than the GDPR's: it applies to the processing of personal data of residents of Saudi Arabia by entities located outside the Kingdom. Your model provider does not escape by being in another jurisdiction. You do not escape by pointing at them.

So the question for any AI feature is mechanical: does the payload leaving your infrastructure contain personal data? For most real deployments the answer is yes, and it arrives through channels teams forget to audit:

• Prompt content — the support ticket, the CV, the medical intake note, the customer's name in the chat history
• Retrieval context — the RAG chunks your vector store injects, which came from documents nobody classified
• Tool call arguments — an agent passing a national ID into a lookup function, then into the model's context
• Logs and traces — the observability layer that quietly stores full prompts on a foreign SaaS for 30 days
• Fine-tuning datasets — the most permanent transfer of all

Notice how many of these are not the model call itself. The model vendor is usually the one relationship that got a contract review. The tracing tool, the eval platform, the vector database and the prompt-management SaaS usually did not.

What the Transfer Regulation actually requires

The August 2024 Regulation on Personal Data Transfer Outside the Kingdom is the operative text, and it is more structured than most teams assume.

A transfer needs a permitted purpose under Article 29(1): performing obligations under an agreement to which the Kingdom is party, serving the Kingdom's interests, performing obligations to a data subject who is party to an agreement, or one of the purposes defined in Article 2 of the Regulation — centralised processing operations, providing a service or benefit to the data subject, and scientific research.

It then needs three additional conditions to hold simultaneously: the transfer must not prejudice national security or the Kingdom's vital interests, the recipient jurisdiction must offer an adequate level of protection as determined by SDAIA, and only the minimum necessary data may move.

Adequacy is where AI teams get stuck. SDAIA has not published its approved-jurisdictions list. Practitioners default to jurisdictions the European Commission recognises as adequate under the GDPR — which does not include the United States, where most frontier model inference runs.

When adequacy or minimisation cannot be satisfied, the Regulation offers three safeguards, each requiring a transfer risk assessment under Article 7 (SDAIA published its Risk Assessment Guideline in February 2025):

Two clauses matter more than the rest for AI work. Transfers of sensitive data — health, biometric, genetic, religious or political belief, criminal conviction — are generally prohibited under the service-benefit and research routes entirely. And the data-minimisation condition is not a principle to gesture at; it is an enforceable requirement to strip what you do not need before it crosses the boundary.

The architecture: put the boundary in your own code

The compliant pattern is not "stop using foreign models." It is to make the border a real, single, auditable place in your system rather than an accident distributed across forty call sites.

In practice that means an egress gateway that every AI call routes through, doing four jobs:

// One boundary. Every model call goes through it.
async function callModel(input: ModelRequest, ctx: RequestContext) {
  // 1. Classify — what is actually in this payload?
  const classified = classify(input.messages);
  if (classified.hasSensitive) {
    // Health, biometric, genetic, belief, conviction data:
    // route to in-Kingdom inference or refuse. Never SCC your way out.
    return routeToRegionalModel(input, ctx);
  }
 
  // 2. Minimise — tokenise identifiers before they leave
  const { payload, vault } = tokenise(classified, [
    "national_id", "iqama", "phone", "iban", "full_name", "email",
  ]);
 
  // 3. Transfer under a recorded basis
  const res = await provider.complete(payload, {
    transferBasis: ctx.transferBasis,   // Art. 29(1) purpose, on the record
    zeroRetention: true,                // no vendor-side training or storage
  });
 
  // 4. Re-identify inside the Kingdom, log the metadata not the content
  audit.record({
    basis: ctx.transferBasis, destination: provider.region,
    fieldsTokenised: vault.keys(), sensitive: false, at: ctx.now,
  });
  return detokenise(res, vault);
}

The tokenisation step is the one that pays for itself. A support ticket with the customer's name replaced by PERSON_1 and the Iqama replaced by ID_1 is materially less personal data crossing the border, and the model's answer quality does not change — LLMs reason about roles, not identities. It converts an unbounded transfer into a minimised one, which is precisely the Article 29 condition you otherwise cannot meet.

Four more decisions follow from having a single boundary:

Turn off retention everywhere, in writing. Zero-retention API tiers exist at every major provider. Enable them, and get it into the contract — not the marketing page. A 30-day vendor-side log is a transfer you did not assess.

Audit the second tier. Your tracing, eval, prompt-management and vector infrastructure are data processors with the same obligations and a fraction of the scrutiny. If your observability vendor stores full prompt bodies outside the Kingdom, that is a transfer.

Keep the record before you need it. Registration on SDAIA's National Data Governance Platform is mandatory for controllers conducting cross-border transfers or processing sensitive data, and a DPO is mandatory where large-scale processing is a core activity. Breach notification is 72 hours. If SDAIA raises a violation notice, the window to respond formally through the portal is five days — which is not enough time to build a transfer register from scratch.

Split the model tier by data class. Most AI workloads do not need frontier capability on personal data. Sensitive and identified data goes to in-Kingdom or self-hosted inference; anonymised and general workloads go wherever they perform best. That is a routing decision, and it is far cheaper to make once at the gateway than to retrofit per feature.

What this costs if you skip it

The honest tally is not the SAR 5 million ceiling. It is that AI features get built, reach pilot, then stall at the security review with no path forward — because the data flows were designed before anyone asked where they terminated, and unpicking them means rewriting the integration layer.

We see this most often on systems that were never designed for an AI consumer at all: an ERP with a reporting layer bolted on, a helpdesk with an export job, a CRM whose API returns the full customer record because that is the only endpoint there is. The AI project inherits every over-broad field. The integration layer is where this gets fixed — and it is the same reason replacing the ERP is almost never the right answer.

The rest of the discipline is familiar if you have thought about agent identity and non-human IAM: scope what the machine can reach, record what it did, and assume you will have to prove both. PDPL just adds a geography to the question. If you are also weighing where inference should physically run, the sovereign cloud picture across MENA is moving fast enough to change the answer within a year.

Start with the map, not the policy

Before writing a single policy document, produce one artefact: a table of every AI-touching data flow, with the destination country, the categories of personal data in the payload, the retention on the far side, and the Article 29 purpose you would cite. Most teams find it takes an afternoon and surfaces three flows nobody knew about — typically a tracing tool, a spreadsheet export, and one integration built during a pilot that quietly went to production.

That table is your transfer register, your risk-assessment input, and your architecture backlog in a single page. Everything else — SCCs, tokenisation, regional routing — is downstream of knowing what actually leaves.

Not sure what your AI features are sending abroad? We map AI data flows against PDPL transfer conditions and hand back the register plus the integration changes needed to close the gaps — no policy templates, just the architecture. Tell us what you are running and we will scope it.