A firm registered in the DIFC adds an assistant that reads client emails, summarises onboarding files and drafts replies for an adviser to approve. Nobody would call it a robot, but the DIFC’s data protection rules do have a name for it: a system operating autonomously or semi-autonomously that processes personal data. Since 1 September 2023, Regulation 10 has said what the company deploying such a system must be able to tell people, and what it must be able to prove.
It is not a licence and there is no form to file for it. It is an evidence obligation, which is easy to meet if it is designed in and awkward to reconstruct later.
Why the DIFC answer differs
A DIFC entity’s personal data is governed by the DIFC’s own Data Protection Law, DIFC Law No. 5 of 2020, and its regulations, not by the federal law that applies on the mainland. The federal checklist for connecting an AI model is a different list. Regulation 10 is specific to the DIFC, and Clyde and Co’s summary of the enactment notes that it supplements the Law rather than replacing any of it.
Are you the deployer or the operator?
Regulation 10 introduces two roles. The deployer is the person or entity that authorises the system or benefits from its operation and output, and carries responsibilities substantially like a controller’s. The operator is the technical provider running the system on the deployer’s instructions, accountable much like a processor. The Commissioner’s guidance on Regulation 10 compares the deployer’s position to that of an employer: the system acts under your authority, so you answer for it.
For most DIFC firms buying an assistant, that settles it. You are the deployer, the supplier is the operator, and the contract between you has to reflect both. If the supplier also uses your clients’ data to improve its own models, it is acting for its own purposes too, and the split stops being simple. Ask the question directly and put the answer in the contract. The guidance also says purely automated systems with no autonomy, whose operation is deterministically controlled by humans, are not what the definition is aimed at. A rules engine is not caught; a language model drafting replies is.
The notice on first use
The first thing Regulation 10 asks for is a clear and explicit notice when someone first uses or accesses the system. It must alert them to technology that may process their personal data without being human-initiated, controlled or directed, and explain how that affects their rights. According to Clyde and Co, the notice also has to describe the purposes the system processes data for, the principles it was designed on, and any codes or certifications it follows.
That is a design task, not a privacy-policy paragraph. Decide where the notice appears: the first screen of a client portal, the first message of a chat, the footer of an email the system drafted. Decide who sees it when the “user” is an employee and the data belongs to a client. Write it so a client can tell what the system does and what it does not. As a starting draft for an email assistant, the portal notice might read: “Some replies you receive are drafted by an automated system that reads your messages and account documents. It drafts for our advisers to review and sends nothing without a person’s approval. It does not make decisions about your account. You can ask for a reply written without it, and ask what data it used.” Each of those sentences is a claim the firm must then be able to evidence, which is the point: the notice doubles as the specification. Keep each version of the notice with the date it went live, because the question will be what a client was told at the time, not what the page says today.
Purposes written down where the system cannot change them
The guidance draws a line between purposes defined by humans and hard-coded into the system, which it cannot change, and purposes the system might generate for itself. Human-defined purposes must always prevail, and any self-defined purpose must stay within principles that people set and the system cannot alter.
In engineering terms, the assistant’s job is written in configuration your team controls: which mailboxes it reads, which actions it may take, which it may only propose. Its instructions are versioned, and a change goes through a named person. That is also the document that says what an agent may decide; under Regulation 10 it becomes evidence as well as good practice.
The evidence you may be asked for
Beyond the notice, Regulation 10 expects the deployer to produce, on request, a register covering the system’s processing: why it is necessary and proportionate, how people can get at their information in it, whether it makes decisions solely by automated means, and where third parties or regulators processing the data are located, with the safeguards for any export. It also expects evidence of audits or certifications claimed, and of the mechanisms that bring in a person where processing could cause unfair or discriminatory impact.
Each of those maps to something built. A log of inputs, outputs and actions, kept for a defined period. A list of every model provider and sub-processor, with the region each one runs in. A review step that is actually used, with its own record. If the system cannot produce these, the company cannot either. Ask how long the log is kept, who can read it, and whether it exports in a form an auditor can open. A log only the supplier can read is not your evidence.
High risk processing changes the answer
The DIFC Law already defines high risk processing. Its triggers include new technology that materially increases the risk to people’s rights, large-scale processing likely to cause high risk, systematic automated evaluation of people that produces legal or similarly significant effects, and a material amount of special category data. A firm doing it regularly must appoint a data protection officer, and the Commissioner’s guidance pairs it with an impact assessment. The line is crossed sooner than founders expect: an assistant reading every client file in a wealth business can meet two triggers at once. Regulation 10 goes further for systems used in high risk processing. Clyde and Co reports that commercial use for such processing is not permitted unless the Commissioner has set audit and certification requirements, the system meets them, it processes data only for human-defined or human-approved purposes, and an Autonomous Systems Officer has been appointed.
The guidance describes that officer as performing a role similar to a data protection officer’s. So the assessment comes first: before the assistant reads a single client file, decide in writing whether the processing is high risk, and if it might be, take that answer to the Commissioner’s office rather than to the launch meeting.
What is changing
On 18 June 2026 the DIFC Authority opened a consultation on amended regulations, with comments due by 18 July 2026. Consultation Paper No. 3 proposes adding safety as a base concept, setting out the officer’s duties and skills, and a new Regulation 11 letting the Commissioner recognise certification schemes. The paper says not to act on the draft until it is enacted, so check the current text on the day you design. A system built around evidence will absorb either version.
Frequently asked questions
Does Regulation 10 apply to staff using a public chatbot?
If staff paste client personal data into it on the firm’s behalf, the firm is processing that data through such a system and the Law applies. That is why unsanctioned use needs a policy before it needs a tool.
Do we need to register the system with the Commissioner?
The guidance describes a certification-based approach rather than a licence or registration for the system itself. Your general data protection obligations as a DIFC entity still apply, including the notification you file with the Commissioner and keep up to date.
Is the supplier responsible instead of us?
No. As deployer you carry controller-like responsibility; the supplier as operator carries processor-like duties. The guidance expects deployers to buy from developers who can give contractual comfort of compliance by design.
What should the notice actually say?
That an automated system processes personal data, for which purposes, on what principles, under which codes or certifications if any, and how this affects the person’s rights. Plain language, at the point of first use.
Who should own this inside the company?
One named person, usually whoever holds data protection, with the technical owner of the system writing the evidence. If the processing is high risk, the Autonomous Systems Officer role comes into play.
The pack to build before launch
Decide whether you are deployer, operator or both. Assess whether the processing is high risk, in writing. Write the purposes into configuration your team controls, and version it. Design the notice into the first screen. Build the log, the provider list with regions, and the review step. Put the operator’s obligations in the contract, and answer the security questions a client will send from the same facts.
Turning a regulation like this into an architecture is the work of an AI consultant, and it starts with four questions before a model touches a live system. If your DIFC firm is planning an assistant on client data, get in touch here.