Saudi PDPL for AI systems: a checklist for banks

Saudi banks are adopting AI for document review, customer service, credit decisions and internal knowledge search. Every one of those systems touches personal data, and since 14 September 2024 the Personal Data Protection Law (PDPL) has been fully enforceable. By mid-January 2026, the Saudi Data and Artificial Intelligence Authority (SDAIA) had announced 48 enforcement decisions.

The law was not written with large language models in mind, but it applies to them in full. Article 1 defines processing as any operation on personal data “whether manual or automated”, which covers sending a customer record to a model, storing it in a vector database or writing it to a trace log.

This is the checklist we use when we design AI systems for Saudi banks and finance companies. Each item points to the article it comes from and says how to check it. It is a practical engineering guide, not legal advice. Your legal and compliance teams, and the Saudi Central Bank’s own rules, have the final word.

1. Map every place personal data enters the AI system

Personal data in an AI system rarely sits in one table. It appears in source documents, prompts, retrieved passages, model outputs, vector embeddings, evaluation sets, caches and trace logs. Each of these is processing under Article 1, and each needs an owner, a purpose and a retention rule.

How to check: pick one customer and trace where their data could appear across the whole pipeline, including logs and evaluation data. If nobody can answer for a location, it is not under control.

2. Confirm the legal basis before the build

Consent is the default basis under Article 5. Article 6 lists the exceptions, including processing required by another law or under an agreement the customer is party to, and the controller’s legitimate interest. Legitimate interest cannot be used for sensitive data, which Article 1 defines to include health data, biometric data and data about criminal convictions.

How to check: for each AI use case, write down the legal basis and whether any sensitive data is involved. A use case that relies on legitimate interest and touches sensitive data needs a different basis.

3. Run the impact assessment before launch, not after

Article 22 requires the controller to conduct an impact assessment of personal data processing for any product or service, according to the nature of the activity. An AI system that reads customer documents or influences a decision about a customer is exactly the kind of product this covers.

How to check: the assessment exists, names the AI components explicitly (model, retrieval, logging), and was signed off before the system went live.

4. Know where the model runs, because that decides whether data leaves the Kingdom

Sending a customer record to a hosted model API outside Saudi Arabia is a transfer of personal data outside the Kingdom. Article 29 allows transfers only for specific purposes and on conditions: the transfer must not prejudice national security or the Kingdom’s interests, the destination must offer an adequate level of protection, and the data sent must be limited to the minimum needed. The Implementing Regulations and SDAIA’s transfer guidelines add the detail, including risk assessments for transfers that rely on safeguards or involve sensitive data at scale.

The simplest way to avoid the question is not to transfer at all. Open-weight models can run inside a Saudi cloud region or on the bank’s own servers, so prompts and documents never leave the Kingdom.

How to check: list every model, embedding service, vector database and tracing tool the system calls, and where each one physically processes data. Any location outside the Kingdom needs a documented Article 29 basis.

5. Send the model the minimum, and redact the rest

Article 29 requires transfers to be limited to the minimum personal data needed, and the same principle is good design everywhere. Most AI tasks do not need a customer’s name, national ID or account number to summarize a policy or classify a request.

How to check: identify the personal fields each prompt actually needs. Confirm that the others are removed or masked before the model call, and that the masking is enforced in code rather than by a prompt instruction.

6. Treat logs, traces and evaluation sets as personal data

Observability tools record full prompts and responses, which means they hold the same personal data as the system itself. Evaluation sets built from real cases do the same. They need the same access control, retention and location rules as the production data, and Article 19 requires the controller to protect personal data with organizational, administrative and technical measures, including during transfer.

How to check: find where traces and evaluation data are stored, who can read them, and when they are deleted. If the tracing service is hosted outside the Kingdom, it is a transfer under item 4.

7. Be able to find and act on one person’s data

Article 21 requires controllers to respond to data subject requests within the periods the Regulations set. In an AI system, a customer’s data may sit inside chunked documents and vector embeddings as well as in ordinary tables.

How to check: given a customer identifier, can you list every document, chunk and embedding derived from their data, and delete or correct it? Test this before launch, not when the first request arrives.

8. Rehearse the breach notification

Article 20 requires the controller to notify SDAIA of any breach, damage or illegal access to personal data, and to notify affected customers where it could harm them. Under the Implementing Regulations, notice to SDAIA is due within 72 hours of becoming aware of the breach. For an AI system, a breach includes a prompt or retrieval flaw that exposes one customer’s data to another user.

How to check: run a tabletop exercise for an AI-specific incident, such as a chatbot returning another customer’s account details, and time how long it takes to establish what was exposed and to whom.

9. Apply the extra rules for credit data

Article 24 sets additional controls for credit data, including verifying the customer’s explicit consent for collection, changes of purpose and disclosure, and notifying the customer when another entity asks for their credit data. Credit scoring, collections and lending assistants all process credit data.

How to check: trace how consent for credit data is captured and verified before the AI system uses it, and confirm disclosure requests trigger a customer notification.

10. Remember the Saudi Central Bank’s rules sit on top

Article 30 makes SDAIA the authority overseeing the PDPL, “without prejudice to” the powers of the Saudi Central Bank (SAMA). For banks, SAMA’s own requirements on cyber security, outsourcing and cloud use apply alongside the PDPL and often go further, particularly on where data may be hosted.

How to check: your AI system’s architecture review covers SAMA’s applicable frameworks as well as the PDPL, with the bank’s compliance team confirming which ones apply.

11. Keep a person accountable for compliance decisions

AI can find gaps and draft fixes, but it should not decide what is compliant. Design an explicit approval step so a qualified reviewer signs off any remediation before it is used, and record who approved what.

How to check: pick a recent AI-drafted output and confirm you can see who reviewed it, when, and what they changed.

12. Keep the evidence

When SDAIA or an auditor asks how a decision was reached, the answer has to come from records, not memory. Version the prompts and models, trace every model call against the version used, and keep the gap reports and approvals.

How to check: for any AI output from the last month, reproduce which model, prompt version and source documents produced it.

The penalties are real

Under Article 36, violations can bring a warning or a fine of up to SAR 5 million, which can be doubled for repeat violations. Article 35 adds a criminal offence for disclosing or publishing sensitive data with intent to harm or for personal benefit, punishable by up to two years in prison, a fine of up to SAR 3 million, or both.

How we apply this

We built an AI compliance platform for Saudi PDPL that is in production with Saudi banks and finance companies. It scores each document’s gaps against PDPL and the client’s internal compliance framework, drafts compliant replacements for review, and runs on open-weight models so the deployment can be designed around where data is allowed to go.

If you are planning an AI system that will touch customer data in the Kingdom, our AI for compliance work starts with a fixed-scope AI readiness assessment that maps these twelve items against your actual architecture.

Sources: the official PDPL text published by SDAIA; Clyde & Co summaries of the Implementing Regulations, transfer risk assessment guidelines and enforcement to date.