DIFC Regulation 10: What AI-Enabled SaaS and HealthTech Vendors Need to Know

Short answer: DIFC Regulation 10 is the part of the DIFC Data Protection Regulations (in force 1 September 2023) that governs personal data processed through autonomous and semi-autonomous systems such as AI. It defines three roles (Deployer, Operator and Provider), requires clear notice and evidence on request, sets five design principles, and bans commercial use of a system for High Risk Processing Activities unless the system is certified and an Autonomous Systems Officer (ASO) is appointed.

Related guides:

• How ISO 42001 helps with EU AI Act compliance
• ISO 42001 checklist: AI management system requirements
• AI governance policy: template and audit evidence

Key takeaways

• Regulation 10 sits inside the DIFC data protection regime (DIFC Data Protection Law No. 5 of 2020 and its Regulations). It is not a standalone AI law, and it only covers systems that process personal data.
• A Deployer is treated as a Controller and an Operator as a Processor (Regulation 10.3.4). A Provider is whoever develops or procures the system to make it available to others. Most AI SaaS vendors are Providers and, when they host the system for a customer, Operators.
• Deployers and Operators must give clear notice on first use, describe the system's purposes, outputs, principles and safeguards, and produce evidence and a register of AI processing on request (Regulation 10.2.2).
• Every system must be designed to be ethical, fair, transparent, secure and accountable (Regulation 10.3.1).
• Commercial use for High Risk Processing Activities requires a certified system and an appointed ASO (Regulation 10.3.3). The Commissioner has published an Accreditation and Certification Framework; certification is per system and lasts up to three years.
• ISO 42001 layered on ISO 27001 produces much of the evidence Regulation 10 asks for, but it is not a substitute for certification under the DIFC Framework.

---

What is DIFC Regulation 10?

DIFC Regulation 10 is titled "Personal Data Processed through Autonomous and Semi-Autonomous Systems." The DIFC is a financial free zone in Dubai with its own legal framework, separate from onshore UAE law. Its data protection regime is DIFC Data Protection Law No. 5 of 2020, supported by the Data Protection Regulations and administered by the DIFC Commissioner of Data Protection.

The amended Regulations, Consolidated Version No. 2, state that they are in force on 1 September 2023. The DIFC announced the enactment on 7 September 2023, describing Regulation 10 as the first enacted regulation in the MEASA region on processing personal data through autonomous and semi-autonomous systems.

Regulation 10.1.1(a) defines a "System" as any machine-based system operating in an autonomous or semi-autonomous manner that can process personal data for human-defined purposes, purposes the system defines itself, or both, and generate output from that processing. The guidance note in the Regulations says purely automated, deterministic systems with no degree of autonomy are not intended to be captured, because the Law already covers automated processing.

The Commissioner has published two guidance documents alongside the text, both updated 27 August 2024: Regulation 10 guidance (DIFC-DP-GL-23) and Regulation 10 FAQs (DIFC-DP-GL-24). Forms, the certification framework and the list of accredited certification bodies are on the DIFC Regulation 10 page.

Deployer, Operator or Provider: which role do you hold?

Your obligations depend on your role. Regulation 10.1.1 defines three, and Regulation 10.3.4 deems the first two to be a Controller and a Processor.

Role	Definition (Regulation 10.1.1)	Treated as	Typical example
Deployer	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. This applies whether or not that person hosts the System or defines its purposes.	Controller (or Joint Controller)	The DIFC bank, insurer or clinic using an AI tool on its customers, staff or patients
Operator	A Provider that operates or supervises a System on behalf of, for the benefit of and on the direction of a Deployer, whether or not it controls the processing.	Processor (or Sub-processor)	The SaaS or HealthTech vendor hosting and running the AI feature for that customer
Provider	A person that develops a System, or has one developed, with a view to providing, commercialising or otherwise making it available to Operators or Deployers.	Not separately deemed	The vendor that builds the model or product, or a foundation model company

A typical AI SaaS vendor is a Provider and, once it hosts the system for a DIFC customer, also an Operator. If the vendor uses AI on its own customers or staff, for example for support triage or fraud scoring, it is a Deployer for that use.

