Your AI systems now need a register, a named officer and evidence.

Regulation 10 supplements DIFC Data Protection Law No. 5 of 2020 and applies to organizations that process personal data through autonomous or semi-autonomous systems. Obligations fall on Deployers and Operators, and the heaviest ones attach to high-risk processing.

The four obligations in practice

1. Certification. High-risk commercial AI systems require certification. It is system-specific rather than entity-specific, so certifying your organization does not certify your next model.
2. An Autonomous Systems Officer. Deployers and Operators carrying out high-risk processing must appoint one to provide independent oversight.
3. A register and an explanation. You maintain a register of your AI systems and must be able to explain the processing, in non-technical terms and backed by evidence, to the people it affects.
4. Risk assessment before processing. Privacy risks are assessed and documented before high-risk processing begins, and then mitigated. Recording a risk is not the same as treating it.

There is also a right to challenge: a data subject can dispute an outcome an AI system produced, which means you need to be able to reconstruct how a specific decision was reached.

Treat scope as a legal question. Whether a given system counts as high-risk under Regulation 10 is a determination to take with counsel, not from a vendor page.

Start with the register. Every other obligation depends on it, because a control cannot attach to a system nobody has written down.

What a register has to hold

• Every system that makes or materially informs a decision, including the ones bought on a card and never reviewed.
• The model and version behind each, so an output can be traced to what produced it.
• What personal data goes in, where it came from, and the lawful basis for using it that way.
• Whether a human approves the outcome, and who that is by role.
• The risk assessment, its date, and what was done about what it found.
• The infrastructure nobody registers: vector stores, prompt and response logs, review queues, evaluation sets and reporting extracts.

That last line is where assessments fail. The model gets scrutinised carefully. The components around it were stood up during a pilot and never entered the governance process at all.

This is the same register ADHICS asks Abu Dhabi healthcare providers to keep for information assets. If you already maintain one, you are further along than you think.

Before building anything, we establish what you actually run and where it stands against the regime that applies to you.

What the assessment produces

• A complete inventory of AI and automated decision systems in use, including shadow deployments.
• A risk tier per system, with the reasoning written down so the classification can be defended or revised.
• A mapping from each system to the obligations that reach it: PDPL, your sector standard and, where you are DIFC-licensed, Regulation 10.
• The gaps, ranked by regulatory exposure rather than by how easy they are to close.
• A remediation plan with an owner and a sequence, and the evidence each step has to leave behind.

Where organizations are usually weakest

• Nobody owns the full list, so the inventory is assembled from three partial ones that disagree.
• Automated decisions affecting individuals were never recognised as such, so PDPL Article 18 was never considered.
• Cross-border transfer was decided by whichever provider the engineering team preferred.
• Human review exists in the process description but not in the system, so there is no record that anyone approved anything.

We build the governance layer as working software inside your environment, not as a policy set you then have to operate by hand.

A typical engagement

1. Run the readiness assessment and agree the risk tiering.
2. Stand up the AI system register as a live record connected to the systems it describes, so it stays current instead of ageing in a spreadsheet.
3. Instrument decision logging: input, model version, output, who approved it and when, written where it cannot be edited after the fact.
4. Build the risk assessment and review workflow, with approval gates that block deployment rather than record that one was skipped.
5. Assemble the evidence pack an assessor, a certification body or a data subject request will ask for.
6. Hand over with the register populated, the logging running and your team able to operate both.

It deploys on your own infrastructure. Decision records and prompt logs hold personal data and often commercially sensitive judgement, so they stay under the same residency and access rules as the rest of your record.

Worth being explicit, because this is a market where the boundary gets blurred.

What we do not do

• We do not issue Regulation 10 certification. Only a DIFC-accredited certification body can, and no engineering vendor can promise an outcome that an accredited third party decides. We prepare you for that assessment and build the evidence it runs on.
• We do not give legal advice. Whether a system is high-risk, whether a transfer mechanism holds, and how an obligation applies to your entity are questions for qualified counsel. We build to the determination your advisors reach.
• We do not act as your Autonomous Systems Officer or DPO. The independence expectations around those appointments are a matter for your advisors. We give whoever holds the role the register, the logs and the reporting to do it properly.

If a vendor offers you guaranteed certification, ask which accredited body issues it and on what basis. The answer is informative.