UAE DPL AI Controls Mapping: Owner, Test, Evidence and Coverage

The UAE Personal Data Protection Law, issued as Federal Decree Law 45 of 2021, came into force on 2 January 2022. The UAE Government's official data-protection summary describes confidentiality and privacy, data-management governance, electronic processing inside and outside the UAE, processing controls, consent with stated exceptions, security, correction, restriction or cessation requests, and cross-border transfers.

A controls mapping adds implementation fields that the official summary leaves open: objective, owner, control point, test, evidence and coverage. I use Full when a control can be enforced on authenticated HTTP traffic to an LLM, Partial when that path supplies one component or evidence, and Outside when the operative decision belongs elsewhere. This is an implementation mapping, with counsel responsible for statutory interpretation.

Scope and regime determination

Objective: identify the legal entity, processing activity and data-protection regime governing each deployed AI feature.

Owner: privacy and legal, with the business system owner supplying facts.

Control: maintain a register naming the entity, AI feature, purpose, personal-data categories, provider, model endpoint, processing region, role and go-live date. Record the approved regime for each row. The official UAE page separately references DIFC Law No. 5 of 2020, so entity and location analysis belongs at the start.

Test and evidence: select one production system and produce its scope memorandum, architecture diagram, endpoint list and dated legal approval. Reconcile the stated route against seven days of observed AI traffic.

Coverage verdict: This control receives Partial coverage. Request records provide route and region facts. Legal determines scope and regime.

Processing purpose and basis

Objective: connect each personal-data use to a specific purpose and a documented consent event or applicable exception.

Owner: product defines the purpose. Privacy and legal approve the processing basis.

Control: assign a stable purpose identifier to each approved AI feature, then map permitted roles, data classes and model destinations to that purpose. Keep the consent record or exception analysis linked to the same identifier.

Test and evidence: use a support-agent identity to send a synthetic customer record to the approved support model, then attempt the same payload against an unapproved general assistant. Retain the purpose register, basis decision, permit record and denial record.

Coverage verdict: Full for purpose-bound destination enforcement when the application supplies the approved purpose. Basis selection, notice and consent handling remain Outside.

Personal-data classification and minimisation

Objective: identify personal data inside the outbound AI payload and reduce processing to the fields required by the approved purpose.

Owner: security and data governance, with product defining necessary fields.

Control: classify prompts before transmission, attach the result to the decision context, and apply redaction or refusal rules for excess or prohibited classes. Treat context assembled by retrieval as part of the same payload.

Test and evidence: send a synthetic customer name, account number, support history and unrelated internal note through a task that needs only the account number and issue category. Keep the classifier output, transformed payload, policy version and decision record.

Coverage verdict: Full for payloads crossing the routed HTTP AI boundary. Upstream source quality, retrieval-store permissions and provider-held copies receive separate controls.

Security and confidentiality

Objective: protect personal data against unauthorized AI processing and preserve evidence of each control decision.

Owner: security engineering and AI platform engineering.

Control: bind the originating identity and role to every request, authorize the model route, apply data-class rules, fail closed when policy evaluation lacks required context, and write an independent record outside the calling application's custody.

Test and evidence: remove the origin identity, select an unknown endpoint and induce an evaluator timeout on 11 August 2026. Each request should receive the documented restrictive outcome and produce a signed record naming the applied rule.

Coverage verdict: Full for authenticated HTTP traffic routed through the enforcement point. Endpoint security, cloud IAM, credential lifetime, storage access, local execution and model training stay Outside.

Cross-border transfer control

Objective: ensure each overseas model route matches the transfer arrangement approved by legal and procurement.

Owner: legal and procurement approve the arrangement. AI platform engineering enforces endpoint and region policy.

Control: map each provider hostname and region to a dated legal review, agreement and configuration owner. Evaluate that route map on every request and alert on drift.

Test and evidence: change a test SDK base URL to a region absent from the approved register. Retain the transfer assessment, provider agreement, route map, denied request and alert.

Coverage verdict: Full for technical route enforcement, Partial for the overall transfer responsibility. Legal adequacy and provider-side onward processing sit outside the request gateway.

Correction, restriction and cessation requests

Objective: locate AI-related processing about an individual and execute approved correction, restriction or cessation actions across affected systems.

Owner: privacy operations and data governance.

Control: operate a rights workflow backed by a searchable disclosure history. Include a stable data-subject reference in the request context when the subject differs from the authenticated caller. Propagate approved actions to enterprise and provider stores.

Test and evidence: query a synthetic subject across a fixed date range, identify each model provider that received the data, and route a correction or restriction through the relevant systems. Keep the verified request, disclosure export, action tickets and response.

Coverage verdict: This control receives Partial coverage. Runtime records supply disclosure history, and future route policy can enforce a reliable restriction flag. Identity verification, legal decisions, source correction and provider-side execution stay Outside.

Data accuracy and output handling