Typical in-scope products include claims or underwriting assistants for DIFC insurers, AI-driven wellness and employee-benefits platforms, machine learning KYC or fraud scoring, and generative AI chatbots that read customer correspondence. Prompts, logs and training sets often contain personal data, so check before deciding a feature is out of scope. Regulation 10.1 also notes that a System that resembles the appearance or behaviour of an identifiable person can itself amount to processing that person's personal data.

What does Regulation 10 require?

The obligations fall into four groups: general lawfulness, notice, evidence on request, and design principles.

1. General lawfulness (Regulation 10.2.1). Where personal data is processed for use in, or to train, a System, the Deployer or Operator must follow the general processing principles in Article 9 of the Law.

2. Notice on first use (Regulation 10.2.2(a) and (b)). Where an application or website uses a System to process personal data, the Deployer or Operator must give clear and explicit notice on first use or access. The notice must flag any processing that is not human-initiated, controlled or directed, explain the impact on individuals' rights (linked to Article 29(1)(h)(ix) of the Law), and give a true and plain description of:

• the human-defined purposes of the processing;
• the human-defined principles and limits within which the System can define further purposes itself;
• the output the System produces and how it is used;
• the principles the System was developed to operate on, including built-in safeguards; and
• the codes, certifications or principles it is designed to. The Regulation names examples such as the Dubai Digital Authority, OECD, UNESCO, the NIST AI framework, and the UAE financial regulators' guidelines on enabling technologies.

3. Evidence and a register on request (Regulation 10.2.2(c) to (h)). The Deployer or Operator must be able to provide:

• evidence of compliance with any audit or certification requirements set by the Commissioner;
• evidence of algorithms that make the System seek human intervention where processing may have an unfair or discriminatory impact, plus a risk and impact assessment covering unjust bias and High Risk Processing;
• the same human-intervention evidence and risk assessment for access requests from government authorities, including law enforcement, and for processing that may breach Regulation 9;
• a register of AI processing covering use cases, necessity and proportionality, how individuals can exercise their access rights, whether the System makes solely automated decisions, the third parties and authorities that receive data, contractual obligations of joint controllers, processors and sub-processors, and where recipients are located with transfer safeguards; and
• any other information the Commissioner requests.

Evidence may be redacted or summarised to protect intellectual property, but the full version must be given to the Commissioner on request.

4. Design principles (Regulation 10.3.1). A System that may affect individuals must be designed to be:

• Ethical: algorithmic decisions and data lineage should be unbiased, with bias mitigated.
• Fair: individuals should be treated equally, and potential bias that could lead to unfair outcomes avoided or mitigated.
• Transparent: processing must be explainable to individuals in non-technical terms, with supporting evidence.
• Secure: personal data must be protected and breaches prevented.
• Accountable: there must be mechanisms such as internal governance, monitoring or external audit to assess algorithms, data and design.

Regulation 10.3.2 adds that no one may make a System available for commercial use unless it processes personal data only for human-defined or human-approved purposes (or self-defined purposes within human-defined principles and limits) and meets 10.3.1 and any audit and certification requirements the Commissioner sets. Under Regulation 10.3.5, individuals can complain about the outcome of AI processing under Parts 9 and 10 of the Law.

When do certification and an Autonomous Systems Officer apply?

Regulation 10.3.3 says no one may use, operate, provide or make available for commercial use a System that engages in High Risk Processing Activities unless all of the following are true:

1. the Commissioner has set audit and certification requirements for such Systems;
2. the System complies with them;
3. the System processes personal data only for human-defined or human-approved purposes; and
4. the Deployer or Operator has appointed an Autonomous Systems Officer (ASO) with the same or substantially similar competencies, status, role and tasks as a DPO under Articles 17 and 18 of the Law.

What counts as High Risk Processing. Schedule 1 of the DIFC Data Protection Law defines it as processing where any of these applies: new or different technologies that materially increase risk or make it harder to exercise rights; a considerable amount of personal data likely to result in high risk; systematic and extensive automated evaluation, including profiling, that drives decisions with legal or similarly significant effects; or a material amount of Special Categories of personal data. HealthTech vendors should note the last limb, because health data is a Special Category.

Certification position. Asked whether the audit and certification framework required by 10.3.3(a) exists, the Commissioner's FAQs answer yes: the Regulation 10 Accreditation and Certification Framework is published on the DIFC website. Key points from the FAQs:

