How to Comply with Saudi AI Policy and PDPL

Saudi Arabia has built one of the most comprehensive AI governance and data protection frameworks in the developing world. The Saudi Personal Data Protection Law (PDPL), SDAIA’s AI ethics guidelines, and a growing body of sector-specific rules create a compliance environment that is genuinely complex — but also well-structured and increasingly predictable for organizations that engage with it systematically.

This guide is written for compliance officers, legal counsel, and technology executives who need to understand the Saudi regulatory environment and build a compliance program that works in practice.

The Foundation: Saudi Personal Data Protection Law (PDPL)

Legislative History and Authority

The PDPL was enacted by Royal Decree M/19 in September 2021 and came into force on September 14, 2023. It was amended in 2023 to address implementation feedback and align more closely with GDPR concepts. SDAIA (Saudi Data and Artificial Intelligence Authority) serves as the primary enforcement authority, with its National Data Management Office (NDMO) acting as the data protection supervisory body.

The PDPL is Saudi Arabia’s first comprehensive data protection law, replacing a fragmented set of sector-specific rules that had governed data use in healthcare, finance, and telecommunications. All prior sector-specific rules remain in force but the PDPL sets minimum standards that apply across all sectors.

Who Must Comply

The PDPL applies to:

  • Any processing of personal data of individuals located in Saudi Arabia, regardless of where the processing entity is located
  • Saudi entities processing personal data anywhere in the world
  • Non-Saudi entities that offer goods or services to Saudi residents or monitor the behavior of Saudi residents

This extraterritorial scope means a US-based SaaS company with Saudi customers is subject to PDPL even with no Saudi physical presence. Saudi enforcement of extraterritorial provisions is still developing, but major international operators should structure compliance proactively.

Core Definitions

Personal Data: Any information that identifies, directly or indirectly, a natural person. Includes names, ID numbers, location data, online identifiers, and any combination of data that can identify an individual.

Sensitive Personal Data (requiring heightened protection): Health and medical data, genetic and biometric data, financial data, credit and banking data, data revealing racial or ethnic origin, religious beliefs, political opinions, criminal records, and data of minors.

Data Controller: Entity that determines the purposes and means of processing personal data.

Data Processor: Entity that processes personal data on behalf of a controller.

Processing: Any operation on personal data — collection, recording, storage, use, transfer, modification, deletion.

Legitimate Processing Bases

Unlike GDPR (which has six lawful bases), the PDPL defines four legitimate bases for processing personal data:

  1. Consent: The data subject has given explicit, informed, specific consent to the processing. Consent must be freely given; pre-checked boxes or bundled consent with terms of service do not comply.

  2. Contract: Processing is necessary for the performance of a contract with the data subject or to take pre-contractual steps at the data subject’s request.

  3. Legal Obligation: Processing is required to comply with Saudi law.

  4. Vital Interests: Processing is necessary to protect the vital interests of the data subject or another person in an emergency situation.

Key PDPL difference from GDPR: PDPL does not include “legitimate interests” as a processing basis. This is significant for AI applications that rely on legitimate interests under GDPR — those use cases need to be mapped to one of the PDPL’s four bases in Saudi Arabia. For many AI analytics, profiling, and behavioral analysis use cases that rely on GDPR’s legitimate interests, PDPL compliance requires either securing explicit consent or structuring the processing as a contractual or legal obligation.

Data Residency Requirements

The PDPL’s data residency provisions are the most operationally impactful requirement for AI applications processing Saudi personal data.

The Residency Rule

Article 29 of the PDPL prohibits the transfer of personal data outside Saudi Arabia except where:

  1. The transfer is to a country that provides an adequate level of personal data protection as determined by SDAIA
  2. Adequate contractual safeguards have been implemented (standard contractual clauses approved by SDAIA)
  3. The transfer is necessary for the performance of a contract to which the data subject is a party
  4. The transfer is in the vital interest of the data subject in an emergency
  5. SDAIA has granted specific authorization for the transfer

SDAIA’s Adequacy Assessments: As of 2025, SDAIA has published adequacy assessments for a limited number of countries. The assessment process is slower than the GDPR adequacy decision process — most countries used by global cloud providers have not yet been assessed. This effectively means that for most international data transfers, organizations must rely on contractual safeguards (the SCCs pathway) or SDAIA-specific authorizations.