Objective: keep personal data used in consequential decisions accurate and prevent unreviewed AI output from changing a source record.

Owner: data governance and the business decision owner, supported by model risk.

Control: validate source data, define review thresholds, preserve request and response provenance, and require a named human approval before consequential output updates an authoritative record.

Test and evidence: seed a synthetic inaccurate account fact into a model response, route it through the review procedure, and confirm the authoritative customer record stays unchanged until approval. Retain the source snapshot, response, reviewer action and correction ticket.

Coverage verdict: This control receives Partial coverage. A gateway can preserve provenance and restrict routes or data classes. Truth assessment, human review and source-record correction remain Outside.

Change control and policy traceability

Objective: prove which approved policy governed a specific AI request at a specific time.

Owner: security governance and AI platform engineering.

Control: version every policy, require approval and test evidence before deployment, bind the exact version to every decision record, and assign a rollback owner.

Test and evidence: take one sample immediately before a staged rule change and another immediately after deployment. Reconstruct the expected difference using the change request, approval, test output, deployment timestamp and two decision records.

Coverage verdict: Full for runtime policy-version binding. Governance approval quality and application changes outside the gateway remain separate responsibilities.

Incident investigation and response

Objective: produce a bounded set of AI requests affected by suspected personal-data exposure and connect it to containment and legal assessment.

Owner: incident response with privacy and legal.

Control: query events by time, originating identity, data-subject reference, data class, destination, policy outcome and version. Preserve containment actions and route the set into the organization's privacy-incident procedure.

Test and evidence: run a tabletop involving an agent attempting to send personal data to an unapproved model endpoint. Produce the affected set within one working day, then record containment, assessment ownership and follow-up stores.

Coverage verdict: This control receives Partial coverage. Runtime evidence bounds routed traffic. Legal assessment, notifications, endpoint investigation and provider response remain Outside.

The consolidated mapping

• Scope and regime: Privacy and Legal own governance; trace one production system; retain scope, route and approval evidence; Partial coverage.
• Purpose and basis: Product, Privacy and Legal own purpose and basis; test approved against unapproved routes; retain the purpose, basis and two decisions; Full runtime and Outside legal coverage.
• Classification: Security and Data Governance own payload handling; test excess data; retain the class, transformed payload and decision; Full runtime and Partial overall coverage.
• Security and confidentiality: Security and Platform own the AI request boundary; test identity, route and timeout failures; retain three signed decisions; Full runtime and Outside adjacent-system coverage.
• Cross-border transfer: Legal and Platform split agreement and route work; change the model region; retain the review, map and denial; Full runtime and Partial overall coverage.
• Rights requests: Privacy and Data Governance own the workflow; run a subject-range query; retain the export, actions and response; Partial coverage.
• Accuracy and output use: Business and Data Governance own review; seed an inaccurate fact; retain provenance, reviewer action and ticket; Partial coverage.
• Policy traceability: Security Governance and Platform own change plus runtime binding; sample before and after a policy deployment; retain approval, versions and events; Full runtime coverage.
• Incident response: Incident Response, Privacy and Legal own query and assessment; run a timed tabletop; retain scope, containment and review; Partial coverage.

The consolidated mapping contains several Full runtime verdicts and zero areas that turn wholly green through an HTTP gateway purchase. Its useful result is the boundary itself: a mapping that labels legal basis, rights execution, data accuracy and transfer approval as solved by request inspection has confused technical evidence with legal performance.

My candid view is that cross-border transfer deserves the first board-level challenge. A changed base URL can send production traffic outside the region named by procurement. The agreement records the approved arrangement; the route decision records what actually happened.

Gap ownership and remediation

Every Partial or Outside result needs an owner, evidence link and remediation date. Privacy and legal own scope, basis and rights decisions, while Product owns purpose specificity. Data Governance owns source accuracy and correction, and Procurement manages provider terms. Incident Response handles containment and recovery coordination. Security and Platform Engineering own identity propagation, classification, destination enforcement, policy failure behavior and runtime traceability.

The UAE DPL AI compliance checklist converts these rows into dependency-ordered actions. The UAE DPL AI audit evidence guide packages the resulting artifacts for sampling and reconstruction.

DeepInspect

DeepInspect is the enforcement point behind the Full runtime verdicts and the evidence source for several Partial rows. It sits inline between authenticated users or agents and HTTP-based LLM endpoints. Each routed request is evaluated against identity context supplied by the application, role, purpose-bound policy, personal-data classification and destination before transmission. A fail-closed decision and signed, tamper-evident record sit outside the calling application's write path.

Against this mapping, DeepInspect enforces purpose-scoped model routes, classifies outbound payloads, binds the originating principal to the event, applies endpoint and region policy, records the exact policy version, and supplies disclosure and incident histories. Scope, legal basis, consent, transfer approval, source accuracy, rights decisions and provider-side execution remain with the owners named above. Book a technical deep dive at deepinspect.ai.