The UAE has a general personal data protection law — Federal Decree-Law No. 45 of 2021 — and most of the AI projects I see were scoped as though it did not exist. Not out of contempt for it. It simply was not in the room when the process was chosen.
That is an expensive place to discover a constraint. Data handling is an architectural decision: it determines which model you can use, where it runs, what you can log, and whether the thing can go live at all. Retrofitting it means rebuilding.
What follows is not legal advice, and I am not a lawyer. It is the set of questions I put to a client before anything gets connected, because the answers change the design. It sits alongside the four reasons most UAE AI pilots never reach production.
1. Does personal data touch the model at all?
Start here, because a surprising number of useful projects can be arranged so the answer is no. Summarising internal policy documents, drafting from templates, classifying tickets by topic rather than by customer — none of these need a name attached.
Where the answer is yes, ask whether it needs to be. Pseudonymising before the call, and re-attaching identity afterwards inside your own systems, removes most of the exposure at very little cost in quality.
2. Where does the processing physically happen?
Sending data to a hosted model is a transfer. Depending on your sector and your contracts, that may be entirely fine, may require specific terms, or may be unacceptable. Regulated sectors and government-adjacent work tend to have the tightest expectations, and those expectations are increasingly about where the data physically sits.
Practically, this splits your options into three: a public API, a private deployment in a region you have chosen, or a model you run yourself. They differ enormously in cost and capability. Choosing between them after the pilot is built is the expensive path.
3. What is the provider doing with it?
Read the actual terms of the tier you are on, not the marketing page. Consumer and business tiers of the same product often differ on training use, retention period and human review. A team that signed up with a corporate card is usually on the wrong one.
4. What are you keeping, and for how long?
Logs are where good intentions go to die. Prompt and response logs are genuinely useful for debugging and quality, and they are also a store of personal data nobody assessed, usually with no retention period and broader access than anyone intended.
Decide what is logged, who can read it, and when it is deleted — before the first log line is written.
5. Can you explain it to the person it is about?
If a customer asks why a decision was made, or asks you to delete their data, can you answer? “It is in the model” is not an answer. In practice this means keeping the reasoning trail in your own systems rather than assuming you can reconstruct it later.
The awkward part
The executive regulations that put detail behind the law have taken time to land, and I have watched several organisations treat that delay as permission to postpone thinking about it. That is a mistake with a specific shape: the design decisions above are the ones that are expensive to reverse, and they are needed at the start regardless of what the regulations eventually say. Getting them right is not compliance theatre — it is the difference between a system you can extend and one you have to rebuild.
The exposure most companies actually have
Almost every conversation about AI and data protection is about the system the company is planning to build. Almost none of the real exposure is there.
It is in what staff are already doing. Someone in sales pasting a customer list into a public assistant to tidy the formatting. Someone in HR summarising a grievance. Someone in finance uploading a spreadsheet of salaries to ask a question about it. None of these people is being reckless; they are being efficient with a tool that is one browser tab away, and nobody told them the rule.
The compliance question is not whether you have approved an AI system. It is whether personal data is leaving your control through tools nobody has approved, which is a very different question and one you can answer this week.
The answer is rarely a ban. Bans move the behaviour to personal phones, where you cannot see it at all. What works is naming one tool people may use, saying plainly what may and may not go into it, and giving them somewhere to ask. That costs an internal note and an hour of somebody’s time, and it removes more risk than any architecture decision on this page.
The vendor questions that get real answers
Providers are used to being asked whether they are compliant, and everyone answers yes. Four narrower questions are harder to answer vaguely.
Where does processing happen, by region, in writing? Not where the company is headquartered. Where the compute runs, named, in the contract rather than in a sales email.
Is our content used for training, by default or on request? The distinction matters enormously and the default varies between a provider’s consumer tier and its business tier, sometimes silently.
How long is our data retained, and what happens on deletion? Ask specifically what happens to copies held for abuse monitoring, which is the usual exception and rarely volunteered.
Who else can see it? Subprocessors, support staff, and anyone reviewing flagged content. A provider with a mature answer has this documented; one without will tell you it is secure.
You are not looking to catch anyone out. You are establishing whether the answers exist in writing, because a commitment that lives only in a meeting is not a commitment you can rely on later.
Frequently asked questions
Does this apply to us if we are a small company?
Data protection obligations attach to what you do with personal data, not to your size. A small company handling customer records, staff files and supplier contacts is handling personal data in the same sense a large one is. What legitimately scales with size is the effort proportionate to the risk — a small operation does not need a large programme, but it does need to know where personal data goes.
Can we use a public AI assistant with customer data if we delete the chat afterwards?
Deleting your side of the conversation does not undo the transfer. The data left your control the moment it was submitted, and what happens to it after that is governed by the provider’s terms, not by your delete button. If personal data genuinely needs to go into a model, the question to settle first is which tier or deployment you are using and what its terms actually say — not what you can tidy up afterwards.
Is anonymising the data enough?
Sometimes, and it is worth doing wherever it works, but it is harder than it looks. Removing names does not anonymise a record that still carries a job title, a branch, a date and an amount. If the remaining fields could identify someone in combination, you are working with pseudonymised data rather than anonymous data, and the obligations follow it. Test it by asking whether someone inside your company could work out who a row refers to.
Do we need consent for every use of personal data in an AI system?
Consent is one lawful basis and not always the right one; relying on it where it does not fit is a common mistake, because consent can be withdrawn and your process then has to cope with that. The practical step is to be clear about why you are processing and to record that reasoning before you build, rather than reverse-engineering a justification afterwards. This is a question worth putting to a data protection lawyer for your specific case, not one to settle from an article.
Who inside the company should own this?
Someone with authority to say no, and it should not sit only with IT. The decisions here are about what the business is willing to do with information people entrusted to it, which is a leadership question with a technical component rather than the reverse. In a company without a dedicated privacy function, this usually lands with whoever owns risk, supported by whoever owns the systems.
What this looks like in practice
One page, agreed before build: what data is involved, whether it needs to be, where it is processed, what the provider may do with it, what is logged and for how long, and who can answer a subject’s question. It takes an afternoon, and it is the first document I produce on any AI engagement. It has saved every project I have used it on from at least one late and unpleasant surprise.
The law itself is published at uaelegislation.gov.ae, and the UAE government portal keeps a plain-language summary of the data protection laws. Verify the current position with counsel before you rely on any of this. Regulations move, and this is a summary of how I scope work rather than a statement of law.