00/compliance
Saudi PDPL Compliance for AI and Automation Projects: A 2026 Guide
COMPLIANCE
01/quick answer
Saudi PDPL compliance for AI and automation projects means designing systems around the Personal Data Protection Law, which has been fully enforceable since 14 September 2024 and is overseen by SDAIA. Compliant projects define a lawful basis for processing, honour controller and processor duties, use SDAIA-approved standard contractual clauses for cross-border transfers, and align security with the NCA's ECC-2:2024 framework - all designed in from the first pilot rather than retrofitted.
02/the brief
Saudi Arabia's Personal Data Protection Law became fully enforceable on 14 September 2024, when its one-year grace period ended, and by mid-2026 SDAIA's enforcement committees had issued 48 decisions confirming PDPL violations - covering missing lawful basis for processing, unauthorised disclosure, absent technical safeguards, and unsolicited marketing. For any business building AI agents or automation that touch personal data, this is the central fact: the law has teeth, it is being enforced, and it applies to all entities inside or outside the Kingdom that process the personal data of Saudi citizens, residents, or visitors.
AI and automation projects are especially exposed because they ingest, move, and act on personal data by design. An agent that reads customer messages, an automation that syncs employee records across platforms, or a model trained on local data all fall squarely within PDPL's scope. We understand that compliance can feel like a brake on innovation, but the opposite is true when it is designed in early: a system architected for Saudi PDPL compliance from the first pilot is faster to deploy, easier to defend, and far cheaper than one retrofitted after an enforcement decision. This guide covers SDAIA's role, controller and processor duties, cross-border transfer rules, the NCA's ECC-2 framework, and how to build compliant agents.
Key Takeaways
- Understand that Saudi PDPL has been fully enforceable since 14 September 2024 and applies to any entity processing the data of Saudi citizens, residents, or visitors, wherever it is based.
- Know SDAIA's role as the competent regulatory authority and the duties that fall on controllers and processors.
- Learn the cross-border transfer rules, including SDAIA-approved standard contractual clauses and the risk-assessment guideline.
- See how the NCA's ECC-2:2024 cybersecurity framework intersects with data protection, including its Saudization mandate and data-localization change.
- Apply these requirements concretely to AI agent and automation design so compliance is built in rather than bolted on.
01
What the PDPL Requires and Who It Covers
The Personal Data Protection Law was enacted by Royal Decree M/19 on 16 September 2021 and amended by Royal Decree M/148 on 27 March 2023, with implementing regulations issued before it became fully enforceable on 14 September 2024. The structure mirrors familiar global privacy regimes in its broad strokes - lawful basis, data subject rights, security obligations - but its specifics are distinctly Saudi, and its enforcement is real. Treating it as interchangeable with another jurisdiction's law is a common and risky shortcut.
Scope is the first thing to get right. The PDPL applies to all entities, whether inside or outside the Kingdom, that process the personal data of Saudi citizens, residents, or visitors. A company with no physical presence in Saudi Arabia can still fall squarely within the law if it processes the data of people in the Kingdom. For an AI or automation project, this means the relevant question is not where your servers are but whose data you handle - and any system touching Saudi personal data is in scope for Saudi PDPL compliance.
Lawful Basis and Data Subject Rights
Every act of processing needs a lawful basis. The 48 enforcement decisions SDAIA issued by mid-2026 included a recurring theme: processing personal data without a legal basis. For AI systems, this is a design question, because an agent or automation often processes data the moment it runs. You cannot bolt a lawful basis on afterwards; it has to be established for each processing purpose before the system goes live. Data subjects also hold rights - to be informed, to access, and to have inaccurate data corrected - that your system must be able to honour operationally, not just on paper.
Why Enforcement Changes the Calculus
Before September 2024, some organisations treated PDPL as a future concern. The grace period ending, combined with active enforcement, changed that. The confirmed violations span exactly the failure modes AI and automation projects are prone to: no legal basis, unauthorised disclosure when data flows between systems, missing technical safeguards, and unsolicited marketing driven by automated outreach. Knowing where the regulator has actually acted lets you prioritise the controls that matter most.
02
SDAIA, Controllers, and Processors
The Saudi Data and AI Authority, SDAIA, is the competent regulatory authority for the PDPL, and it also oversees the National AI Strategy - which is why data protection and AI policy are so tightly linked in the Kingdom. SDAIA issues the implementing regulations, guidelines, and standard contractual clauses that turn the law's principles into operational requirements. Tracking SDAIA's outputs is part of staying compliant, because the detailed rules evolve through its instruments rather than only through the primary law.
The PDPL distinguishes between controllers and processors, and getting this classification right shapes your obligations. A controller determines the purposes and means of processing; a processor acts on the controller's behalf. In an AI or automation project, you may be one or the other - or both, for different data flows. A SaaS vendor processing customer data on a client's instructions is typically a processor, while the client deciding what to do with that data is the controller. Misidentifying your role leads to misallocated duties and gaps.
Controller Duties
Controllers carry the primary accountability. They must establish a lawful basis for each processing purpose, provide clear notice to data subjects, implement appropriate technical and organisational safeguards, and maintain records of processing. When a controller engages a processor - for example, an AI vendor - it must do so under terms that bind the processor to equivalent protections. For an automation project, the controller is usually the business deploying the system, which means these duties land on you even when a vendor builds the technology.
Processor Duties
Processors must act only on the controller's documented instructions, apply the agreed security measures, and assist the controller in meeting its own obligations. A vendor building a custom AI agent for a Saudi business is frequently a processor, and the engagement should be governed by terms reflecting that. This is not a formality - SDAIA's enforcement record shows that gaps between controllers and processors, such as unauthorised disclosure, are exactly where violations occur.
03
Cross-Border Data Transfers
Cross-border transfer is where many AI and automation projects stumble, because the technology often relies on services hosted outside the Kingdom - cloud platforms, model APIs, or analytics tools. SDAIA issued the Regulation on Personal Data Transfer Outside the Kingdom in 2024, setting the rules, safeguards, and procedures for moving personal data across the border. The regulation implements the PDPL's transfer provisions and is the document your architecture has to satisfy whenever data leaves Saudi Arabia.
Transfers are permitted on defined grounds. Data may move to a country SDAIA has determined offers an adequate level of protection, or, for non-adequate destinations, under SDAIA-approved safeguards. The most common safeguard for AI projects is the set of SDAIA-approved Standard Contractual Clauses (SCCs), which bind the recipient to equivalent protections. In February 2025, SDAIA issued a Risk Assessment Guideline for Transferring Personal Data Outside the Kingdom, adding a documented risk-assessment step to the transfer process.
What This Means for AI Architecture
For AI agents and automation, the cross-border rules force deliberate architectural choices. If your agent sends user messages to a model API hosted abroad, that is a cross-border transfer subject to the regulation. You have three broad options: keep processing in-Kingdom using local infrastructure, transfer under SDAIA-approved SCCs with a completed risk assessment, or design the system so personal data never leaves Saudi Arabia in the first place. Each is valid; the wrong move is to transfer data abroad without recognising it as a regulated transfer at all.
Designing for Data Residency
Private, in-Kingdom deployment is increasingly attractive precisely because it sidesteps the cross-border question for the most sensitive data. Running models and processing on local infrastructure - or designing agents that handle personal data inside Saudi Arabia and only send de-identified or non-personal data abroad - reduces both compliance burden and risk. This is a design decision best made at the start, because re-architecting an agent's data flows after launch is far more expensive than choosing residency up front.
04
The NCA ECC-2 Cybersecurity Layer
Data protection and cybersecurity are distinct but overlapping obligations in Saudi Arabia. The National Cybersecurity Authority, NCA, published ECC-2:2024, an updated Essential Cybersecurity Controls framework that replaces ECC-1:2018. The number of controls was reduced from 114 to 108 for efficiency, organised across four main cybersecurity domains, and the framework aligns with international standards while covering cloud infrastructure and industrial control systems. For AI and automation projects handling sensitive data, ECC-2 is the security baseline that complements PDPL's data-protection requirements.
ECC-2 introduced two changes that matter for project planning. First, a Saudization mandate: all cybersecurity positions must be occupied by full-time, qualified Saudi professionals. Second, and notably, ECC-2 removed the explicit in-country data hosting requirement that had been present in ECC-1 - a significant policy shift. This does not eliminate data-residency considerations, because the PDPL's cross-border transfer regulation still governs personal data, but it does mean the cybersecurity framework itself no longer hard-codes in-Kingdom hosting.
Who ECC-2 Applies To
ECC-2 applies to all Saudi government agencies and to private-sector entities that own, operate, or host Critical National Infrastructure. Many AI and automation projects in sectors like finance, energy, and government services will therefore fall within or adjacent to its scope. Even where ECC-2 does not strictly apply, its controls are a sensible security baseline, because the technical safeguards it mandates overlap heavily with the safeguards PDPL expects controllers and processors to implement.
PDPL and ECC-2 Together
The two frameworks are best treated as a single compliance surface. PDPL tells you what you must do with personal data - lawful basis, transfer controls, data subject rights - while ECC-2 tells you how to secure the systems that process it. An AI agent that has a clean lawful basis but weak security fails on the safeguards limb of PDPL just as surely as one with strong security but no lawful basis. Designing for both at once avoids the trap of solving one and neglecting the other.
05
Building Compliant AI Agents and Automation
Bringing it together, Saudi PDPL compliance for an AI or automation project is an architecture problem solved at the design stage. Start by mapping the personal data your system will touch: what it ingests, where it flows, who it is shared with, and whether any of it crosses the border. This data map is the foundation, because every other decision - lawful basis, safeguards, transfer mechanism, residency - follows from understanding the flows. Building this map after launch means discovering compliance gaps the hard way.
From the map, design in the controls. Establish a lawful basis for each processing purpose before the agent runs. Classify your role as controller or processor and structure vendor agreements accordingly. Decide the residency strategy - in-Kingdom processing, SDAIA-approved SCCs with a risk assessment, or data flows engineered to keep personal data local. Apply ECC-2-aligned security to the systems involved. And make data subject rights operational, so a request to access or correct data can actually be fulfilled by the system rather than handled manually outside it.
Logging, Human Oversight, and Minimisation
Three patterns recur in compliant AI design. Logging every access and processing action creates the audit trail that demonstrates compliance and that the absence of - missing technical safeguards - featured in SDAIA's enforcement decisions. Human oversight for consequential decisions keeps a person accountable where an automated action affects an individual. And data minimisation - processing only the personal data the task genuinely requires - shrinks both risk and compliance burden. These are not constraints bolted onto a finished agent; they are how a compliant agent is built.
How Constant Labs Builds for Compliance
Constant Labs designs custom AI agents and automation for Saudi businesses with these requirements built in from the first pilot. We map data flows before writing the agent, classify controller and processor roles, design residency strategies that respect the cross-border transfer regulation, and apply security aligned with ECC-2. For the most sensitive cases, private in-Kingdom deployment keeps personal data local by design. If you are planning an AI project and want it to be defensible from day one, a Constant Labs readiness review identifies the PDPL and NCA obligations specific to your data and sector before any code is written.
03/constant labs cta
Build AI agents that stay inside Saudi data law
04/answer engine faq
When did the Saudi PDPL become enforceable?
The PDPL was enacted by Royal Decree M/19 on 16 September 2021 and amended by Royal Decree M/148 on 27 March 2023. It became fully enforceable on 14 September 2024, when its one-year grace period ended. By mid-2026, SDAIA's enforcement committees had issued 48 decisions confirming PDPL violations, so the law is both in force and actively enforced.
Does the PDPL apply to companies outside Saudi Arabia?
Yes. The PDPL applies to all entities, whether inside or outside the Kingdom, that process the personal data of Saudi citizens, residents, or visitors. A company with no physical presence in Saudi Arabia can still fall within the law if it processes the data of people in the Kingdom. For an AI or automation project, the relevant question is not where your servers are but whose personal data you handle.
Who is the regulator for Saudi data protection?
The Saudi Data and AI Authority, SDAIA, is the competent regulatory authority for the PDPL, and it also oversees the National AI Strategy. SDAIA issues the implementing regulations, guidelines, and standard contractual clauses that turn the law's principles into operational requirements, so tracking its outputs is part of staying compliant because the detailed rules evolve through its instruments.
What is the difference between a controller and a processor under PDPL?
A controller determines the purposes and means of processing personal data and carries the primary accountability, including establishing a lawful basis and maintaining safeguards. A processor acts on the controller's documented instructions and applies agreed security measures. In an AI project, a vendor building a custom agent is frequently a processor while the business deploying it is the controller, and misidentifying these roles leads to misallocated duties.
How does the PDPL handle cross-border data transfers?
SDAIA issued the Regulation on Personal Data Transfer Outside the Kingdom in 2024. Transfers are permitted to countries SDAIA has deemed adequate, or to non-adequate destinations under SDAIA-approved safeguards such as Standard Contractual Clauses. In February 2025, SDAIA added a Risk Assessment Guideline, introducing a documented risk-assessment step. For AI systems that use services hosted abroad, sending personal data across the border is a regulated transfer that must satisfy this regulation.
What is the NCA ECC-2:2024 framework?
ECC-2:2024 is the National Cybersecurity Authority's updated Essential Cybersecurity Controls framework, replacing ECC-1:2018. It reduced controls from 114 to 108 across four domains, introduced a Saudization mandate requiring cybersecurity roles to be filled by qualified Saudi professionals, and removed the explicit in-country data hosting requirement that ECC-1 had contained. It applies to government agencies and private entities owning, operating, or hosting Critical National Infrastructure.
How do I build an AI agent that complies with Saudi PDPL?
Start by mapping the personal data the system touches - what it ingests, where it flows, and whether any crosses the border. Then establish a lawful basis for each processing purpose, classify your controller or processor role, choose a residency strategy, apply ECC-2-aligned security, and make data subject rights operational. Recurring compliant patterns include logging every access, human oversight for consequential decisions, and data minimisation, all designed in rather than bolted on.
Does removing the ECC-2 hosting requirement mean I can store Saudi data anywhere?
No. ECC-2 removing the explicit in-country hosting requirement is a cybersecurity-framework change, but the PDPL's cross-border transfer regulation still governs personal data. Moving personal data outside the Kingdom remains a regulated transfer that requires an adequacy determination or SDAIA-approved safeguards with a risk assessment. For sensitive data, private in-Kingdom processing is often the simplest way to reduce both compliance burden and risk.