DIFC Regulation 10 is now enforced. What evidence must your AI system produce?

Most coverage of DIFC Regulation 10 explains the org chart. Appoint an Autonomous Systems Officer, get the system certified, keep a register of processing activities. All of that is correct and all of it is incomplete, because it describes who is responsible without describing what they have to be able to hand over.

Regulation 10 is, on one specific point, the most demanding of the major AI governance frameworks. Five of its sub-paragraphs turn on a single word: evidence. Not records. Not documentation. Not "appropriate technical and organisational measures." Evidence, produced on request, to an affected party. The EU AI Act tells you to keep logs. India's DPDP Rules tell you how long to retain them. Regulation 10 tells you to prove things, to people who are not necessarily the regulator, on demand.

If your agent touches personal data inside the DIFC, that distinction is the entire compliance problem, and almost nothing published for builders addresses it.

What is DIFC Regulation 10 and who does it apply to?

DIFC Regulation 10 governs personal data processed through autonomous and semi-autonomous systems. It binds Deployers and Operators of any machine-based system that processes personal data for human-defined purposes, purposes the system defines itself, or both, and generates output on that basis.

The definitions sit in Regulation 10.1.1. A Deployer is the person under whose authority or for whose benefit the System operates, or who receives the benefit of its output, regardless of whether that person hosts the System or determines any of the purposes for which it processes data. An Operator is a Provider running the System on a Deployer's direction. A Provider develops the System, or procures its development, to make it available to Operators or Deployers.

Regulation 10.3.4 then does the work that matters: a Deployer is deemed to act as a Controller, and an Operator as a Processor. The Commissioner's guidance explains the reasoning in a way worth quoting because it settles a question builders often treat as open. A System operating under its Deployer's authority is said to occupy a position substantially similar to an employee within that organisation, with liability following accordingly.

That analogy has a consequence. You do not get to argue that the model decided. You are answerable for the agent the way you are answerable for staff.

On the enforcement date, a distinction is needed. A great deal of published commentary states that Regulation 10 "moved to full enforcement" on 1 January 2026, and treats that as a compliance deadline. The date did not come from nowhere. DIFC itself communicated during 2025 that enforcement of Regulation 10 was planned to commence early in 2026 and that firms should be working towards certification of appropriate systems.

What DIFC announced and what commentary now reports are two different things.

The announcement was an enforcement posture. The reporting has hardened it into a commencement date, and no such provision exists. The Data Protection Regulations, Consolidated Version No. 2, record only that they are in force from 1 September 2023, with no phased commencement for Regulation 10. The Commissioner's Accreditation and Certification Framework states that the timeline for implementing the Framework is at the Commissioner's discretion. On the text, Regulation 10 has been binding since September 2023.

That is not a small distinction. A commencement date tells you when an obligation attaches. An enforcement posture tells you when someone started looking. If you have been running a System on personal data in the DIFC since 2024, the second reading means you were already non-compliant, not that you were early, and a Commissioner examining conduct from that period is not looking outside the operative window.

It matters commercially too. Anyone who scheduled a Regulation 10 programme to land in January 2026 was scheduling against a supervisory expectation, not a grace period, and had no legal cover for the interval.

What counts as high-risk processing under Regulation 10?

High Risk Processing Activities are defined in Schedule 1 of the DIFC Data Protection Law, not in Regulation 10. The definition covers new or different technologies creating materially increased risk, processing a considerable amount of personal data, systematic and extensive automated evaluation including profiling, and processing a material amount of special category data.

Here the drafting rewards close reading. Regulation 10.3.3 does not point at the whole definition. It prohibits commercial use of a System for High Risk Processing Activities "set out the Defined Term, sub-clause (a) in Schedule 1, Article 3 of the Law." Sub-clause (a) is the new-or-different-technologies limb alone.

Read literally, the certification gate is narrower than the general high-risk regime. A System doing large-scale profiling would trigger the Law's DPIA and DPO machinery without necessarily triggering Regulation 10.3.3's certification prohibition, unless the technology limb is also engaged. The Commissioner's own FAQs paraphrase 10.3.3 without the sub-clause qualifier, which suggests the narrow reading may not be intended.

Whether the narrow reading holds is genuinely unsettled, and I have not seen it tested. For most agent deployments the point is academic, because deploying a general-purpose model against personal data is close to a textbook adoption of a new technology that makes it harder for data subjects to exercise their rights. But if you are relying on falling outside certification, that is the provision to read carefully and the question to put to the Commissioner under the Article 20 prior consultation route rather than to answer internally.

What evidence of compliance must a deployer produce?

Regulation 10.2.2 sets out five evidentiary duties, at sub-paragraphs (c) through (g), each owed on request. Together they require proof of certification compliance, proof of human-intervention algorithms in three defined circumstances, and a register of processing activities.

Taking them in order.

10.2.2(c) requires evidence of the System's compliance with any audit or certification requirements the Commissioner establishes.

10.2.2(d) requires evidence of any algorithm causing the System to seek human intervention where processing may produce an unfair or discriminatory impact on a data subject, together with a risk and impact assessment of unjust bias.

10.2.2(e) requires the same for algorithms causing the System to seek human intervention where personal data must be accessed by competent government authorities, including law enforcement.

