AI Regulations in DIFC: Complete Guide
Automating an activity does not change its regulatory character.
The DIFC has its own courts, its own financial regulator and its own data protection regime. This guide sets out what a firm should settle before an AI product goes live: whether the licensed activity still describes what the model outputs, how training data are treated, which vendor clauses decide who carries the risk, and what record of model version, inputs and human review makes a decision defensible.
Reviewed by Mohamed Noureldin, Founder, Managing Partner & Senior Legal Consultant
Companies building or buying artificial intelligence systems in the Dubai International Financial Centre usually arrive with the same question: which rulebook applies to the model? What governs an AI system is the law that already applies to the activity the system performs, the data it consumes, and the licence the company holds.
That is a more workable answer than it first appears, because it tells you where to look. This guide sets out the DIFC framework a technology business needs to work through before an AI product goes live, and the points where DIFC obligations diverge from federal UAE law.
The DIFC is a separate legal system
The DIFC is a common-law jurisdiction with its own courts and its own financial services regulator, the Dubai Financial Services Authority.
This matters for AI work in a practical way. A software licence, a data processing agreement or a development contract drafted for a mainland Dubai counterparty is written against a different body of law and a different court. Group templates should be reviewed rather than reused, and the entity that actually signs should be the one whose law and forum the contract names.
Start with the licence
A DIFC entity may only carry on the activities its licence permits. AI products have a habit of drifting past their original description: a tool built to summarise documents starts generating client-facing recommendations, an analytics service begins producing something that looks like investment advice, an internal model is packaged and sold to third parties.
Automating an activity does not change its regulatory character. Firms should confirm that the licensed activity still describes the product as it exists today, and should treat any material change in what the model outputs as a licensing question before it becomes a supervisory one.
Data protection: the DIFC regime
The DIFC operates its own data protection regime, and a group policy written for a mainland or free zone entity will not satisfy it by default.
For AI systems, a few themes recur regardless of which regime applies:
- Purpose. Personal data collected for one purpose is not automatically available to train a model for another. If training was not part of the original basis, it needs its own.
- Transparency. People whose data is processed are entitled to understand what is happening to it. A notice that describes only the original service does not cover model training.
- Retention. Training sets are still data. They need a retention position, not indefinite storage by default.
The practical failure is rarely the absence of a policy. It is a model trained on data that was collected for something else, documented nowhere, and discovered during due diligence.
Contracts with model and tool providers
Most DIFC firms do not build foundation models. They license them, and the allocation of risk sits in the vendor contract. The clauses worth reading closely are usually these:
- Inputs and training. Whether the provider may use your prompts, documents or customer data to improve its models, and whether that can be switched off.
- Ownership of outputs. Who owns what the system generates, and whether the provider grants anything beyond a licence to use it.
- Third-party rights. What the provider says about the material the model was trained on, and whether any indemnity for infringement claims survives the limitation of liability clause.
- Confidentiality. Whether confidential client information can be put into the tool at all, and by whom.
- Change and withdrawal. What happens when the provider changes a model version, restricts an API or discontinues a service the business now depends on.
Liability caps in these agreements are frequently set well below the exposure the customer is accepting. That is a commercial decision, but it should be a conscious one, recorded and approved rather than absorbed by whoever signed the online terms.
Who is responsible when the output is wrong
Responsibility for an AI system's output does not transfer to the vendor because the vendor built the model. A DIFC entity that gives a client advice, a price or a decision produced by a tool answers for it under its own contracts and its own regulatory obligations.
The controls that make that defensible are unglamorous: a record of which model version was used, what it was given, who reviewed the output and on what basis it was released. Where a decision affects a client, human review should be real rather than nominal, and the reviewer should have the information and the authority to disagree with the system.
Employment and internal use
Internal use raises its own issues. Tools used to screen candidates, monitor performance or assist decisions about staff process personal data about identifiable people, often sensitive data, and often through a provider outside the centre. Staff use of external AI tools also creates a confidentiality exposure that no contract with a client anticipates: material goes into a third-party system that the firm has never assessed. A short, enforced internal policy on which tools may be used and with what information prevents most of these problems.
Disputes
Contracts involving AI systems produce familiar disputes in unfamiliar packaging: performance that does not match what was demonstrated, data used beyond the agreed scope, ownership arguments over outputs, and liability arguments after a system produced something damaging. The DIFC Courts hear DIFC-law disputes, and the DIFC also remains available as an arbitral seat. Arbitration carried out in the UAE is governed by Federal Law No. 6 of 2018, as amended in 2023, unless the parties agree on the application of another arbitration law. Careful drafting at this stage avoids most technology dispute resolution work later.
Conclusion
AI compliance in the DIFC is not a search for an AI code. It is a sequence of concrete checks: does the licence still describe what the product does, does the data used for training have a lawful basis under the DIFC regime, does the vendor contract allocate risk in a way the business would defend, and can the firm show who was accountable for a given output?
Businesses that work through those questions before launch, and record the answers, are far better placed than those that discover the gaps during an investor's due diligence or a regulator's review.
For guidance on AI projects, data protection or technology contracts in the DIFC, contact the Nour Attorneys team.
Disclaimer: The information provided in this article is for general informational purposes only and does not constitute legal advice. Readers should seek professional legal advice tailored to their specific circumstances before making any decisions or taking any action based on the content of this article.
Nour Attorneys Team
Related Resources
Explore more of our insights on related topics:
- AI Regulations Compliance Requirements in the UAE
- Blockchain Legal Defense Strategies for Dubai Businesses
- Cryptocurrency Compliance Guidelines for UAE Operators
- Data Privacy Laws for Multinational Entities