Practical compliance for AI applications: If your AI system collects and processes personal data of Saudi residents:

  • Primary storage must be in KSA or an SDAIA-approved country
  • Model training on Saudi personal data must occur on KSA-resident or approved infrastructure
  • Inference calls that include personal data cannot be routed through non-approved countries without SDAIA contractual safeguard approval
  • Log data containing personal data (user queries, behavioral data) must be stored in KSA

Approved infrastructure: AWS Saudi Arabia (Riyadh), Microsoft Azure Saudi North (Riyadh), Google Cloud Saudi Arabia (Dammam), and STC Cloud (Riyadh) are all acceptable for PDPL residency compliance for personal data storage and processing. AWS Bahrain is conditionally acceptable for processing (not storage) if supported by contractual safeguards.

SDAIA as Enforcement Authority

SDAIA’s NDMO is operationally responsible for PDPL enforcement. Understanding how SDAIA approaches enforcement is important for compliance program calibration.

Current Enforcement Posture

SDAIA has taken a graduated approach to enforcement since the law came into force in September 2023:

  • First 12 months (September 2023–August 2024): Primarily educational and guidance-focused; few formal enforcement actions
  • From 2024 onward: Increasingly active; investigations following major data incidents; formal notices to non-compliant entities

SDAIA has published sector-specific implementation guidelines for healthcare, financial services, and e-commerce. These guidelines are binding interpretation of the PDPL for covered sectors and must be incorporated into compliance programs.

How to Register and Notify SDAIA

Data Controllers must:

  1. Register with SDAIA’s Personal Data Protection Registry within 90 days of commencing processing operations in Saudi Arabia
  2. Designate a Data Protection Officer (DPO) for large-scale processing or sensitive data processing operations
  3. Maintain a Record of Processing Activities (ROPA) in Arabic and English
  4. Report personal data breaches to SDAIA within 72 hours of discovery (for breaches that may cause harm to data subjects)

Penalties

PDPL penalties are structured as:

Violation Type Maximum Penalty
Processing without consent or legal basis SAR 5 million ($1.33M)
Unauthorized cross-border transfer SAR 5 million ($1.33M)
Failure to implement data security measures SAR 3 million ($800K)
Failure to notify data breach SAR 2.5 million ($667K)
Failure to register or appoint DPO SAR 1 million ($267K)
Violation of data subject rights SAR 1 million ($267K)

Penalties can be doubled for repeat violations. Criminal prosecution (for willful violations) can result in imprisonment in addition to financial penalties.

AI Impact Assessment Requirements

SDAIA’s AI Ethics Principles (published 2022, updated 2024) and the emerging AI Governance Framework require AI Impact Assessments (AIIA) for high-risk AI applications. This is Saudi Arabia’s equivalent of the EU AI Act’s Fundamental Rights Impact Assessment, though implemented through SDAIA guidance rather than formal legislation as of 2025.

What Triggers an AIIA

High-risk AI applications requiring formal assessment include:

  • AI systems making or assisting in decisions that materially affect Saudi residents (credit scoring, hiring, benefits eligibility, criminal risk scoring)
  • AI systems processing sensitive personal data at scale
  • AI systems deployed by government entities for public administration
  • AI systems in healthcare diagnostics or treatment recommendation
  • AI systems in financial services fraud detection and compliance

AIIA Process

A standard AIIA covers:

  1. System description: Purpose, intended use, user base, training data description
  2. Risk identification: List of ways the system could cause harm to individuals or groups (bias, error, privacy violation, security vulnerability)
  3. Risk assessment: Likelihood and severity for each identified risk
  4. Mitigation measures: Technical and organizational controls to reduce each risk
  5. Residual risk acceptance: Documented decision that residual risks are acceptable
  6. Monitoring plan: Ongoing performance monitoring to detect emerging harms

SDAIA reviews AIIAs for government-deployed systems. For private sector AI applications, the AIIA is primarily an internal governance document, though SDAIA may request it during an investigation.

Government AI Procurement Requirements

If you are selling AI solutions to Saudi government entities — ministries, SOEs, PIF portfolio companies — you face additional compliance requirements beyond PDPL.

Nitaqat for Saudi Employees

Saudi government procurement contracts include Saudization (Nitaqat) requirements. AI service contracts typically require:

  • Minimum 5–15% of team members on the contract to be Saudi nationals (varies by contract size and sector)
  • Saudi nationals must be in substantive roles (not administrative-only)
  • Proof of Saudization compliance at contract award and annually during performance

Non-compliance with Nitaqat is grounds for contract termination and can result in prohibition from future government procurement.

Saudi Content Requirements

