SDAIA PDPL Enforcement in 2026: A Practical Checklist for Saudi SME AI Chatbots
Yes — enforcement is live. Saudi Arabia's Personal Data Protection Law (PDPL) became fully enforceable on September 14, 2024, when the grace period ended. SDAIA is the enforcing authority, fines run to SAR 5 million per violation (doubled for repeat offenses), and breaches must be reported to SDAIA within 72 hours. If your business runs an AI chatbot that talks to customers in the Kingdom, the checklist below is the practical version of what the law requires of you.
This post is the follow-on to our background explainer on PDPL compliance for Saudi SMEs — that post covers what the law is; this one is the operator's checklist for AI chatbots specifically. Two honest caveats: we are an AI consultancy, not a law firm, and this is not legal advice — it's the checklist we run on every KSA chatbot deployment before launch. And PDPL applies to anyone processing personal data of individuals in Saudi Arabia, including companies outside the Kingdom.
Is the grace period really over?
Yes. The PDPL (Royal Decree M/19 of 2021, amended by Royal Decree M/148 of 2023) was issued in 2021, took effect in September 2023, and came with a one-year compliance grace period that ended on September 14, 2024. Since that date the law is fully enforceable, and SDAIA — the Saudi Data and Artificial Intelligence Authority — enforces it.
There is a persistent belief among SMEs that enforcement is "still coming." That belief was defensible in 2024. In late 2026 it is not: SDAIA has been issuing violation decisions through its adjudication committees, and the fine schedule is public. Treating PDPL as optional in 2026 is the same category of risk as treating VAT filings as optional — technically a choice, practically a very expensive one.
The Year of AI has raised the temperature further. Saudi Arabia's Cabinet declared 2026 the Year of Artificial Intelligence, with SDAIA leading the agenda. More AI in production means more AI systems touching personal data, which means the regulator's attention is focused exactly where your chatbot sits. A 2026 chatbot project that ignores PDPL is deploying into the most compliance-scrutinized environment the Kingdom has ever had for AI.
Why does a chatbot make PDPL harder?
A chatbot is not a form. A form collects the fields you decided to collect; a chatbot collects whatever the customer volunteers — names, phone numbers, national ID numbers, health details, family information, location. Saudi PDPL defines personal data broadly, and conversation transcripts are among the messiest data stores an SME can own: unstructured, unpredictable, and rich in details nobody asked for.
Four chatbot-specific problems recur in the projects we review:
- Indefinite retention by default. Most chatbot platforms keep full transcripts forever unless someone configures otherwise. Under PDPL, you need a lawful basis and a defined retention period for each data category — "we never got around to deleting it" is neither.
- No real deletion path. The customer says "delete my data" and the team deletes the CRM row — but the transcript survives in the chat platform's archive, the vector database used for retrieval, and the analytics warehouse. Deletion that isn't complete isn't deletion.
- Cross-border leakage by architecture. The chat widget posts to a SaaS platform hosted abroad, the LLM call goes to another region, and the analytics tool is a third. Every one of those is a cross-border transfer that needs a lawful basis under PDPL's transfer rules.
- Nobody owns it. The marketing team bought the bot, IT didn't configure it, and legal never saw it. Ownership gaps are where violations are born.
The checklist below addresses each of these. It is organized in the order we'd implement it on a real project: legal basis first, then data flow, then rights, then incidents, then governance.
The checklist: thirteen things to get right before launch
1. Consent — captured, specific, and withdrawable
PDPL's default lawful basis is consent: explicit, for a specific purpose, and withdrawable as easily as given. The conversation should open with a clear statement of what you collect and why, plus a real withdrawal mechanism — not a buried link, and definitely not a pre-ticked box.
2. Identify the controller
The bot should identify who is behind it — your business, not the vendor. Data subjects have the right to know who controls their data; a bot that never says whose bot it is fails the most basic transparency test.
3. Purpose limitation — collect only what the purpose needs
Every field must tie to a stated purpose. A booking bot needs a name and phone number; it doesn't need a national ID number, and shouldn't retain one a customer volunteers. Design the flow so the bot doesn't ask for what it doesn't need.
4. Map every data flow the bot touches
Inventory where transcripts go, field by field, system by system — chat platform, LLM provider, CRM, analytics, backups, support desks. This inventory becomes your Records of Processing Activities (item 12) and the basis for everything downstream.
5. Give customers their rights — for real
PDPL grants data subjects rights including access, correction, deletion, and portability. That means a documented request-handling process with an owner and response timeline — and a deletion process that reaches transcripts, backups, logs, and vector stores, not just the CRM row. Test the deletion path end to end before launch.
6. Set a retention schedule and enforce it
Define in writing how long each data type lives — transcripts (e.g., 90 days, then anonymized or destroyed), booking records, analytics aggregates — then implement destruction. A policy nobody enforces is a liability document. Automated retention deletion is the standard; "when someone remembers" is how indefinite retention happens.
7. Build the 72-hour breach plan before you need it
SDAIA must be notified within 72 hours of becoming aware of a personal data breach, and affected subjects where harm is likely. That presumes a plan that exists before the incident: who detects, who assesses, who drafts the report. Chatbots widen the breach surface — leaked API keys, exposed transcript databases, prompt-injection exfiltration — so the plan must name the bot specifically. Write it, run it once as a tabletop exercise, fix what breaks.
8. Control cross-border transfers
Transferring personal data outside the Kingdom is permitted but needs a lawful path: SDAIA adequacy recognition, approved contractual safeguards (standard contractual clauses, binding common rules, certifications), explicit consent, or limited exceptions — always with data minimization. Default to in-Kingdom hosting for transcript stores, and document every foreign system in the chain.
9. Get data processing agreements with every vendor
Every platform your conversations pass through — chat widget, LLM API, CRM, analytics, hosting — is processing personal data on your behalf. Each needs an agreement covering its obligations, security measures, and where it stores the data. The question that sinks most SME audits: "where does this vendor actually store our customer conversations?" If you can't answer, you can't comply.
10. Lock down access and logging
Encryption at rest and in transit, role-based access (each team member sees only what their role requires), and audit logs of who accessed what. Separate production transcript data from dev and test environments — training environments full of real customer conversations are one of the most common findings we see.
11. Run a data protection impact assessment for high-risk processing
If the bot processes sensitive personal data at scale — health, financial, children's data — or makes automated decisions with significant effects, run a formal impact assessment before launch. It's the document SDAIA will ask for first if something goes wrong.
12. Maintain records of processing and register where required
Keep Records of Processing Activities: purposes, data categories, recipients, cross-border arrangements, retention, security measures — producible to SDAIA on request. Controllers are expected to engage with SDAIA's National Data Governance Platform, and certain organizations (government-data processors, sensitive-data controllers, large-scale processors) need an appointed Data Protection Officer. Check where you land.
13. Name an owner and train the team
Someone in the business must own the bot's data protection position — a named person, not "IT generally." And the people who read transcripts daily need the rules: minimize what they copy elsewhere, never export to personal devices, report anything odd immediately. Most PDPL violations are human, not technical.
Where do your chatbot's transcripts actually live?
This is the question that derails the most compliance reviews. The honest architecture of a typical SME chatbot: the widget is served by a vendor hosted abroad, conversation state lives in that vendor's database, the LLM inference runs in another provider's region, a webhook copies everything into your CRM, and an analytics snippet ships event data to a fourth system. Four or more cross-border transfers and vendor relationships — from a bot the business thinks of as "the thing on our website."
The compliant version isn't exotic: in-Kingdom hosting for the transcript store as the default, an LLM provider and region chosen with the transfer rules in mind, documented safeguards where foreign processing is unavoidable, and processing agreements covering each link. It costs no more than the careless version — it just requires the decisions to be made before launch rather than discovered during an audit.
If you're buying an off-the-shelf platform, the single most valuable due-diligence question is: "Show me, in writing, every country our customer conversations are stored or processed in." Vendors that answer crisply are worth keeping. Vendors that wave their hands are worth replacing.
What about WhatsApp and the channels you don't control?
In the GCC, much customer conversation happens on WhatsApp — often on employees' personal phones. PDPL does not exempt any of this. A bot that routes customers into an unmanaged WhatsApp number has moved the compliance problem into a channel with less control, not more. The fix is channel discipline: route bot conversations through a business account with defined retention and access management, prohibit transcript handling on personal devices, and extend the same consent, retention, and deletion rules to the messaging channel. The law follows the data, not the app icon.
When should a lawyer look at this?
Three situations warrant counsel rather than a checklist: you process sensitive personal data at scale (health, financial, children's data); you've had a breach or complaint that might reach SDAIA; or your vendor chain crosses jurisdictions in ways you can't fully map. A checklist gets you to a defensible baseline. Counsel gets you through the situations where the baseline is tested.
Frequently asked questions
Is Saudi Arabia's PDPL actually being enforced in 2026?
Yes. The one-year grace period ended on September 14, 2024, and since then the law has been fully enforceable. SDAIA, the Saudi Data and Artificial Intelligence Authority, is the enforcing authority and has been issuing violation decisions through its adjudication committees.
What are the fines for PDPL violations?
Fines reach up to SAR 5 million per violation and can be doubled for repeat offenses. Separately, disclosing sensitive personal data with intent to harm can be a criminal offense carrying up to two years' imprisonment and fines of up to SAR 3 million. Terms vary by violation category, so confirm specifics with counsel.
Does PDPL apply if my company is outside Saudi Arabia?
Yes, if your chatbot processes personal data of individuals in Saudi Arabia. PDPL has extraterritorial scope — the question is where the data subject is, not where your company or servers are.
How fast must we report a data breach to SDAIA?
Within 72 hours of becoming aware of the incident, under the breach notification rules. Affected data subjects must also be notified where the incident is likely to cause them harm. This requires an incident plan that exists before the breach — who detects, who assesses, who notifies.
Can our chatbot store conversations on servers outside the Kingdom?
Cross-border transfer is permitted but needs a lawful basis: SDAIA adequacy recognition, approved safeguards such as standard contractual clauses, explicit consent, or limited exceptions — always with data minimization. The practical default is in-Kingdom hosting for transcript stores, with every foreign system in the chain documented.
Do we need a Data Protection Officer?
It depends on what you process. DPO appointment rules apply to certain categories — including government-data processors, sensitive-data controllers, and large-scale processors — with contact details submitted to SDAIA's platform. If you're unsure where you land, that's a question for counsel, not a checklist.
About this post
Creatrixe is a Canadian AI consultancy with a Riyadh office. We build AI receptionists, lead-capture, and follow-up systems for local businesses in Canada and the GCC — human-assisted AI, designed so a person stays in the loop where it matters. We run the PDPL checklist above on every KSA chatbot deployment before launch. This post is operational guidance from that work, not legal advice; confirm your position with your DPO or counsel.
Deploying a chatbot in the Kingdom?
We'll walk your deployment through this checklist before launch — consent, retention, cross-border transfers, vendor agreements — and tell you honestly what's missing.