PDPL — UAE Personal Data Protection Law.

The PDPL was enacted as Federal Decree-Law No. 45 of 2021 and operationalised through the UAE Data Office in subsequent executive regulations. It is the federal backbone for personal-data protection across the seven emirates, sitting alongside — not replacing — the older sector-specific regimes in DIFC and ADGM.

The trigger for application is processing of personal data relating to a UAE resident. Where the processing happens is largely irrelevant: an agent hosted in Frankfurt, invoking an OpenAI endpoint in the United States, that reads CRM records of UAE customers, is processing UAE personal data and is in scope. The location of the data controller, the model provider, or the deployment infrastructure does not exempt the activity.

Free zones with their own data-protection regimes — DIFC under the DIFC Data Protection Law and ADGM under its Data Protection Regulations — generally take precedence within their territorial scope, but personal data flowing across the boundary (a DIFC entity processing data of mainland UAE residents, for example) commonly engages both regimes simultaneously. We treat dual compliance as the working assumption for any cross-zone deployment.

Lawful basis. Every processing activity needs a documented legal ground — typically consent, contractual necessity, legal obligation, vital interest, public interest, or legitimate interest. For most agentic deployments handling existing customers, contractual necessity carries the conversation-handling and order-processing workflows. Outbound marketing on WhatsApp requires explicit consent; legitimate-interest claims do not extend to direct marketing under TDRA rules.

Data minimisation. The agent should only see, retrieve, and retain the personal-data fields necessary to complete the task. A WhatsApp lead-qualification agent does not need passport numbers; an appointment scheduler does not need transaction history. We enforce minimisation at the integration layer through scoped views and filtered API responses, not at the prompt layer — relying on a prompt to "ignore" personal data is not a defensible control.

Retention limits. Personal data must not be kept longer than necessary for the documented purpose. The PDPL does not prescribe specific durations, but the UAE Data Office expects controllers to set, document, and enforce time-bound retention policies — and to provide evidence of the deletion mechanism. Indefinite log retention is not compliant.

Data-subject rights. Residents have the right to access, correct, delete, restrict, port, and object to processing of their personal data. The agent architecture must expose a request path — typically via a controller-side intake form and an internal workflow that includes the agent's logs and any derived embeddings. Vector stores and retrieval indexes are in scope; "we cannot delete from the embeddings" is not a valid response.

Scoped API access. The agent's service account or API token must read from a personal-data view, not the raw CRM. We implement this as a database view, a GraphQL field-level permission, or a BSP-side filter — wherever the integration layer naturally lives. The scope is documented and reviewed quarterly.

Audit logs. Every personal-data access by the agent — read, write, outbound message, tool call — is logged with timestamp, actor, purpose code, and the data-subject identifier. Logs are immutable, time-stamped, and retained for the audit window agreed with the controller (typically 24 months for active conversations, 7 years for de-identified records).

Decision-trace records. For every agent decision that affects a data-subject (escalation, qualification verdict, automated reply), the trace records inputs, intermediate reasoning, tool invocations, and the final action. This is the evidence pack you produce on a data-subject access request or regulator inquiry.

Retention windows and deletion paths. Conversation transcripts and derived embeddings have explicit time-to-live values. A deletion request triggers a workflow that removes the record from primary storage, the audit log, and any vector index. We test the deletion path quarterly.

Opt-in for outbound WhatsApp. TDRA opt-in evidence is captured at the point of consent and surfaced in the audit log. The agent never initiates outbound marketing without a verifiable opt-in record. Transactional messages (order updates, appointment reminders) follow a narrower contractual-necessity carve-out and are documented separately.

Legitimate-interest boundaries. Where legitimate interest is the lawful basis, the controller produces a balancing test before deployment and reviews it annually. The test documents the interest, the necessity, and the data-subject impact assessment. Direct marketing is excluded from legitimate interest under UAE practice.

The PDPL is the floor. Three overlays raise it for specific sectors.

DIFC Data Protection Regulation 10 applies to financial-services firms licensed in the Dubai International Financial Centre. It adds AI-specific obligations on ethics, fairness, transparency, security, and accountability — demonstrably so during a DFSA examination. See our dedicated DIFC Reg 10 reference page.

DHA AI guidance covers the Dubai Health Authority's framework for AI in healthcare facilities. Operational AI (scheduling, documentation, intake) is held to a lower bar; clinical-decision systems carry full registration, validation, and traceability obligations.

TDRA rules govern outbound digital messaging — opt-in capture, unsubscribe handling, and marketing-channel-specific consent. Any agent that originates outbound WhatsApp, SMS, or email marketing is in scope.