Beyond Saudization, government procurement increasingly applies Saudi content requirements under the Saudi Content Program (managed by the Local Content and Government Procurement Authority — LCGPA). AI solutions procured by government must demonstrate:

  • Data processing occurring on Saudi-resident infrastructure (satisfies both PDPL and local content requirements)
  • Software development activity in Saudi Arabia (counting toward local content percentage)
  • Use of Saudi-registered subcontractors where applicable

Local content compliance is scored on the Saudi Content Index, and companies with higher scores receive preference in bid evaluation.

Sector-Specific Rules

Health Data

Health data is classified as sensitive personal data under PDPL with enhanced protections. Additionally, the Ministry of Health (MoH) and Saudi Health Council have issued specific regulations:

  • Health data must be stored in MoH-approved healthcare data centers
  • AI applications accessing patient records require clinical safety evaluation under Saudi Health Council guidelines
  • Secondary use of health data for AI training requires either patient consent or ethics board approval from a Saudi Institutional Review Board (IRB)
  • Telemedicine AI applications require SFDA (Saudi Food and Drug Administration) medical device registration if making diagnostic suggestions

Financial Data

The Saudi Central Bank (SAMA) governs data practices for licensed financial institutions. Key requirements for AI applications in financial services:

  • SAMA’s Open Banking Framework governs data sharing between banks; AI applications consuming open banking APIs must be SAMA-registered
  • Credit scoring AI must demonstrate fairness (no proxy discrimination) and explainability sufficient for adverse action notices to consumers
  • SAMA’s Cybersecurity Framework requires risk assessments and penetration testing for AI systems processing financial data
  • AI-generated investment advice may trigger Capital Market Authority (CMA) licensing requirements depending on how advice is framed

Telecom Data

Communications and call record data is regulated by the Communications, Space and Technology Commission (CST). AI applications using telecom subscriber data or call metadata must comply with CST’s data handling guidelines, which include additional restrictions on retention periods and third-party sharing beyond PDPL’s baseline requirements.

Building a Compliance Program: Practical Steps

A compliance program for Saudi AI policy should be built in this sequence:

Step 1: Data Mapping (Months 1–2) Document all personal data flows: what data you collect, from whom, for what purpose, where it is stored, who can access it, and where it is transferred. Saudi personal data must be identified and tagged explicitly.

Step 2: Legal Basis Assessment (Month 2–3) For each processing activity, confirm the applicable PDPL legal basis. Identify any activities currently relying on legitimate interests (which does not exist under PDPL) and restructure to consent, contract, or legal obligation.

Step 3: Infrastructure Assessment (Month 2–3) Confirm that all Saudi personal data storage and processing is occurring on PDPL-compliant infrastructure. Identify any non-compliant infrastructure and plan migration.

Step 4: SDAIA Registration (Month 3) Register with SDAIA’s Personal Data Protection Registry. Appoint a DPO if required. Establish breach notification procedures.

Step 5: AI Impact Assessments (Month 3–6) Conduct AIIAs for high-risk AI applications. Document findings and mitigation measures. Establish ongoing monitoring.

Step 6: Consent and Notice Infrastructure (Month 4–6) Update privacy notices to PDPL requirements (Arabic-language notice required for Saudi residents; plain language; specific to each processing purpose). Build consent management infrastructure for consent-based processing.

Step 7: Data Subject Rights Procedures (Month 5–6) Establish processes for: access requests (data subjects can request a copy of their data), correction requests, deletion requests (“right to be forgotten” exists under PDPL but with limitations), and objection to processing. PDPL requires response within 30 days.

Step 8: Vendor Management (Month 4–6) Update data processing agreements with all vendors who process Saudi personal data. Ensure data residency obligations flow down to processors. For cloud providers, confirm Saudi-resident deployment.

Step 9: Staff Training (Month 6) All staff handling Saudi personal data must receive PDPL training. Arabic-language training modules are available through SDAIA’s training portal. Training records must be maintained.

Step 10: Annual Review and Audit (Ongoing) Conduct an annual PDPL compliance review. SDAIA periodically issues updated guidance; compliance programs must track and incorporate new requirements. Consider engaging a Saudi-licensed law firm for annual compliance audits — SDAIA views organizations with independent audit programs more favorably in enforcement contexts.

PDPL compliance is not a one-time project — it is an operational function that must evolve as your Saudi AI applications grow in scope and as SDAIA’s enforcement guidance matures. Organizations that invest in genuine compliance programs, rather than checkbox exercises, build a competitive advantage in Saudi government and enterprise procurement, where PDPL compliance is increasingly evaluated as part of vendor due diligence.