Your retrieval index and the PDPL: what a deletion request means for RAG

On 6 October 2026, SDAIA opened a public consultation on amendments to the Implementing Regulation of the Personal Data Protection Law, with comments taken through the Istitlaa platform. Law-firm summaries put the closing date at 5 November 2026. It touches storage inside the Kingdom, data subject requests and impact assessments. For teams running retrieval over their own documents, that raises a practical question: when someone asks to see or destroy their personal data, does that request actually reach the index behind your AI assistant?

Short answer: It has to, and the regulation in force today already says so. Destruction covers every copy in the controller's systems, including backups, and a retrieval system is mostly copies: chunks, embeddings, keyword indexes, caches and logs. Build the index so you can find, show and remove one person's data inside the 30-day window, and treat the draft amendments as a reason to check that now rather than after an incident.

What the regulation already asks for

The Implementing Regulation published in Umm Al-Qura in September 2023 is the text to read. Six parts of it land directly on a retrieval system:

• Access. Article 5 gives a data subject the right to access the personal data a controller holds about them, without exposing data that identifies someone else.
• Destruction. Article 8 requires destruction when the person asks, when the data is no longer needed for the purpose it was collected for, when consent was the only basis and is withdrawn, or when the processing turns out to be unlawful.
• All copies. Article 8 also says destruction reaches all copies stored in the controller's systems, backups included, and that parties who received the data should be told to destroy it too.
• Thirty days. Article 3 sets 30 days to act on a rights request, with one extension of up to 30 more if the person is told in advance and given reasons.
• Minimum necessary. Article 19 limits collection and retention to what the purpose needs.
• Anonymisation. Article 9 only treats data as no longer personal when the controller has confirmed the person cannot be re-identified.

None of this mentions AI, and it does not need to. An index built from documents that contain names, ID numbers, phone numbers or case details is personal data processing like any other.

What the draft would add

According to summaries by Clyde & Co and Al Tamimi, the draft would add an express duty to store personal data inside the Kingdom, while still allowing transfers that meet the law. An unanswered request would count as rejected once the deadline passes, and the person could complain to SDAIA. Impact assessments would be required for emerging technologies and for automated decisions that affect people's rights or interests. Records of processing would be kept for the life of the processing plus five years.

This is a draft, and SDAIA can adopt it as written or change it. The direction is still clear enough to plan around: where your index lives, and how fast you can answer a request about it, are becoming easier to check.

Where personal data sits in a retrieval system

When we map a retrieval build, the source document is rarely the only copy:

• The source store. The original files, plus any OCR or converted text.
• Chunks. The split passages, often in a separate database with their own IDs.
• Embeddings. Vectors for each chunk. These are not anonymous by default: a 2023 research paper used a trained inversion method to reconstruct 92% of 32-token inputs exactly from their embeddings, and recovered full names from clinical notes. Against Article 9's re-identification test, we treat vectors as personal data.
• The keyword index. Hybrid search keeps a lexical index next to the vectors.
• Caches. Stored answers or retrieved passages kept to save cost.
• Logs and audit trails. Questions, retrieved sources and answers, which often quote the passage word for word.
• Evaluation sets. Real questions and passages copied in to test quality.
• Backups and snapshots. Of every item above.

If a deletion only reaches the first item, the assistant can keep quoting a document that no longer exists.

A destruction request, walked through

Take a customer-service assistant that answers staff questions from complaint files. A customer writes in asking for their personal data to be destroyed. Here is how we would want that to run:

1. Log the request with a date. The 30-day clock starts, and under the draft, silence would count as a rejection.
2. Check for a legal reason to keep data. Other rules may require some records to be kept. The data protection officer or legal team decides, and the outcome is recorded.
3. Find every source item. Search the source store by the customer's identifiers, in Arabic and English spellings, with and without diacritics, because Arabic names vary in how they are written.
4. Delete by source ID, not by guess. Every chunk, vector and keyword entry carries the ID of the document it came from, so one filtered delete removes them all.
5. Clear caches and evaluation copies. Purge cached answers that cited those documents and drop them from test sets.
6. Handle logs and backups. Redact or expire log entries under a written retention rule, and make sure a restored backup cannot quietly bring the data back.
7. Prove it. Run the customer's name and ID through the assistant again and confirm nothing comes back, then record the result.

Steps 4 and 7 are where systems usually fail: without source IDs, deletion becomes a manual hunt, and without a test, nobody knows it worked.

What we design in from the start

In our builds, the index sits in the data inventory with a named owner, like any other system that holds personal data. In practice:

• Source IDs on everything. As in our Arabic RAG builds, each chunk and vector records the document and version it came from, so deletion and re-indexing follow one path.
• Same location as the data. The index, embeddings and logs run in the customer's environment, as described on our security and compliance page, so a storage rule covers all of it at once.
• Permissions at retrieval time. Results are filtered by what each user may see in the source system, which also keeps one person's data out of another's answers.
• A written log policy. What gets logged, for how long and who can read it is decided before launch.
• Deletion as a test case. A delete-then-search check sits in the evaluation suite next to answer quality, so it runs on every release.

What this is not

This is our reading as builders, not legal advice. The amendments are still a draft and the final text may differ, so check the current version on Istitlaa and the published regulation before deciding anything. Retention duties under other laws, sector regulators' rules and your own contracts can change what must be kept or destroyed. Your data protection officer and counsel make that call.

If you want to test this on your own index, start with one workflow and one deletion request.