Your Customer Conversations and the Personal Data Protection Law: What Is Actually Required

Your Customer Conversations and the Personal Data Protection Law: What Is Actually Required

In part five we drew the line between what the assistant answers and what an employee handles, and required a handoff that carries the whole conversation. Everything we have built so far rests on one thing: the record of your customer conversations. And that record is not an operational file — it is personal data governed by law.

This part is not a scare piece or a legal recital. Most of what a small or medium business needs comes down to simple management decisions taken once, before launch, costing an hour in a meeting rather than a consultant. Taking them after launch costs many times more.

A WhatsApp conversation is personal data, and you are responsible for it

The Kingdom's Personal Data Protection Law has been in force since 14 September 2023, the compliance grace period ended on 14 September 2024, and the Saudi Data and AI Authority (SDAIA) is the supervisory authority. Its scope is wider than many business owners assume: it covers any processing of the data of individuals inside the Kingdom by any means, and extends to entities outside the Kingdom processing data of people within it.

When a customer sends her name, her number and her home address to book an installation slot, that is personal data under the law, not a passing chat. And what most people overlook is how much a conversation actually holds: names and numbers, ID or residency photos customers send unprompted, home addresses, images of documents and invoices, and sometimes health or financial details mentioned in passing inside a complaint. An AI assistant does not create this data, but it does make it stored, indexed and searchable instead of lost on an employee's phone. That is an operational improvement in itself — and it raises your responsibility too.

The lawful basis and notifying the customer

You do not process personal data without a legitimate reason. For most companies the basis is straightforward: the customer started the conversation themselves asking for a service, and delivering what they asked for requires processing their data. That is a solid basis for answering their enquiry and preparing their order. It does not automatically extend to anything they did not ask for.

The practical distinction is worth pausing on. Replying to a customer's enquiry is one thing; adding their number a month later to a bulk marketing broadcast is something else entirely. The first delivers what they requested; the second is a new purpose that needs their explicit consent. This is the single most common breach we see in the market, precisely because it feels free and harmless.

As for the notice, less is required than you imagine: one short line at the start of the conversation, or a privacy policy on your site that the assistant links to, saying who you are, why you collect the data, how long you keep it, who you share it with, and how the customer exercises their rights. Write it in language your customer understands, not contract language.

Collect the minimum, and delete what has served its purpose

The easiest rule in the whole law to apply: data you never collected cannot leak from you and cannot be demanded of you. Control starts there — in the wording of the assistant's own questions.

• Ask only for what the service needs. If a booking needs a name, a number and a district, do not have the assistant ask for an ID number or a date of birth just because the field exists on your old paper form.
• Block sensitive documents in chat. ID photos and bank cards are not requested over WhatsApp. Put them on the refusal list we built in part four, and move the customer to an appropriate channel if it is genuinely needed.
• Set a written retention period. Choose one per type: enquiry conversations that never became an order, and completed orders whose records you must keep for accounting and regulatory purposes. What matters is that the period is written down and applied, not left open-ended forever.
• Make deletion a procedure, not an intention. A retention period with no mechanism behind it is a permanent archive under another name. Ask your vendor how you delete a conversation or an entire customer, and when it actually disappears from their backups.

Who on your team can see the conversations?

The biggest practical risk to your customer data is not an external breach — it is unrestricted internal access. When conversations live on an employee's personal phone, they walk out of the company with them on the day they resign, and you hold neither a copy nor any control. Moving conversations into a central system solves that, provided you control who sees what.

Three management decisions are enough: each employee sees the conversations assigned to them or relevant to their work rather than everything; every user has a named account rather than a shared login the team passes around, so you know who viewed what; and access is revoked the same day the employment relationship ends, not weeks later. Add a clause to your employment contracts and procedures prohibiting the export of customer data or its removal from the system.

When conversations leave the Kingdom

This is the part business owners miss completely, because it is invisible. An AI assistant runs on a language model, and that model may be hosted outside the Kingdom, which means the text of your customer's conversation may cross the border in order to generate the reply.

Transferring personal data outside the Kingdom is restricted by law to defined cases and controls, and is not left to a vendor's discretion. You do not need to be a legal expert — you need to put three written questions to any vendor and keep the answers documented:

• Where are my customer conversations stored and where are they processed? Does the data leave the Kingdom at any stage?
• If it does leave, what basis and what controls do you rely on for the transfer?
• Do you use my customers' conversations to train your models, or for any purpose of your own?

The third question is the most commercially important and the least often asked. Your customer data is yours, and a vendor holding it to deliver a service is not permission to use it for another purpose. Make the prohibition explicit in the contract rather than implied by context.

The customer's rights, and where your responsibility ends and your vendor's begins

The law grants the data subject clear rights: to be informed that their data is being collected and why, to access it and obtain a copy, to request its correction, and to request its destruction once its purpose no longer applies. These are not theoretical texts — they are requests that may one day arrive in the same WhatsApp conversation, so your team needs to know what to do when one lands, and your system needs a button that executes it rather than a laborious manual process.

Which leaves the point that settles most arguments with vendors: you are the controller, because you determine the purpose and manner of processing, and the AI assistant vendor is a processor acting on your behalf. Legal responsibility towards your customer stays with you, even when the failure is technical and sits with your vendor. So insist on a written contract that sets out what they may and may not do with your data, obliges them to notify you without delay of any breach, and defines what happens to your data the day the relationship ends: returned in full, then destroyed on their side.

The Origami view

In Mahir, Origami's AI assistant for WhatsApp, the assistant runs on your company's own existing number with no new number and no extra app on the employee's phone, and linking is a one-time QR scan — so your customer conversations stay in a company system rather than scattered across personal devices that leave when their owners do. Training starts by giving it your website link to read and fill in your details, then you add the services, prices and frequently asked questions with answers you approve. It has two tiers you choose between — Malik for fast, repetitive direct questions and Mahir for long conversations, compound requests and objections — and you can switch at any time with no re-linking and no loss of training, and the trial is free. As for the six questions in this part about storage location, transfers outside the Kingdom and using data for training: put them in writing to any vendor you are considering, ourselves included, and keep the answer in the contract.

Conclusion

What is required of you is less than what frightens you: a clear lawful basis, a short and understandable notice, collecting the minimum you need, a written retention period followed by actual deletion, controlled access inside your team, documented answers on where the data sits and how it moves and how it is used, and a written contract with your vendor in which each side knows its role. Take these decisions before launch — they are far easier than correcting them afterwards. Which leaves the business owner's final question: what does all of this return, and how do you roll it out in a single week? That is part seven, and the end of the series.

Sources

• Saudi Data and AI Authority (SDAIA) — the Personal Data Protection Law and its Implementing Regulation: scope, lawful basis for processing, data subject rights, and the obligations of controllers and processors.
• SDAIA — the Regulation on Personal Data Transfer outside the Kingdom and its associated controls.
• SDAIA — compliance guidance and tools published for controllers on the Authority's platforms.
• Saudi Vision 2030 — the digital economy and building consumer trust in digital transactions.