PDPL in 2026: what changed for AI vendors

Context: PDPL isn’t new — but its regulatory perimeter is moving

The law was issued by Royal Decree M/19 of 2021⁴. The first Implementing Regulations followed in 2023. The PDPL entered into force on 14 September 2023, with a one-year grace period running to 14 September 2024¹. Since 14 September 2024, SDAIA (Saudi Data and Artificial Intelligence Authority), as regulator, has had full authority to levy fines and refer matters for criminal prosecution.

In 2025 the regulatory perimeter moved on two distinct tracks:

• February 2025 — SDAIA issued the Risk Assessment Guideline for Transferring Personal Data Outside the Kingdom, formalizing the pre-transfer assessment expected for cross-border flows⁵.
• May 2025 — SDAIA opened a public consultation on proposed amendments to the Implementing Regulations; the consultation closed on 27 May 2025. The proposed amendments would simplify Records of Processing Activities, soften the blanket foreign-vendor local-representative obligation, and adjust other operational requirements — but as of the date of this article these amendments are not yet enacted, and the 2023 Implementing Regulations remain the operative text on those points².

Anyone serving a Saudi customer in 2026 needs to read both tracks through an AI-vendor lens — which is what this piece does.

Axis 1: cross-border transfer — Article 29 framework

PDPL Article 29, the Transfer Regulations, and SDAIA’s February 2025 Risk Assessment Guideline together set the cross-border framework⁵⁶. The structure is not a flat list of four “lawful bases” borrowed from GDPR — it is layered:

1. A Permitted Purpose (Article 29(1)): performance of an obligation under an international agreement to which Saudi Arabia is a party; serving the interests of the Kingdom; performance of an obligation to which the data subject is a party; or another purpose specified in the Transfer Regulations.
2. Additional Conditions: no prejudice to national security; recipient-jurisdiction adequacy assessment; data minimization to what is necessary for the purpose.
3. Appropriate Safeguards where adequacy is absent: Saudi Standard Contractual Clauses (SCCs), Binding Common Rules (BCRs), or a Certificate of Accreditation⁶.

Explicit data-subject consent retains a role for sensitive and credit-related data but is not an independent flat substitute for the Article 29 architecture.

Practically for an AI vendor: an API call to OpenAI or Anthropic from a Saudi application carrying personal data of a Saudi resident is a cross-border transfer. You need (i) a permitted purpose, (ii) the additional conditions met, and (iii) the appropriate safeguard (SCC / BCR / accreditation) plus the pre-transfer risk assessment.

Comparison to GDPR:

Practical takeaway: treat in-Kingdom processing as the default architecture. Cross-border is the exception that needs documentation — permitted purpose, safeguard mechanism, and risk assessment — from day one.

Axis 2: data-subject rights

PDPL recognizes a broader set of data-subject rights than the four most commonly listed in commentary. The rights include⁷:

1. Right to be informed — about processing purposes, categories, and parties
2. Right of access — to know what’s being processed
3. Right to obtain a copy — of personal data in a structured form
4. Right to rectification — to correct inaccurate data
5. Right to deletion — to have data erased (with limited legal exceptions)
6. Right to object to processing — including automated processing and automated decision-making

For an AI vendor, the operationally hardest rights are deletion and objection:

• Deletion after model training: can you remove an individual’s contribution from a trained model? The practical answer is per-record provenance plus a periodic retraining policy that excludes deleted items — or machine unlearning if you can carry the cost.
• Objection to automated decisions: if your model produces a decision affecting a data subject (loan approval, CV screening, insurance pricing), you must provide a human-review path.

Timing: the Implementing Regulations require controllers to respond to a data-subject request within 30 days⁸, with an extension possible on justification and prior notice (e.g., disproportionate effort or multiple requests). For a B2B AI vendor this means a contractual SLA with the customer that’s shorter than 30 days — usually 14–21 — so the customer can meet its own deadline.

Axis 3: when a DPIA is required

PDPL Article 22 and the Implementing Regulations mandate a Data Protection Impact Assessment before processing that may pose risk to data-subject rights⁹. For AI vendors, the most common triggers:

• Processing of sensitive data at scale (health, financial, biometric)
• Automated decision-making with legal or similar significant effect (credit scoring, hiring screening)
• Systematic monitoring of public areas (CCTV + face recognition)
• Large-scale processing of minors’ data
• Linking datasets from multiple sources in a way that may identify individuals
• Use of novel technologies with under-studied risks (much LLM deployment lands here)

A DPIA must contain at minimum:

dpia_minimum_contents:
  - Description of processing (purposes, data categories, subject categories)
  - Necessity and proportionality assessment
  - Risk assessment to data-subject rights
  - Mitigating measures (technical + organizational)
  - DPO consultation (if appointed)
  - Data-subject consultation (where feasible)
  - Periodic review

The absence of a DPIA for triggering processing isn’t only a gap — it’s a separately sanctionable violation under Article 22.

Axis 4: 72-hour breach notification

Per SDAIA’s Personal Data Breach Incidents Procedural Guide¹⁰:

• Notify SDAIA: within 72 hours of becoming aware of the breach
• Notify affected data subjects: “without undue delay” where the breach results in damage to their data or conflicts with their rights and interests. Unlike GDPR, PDPL contains no materiality-threshold exception to the obligation to notify data subjects¹⁰.

Minimum content of the notification:

• Nature of the breach and data categories
• Number of affected data subjects
• Likely consequences
• Measures taken or proposed
• Contact details (DPO or contact point)

For an AI vendor acting as a sub-processor, the 72 hours runs from the controller’s awareness — that’s your customer. This implies a contractual obligation to notify the customer within 24–48 hours so they can meet the 72.

Practical: an incident-response team with a PDPL-specific playbook, plus a pre-agreed notification channel with every Saudi customer. Don’t try to draft a notice after the incident.

Axis 5: penalties + criminal liability

Administrative ceiling under Article 35: SAR 5,000,000 per violation, doubled on repeat offense³.

Criminal penalties for the most serious offenses:

• Article 36 — disclosure or publication of sensitive personal data with intent to harm or for personal gain: up to two years’ imprisonment + fine up to SAR 3,000,000¹¹.
• Additional criminal liability attaches under the PDPL penalties chapter to unlawful cross-border transfer of personal data — readers should consult licensed Saudi counsel and the PDPL text directly for the specific penalties in their fact pattern.

Criminal liability attaches to natural persons — directors, DPOs, technical leads — where negligence or knowledge is established. This is not a corporate-only risk; it’s a personal risk for whoever signs the accountability.

For the founder of a foreign AI company (e.g., a Delaware LLC) serving a Saudi customer: civil settlement plus license revocation applies to the entity itself, and the local representative (see Axis 7) is a contact point for SDAIA and data subjects under the current regulations.

Axis 6: when to appoint a DPO

PDPL requires a Data Protection Officer when¹²:

• The controller is a government / public authority
• Core activity involves large-scale processing of sensitive data
• Core activity involves large-scale systematic monitoring of data subjects
• Processing involves children’s or other vulnerable individuals’ data

Many AI vendors serving Saudi enterprises fall into the second and third buckets. Even when not mandatory, appointing a DPO creates a clean contact point with SDAIA and with customers, and eases audits.

SDAIA’s 2024 DPO Rules require¹²:

• Independence (cannot be instructed on the substance of their tasks)
• Access to information and resources
• Protection from sanction for performing their duties
• Direct reporting to senior management
• Public disclosure of contact details

The DPO can be an internal employee or an external contractor (fractional DPO became common in 2025–2026).

Axis 7: foreign vendor — local-representative obligation

Under the current Implementing Regulations, a controller or processor established outside the Kingdom but processing personal data of subjects inside the Kingdom must appoint a local representative in the Kingdom. The representative is designated in writing and acts as a contact point for SDAIA and data subjects.

A nuance to be aware of: the 2025 proposed amendments (consultation closed 27 May 2025) move in the opposite direction from “tightening” — Article 31 of the amended draft would remove the blanket local-representative obligation while preserving SDAIA’s discretion to require one in specific cases². As of the date of this article those amendments are not enacted, so the current obligation still applies until the final text is published.

For a Delaware LLC serving a Saudi customer today, the practical options are:

1. Appoint a Saudi law firm as representative (fractional model)
2. Establish a Saudi LLC subsidiary under MISA
3. Partner with a Saudi entity that takes the representative role contractually

Option 2 is most stable for any vendor with a real Saudi customer pipeline. Watch the SDAIA gazette for the final amendment text — the regime may relax during 2026.

PDPL intersected with NDMO data classification

PDPL governs personal data. NDMO (National Data Management Office) governs data classification for the public sector and critical industries. The NDMO Data Classification Policy uses four impact-based levels¹³:

• Top Secret — unauthorized disclosure would cause exceptional damage to national interests; subject to the most stringent processing and transfer controls
• Secret — unauthorized disclosure would cause serious damage to national interests; severe processing and transfer restrictions
• Restricted — unauthorized disclosure would cause limited damage; restrictions on who may process and how
• Public — no harm from disclosure; relative freedom

Key intersection: data may be lawful to process under PDPL (with consent), yet be classified Restricted or higher under NDMO and prohibited from leaving the Kingdom under any circumstance. Anyone processing data for a Saudi government entity needs to read both frameworks together — not just one.

Similar overlays exist with SAMA for financial sector, ZATCA for tax, and CST for telecoms — each regulator layers its own rules over PDPL.

A fast readiness model for vendors

A ten-point self-check you can run in a two-hour session:

1. Do you have an inventory of personal data flowing to/from a Saudi customer?
2. Does each flow have a documented lawful basis?
3. Is processing in-Kingdom, or cross-border with a permitted purpose, conditions met, and the right safeguard (SCC / BCR / accreditation) plus risk assessment?
4. Do you have a DPIA for each high-risk processing activity?
5. Do you have a 72-hour breach-notification playbook?
6. Do you have a DPO appointed (internal or external)?
7. Do you have a local representative if you’re a foreign vendor (per current regulations)?
8. Do you maintain an up-to-date Record of Processing Activities (RoPA)?
9. Do your sub-processor contracts include flowed-down PDPL obligations?
10. Have you checked the NDMO intersection where you handle public-sector or critical data?

A score of 8/10 or higher = relatively ready. Below 6/10 = serious risk before any new Saudi deal.

How we’re approaching this at Annota8

Annota8 is being designed as a sub-processor for GCC enterprise customers. Our architecture assumes in-Kingdom as default: local labelers where the customer requires, regional data storage, auditable processing logs, and a breach-notification playbook agreed with each customer before the first record is loaded. We treat these as entry conditions for any training-data engagement in 2026, not as marketing features.

References