UAE DPL AI Audit Evidence: Reconstruct the Request and Its Controls

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 summary describes a federal framework for confidentiality, privacy, data-management governance, processing controls, consent and stated exceptions, correction, restriction or cessation requests, and cross-border transfers.

An AI audit has to connect those governance statements to a particular request. The useful evidence chain starts with the approved purpose, follows the authenticated person or agent, identifies the personal data and model destination, and ends with the policy decision plus the resulting disclosure record. I want to build that chain as an assessor would test it, one artifact at a time.

Scope and processing record

The official UAE summary says the law covers personal-data processing performed wholly or partly through electronic systems, including processing inside and outside the country. Applicability still needs a legal decision for the entity, activity and location involved. The same official page points separately to DIFC Law No. 5 of 2020, which is a practical warning against treating every UAE deployment as one undifferentiated regime.

Create one scope record per AI system. Name the legal entity, business owner, AI feature, processing purpose, personal-data categories, model provider, endpoint, region, go-live date and applicable regime. Add the organization's role and the provider's contractual role after counsel reviews the arrangement.

Reconciliation provides the first test: compare the approved endpoint inventory with seven days of observed HTTP AI traffic. A yellow row showing an Azure endpoint in procurement and a different production hostname in the request log gives the assessor a concrete gap to investigate.

Purpose, consent and exception evidence

The UAE Government summary says processing without the data owner's consent is prohibited, subject to cases including processing necessary to protect a public interest or carry out legal procedures and rights. That summary supports a conditional model rather than a blanket claim that every AI request needs consent.

For each purpose, retain the approved statement, the consent event or documented exception analysis, the notice version, the approval owner and the effective date. Test actual use against those artifacts. A customer-support summarization purpose should map to specified data classes and an approved support-model route. A developer sending the same account history to a general assistant creates a different processing event.

Runtime evidence needs a purpose identifier supplied by the application. A gateway can evaluate that identifier against data class and destination. Legal still decides the valid processing basis. I would reject a spreadsheet containing consent timestamps if the package lacks any record of the endpoint that received the data.

Request and decision evidence

The central technical artifact is one independent record per outbound AI request. Each record should carry a stable event ID, timestamp, originating human or workload identity, asserted role, purpose identifier, personal-data classification, model endpoint, region, policy version, decision and correlation ID. A permitted request, a redaction and a denial should share the same schema.

Independence matters because the application under review has incentives and failure modes of its own. Put the audit writer outside the calling application's write path. Add a tamper-evident signature or chained integrity value, then test verification after export. The evidence package should state retention and access rules for this record set as an operating choice, clearly separated from any legal retention conclusion.

A useful sample includes twenty records across two roles, two destinations, one policy change and one evaluator failure. Reconstruct each event back to the purpose register and forward to the provider route. The chain should fit on one screen without manual joins through four application databases.

Security-control evidence

The official summary says companies holding personal data have general obligations to secure it and maintain confidentiality and privacy. For hosted AI, the request boundary is one place to produce evidence of those safeguards. Classify the outbound payload, authorize the destination against the originating identity, apply the route policy, and record the outcome before transmission.

Test three failure conditions on 11 August 2026. Send a synthetic UAE customer identifier to an unapproved model route. Remove the originating identity from a second request. Force the policy evaluator to time out on a third. The expected restrictive outcome should appear in three signed records with the exact rule and policy version.

This test covers authenticated HTTP traffic to an LLM. Storage permissions, endpoint security, model training, retrieval-database access and local agent execution require separate controls. The audit file should name those owners rather than painting the request gateway green for their work.

Cross-border transfer evidence

The UAE Government summary states that the law sets requirements for cross-border transfer and sharing of personal data for processing. The legal mechanism and destination assessment belong in the privacy and legal file. Runtime evidence answers the factual question of where an AI payload went.

Build a transfer register that maps every approved model endpoint and region to the legal review, provider agreement, configuration owner and approval date. Bind each runtime decision record to the matched destination row. Then change a test SDK base URL to an unapproved region and retain the denial plus its alert.

Procurement records may show the intended region while routing records show the actual one. Both belong in the package. The contract establishes the approved arrangement; the request record establishes observed production behavior. The UAE DPL AI controls mapping assigns those two artifacts to their proper control owners.

Data-subject rights evidence

The official summary names rights to request correction of inaccurate personal data and to restrict or stop processing. A rights package needs an intake workflow, identity-verification record, decision, response and execution evidence across the stores that hold the person's data.

Runtime AI records contribute a disclosure history. That history needs a stable data-subject reference when the person described in a prompt differs from the authenticated caller. Select a synthetic subject, send the record through an approved model route, and confirm that the rights workflow can retrieve the event by subject reference, date and provider. Then route a correction or restriction instruction to each affected system and keep execution evidence.

A gateway supplies the searchable event and can enforce a future restriction when the application sends a reliable subject reference. Customer-master correction, provider-side deletion and legal review sit with privacy, data governance and procurement.

Sampling and reconstruction package

Package the evidence in an order an independent reviewer can follow:

• Scope: entity and AI system register, supported by endpoint reconciliation.
• Purpose and basis: purpose, consent or exception file, supported by the purpose-policy match.
• Security: design, test plan and remediation, supported by per-request decisions.
• Transfer: legal review and provider agreement, supported by endpoint and region history.
• Rights: intake, decision and execution records, supported by searchable disclosure history.
• Change control: approval and policy version history, supported by the version bound to each request.
• Incident response: assessment and containment file, supported by a bounded affected-request set.

Start with a denied request. A permitted event proves that traffic moved. A denial demonstrates an independent decision at the control point, and the red result beside policy version uae-dpl-07 is more persuasive than a slide promising enforcement.

Evidence outside the HTTP request path

A full UAE DPL review covers work beyond an AI gateway. Counsel determines applicability and the processing basis. Privacy drafts notices, manages consent and exceptions, handles rights requests and interprets transfer requirements. Procurement manages provider terms. Data governance corrects, restricts and removes data across enterprise stores. Security covers endpoints, secrets, networks and storage.

The request-path package contributes proof of actual AI processing. It should be labeled as one evidence source within the wider compliance file. This boundary also prevents unsupported claims that a runtime record alone satisfies the federal framework.

DeepInspect

DeepInspect supplies the independent request and policy record for authenticated users or agents calling HTTP-based LLM endpoints. It evaluates identity context supplied by the application, role, purpose-bound policy, data classification and destination before forwarding the request. Each permit, redaction or denial produces a signed, tamper-evident record outside the calling application's custody.

For UAE DPL AI audit evidence, those records connect approved processing to observed traffic, show the security decision applied to the prompt, identify the model endpoint and region, bind the event to a policy version, and produce a bounded request set for rights or incident work. Scope, legal basis, contracts, provider-side handling and enterprise data correction remain with their named owners. Book a technical deep dive at deepinspect.ai.