DIFC Regulation 10 for AI deployers: notices, evidence and certification

Regulation 10 sits inside the Data Protection Regulations made under the DIFC Data Protection Law, DIFC Law No. 5 of 2020, and has been in force since 1 September 2023 [2, 7]. It is not a separate AI law. It adds rules for one kind of processing, personal data processed through autonomous and semi-autonomous systems, on top of everything the Law already asks of a controller [2, 3].

The Law reaches past the DIFC’s boundary. It applies to a controller or processor incorporated in the DIFC wherever the processing happens, and to processing inside the DIFC by any controller or processor as part of stable arrangements, wherever that firm is incorporated [1]. A DIFC firm running a model in a European or US cloud region is inside it. Transfers out of the DIFC are governed by Articles 26 and 27 of the Law [1, 4], and which region actually runs a model, and what to ask a vendor about it, is covered in the architecture questions for Gulf AI data residency.

A System, in the regulation’s words, is “any machine-based system operating in an autonomous or semi-autonomous manner” that can process personal data for purposes people define, purposes it defines itself, or both, and generate output from that processing [2]. The Commissioner’s guidance says purely automated systems, with no autonomy and deterministically controlled by people, are not meant to be caught, because the Law already covers automated processing [3]. A language model assistant, a retrieval system that drafts answers or an agent that picks its own tools is a System. A rules engine that scores a form the same way every time is probably not.

One note catches people out. If a System resembles the appearance or behaviour of an identifiable person, by design or by accident, the guidance note to Regulation 10.1 says that operating it counts as processing that person’s personal data, even when it processes no other personal data at all [2, 3]. A voice clone or an avatar of a real employee is in scope on that note alone.

Regulation 10 adds three roles because the Law’s usual test, who decides the purposes of the processing, is hard to apply when a system sets some of its own purposes [2, 3]. Here is how they map onto the controller and processor the Law already knows.

The definitions are from Regulation 10.1.1 and 10.3.4 [2], and the provider row’s last cell is the Commissioner’s guidance [3]. The guidance compares a System running under a deployer’s authority to an employee: the deployer is liable for what it does and must keep it inside the limits it sets, much as it would train staff to follow its privacy policies [3].

My reading is that the deployer label is deliberately wide. A bank in the DIFC that licenses a vendor’s AI assistant for its relationship managers is the deployer of that assistant, and nothing in the vendor’s terms moves that duty back to the vendor.

Regulation 10.2.2 applies where an application or website service uses a System to process personal data, and it puts the duties on the deployer or the operator [2]. Read as an engineering team has to read it, it asks for three things: a notice, evidence on request and a register.

The first column is the Regulations [2] and the Law [1]. The middle column is my plain reading of the text, and this page is not legal advice.

Two details matter more than they look. Evidence under (c) to (f) can be redacted or summarised to protect intellectual property or to comply with other laws, but only as far as necessary, and the full version goes to the Commissioner on request [2]. The DIFC’s FAQs say the evidence can take the form of policies, governance frameworks and principles documents [4]. I would treat that as the floor. A policy saying the System escalates unfair outcomes is weaker evidence than the escalation rule itself, its tests and a log showing it firing.

The principles clause in 10.2.2(b)(v) is more useful than it looks. The notice names the principles the System was built on, and the regulation lists sources it will accept, among them the Dubai Digital Authority, the OECD, UNESCO, the NIST AI framework and the guidelines for financial institutions adopting enabling technologies published by the UAE’s financial regulators [2]. The guidance calls this plug and play: pick a recognised set rather than invent one [3]. An AI policy that maps each clause to a control is how that set becomes something the System enforces.

The regulation sorts a System’s purposes into two kinds. Human-defined purposes are set by people and hard-coded, and the System cannot change them. Self-defined purposes are ones the System generates itself, and the guidance says those must come from an exhaustive set of detailed principles that people define and the System cannot change [2, 3].

Regulation 10.3.2 makes that a condition of commercial use. Nobody may use, operate or offer a System to process personal data commercially unless it processes only for purposes that are human-defined or human-approved, or set by the System solely on human-defined principles and within human-defined limits, and unless it is designed to the five concepts in Regulation 10.3.1: ethical, fair, transparent, secure and accountable [2]. Transparent has a specific meaning here, processing that can be explained to data subjects and other stakeholders in non-technical terms, with supporting evidence [2].

For an agent, this is concrete. The purposes are the jobs the agent may do. The principles and limits are the tools it may call, the data it may read and the actions it may not take without a person, and all of it belongs in configuration the agent cannot rewrite. An agent that can widen its own permissions fails this test however good its outputs are. The design that passes is the one where the model proposes and a gate decides.

