Saudi PDPL AI Controls Mapping: Each Obligation Against the Control That Satisfies It

Saudi Arabia is the only major jurisdiction where the data protection regulator and the national AI authority are the same body. SDAIA supervises the Personal Data Protection Law, issued the Implementing Regulations on 7 September 2023, and publishes the Kingdom's AI ethics principles and generative AI guidance. An organisation running AI on personal data in the Kingdom is being examined by one authority against both.

The transition period closed on 14 September 2024, and SDAIA's specialised committees have since issued 48 decisions confirming violations, concentrated on legal basis, unauthorised disclosure, absent safeguards, and marketing without consent.

I want to map the operative obligations to controls for an organisation deploying AI rather than building models, because the deployer's exposure sits in different places than a developer's, and most mappings published for this regime are written from a generic privacy template with AI bolted on at the end.

Legal basis and purpose limitation

The PDPL requires a lawful basis per processing activity. The 2023 amendments added legitimate interest for non-sensitive data alongside consent, contractual necessity, and legal obligation, and processing must stay within the purpose it was collected for.

Two separate controls sit under this obligation. The first is documentary: an activity-to-basis register, with a balancing assessment where legitimate interest is relied on. The second is enforcement, and it exists because AI breaks purpose limitation quietly. Customer records held under a documented basis get routed through a summarisation tool nobody assessed, and the processing activity changes while the register does not. A destination policy that permits specific data classes to specific endpoints, evaluated per request, is the control that keeps the two aligned. The register is owned by privacy, and the enforcement by platform.

Records of processing activities

Controllers must maintain a RoPA and produce it to SDAIA on request, covering purposes, categories of data subjects and personal data, recipients, cross-border transfers, and retention periods.

The recipients and transfers fields are where an interview-built RoPA diverges from what is happening. Interviews return the providers people remember. Observed egress to model endpoints returns the providers in use, and reconciling the two is a discovery exercise most organisations have never run. The control is an observed destination inventory feeding the register, and the same problem appears under an asset heading as shadow AI discovery.

Impact assessment

The Implementing Regulations require assessing the impact of processing personal data for products and services offered to the public, and for processing that carries heightened risk. A customer-facing AI system meets that trigger.

This control is documentary and dated, and no component on the request path produces it. What architecture supplies is the input: the data classes actually flowing, the destinations actually reached, and the region each sits in. An assessment written from an architecture diagram describes the intended system, and the useful version describes the deployed one.

Cross-border transfer

Transfer of personal data outside the Kingdom is governed by a regime issued alongside the Implementing Regulations and amended in 2024, permitting transfer for specified purposes subject to conditions, including a risk assessment where an adequate level of protection has not been established for the destination.

AI traffic differs from ordinary SaaS here in a way worth stating plainly. A hosted model endpoint sits in a foreign region by default, and the transfer occurs per request rather than per contract. Contractual controls settle whether transfer is permitted. Only a per-request control settles whether a given payload went to a permitted region, and only a per-request record evidences it afterwards.

Safeguards

Absent technical and organisational safeguards recurred across the 48 decisions. Applied to AI traffic, the standard estate does not reach the payload: network data-loss prevention runs underneath TLS to a provider API, and document classification reads a file rather than a context window assembled from several systems.

The control is classification on the request, with per-role and per-route policy and a fail-closed default. Only 37% of organizations have any detection or governance policies in place for AI usage, according to Netwrix, which sets a realistic expectation for a first assessment against this obligation.

Breach notification

Controllers must notify SDAIA within 72 hours of becoming aware of a breach that may cause harm to the personal data or the data subject, and inform affected individuals without delay, on a clock that runs continuously.

The control is a record that lets you characterise harm inside three days: the data classes present in the affected requests, the volume, the destinations, and the individuals implicated. An organisation reconstructing that from application logs during the notification window has already lost most of it.

The mapping

Five Full, one Partial, six None. A mapping that turned all twelve green would be the more persuasive document and the less useful one, since six of these rows are the ones SDAIA's committees have actually been issuing decisions about.

Why the penalty structure changes the priority order

Administrative fines reach SAR 5 million for general violations and double for repeat offences. Disclosure of sensitive personal data with intent to harm or for personal benefit carries criminal exposure: up to two years imprisonment and a fine of up to SAR 3 million, doubling on repeat.

That criminal limb attaches to disclosure, and a prompt carrying sensitive personal data to a foreign model endpoint is a disclosure. Nobody is suggesting an employee summarising a patient file intends harm. The point is that the highest-consequence provision in this law reaches the exact action AI tools make frictionless to perform and nearly impossible to observe after the fact.

My candid view: the row most organisations will get wrong is transfer enforcement, and they will get it wrong because they solved it at the contract layer and stopped. A data processing agreement with a provider establishes that transfer is permitted. It says nothing about which endpoint the SDK actually resolved to when a developer changed a base URL in a config file. The transfer happens per request, so the control has to be evaluated per request. The same structural point applies under Japan's APPI, where cross-border rules also attach to the transfer rather than to the agreement.

DeepInspect

This is the enforcement point behind the five rows marked Full. DeepInspect sits inline between your users or agents and the LLM APIs they call, as a stateless proxy the calling application has no custody over. For every request and response it evaluates identity, data classification, model authorization, and organizational policy, and makes a pass or block decision before the traffic reaches the model.

Against this mapping it fills purpose limitation with per-request destination policy, the RoPA recipient fields with an inventory built from observed egress rather than interviews, transfer enforcement with region-aware routing evaluated per call, safeguards with classification inside the context window and a fail-closed default, and the 72-hour notification row with a signed, tamper-evident record carrying the payload classes, volume and destinations. The register, the impact assessment, the DPO appointment and the platform registration stay with your privacy function. Book a technical deep dive at deepinspect.ai.