AI compliance in Saudi Arabia and India rests on two data protection laws that predate the current wave of AI and were not written for it: Saudi Arabia's Personal Data Protection Law (PDPL), overseen by the Saudi Data and AI Authority (SDAIA), and India's Digital Personal Data Protection Act (DPDP Act) of 2023. Neither law regulates "AI" as a category. Both govern the personal data that AI systems ingest, process, and generate, which is where nearly all practical obligation lives. SDAIA adds AI-specific ethics principles and generative AI guidance on top, but for most companies the enforceable rules are the data protection rules, applied to a new kind of processing.
That distinction matters because it tells you where to look. If you are deploying an AI system in either market, the question is rarely "is this AI legal." It is "what personal data does this system touch, on what legal basis, where does it live, and who can be held accountable when it produces a wrong or harmful output." Answer those and you have covered most of what SDAIA and the DPDP Act actually require.
What does SDAIA actually require in Saudi Arabia?
SDAIA is both the authority that supervises the PDPL and the body that publishes Saudi Arabia's AI policy. It is useful to keep the two roles separate.
The PDPL is the binding law. Its core demands are familiar to anyone who has read a modern privacy regime: a lawful basis for processing personal data, purpose limitation, data minimisation, defined retention, and rights for the individual to access and correct their data. It applies to processing of Saudi residents' data regardless of where the processor sits, and it treats sensitive data and cross-border transfers with extra caution.
On top of that, SDAIA issues guidance aimed squarely at AI:
- AI Ethics Principles covering fairness, accountability, transparency, privacy, and human oversight, framed as principles rather than line-item rules.
- Generative AI guidelines for both public bodies and the wider public, addressing acceptable use, disclosure, and the risks of hallucinated or fabricated output.
- Data classification expectations for government and regulated data, which feed directly into where an AI workload is allowed to run.
For a private company, the practical reading is this: the PDPL is what you can be penalised against, and the SDAIA AI guidance is the standard of care you are expected to meet, especially if you handle government data or bid through platforms like Etimad. A system that quietly trains on customer data collected for a different purpose fails the PDPL long before anyone debates AI ethics.
What does India's DPDP Act require for AI systems?
The DPDP Act 2023 is India's first comprehensive personal data law, and it governs any AI system that processes the personal data of people in India. It centres on a few obligations that reshape how AI pipelines must be built.
- Consent and legitimate uses. Personal data needs a clear legal basis. The default is specific, informed consent for a stated purpose, with a narrow set of "legitimate uses" as alternatives. Repurposing that data to train or fine-tune a model is a new purpose that consent may not cover.
- Purpose limitation and erasure. Data must be used for the purpose it was collected for and deleted when that purpose ends. Indefinite logging of prompts and outputs, the default in most AI stacks, cuts against this.
- Data fiduciary accountability. The organisation deciding why and how data is processed carries the duty, including when a model vendor sits in the middle. You cannot outsource accountability to the AI provider.
- Significant Data Fiduciary duties. Larger or higher-risk processors face added obligations such as audits and data protection impact assessments, which AI deployments handling sensitive data can trigger.
On residency, the DPDP Act uses a blocklist rather than a localisation mandate: transfers abroad are allowed except to countries the government restricts by notification. But sector rules override this. The RBI's payment data localisation, for instance, keeps that data in India regardless. So an AI workload in Indian BFSI can face hard residency limits even though the DPDP Act itself does not impose them. Deciding where a workload may run is a core part of any AI governance control plane, and the residency question deserves its own treatment in keeping sensitive AI workloads in-country.
Where do SDAIA and DPDP agree, and where do they diverge?
The two regimes rhyme more than they clash, which helps companies operating across the Gulf and India run one governance model rather than two.
They agree on the fundamentals: a lawful basis for processing, purpose limitation, minimisation, defined retention, individual rights, and accountability that stays with the organisation controlling the data. Build to those and you satisfy the shared core of both.
They diverge on the details that trip up implementation:
- AI-specific guidance. SDAIA publishes explicit AI ethics and generative AI guidance; India relies on the DPDP Act plus advisories and sectoral guidance, with dedicated AI rules still maturing.
- Cross-border data. Saudi Arabia scrutinises transfers case by case with conditions; India permits transfers except to notified restricted countries. Neither is a blanket "keep everything in-country" rule, but both can become one through sector regulation or data classification.
- Regulator posture. SDAIA is a single, visible authority spanning data and AI; India's oversight is split between the forthcoming Data Protection Board and existing sector regulators, so the map of who enforces what is more fragmented.
If you handle data classified as sensitive or governmental in either market, the safer assumption is in-country processing and a model you can run without depending on a foreign kill switch, which is where the sovereign AI question enters and shapes your deployment model.
What this guide does not cover
This is an orientation, not legal advice, and it has deliberate limits.
It does not substitute for counsel licensed in Saudi Arabia or India. Both regimes are evolving: the DPDP Act's implementing rules and the operational Data Protection Board are still settling, and SDAIA continues to issue and revise guidance. Specific thresholds, notified restricted countries, and Significant Data Fiduciary designations change, and this guide names none of them as fixed. It also does not cover sector-specific rules in depth, from RBI localisation to healthcare and defence, which frequently impose stricter obligations than the base data laws. Treat what follows here as a map of the terrain, not a compliance checklist, and verify current requirements before you rely on them.
Where to start
Begin with an inventory, not a legal memo. List every AI system you run or plan to run, and for each one write down the personal data it touches, the purpose the data was originally collected for, where it is stored and processed, and how long inputs and outputs are retained. Most non-compliance in both markets hides in two answers: data reused for a purpose it was never consented to, and logs kept forever by default.
Fix those two first. Then map each workload against residency: if any of it touches government, payment, or classified data, assume it needs to stay in-country and needs a provider you can audit and replace. From there, controls like multi-model routing to avoid lock-in and monitoring of AI outputs in production turn compliance from a document into something you can actually enforce. The machine reads the regulation; the human still decides what is defensible.