10.2.2(f) requires the same again where processing may result in non-compliance with Regulation 9, which governs digital communications, marketing and consent.

10.2.2(g) requires a register listing use cases, necessity and proportionality, how data subjects can access information held in the System, whether the System is used solely for automated decisions, which third parties or requesting authorities are involved, and where they sit.

Notice what (d), (e) and (f) actually ask for. Not a policy saying a human reviews sensitive cases. Evidence of the mechanism that routes the case to a human. For an agent, that is an escalation path in code, with a record showing it fired. A governance document asserting that discriminatory outputs get reviewed does not evidence an algorithm; it evidences an intention.

Regulation 10.2.2(h) supplies the only relief and it is narrow. Information under (c) through (f) may be redacted or summarised, but solely to the minimum extent necessary to protect intellectual property or comply with legal restrictions, and the Commissioner may demand the full unredacted version and require revisions to your redactions. Trade secrecy buys you a summary for the affected party. It buys you nothing against the regulator.

Sitting above all of this, Regulation 10.3.1(c) requires that processing be explainable to data subjects and other stakeholders in non-technical terms, with appropriate supporting evidence. That phrase is the design constraint. Plain-language explanation is not enough on its own, and raw traces are not enough on their own. You need the explanation and the artifact that backs it.

The Certification Framework confirms the direction. Its programme requirements contemplate processing purpose logs that track how data is being handled against human-defined purposes, algorithmic audits assessing algorithms against those purposes, and code review records. Certification is valid for three years, with audit at least once inside that window.

What is an Autonomous Systems Officer and do you need one?

An Autonomous Systems Officer is required under Regulation 10.3.3(d) where a System is made available for commercial use in High Risk Processing Activities. The role carries competencies, status and tasks substantially similar to a Data Protection Officer under Articles 17 and 18 of the Law.

Outside high-risk processing there is no ASO requirement. That is worth stating plainly, because a fair amount of advisory material implies otherwise.

Two details from the Certification Framework are easy to miss and expensive to miss. Its audit criteria require that there be no gap of more than one month before a System begins high-risk operation, or between a departing ASO and a replacement, absent an approved exception. And the Framework describes the ASO as needing technical and organisational expertise sufficient to oversee the System and the continuing validity of its certification, which is a different skill profile from a conventional DPO.

The Framework also refers to the role in one place as an "Automated Systems Officer" and cites Articles 16, 17 and 18, where Regulation 10.3.3(d) says Autonomous and cites Articles 17 and 18. These read as drafting slips rather than substantive divergence, but if you are mapping obligations line by line, expect the inconsistency.

Does Regulation 10 apply to systems built outside the DIFC?

Regulation 10 applies to any person to whom the DIFC Data Protection Law applies. Where the System was built is irrelevant. What matters is whether a Deployer inside the DIFC operates it, directs it, or receives the benefit of its output while personal data is processed.

Providers are not directly bound by most of Regulation 10. The Commissioner's guidance is candid that this is deliberate: Deployers and Operators are the visible entities exposed to affected data subjects, and they are expected to procure only from developers who can give contractual comfort of compliance by design.

For anyone selling agent infrastructure into the DIFC, that is the commercial reality. Your customer carries the obligation and will push it back to you by contract. The evidentiary duties in 10.2.2(c) to (g) are not things a Deployer can satisfy from the outside if your platform does not emit the underlying record. A customer who cannot evidence a human-intervention algorithm because your product does not log escalations has a problem that only you can fix, and they will have signed a warranty saying you would.

Two things to watch, and one to use.

The one to use is the Regulation 10 Accelerator. The Commissioner's guidance contemplates use case testing in a data protection by design accelerator, and DIFC has soft-launched it as a sandbox where a System can be tested against privacy by design principles and the Regulation 10 requirements before it goes live. Applications go to the Commissioner's office directly. For a team that cannot yet tell whether its agent is inside the certification gate, that is a cheaper answer than a legal opinion and a better one, because it produces a documented assessment rather than a view. The Article 20 prior consultation route sits alongside it for the harder questions.

The first thing to watch is that DIFC has committed the whole jurisdiction to this direction. On 21 April 2026 it announced its Native AI programme, stating an intention to become the world's first AI-native financial centre with artificial intelligence embedded across its legal and regulatory frameworks. Read against Regulation 10, that signals a regulator planning to lean harder on the instrument it already has rather than one likely to let it lapse.

The second is the consultation. On 18 June 2026 DIFC opened Consultation Paper No. 3 of 2026, proposing amendments to Regulation 10 and a new Regulation 11 giving the Commissioner power to recognise external accreditation and certification frameworks, with further clarity promised on certification obligations and the ASO role. Comments closed on 18 July 2026. The press release describes the amendments as strengthening expectations for an AI-native jurisdiction, which is the Native AI programme reaching the regulations. Nothing in the consultation changes what binds today, but a mutual-recognition route would materially reduce the cost of holding an EU conformity assessment and a DIFC certification at once. Anyone building for both markets should read the outcome when it lands.

Truveil scores AI agents against DIFC Regulation 10 and five other frameworks, and produces the evidence described here.