AI compliance in the UAE starts with working out which law applies to you. Most onshore companies fall under the federal Personal Data Protection Law (PDPL). Companies in the DIFC or ADGM fall under those free zones' own data protection laws instead. Health data, and banks, insurers and government entities, usually have stricter rules on top. Once you know your regime, the practical work is the same: know what data the AI touches, settle where it is stored and processed, and get your vendors to answer in writing.

I run Skcript Applied Labs. We build AI systems for companies in the UAE and across the Gulf, and data protection is the first thing most security teams raise. We are engineers, not lawyers. This is the practical picture as I understand it, not legal advice, and your counsel should have the final word.

Step 1: Find out which regime you are in

The UAE has more than one data protection regime, and they don't overlap.

  • Federal PDPL. Federal Decree-Law No. 45 of 2021 covers personal data processing in the UAE outside the financial free zones. Some kinds of data that have their own laws, such as certain health and banking data, are handled under those laws instead. The Executive Regulations that are meant to fill in detail had not been published when I last checked, so confirm the current position.
  • DIFC. The Dubai International Financial Centre has its own Data Protection Law and Regulations, with its own Commissioner. It is the regime in the UAE that most directly addresses AI, through Regulation 10.
  • ADGM. Abu Dhabi Global Market has its own Data Protection Regulations and its own Office of Data Protection. If you are an ADGM entity, check that regime and any guidance it has published on AI with your counsel.
  • Sector rules. Health data falls under Federal Law No. 2 of 2019, which restricts storing, processing or transferring health data related to services in the UAE outside the country, except where the health authorities allow. Financial regulators and government entities often have their own rules too.

For many companies, the strictest rule is not the law at all. It is internal policy. That is fine, but it means the policy owner has to sign off, so talk to them early.

Step 2: What the PDPL means for AI

The PDPL doesn't have an AI chapter. Its general rules apply to AI the same way they apply to any other processing of personal data. In practice, for an AI project, I would check:

  • Purpose. Is using this data for this AI task consistent with why it was collected?
  • Legal basis. Consent is the default basis in the PDPL, with listed exceptions. Know which one you rely on.
  • Minimisation. Send the model only what the task needs. Most invoice or email tasks don't need full customer records.
  • Security. Who can see prompts, outputs and logs, inside your company and at the vendor?
  • Rights. People have rights to access and correct their data and, in some cases, to object to automated processing. Make sure a person can review a decision when it matters.
  • Transfers. If a vendor processes data outside the UAE, check it fits one of the transfer cases the law allows.

None of this is new to anyone who has done GDPR work. The difference in AI projects is that data often goes somewhere nobody looked, such as a model running in another region.

Step 3: DIFC Regulation 10 at a general level

If you are a DIFC entity, Regulation 10 of the DIFC Data Protection Regulations is the part to read. It deals with personal data processed through autonomous and semi-autonomous systems, which covers most AI. At a general level it sets expectations around:

  • Telling people, clearly, when such a system processes their data and for what purpose.
  • Designing and running the system so that it respects data protection principles.
  • Being able to explain and account for how the system is used.

I am not going to paraphrase the detailed requirements here, because they are specific and the text is what counts. Read the current version on the DIFC Commissioner's site and get counsel to map it to your use case. What I will say is that the work it asks for, a clear notice, a documented purpose and a record of how the system behaves, is work a well-run AI project should produce anyway.

Step 4: Data residency, done properly

"Our data can't leave the UAE" is usually the first thing I hear. That sentence hides three questions: where is the data stored, where does the model process it, and who else can see it, keep it or learn from it?

Storage and processing are often different. Many AI services let you keep files and logs in a UAE region while the request itself is processed wherever the model has spare capacity. So the question to ask a vendor is not "do you have a UAE region?" It is "for this exact model, in this exact setup, where does my request get processed?"

I go through this in detail in Keeping your data in the UAE, including how business plans differ from personal accounts. The short version: get the processing location in writing, and check it again each time you change models.

Step 5: Questions for AI vendors and models

Before any real data goes in, I would want these answered in writing:

  • Where is our data stored at rest, and where does this specific model process our requests?
  • Which subprocessors touch our data, and in which countries?
  • How long are prompts, outputs and logs kept, and can we change that?
  • Is our data used to train or improve any model? Is that off by default?
  • Can the provider's staff read our data, and under what conditions?
  • Does the model handle Arabic and English well enough for our cases? Test it, don't take the claim.
  • How do we delete everything when we leave?

If a vendor can't answer clearly, treat that as an answer.

How we keep data in the UAE

Data location is one of the first things we settle in a pilot, not the last. Here is how we handle it.

  1. Sort the data by sensitivity. Before testing, we sort your real cases into tiers: personal data, health or financial records, and nothing sensitive.
  2. Test only setups that meet the rule. For each tier, we only test models and setups that meet the rule for that data. If a tier must stay in the UAE, a model that processes elsewhere doesn't make the list, however well it scores.
  3. Record it on the scorecard. Where data is stored and processed sits on the model scorecard next to accuracy and cost per task, so your security team sees it in the same place as the results.
  4. Run it ourselves where needed. Sometimes the answer is an open model on servers in the UAE that you control. You then run and pay for it, so we test it on your cases before recommending it.
  5. Split the work. Sometimes the sensitive step stays with a person or a plain rule, and AI handles the rest.

All of this fits inside our 10-day AI pilot, with one fixed, published price on our pricing page.

A short checklist before you build

  • We know whether we fall under the PDPL, the DIFC or the ADGM regime.
  • We know whether any sector rule, such as health, applies to this data.
  • We know whether our internal policy is stricter than the law, and who owns it.
  • We have listed what personal data this AI task actually needs.
  • We have the storage and processing location in writing for the exact model.
  • A person reviews AI output before it makes a significant decision about someone.
  • Counsel has reviewed the plan.

If you are in Europe, the equivalent guide is EU AI Act readiness for SMEs.

If data protection is what's holding up your AI plans, see how we work in AI consulting in the UAE, start a chat with us on the site, or bring your policy and one task to a call. We'll show you which setups would actually meet it.