DIFC Regulation 10, explained for platform owners

The Dubai International Financial Centre was one of the first jurisdictions to regulate autonomous and semi-autonomous systems directly. If you operate AI on personal data in the DIFC, Regulation 10 is your operating manual — and your architecture decides how painful it is.

What Regulation 10 covers

Regulation 10, made under the DIFC Data Protection Law, addresses the processing of personal data through autonomous and semi-autonomous systems — a definition that squarely captures modern AI assistants and agents. Its core demands will feel familiar to anyone tracking the EU AI Act, and that is deliberate: the DIFC aligned with emerging international norms. The obligations that matter operationally are records of processing, meaningful human oversight, transparency about when a system is acting autonomously, and accountability for outcomes. If your institution also serves EU data subjects, note that the same control set does double duty — alongside GDPR Article 22's constraints on solely automated decisions with significant effects.

Processing records, in practice

The record-keeping expectation is not satisfied by a data inventory spreadsheet. For an AI platform, the regulator's questions are transactional: what data did the system process, on whose behalf, using which model, producing what output, leading to what action? Answering requires per-interaction logging — prompt, retrieved context, model version, response, downstream effect — retained in a form you can produce for a specific date and user on request. Institutions that treat this as a reporting problem end up reconstructing history from application logs never designed for it. Institutions that treat it as an architecture problem write the record at the moment of inference and never reconstruct anything.

Human oversight and tamper-resistance

Regulation 10's oversight expectation parallels the reasoning behind EU AI Act Article 14: a person must be able to understand, intervene in, and override system behaviour — and demonstrate they can. The practical control is an approval gate on consequential actions with a recorded decision trail. Tamper-resistance is the quieter requirement with the sharper teeth: a compliance record that can be silently edited is not evidence, it is testimony. Expect assessors to probe log integrity — append-only storage and cryptographic chaining answer the question before it is asked; database write-access lists do not.

Why deployment architecture decides the audit

Here is the pattern platform owners in financial centres keep rediscovering: shared cloud AI turns every audit into a three-party negotiation between you, your regulator and your provider — sub-processor chains, cross-border transfer analyses, contractual audit rights that stop at the provider's boundary. Per-institution on-prem deployment collapses that conversation. The processing happens on infrastructure the institution controls, in the jurisdiction the regulator supervises, with logs the institution can hand over without a third party's cooperation. For firms also in scope for DORA's ICT third-party risk regime or NIS2, shrinking the external dependency surface simplifies those files too.

• Per-call processing records, written at inference time, retrievable by user and date.
• Approval gates with recorded human decisions on consequential actions.
• Append-only, tamper-evident log storage inside the institution's perimeter.
• A deployment map with no third country and no third party in the data path.

Get those four right and a Regulation 10 conversation becomes a demonstration rather than a negotiation.

Walk through a DIFC evidence pack →