UAE PDPL and LLM, in depth: which regime applies, lawful basis, cross-border routing, rights requests and DPIAs for AI systems

Which UAE regime applies

Start by working out which law you are under, because the UAE is not one data protection zone. The PDPL applies to processing of personal data of people who reside or have a place of business in the UAE, to controllers and processors established in the UAE, and to controllers and processors outside the UAE that process the data of people in it. Article 2 then carves out several areas that keep their own rules. The ones that matter most for LLM projects are below.

A free zone licence is not an exemption by itself: only DIFC and ADGM, with their own data protection laws, sit outside the PDPL. And the Saudi PDPL is a different statute, so a GCC-wide product needs a mapping per country.

PDPL concepts mapped to an LLM stack

The PDPL's working concepts translate cleanly into an LLM pipeline once you name the data stores. Personal data is any data relating to an identified or identifiable natural person; that includes free text in prompts, not just structured fields. Sensitive personal data, defined in Article 1, covers data revealing family, racial origin, political or religious views, criminal records, biometric and genetic data and health data. Chat transcripts in a clinic, an HR bot or a bank complaints desk will contain it whether you planned for it or not.

The controller is the company that decides why and how the data is processed. A hosted model provider that processes prompts on your instructions is normally your processor, and Article 8 puts direct duties on processors too. A provider that reuses your prompts to train its own models is acting for its own purposes, which pushes it toward being a controller for that use and gives you a disclosure problem you must cover in your notice.

Of the Article 5 principles, purpose limitation and storage limitation bite hardest: support transcripts later wanted for fine-tuning, and debug logs that keep full prompts for a year.

Architecture: the data inventory

This inventory comes before any legal analysis. Every store where prompt text lands needs a purpose, a retention period, a location and a way to find one person's records in it. If you cannot draw it, you cannot answer an access request on time.

Lawful basis, consent and automated decisions

The PDPL starts from consent. Processing without consent is unlawful unless it falls into one of the cases listed in Article 4, which include performing a contract with the data subject, meeting a legal obligation of the controller, protecting the data subject's vital interests, public interest tasks and certain health and employment purposes. Unlike the GDPR, there is no general legitimate interests basis to fall back on, so a feature that only makes sense under a balancing test needs consent or a redesign.

Answering a customer's own support question is usually contract performance. Fine-tuning on the same transcripts is a new purpose that contract necessity hardly covers; plan on consent, proper anonymisation, or not doing it. Consent must be specific, clear and withdrawable, so your training pipeline must know whose data is in which dataset version.

Article 18 gives data subjects a right to object to decisions based solely on automated processing that have legal consequences or seriously affect them, with exceptions where the processing is part of a contract, is required by law, or the person consented. An LLM that scores loan applications, triages insurance claims or filters job candidates is exactly that kind of processing. Put a human review path in the design from the start, record the model version and inputs behind each decision, and be ready to explain the logic in the access response that Article 13 requires.

Cross-border transfers and model hosting

Most UAE teams call a model hosted outside the country, so cross-border transfer is usually the central question. Article 22 allows transfers to countries with an adequate level of protection, as approved by the UAE Data Office, the regulator created by Federal Decree-Law No. 44 of 2021. Article 23 covers destinations without that approval, allowing transfer in listed cases that include a contract binding the recipient to PDPL-equivalent protections, the data subject's express consent, and necessity for performing a contract with the data subject.

The catch is timing. The detailed procedures were left to executive regulations, and public legal summaries we reviewed disagree on whether those regulations and any adequacy list have been formally published and are in force. Do not encode a guess. Check the Official Gazette and the Data Office directly, and build the router so the adequacy list is data you can change without a deploy, starting empty and filled only from a decision you can cite.

from dataclasses import dataclass

# Fill ONLY from a published Data Office decision you can cite. Empty means "none confirmed".
ADEQUATE_COUNTRIES: set[str] = set()

@dataclass
class Route:
    provider: str
    country: str            # ISO code where prompts are processed and stored
    pdpl_contract: bool     # signed terms binding the provider to PDPL-equivalent protection
    retention_days: int
    trains_on_inputs: bool

def transfer_basis(route: Route, data_class: str, consented_to_transfer: bool,
                   contract_necessity: bool) -> str | None:
    if data_class == "health":
        return "domestic" if route.country == "AE" else None   # health law: stay in-country
    if route.country == "AE":
        return "domestic"
    if route.trains_on_inputs:
        return None                      # new purpose: block until notice and basis exist
    if route.country in ADEQUATE_COUNTRIES:
        return "art22_adequacy"
    if route.pdpl_contract:
        return "art23_contract"
    if consented_to_transfer:
        return "art23_express_consent"
    if contract_necessity:
        return "art23_contract_necessity"
    return None                          # no basis: use the in-country model or refuse

Log the basis string with each request, so an auditor's question becomes a query.

Rights requests across unstructured stores

