This is our published view
The bench stands behind it
For your facts, in confidence, put the question to the firm.
The bench stands behind it
The position
Regulation 10 of the DIFC Data Protection Regulations is the first instrument in the region to name artificial intelligence, and its method is worth stating before its detail, because the method is the point.
Regulation 10 of the DIFC Data Protection Regulations is the first instrument in the region to name artificial intelligence, and its method is worth stating before its detail, because the method is the point. It does not regulate the algorithm. It relocates data-protection responsibility onto the people who deploy and operate the system, and gates the commercial use of such systems behind a set of design principles and, for the highest-risk uses, a certification regime and a dedicated officer. Its defining move is a deeming provision: a Deployer of a system is deemed to be the Controller of the personal data that system processes, and an Operator is deemed to be the Processor, regardless of whether either of them controls how the system works (Data Protection Regulations, Regulation 10.3.4). The question in the title has a precise answer, and it is the whole architecture: responsibility lands on the entity under whose authority or for whose benefit the system runs, not on the machine and not necessarily on whoever built it.
Two features of the regime should be held in view from the outset. First, Regulation 10 is certification-based, not licence-based. There is no licence to obtain; the Commissioner’s own guidance describes the scheme as permissive and certification-led rather than requiring any licence or registration (Guidance on Regulation 10.2.2(c)). Second, and most consequentially, the gate on high-risk uses may currently be shut. Regulation 10.3.3 permits the commercial use of a system for High Risk Processing only where, among other conditions, the Commissioner has established audit and certification requirements for such systems, and the guidance states the regulatory intent plainly: no system may be used for High Risk Processing Activities until the Commissioner has promulgated those requirements (Guidance on Regulation 10.3.3). Whether those requirements have in fact been established is the determinative open question this article returns to in Section V.
This is a DIFC instrument and it binds only in the DIFC. A firm on the UAE mainland is governed by the federal Personal Data Protection Law, whose treatment of automated processing is objection-shaped and examined in the companion article on the federal law. The two regimes reach the same technology and do very different things with it, a contrast Section VII draws.
The trigger is a defined “System,” and the definition does the sorting. A System is any machine-based system operating in an autonomous or semi-autonomous manner that can process personal data for human-defined purposes or purposes the system itself defines, or both, and that generates output on the basis of such processing (Regulation 10.1.1(a)). Two boundaries follow from the words. Autonomy is the gate: the Commissioner’s guidance states that purely automated systems, meaning systems with no degree of autonomy whose operation is deterministically controlled by humans, are not intended to be caught by this definition and remain governed by the Law’s ordinary automated-processing provisions (Guidance on Regulation 10.1.1(a)). So a deterministic rules engine is outside Regulation 10 and inside the general Law; a system with genuine autonomous or semi-autonomous operation is inside Regulation 10. And personal data is the second gate: as with every data-protection instrument, a system that processes no personal data is outside the regime.
The second gate has a striking extension, and it sits in the guidance rather than the operative clause, which is where its weight and its limit both lie. The guidance to Regulation 10.1 states that because a system is itself made of data, a system that resembles the physical appearance or behaviour of an identifiable natural person, even where the resemblance is unintended and even in circumstances where the system is not used to process any personal data, will itself be considered to be processing the personal data of that person (Guidance on Regulation 10.1). Read for what it says, this reaches a synthetic voice or an avatar that resembles a real person and treats the mere operation of that system as processing that person’s data, with no database in sight. This is the Commissioner’s interpretive position expressed in guidance, not a rule stated in the operative text of Regulation 10.1.1, and that distinction should be marked rather than smoothed: it is a strong indication of how the Commissioner reads the personal-data gate, and it should be treated as a live risk for anyone deploying a human-resembling system in the DIFC, but it is guidance construing the Law, not black-letter regulation.
Regulation 10 introduces three actors and then deems two of them into the familiar roles. A Deployer is the person under whose authority, on whose direction or for whose benefit the system is operated, or who receives the benefit of its operation or output, and the definition attaches that status without regard to whether the person operates, supervises or hosts the system, or defines any of the purposes for which it processes personal data (Regulation 10.1.1(b)). An Operator is the provider that operates or supervises the system on a Deployer’s direction and for its benefit, again without regard to whether it controls the processing (Regulation 10.1.1(c)). A Provider is the person that develops the system, or has it developed, to make it available to Operators or Deployers (Regulation 10.1.1(d)). The regime then deems the Deployer to act as the Controller, and the Operator to act as the Processor, in respect of the personal data the system processes (Regulation 10.3.4).
The significance is in what the deeming displaces. The traditional test for a Controller turns on who determines the purposes and means of processing, and the difficulty an autonomous system creates is that no person may, strictly, determine the purposes the system pursues. The Commissioner’s guidance is express that this is the problem the deeming solves: a Deployer should be accountable for how the system processes personal data even where it does not determine the purposes, because it is the Deployer who benefits from the operation and under whose authority the system runs, its position analogised in the guidance to that of an employer answerable for an employee (Guidance on Regulation 10.3.4). The operative consequence for a DIFC firm is direct and often unwelcome: a firm that licenses a third-party model and runs it for its own benefit is the Controller of the personal data that model processes and answers for it, even though a vendor built the model, hosts it and determines how it behaves. Responsibility follows benefit and authority, not authorship and not technical control.
The obligations begin at the training data and run through to a standing register. The general requirements and principles of the Law for processing personal data apply to a Deployer and Operator in respect of personal data processed for use in, or to enable the learning processes of, any system (Regulation 10.2.1), so the data used to train or fine-tune a system is within the regime, not only the data it processes in production. This is a point many system-buyers miss: the lawful basis and the principles reach the training set.
The transparency obligations are specific and itemised. Where an application or website service uses a system to process personal data, the Deployer or Operator must give clear and explicit notice on first use alerting users to any processing that is not human-initiated, controlled or directed, and indicating the impact on individual rights (Regulation 10.2.2(a)). That notice must carry a true and plain description of the human-defined purposes for which the system processes personal data, the human-defined principles and limits within which the system may itself define further purposes, the output the system produces and how it is used, the design principles and built-in safeguards, and the codes or certifications on which the system relies, the provision naming among others the OECD, UNESCO, the NIST AI framework, the Dubai Digital Authority and the enabling-technologies guidelines of the UAE financial regulators (Regulation 10.2.2(b)). Beyond notice, the Deployer or Operator must be able to produce on request evidence of the system’s certification compliance, and evidence of the algorithms that make the system seek human intervention in three defined situations: where processing may have an unfair or discriminatory impact on a data subject, where personal data must be accessed by government or law-enforcement authorities, and where processing may breach the digital-communications rules of Regulation 9, in each case with a risk and impact assessment (Regulation 10.2.2(c) to (f)). Finally, a standing register must be available on request, recording the use cases, how data subjects can access their data, whether the system is used solely to make automated decisions, the third parties involved, the lawful bases relied on, and where personal data is exported and under what safeguards (Regulation 10.2.2(g)). Intellectual-property redaction of the evidence is permitted, but the full unredacted material must go to the Commissioner on request (Regulation 10.2.2(h)).
One cross-reference sharpens the transparency duty into an enforcement exposure. Misleading notices or public representations about a system’s certification or adherence to standards are named, by cross-reference to Regulation 10, as an unfair or deceptive practice the Commissioner may investigate and act on (Regulation 6.2.2). A claim of Regulation 10 compliance that does not hold is therefore not merely a compliance gap; it is itself an enforceable contravention.
Regulation 10 sets two gates on commercial use, and reading them structurally is where the operative content sits. The first is general. No person may make a system available for commercial use to process personal data unless the system processes personal data only for human-defined or human-approved purposes, or for purposes the system defines solely on the basis of human-defined principles and solely within human-defined limits, and is designed in compliance with the five design concepts of Regulation 10.3.1, being ethical, fair, transparent, secure and accountable (Regulation 10.3.2). The autonomy cap here is real and is easily underread: the guidance requires that any purpose a system generates for itself must rest on an exhaustive set of detailed principles hard-coded by humans that the system cannot change (Guidance on Regulation 10.2.2(b)). A genuinely open-ended system that can define its own processing purposes outside fixed human constraints does not clear this gate.
The second gate is for High Risk Processing, and on its own terms it may currently be closed. No person may use a system commercially to engage in High Risk Processing Activities unless the Commissioner has established audit and certification requirements for such systems, the system complies with them, it processes personal data solely for human-defined or human-approved purposes, and the Deployer or Operator has appointed an Autonomous Systems Officer (Regulation 10.3.3). The first of those conditions is a precondition, not a description: the permission is available only where the Commissioner has established the certification requirements. Reading the conditional as written, if those requirements have not been established, condition (a) is not met, the exception does not open, and the prohibition in the opening words governs. This is an interpretation of the conditional structure rather than a statement Regulation 10 makes in one sentence, and it is marked as such; but the Commissioner’s own guidance points the same way, stating the regulatory intent that no system may be used for High Risk Processing until the certification requirements are promulgated (Guidance on Regulation 10.3.3). The determinative factual question is therefore whether the Commissioner has by now established the audit and certification requirements for high-risk systems. If it has, the gate operates as a certification hurdle; if it has not, the gate is shut and High Risk Processing through an autonomous system is not permitted in the DIFC at all. That question is an open item, flagged in the note, and it is the single most important thing a DIFC deployer of a high-risk system needs to resolve against current Commissioner guidance before proceeding.
Two precision points attach to this gate. The Autonomous Systems Officer, defined by reference to the competencies and role of a Data Protection Officer under the Law, is required only for High Risk Processing through a system (Regulation 10.3.3(d)), not for every use of a system; the common statement that Regulation 10 requires an ASO is true only for the high-risk case. And the records exemption for small entities falls away here: the reduced record-keeping available to a Controller or Processor employing fewer than fifty persons does not apply where it engages in High Risk Processing Activities (Regulation 2.2), so a small DIFC firm doing high-risk AI carries the full records burden.
The content of the High Risk Processing Activities definition itself sits in the Law rather than the Regulation, at Schedule 1, Article 3 of DIFC Law No. 5 of 2020, to which Regulation 10.3.3 refers; its detailed terms should be confirmed against the Law before reliance, and this article does not restate them from the Regulation alone.
A system that processes personal data and moves it abroad meets the Law’s cross-border regime, and Regulation 10 feeds it. Transfers out of the DIFC to a jurisdiction without an adequate level of protection require the Commissioner’s standard contractual clauses (Regulation 5), and the register a Deployer must keep expressly records where third parties processing the system’s data are located and the safeguards for exporting to them (Regulation 10.2.2(g)(vii)). The list of jurisdictions treated as adequate is set out in Appendix 3 and includes the ADGM, the United Kingdom, the EU member states, Singapore and others, so a transfer from a DIFC system to an ADGM or EU recipient runs on adequacy while a transfer to a non-adequate jurisdiction runs on the clauses. For the cross-border structures this series examines, the practical point is that the AI layer does not change the transfer analysis; it adds a register obligation on top of it.
Binding now, on Regulation 10’s own text: the deeming of Deployer and Operator into Controller and Processor; the transparency, notice, evidence and register obligations of Regulation 10.2; the general commercial-use gate and its five design principles; the autonomy cap on self-defined purposes; and the transfer and records provisions. Waiting on the Commissioner: the audit and certification requirements for high-risk systems, whose absence, on the reading above, holds the High Risk Processing gate shut, and the general certification requirements the guidance anticipates for systems used in ordinary processing. The scheme is drawn so that its hardest edge, the high-risk regime, only becomes operable when the Commissioner acts, and until then the safe reading for a high-risk deployer is restraint, not the assumption that silence is permission.
Set against the federal law, the divergence is instructive. The mainland Personal Data Protection Law reaches AI through a single objection-shaped provision that lets a data subject object to an automated decision and demand a human review, with no AI-specific gate on deployment. The DIFC does something structurally different: it deems the deployer into controllership, imposes a design-and-transparency code, and gates high-risk deployment behind certification and a dedicated officer. Same technology, two regimes, and the choice of incorporation decides which governs.
A word on lineage, kept to what the loaded text supports. Regulation 10’s own guidance states that its definition of “System” was adapted from the OECD guidelines and the then-draft EU AI Act, and that its “Deployer” concept was adapted from the EU AI Act and from a Chinese draft measure on generative AI (Guidance on Regulation 10.1.1(a) and (b)). That the DIFC borrowed these concepts is therefore established on the instrument itself. A substantive comparison of how Regulation 10 and the EU AI Act now treat a deployer, or of how the deeming provisions sit against the GDPR-lineage controller test the DIFC Law otherwise shares, requires those instruments to be loaded and read, which this article has not done; the EU AI Act (in force since 2024 with phased application), the GDPR (in force since 2018) and the emerging US state frameworks are named here only with their status flagged, and the divergence analysis is reserved for a piece that loads them. The lineage matters precisely because the DIFC took a term from a product-safety-style AI regime and put it to work as a data-protection deeming, and naming that difference accurately is worth more than asserting it from memory.
The refresh triggers follow from the open items. The first and largest is any establishment by the Commissioner of the audit and certification requirements for high-risk systems, which would convert the shut gate into a certification hurdle and should be checked against current Commissioner guidance before any high-risk deployment. The second is any new consolidated version of the Regulations superseding Version No. 2. The third is any amendment to the underlying DIFC Data Protection Law No. 5 of 2020, into which several of Regulation 10’s cross-references resolve. The answer to the question in the title is settled on the text: in the DIFC, the person responsible when an AI system processes personal data is the Deployer, deemed the Controller, with the Operator deemed the Processor beside it, and the reach of that responsibility is fixed by benefit and authority rather than by control of the machine.
For your facts, in confidence, put the question to the firm.
The bench stands behind it