The Law adds its own rule on decisions. A person can object to a decision based solely on automated processing that has legal or similarly serious consequences and ask for a manual review, and a controller relying on the contract or explicit consent exceptions must still offer that review [1].

The Law defines High Risk Processing Activities as processing where any one of four things applies [1].

The first limb is the one AI meets. Personal data that has gone into a model or an index is hard to rectify or erase, which is the Law’s own test of rights made harder to exercise, and the Commissioner’s guidance warns that generative AI in particular can make shared information indelible [1, 3]. On my reading, a generative AI system in production on customer data at a DIFC firm should be treated as high risk unless its assessment shows otherwise. A pilot on synthetic data usually is not. To decide which systems to assess first, a six-factor score for each use case is a quick start.

Under the Law, high risk processing already means a data protection impact assessment before it starts, and a data protection officer where it happens on a systematic or regular basis [1]. Failing either carries a maximum administrative fine of USD 50,000 in the Law’s schedule [1]. Regulation 10.3.3 then sets four conditions before anyone may use, operate or offer a System commercially for high risk processing: the Commissioner has set audit and certification requirements, the System meets them, it processes personal data solely for human-defined or human-approved purposes, and the deployer or operator has appointed an Autonomous Systems Officer with the competencies, status and tasks of a data protection officer [2].

The guidance note to Regulation 10.3.3 states the intent that no System be used for high risk processing until the Commissioner has set certification requirements [2, 3]. He has. The Regulation 10 Accreditation and Certification Framework, which the guidance and FAQs of August 2024 already point to, sets out how accredited certification bodies assess a System, and the DIFC’s Regulation 10 page lists four accredited bodies, one of which certifies only its own internal systems [3, 4, 5, 7]. The System is certified, not the firm, and a certificate lasts up to three years, with at least one audit in that time [4, 5].

The Commissioner’s portal guide, updated on 10 August 2026, sets out the route. You assess whether the System does high risk processing for commercial use, answer preliminary questions on the DIFC portal (USD 100 for a DIFC entity, USD 200 for others, not refundable), choose a certification body, complete a detailed questionnaire and wait for the Commissioner’s final decision [6]. The guide says certification bodies’ application fees are currently capped at USD 5,000, and that the assessment belongs early, before commercial use starts or continues [6].

Two words decide how far this reaches. “Commercial use” is not defined in the regulation: the DIFC’s FAQs liken it to placing a System in the consumer market under the EU AI Act, with a consumer-protection element, and the guidance says the Commissioner may consider Regulation 10.3.3 case by case [3, 4]. If you are unsure whether an internal tool counts, the Framework points to a prior consultation with the Commissioner under Article 20 of the Law before you deploy [5]. I would take that route rather than argue the point afterwards.

The Autonomous Systems Officer is a new role. The guidance says it will at first work much like a data protection officer’s, running impact assessments and reviewing risks and processing with senior management [3]. The Framework adds that the officer needs technical knowledge of the System, and that a certified System should not run for more than a month without one [5]. The same person can hold both roles, and the guidance says the Law’s Article 19 assessment, which it ties to the data protection officer, reaches the Autonomous Systems Officer only where they do [3].

This is the order I would work in for one System at a DIFC firm. It is built from the texts above, not a sequence the Commissioner sets.

Nearly all of that list is evidence the System should produce as it runs. Evidence that exists only as documents written beside the System drifts from it within months, and an assessor will find the gap.

The work on this page is what we sell as AI governance implementation: the notice, the register, the escalation rules and the evidence built into the System they describe, so an assessor or the Commissioner sees what the System actually does. For a DIFC firm that usually starts with one System and the high risk test, and ends with a System whose Regulation 10 evidence comes out of its own logs. We are not a certification body and we cannot certify anything. We build what a certification body assesses, and whether it passes is for that body and the Commissioner.

We work with clients across the UK, the US and the Gulf, and clients in the UAE can contract locally through our UAE entity. We have built Arabic-language AI, including bilingual Arabic and English search and Arabic document OCR. Our closest published work in the region is the production estate of a government-accredited EdTech in the Middle East, whose database we replatformed into Google Cloud’s Doha region, me-central1, to meet Gulf data-residency requirements. Once a scope is signed, a fixed-scope build can start within a day, and if you already have a scoped job, we can resource it on contract from the collective of associates who work with us, held to the same standard. The call is booked from the end of this page.