Articles 13 to 18 give data subjects rights to information and access, portability, correction and erasure, restriction, stopping processing, and objection to automated decisions. Requests are expected to be answered within a month in normal cases, with an extension for complex ones. In an LLM system the work is finding the person's data across unstructured stores, so key every store by a stable subject identifier at write time.

def handle_rights_request(subject_id: str, kind: str, stores) -> dict:
    """kind is 'access', 'erase' or 'export'. Every store implements find/delete by subject_id."""
    report = {}
    for store in stores:                     # gateway logs, traces, RAG index, eval exports, datasets
        hits = store.find(subject_id)
        if kind in ("access", "export"):
            report[store.name] = [h.to_portable_json() for h in hits]
        elif kind == "erase":
            if store.legal_hold(subject_id):
                report[store.name] = "retained: legal obligation"
                continue
            store.delete(subject_id)
            report[store.name] = f"deleted {len(hits)}"
    if kind == "erase":
        report["training"] = mark_for_exclusion(subject_id)  # next dataset build drops them
    return report

Weights are the gap. You cannot reliably delete one person from a trained model, so the defensible position is not to put identifiable personal data into training sets in the first place, to exclude erased subjects from every future build, and to filter outputs for memorised identifiers. Our guide to erasure in LLM systems covers the technical options in more depth, and they carry over to the PDPL.

DPIA and DPO

Article 21 requires a data protection impact assessment before processing that uses new technologies likely to pose a high risk to privacy, or that involves a large amount of sensitive data. Treat any customer-facing or employee-facing LLM as in scope. Article 10 requires a data protection officer in similar high-risk cases, including systematic evaluation, profiling and large-scale sensitive data. For an LLM, the assessment should record at least the following.

• The data flow diagram above, with locations and retention for every store.
• What personal and sensitive data users are likely to type, measured from a sample of real transcripts rather than assumed.
• Model provider terms: whether inputs are retained, for how long, and whether they are used for training.
• Leakage risks: memorisation, cross-tenant retrieval, prompt injection that exfiltrates context (see PII leakage in LLMs).
• Automated decision points, their human review path, and who signed off the residual risk.

Breaches and penalties

Article 9 requires the controller to notify the Data Office of a breach that would prejudice the privacy, confidentiality or security of personal data immediately on becoming aware of it, and to inform affected data subjects in some cases; the processor must tell the controller. The procedure detail again sits in the executive regulations, so write your runbook to the strict reading. Separately, Federal Decree-Law No. 34 of 2021 on cybercrimes creates criminal offences for processing personal data in breach of the legislation in force, which DLA Piper's summary puts at detention and fines of AED 50,000 to 500,000. The PDPL itself leaves administrative penalties to a Cabinet decision.

Add LLM-specific breaches to the runbook: retrieval returning another customer's records, an injected agent emailing a transcript out, exposed prompt logs, and provider-side incidents.

Worked example: a Dubai support assistant

Take a mainland e-commerce company in Dubai launching an Arabic and English support assistant. It plans to call a US-hosted model API, ground answers in order history through a retrieval index, keep traces for 90 days and later fine-tune on resolved tickets.

Regime: mainland, ordinary customer data, so the federal PDPL applies; card data stays with the payment provider and never enters the assistant. Basis: answering the customer's own order question is contract performance. Transfer: no adequacy decision is confirmed, so the team signs provider terms binding it to PDPL-equivalent protection, zero retention and no training, uses that as an Article 23 contract basis and logs it per request, with a UAE-region model as fallback. Minimisation: the gateway redacts phone numbers, Emirates ID numbers and card-like strings, which a delivery question never needs. Retention: traces drop to 30 days. Fine-tuning is split out with its own notice and consent at ticket close. The DPIA is written before launch, with the rights handler tested on a staff account.

Failure modes

• Assuming GDPR legitimate interests exists. Features justified by balancing tests have no PDPL basis; they need consent or a redesign.
• Forgetting traces. Observability tools keep full prompts and are rarely in the rights handler.
• Fine-tuning on support data under the original notice. A new purpose without a new basis.
• Sending health or bank data down the general route. Sector rules override the general router; classify before routing.
• No human path for automated decisions. Article 18 objections then have nowhere to go.

Trade-offs

What to do next

1. Decide which regime applies: mainland PDPL, DIFC, ADGM or a sector law. Write it down with the reason.
2. Draw the data flow and list every store that holds prompt text, with location and retention.
3. Assign a lawful basis to each LLM use; drop or redesign anything that relied on legitimate interests.
4. Check the current status of the executive regulations and any adequacy decisions at the source, then configure the router.
5. Key every store by subject ID and test access, export and erasure on a staff account.
6. Write the DPIA and decide whether you need a DPO; add LLM-specific breach scenarios to the runbook.
7. Keep learning: PII handling for LLMs and India's AI and data rules for another regional comparison.