• Certification assesses the System, not the company.
• It is awarded and monitored by an Accredited Certification Body approved by the Commissioner, and the approved bodies are listed on the DIFC Regulation 10 page.
• Certification is valid for a maximum of three years, subject to monitoring.
• Fees are set by the certification body and must be reasonable.
• An applicant refused certification can reapply after one year.
• "Commercial use" is compared to placing a System on the market under the EU AI Act.
• Certification under another scheme, such as one used for the EU AI Act, can be put to the Commissioner for fast-track recognition through a short-form application.

Systems that are not used for High Risk Processing still have to meet 10.3.1 and 10.3.2, including any audit and certification requirements the Commissioner sets for Systems generally.

The ASO role. The guidance says the ASO initially performs a function similar to a DPO: data protection impact assessments, reviewing risks and processing with senior management, and recommending improvements. Unless the ASO is also the DPO, the Article 19 DPO assessment does not apply to the role.

Regulation 10 timeline

Date	Event	Source
1 September 2023	Amended Data Protection Regulations, including Regulation 10, in force	Regulations, Consolidated Version No. 2
7 September 2023	DIFC announces enactment	DIFC news release
27 August 2024	Guidance and FAQs updated (Rev. 03); FAQs confirm the Accreditation and Certification Framework is published	Regulation 10 FAQs
18 June to 18 July 2026	Public consultation on amendments refining Regulation 10, clarifying certification and the ASO role, and adding a new Regulation 11 on recognising accreditation and certification frameworks	DIFC consultation notice

Note: Some secondary sources say "full enforcement" of Regulation 10 began in January 2026. We could not find that date in the Regulations or the Commissioner's published guidance, so we do not rely on it here. The obligations above have been in force since 1 September 2023. As of 1 October 2026, the amendments consulted on in mid-2026 may change the certification and ASO details, so check the DIFC Regulation 10 page for the final text.

Regulation 10 readiness checklist: where should you start?

Start by working out your role for each AI feature, then build the notice, evidence and register that Regulation 10.2.2 requires. This checklist is sized for an SMB SaaS or HealthTech team without a dedicated AI governance function.

• Inventory Systems. List every feature with autonomous or semi-autonomous behaviour, including internal tools, and mark which process personal data for DIFC customers.
• Assign roles. For each feature, record whether you are the Provider, Operator or Deployer, and reflect that in your data processing agreement.
• Screen for High Risk Processing. Test each System against the four Schedule 1 limbs. Flag profiling with significant effects and any health or other Special Category data. The DIFC publishes an HRP assessment tool.
• Draft notice text (10.2.2(a) and (b)). Write a reusable description of purposes, self-defined purpose limits, outputs, design principles and safeguards, and the frameworks you design to.
• Build the evidence pack (10.2.2(c) to (f)). Document human-intervention triggers for unfair or discriminatory outcomes, government access requests and Regulation 9 risks, with a risk and impact assessment for each.
• Maintain the AI register (10.2.2(g)). Capture use cases, necessity, data subject access routes, automated decision use, recipients, contracts and transfer safeguards.
• Lock down purpose (10.3.2). Make sure the System processes personal data only for human-defined or human-approved purposes. Do not reuse customer data to train shared models without agreement.
• Evidence the five principles (10.3.1). Keep bias and accuracy test results, explainability material, security controls and governance records.
• Plan for certification and an ASO (10.3.3). If a System supports High Risk Processing for commercial use, contact an Accredited Certification Body and decide who will act as ASO.
• Track changes. Watch the outcome of the 2026 consultation and update the checklist when the amended Regulations are published.

How do ISO 42001 and ISO 27001 map to Regulation 10?

ISO 42001 covers much of the AI governance in Regulation 10, while ISO 27001 covers the security foundations underneath it. The table below is SecureSlate's own mapping, not an official crosswalk from the Commissioner, and neither standard replaces DIFC certification for high-risk use.

