PDPL and AI Chatbots: What Saudi Companies Must Get Right
An assistant that talks to customers is a personal data processing activity whether anyone described it that way in the project plan or not. Most of the work is design decisions taken early, cheaply, before anything is built.
A note on what this is before anything else: this is a technology and governance guide, written from implementation experience. It is not legal advice, it quotes no clause numbers and no deadlines, and it is not a substitute for reading the Personal Data Protection Law and its Implementing Regulations or for involving your own legal and compliance function. Requirements are amended; a blog post that states a threshold confidently is more dangerous than one that tells you where to look.
What this article does cover is the part engineers and project owners actually control: the design decisions that determine whether a compliance conversation later is straightforward or extremely expensive. Almost all of them are cheap when taken at the start and painful when retrofitted.
The thing people miss: a chatbot is a collection point
Organisations think carefully about the personal data in their CRM and considerably less about the personal data arriving through a chat window, because the chat window does not look like a form. It has no fields. Nobody designed it to collect anything.
It collects anyway, and it collects the least structured and most sensitive material in the organisation, because customers explain themselves. They type their national ID to prove eligibility. They give a phone number so someone can call back. They describe a medical situation to ask whether it is covered, or a financial one to ask why a payment failed. None of it was requested. All of it is now yours to account for.
The bottom two rows are why a transcript store deserves more care than a contact form. Nobody asked for that information; it arrived because someone was explaining.
Ordered by how often it appears without ever being asked for. Structural pattern from implementation practice, not a survey.
Design for what customers will actually type, not for what your form asks. An assistant that never requests an ID number will still receive them, and the obligations attach to what you hold, not to what you intended to collect.
Minimisation is a design decision, not a policy statement
Every framework asks you to collect only what you need. In a chat interface that translates into a small number of concrete build choices.
Do not ask for identity you do not need. A large share of questions — hours, policies, eligibility criteria, product information — require no idea who is asking. Ask only at the point where the answer genuinely depends on the person, and not on the first screen out of habit.
Detect and remove what arrives anyway. An assistant can recognise things that look like identifiers, card numbers or contact details in an incoming message and replace them before the text is stored or passed on — see PII redaction. The mechanism has to be tested against real formats rather than assumed to work, and it has to be tested against conversation history rather than a single message, because a system that redacts the first turn and stores the fifth has not solved the problem.
Decide what a transcript is for before deciding how long to keep it. Most retention arguments dissolve once the purpose is named. If transcripts exist to improve answers, what you need is the questions, not the identities in them.
Notice and consent, done properly
Two failure modes are common and opposite. One is no notice at all, on the reasoning that a chat window is not a form. The other is a wall of legal text in front of a customer who wants to know whether you are open on Friday.
What works is short, specific, at the point of collection, and honest about the parts people would object to if they found out later: that the conversation is recorded, how long it is kept, whether a person may read it, whether any third party is involved in processing it, and how to ask for it to be deleted. Anything a customer would be surprised by belongs in the notice. Surprise is the practical test.
Consent needs the same treatment. It has to be a recorded event with a time attached, not an assumption derived from the customer having continued to type. It has to be withdrawable, and withdrawal has to actually do something. And if the assistant collects for more than one purpose, the purposes are separable — agreeing to be helped is not agreeing to be marketed to.
- 1Enforce consent in the system, not on the pageThe check belongs where the data is received, so that a request arriving without it is refused. A banner that can be bypassed is a design, not a control.
- 2Give every record a deletion path from day oneIf a customer asks for their data to be removed, someone has to be able to do it completely — including from backups, logs and analytics. Retrofitting this is the hardest item on the list.
- 3Separate the conversation from the identityAnalytics almost always needs the questions and almost never needs who asked them. Splitting the two lets you keep the useful half far longer than the sensitive half.
- 4Set retention per data type, not per systemMessage content, contact details, uploaded files and aggregate statistics have different useful lifespans. One retention period for everything is either too long for the sensitive data or too short for the useful data.
- 5Log access to transcriptsWho read which conversation and when. This is what turns "only authorised staff can see it" from a claim into something you can demonstrate.
- 6Write the record of processing while you buildWhat is collected, why, on what basis, where it goes, how long it stays. Assembled during the project this takes an afternoon; reconstructed a year later it takes weeks.
Item two is the one that most often turns out to be impossible when first requested. Ask about it before the architecture is fixed.
Each of these is inexpensive at design time and expensive to add afterwards. That asymmetry is the entire argument for having the conversation early.
Third parties are the question that reshapes projects
This is where AI systems differ from ordinary software, and it is the point at which many otherwise-suitable products are eliminated from regulated procurements.
If the assistant sends conversation content to an external model provider in order to produce an answer, then that provider processes your customers’ personal data. That is not a technical footnote, it is a processing relationship: it needs to be identified, documented, covered by appropriate terms, disclosed to the people whose data it is, and assessed against whatever your position is on data leaving the Kingdom.
The reason this reshapes projects is that it is architectural. Whether an assistant calls an external provider is not a setting that can be turned off after signature — it is how the system was built. Ask the question in the first meeting and ask for the answer in writing, because it either eliminates a vendor or it does not, and finding out late is expensive.
Our own position is published on the comparison page and in our security and compliance material: conversation processing happens inside the Kingdom, no external model provider is involved, and message content is destroyed on a short defined cycle. We publish it because it is exactly the question we would ask a vendor first.
Retention, and the promise that quietly breaks
A short retention period is one of the most effective privacy controls available and one of the easiest to state without implementing. The failure is rarely deliberate. It is that message content is deleted from the obvious place while copies persist in the places nobody listed — application logs, error reports, analytics tables, message queues, database backups, an export somebody made for a report.
A retention promise is a claim about every copy, not about the main table. Before publishing one, list every location the data reaches and confirm the deletion covers each — and then verify it actually ran, rather than that the job reported success.
The related trap is a deletion that depends on something else succeeding. If a nightly job removes content only after another process has finished with it, then a failure in that other process silently extends your retention period while every dashboard shows green. Whatever your published period is, it needs to hold when things go wrong, not only when they go right.
Access control, and the sentence that is not a control
Two access questions run in parallel and are frequently confused.
The first is who among your staff can read conversations. Transcripts are genuinely useful — for quality, for training, for finding what the assistant handles badly — and that usefulness is exactly why access should be role-based, logged, and narrower than "the support team". Someone reviewing answer quality rarely needs the customer’s identity attached.
The second is what the assistant itself is allowed to retrieve for a given user. If the same system serves staff and customers, internal material must be excluded from what a customer’s question can even reach — and that exclusion has to be enforced in the retrieval filter, not requested in the model’s instructions. A model asked to keep something confidential is being asked to exercise discretion it does not have. The mechanics are in how to train an AI chatbot on your own data.
Rights requests: the operational test
Compliance frameworks give people rights over their data, and the rights are straightforward to state and awkward to serve. When someone asks what you hold about them, or asks for it to be deleted, three practical questions decide whether you can answer.
Can you find it? Chat data is keyed by session rather than by person, so linking conversations to an identified individual requires that link to have been designed. Can you produce it? In a form the person can actually read, without an engineer running queries. Can you delete it everywhere? Which returns to the list of copies above.
The honest way to check is to run one against yourself before a customer does. Pick a real conversation, and have someone who is not an engineer try to locate, export and erase it end to end. Whatever breaks is what would have broken under a real request, and it is much cheaper to find this way.
Where the legal and compliance team belongs
Early, and in a specific role. The unhelpful version of this involvement is a review at the end, which produces either rubber-stamping or a late redesign. The useful version is four decisions taken at the start, with legal in the room: what the lawful basis for processing is; what the retention period is per data type; whether any processing may happen outside the Kingdom; and what the notice will say.
Those four determine most of the architecture. Every one of them is a fifteen-minute conversation before the build and a rebuild afterwards, which is the whole reason this article exists.
How we approach it
Elbi is built on the assumption that the compliance question will be asked, because in the sectors we work in it always is. Consent is enforced where data is received rather than presented as a banner; identifiers are detected and removed from stored text; retention is set per data type and message content is destroyed on a short cycle; access to transcripts is role-based and logged; retrieval is filtered by who is asking; and export and erasure exist as operations rather than as engineering tasks.
None of that makes an organisation compliant, and we would not claim it does — compliance is a property of your processing, your notices, your lawful basis and your governance, most of which is yours rather than ours. What a well-designed system does is make the position defensible instead of making it a project. If you want the design questions above walked through against your own case, that is worth a conversation before the architecture is chosen.
Common questions
If the assistant handles personal data, it is a processing activity like any other, and the obligations attach to what you hold rather than to what you intended to collect. Chat is easy to overlook because it has no form fields — but customers volunteer names, contact details, ID numbers and personal circumstances while explaining their problem. This is a technology guide, not legal advice; the Law and its Implementing Regulations are the source.
More than it asks for. Names and contact details almost always; account and reference numbers routinely; national ID or Iqama numbers often, offered as proof of eligibility; and free-text descriptions of health, financial or family circumstances whenever the customer is explaining why they are asking. Uploaded documents add another category again.
It is not automatically a problem, but it is a processing relationship that must be identified, documented, covered by appropriate terms, disclosed, and assessed against your position on data leaving the Kingdom. It is also architectural rather than configurable, so ask in the first meeting and get the answer in writing — it either eliminates a vendor or it does not, and finding out after signature is expensive.
Long enough to serve a purpose you can name, and no longer, set per data type rather than per system. The common failure is not the period but the copies: content deleted from the main table while it persists in logs, error reports, analytics and backups. A retention promise is a claim about every copy, and it needs to hold when a job fails, not only when everything runs.
Test it before a customer does. Take one real conversation and have a non-engineer try to locate it, export it in a readable form and erase it everywhere. Chat data is keyed by session rather than by person, so the link to an identified individual has to have been designed in — which is why this is the hardest item to retrofit and the one worth settling at the start.
Keep reading
AI Agents vs AI Chatbots: What Changes When Software Can Act?
A chatbot that is wrong has given bad information. An agent that is wrong has cancelled an order, issued a…
Read Article
AI Chatbots for E-commerce: Orders, Returns and Cart Recovery
Online retail generates the most predictable contact volume of any sector — three questions, asked…
Read Article
What Does an AI Chatbot Actually Save? Measuring It Honestly
"AI saves money" is not a business case, and the percentages in vendor decks are somebody else’s numbers from…
Read Article