Regulation 10 requirement	ISO 42001 practice	ISO 27001 practice
Notice and description of purposes, outputs and principles (10.2.2(a), (b))	AI system documentation and information for interested parties, including users and affected individuals	Privacy and information classification policies that define what is disclosed
Human-defined purposes (10.3.2)	AI policy and objectives, defined intended use for each AI system, controls on data used in the AI lifecycle	Asset inventory, data handling rules and acceptable use policy
Bias and human-intervention evidence, risk and impact assessments (10.2.2(d) to (f))	AI risk assessment and AI system impact assessment covering effects on individuals and groups	Risk assessment and treatment process that records AI risks alongside security risks
Secure principle (10.3.1(d))	AI-specific risks in the lifecycle, such as data quality and model integrity	Annex A technical controls such as access control, logging, secure development and supplier security
Accountable principle and ASO (10.3.1(e), 10.3.3(d))	Defined roles and responsibilities for AI, human oversight measures, management review	Leadership commitment, assigned roles and internal audit
Register and evidence on request (10.2.2(g), (h))	Management system documentation, monitoring, internal audit and continual improvement	ISMS documentation, Statement of Applicability and evidence of operating controls

If you are new to ISO 42001, start with the checklist and AI governance policy guides listed at the top of this article. Teams weighing frameworks can also compare NIST AI RMF vs ISO 42001, which is relevant because Regulation 10.2.2(b)(v) names the NIST AI framework as an example.

How does Regulation 10 compare to the EU AI Act?

Regulation 10 is a data protection rule for AI that processes personal data, while the EU AI Act is a product-style regulation for AI systems placed on the EU market regardless of whether personal data is involved. Some of the vocabulary, such as "Deployer", overlaps with the EU AI Act.

	DIFC Regulation 10	EU AI Act
Legal basis	Part of the DIFC data protection regime	Standalone EU regulation on AI
Trigger	Personal data processed by autonomous or semi-autonomous systems in a DIFC context	AI systems placed on the market or used in the EU
Approach	Notice, evidence and five design principles for all Systems; certification and an ASO for High Risk Processing	Risk tiers, including prohibited practices and detailed duties for high-risk systems
Roles	Deployer, Operator, Provider	Providers, deployers, importers and distributors, among others
Conformity	System certification by an Accredited Certification Body, valid up to three years; no CE marking	Conformity assessment and CE marking for high-risk systems
Timing	In force since 1 September 2023; amendments consulted on in 2026	Obligations phased in over several years

The Commissioner's FAQs say the DIFC Framework aligns with EU AI Act Articles 16 and 43, and that certification under another scheme can be submitted for fast-track recognition. For vendors selling into both markets, one governance program can serve both. Our EU AI Act checklist covers the EU side, and an ISO 42001 management system is a practical way to bridge the two.

How SecureSlate helps

SecureSlate helps SMB, SaaS and HealthTech teams run one compliance program that answers ISO and DIFC customer due diligence questions together. Multi-framework mapping links one set of controls to ISO 42001, ISO 27001, GDPR and more. Policy templates jump-start AI governance and data handling policies. Continuous control monitoring and evidence collection keep the evidence behind your Regulation 10 readiness work current, vendor risk management tracks the model providers behind your AI features, and a trust center lets DIFC customers review your documentation on demand.

Start your free SecureSlate trial

FAQ

Is DIFC Regulation 10 a separate AI law?

No. Regulation 10 is part of the DIFC Data Protection Regulations, which support DIFC Data Protection Law No. 5 of 2020. It applies only where autonomous or semi-autonomous systems process personal data.

What is the difference between a Deployer and an Operator?

A Deployer is the person on whose authority or for whose benefit the System runs, and is treated as a Controller. An Operator is a Provider that runs or supervises the System for a Deployer, and is treated as a Processor (Regulations 10.1.1 and 10.3.4).

Does Regulation 10 apply to onshore UAE companies?

Regulation 10 belongs to the DIFC's own legal framework, so it is tied to processing connected with the DIFC. Elsewhere in the UAE, federal law or other free zone regimes may apply instead. Check with counsel which regimes cover your operations.

Do vendors need certification under Regulation 10?

Yes, if the System is used, operated, provided or made available for commercial use in High Risk Processing Activities. Regulation 10.3.3 requires the System to be certified under the Commissioner's published Accreditation and Certification Framework and an Autonomous Systems Officer to be appointed. Certification is per System and valid for up to three years. Amendments consulted on in June and July 2026 may refine these rules.

Is ISO 42001 certification enough to comply with Regulation 10?

No. ISO 42001 is a voluntary standard, and high-risk Systems need certification under the DIFC Framework. It does give you documented risk and impact assessments, oversight roles and evidence that map closely to Regulation 10's notice, evidence and design requirements.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction, and the DIFC Regulations and guidance may have changed since publication. Consult qualified advisors for your specific obligations.