Abu Dhabi regulates healthcare AI across its whole lifecycle, not at launch.

The standard is organised into four parts. Two of them concern how a system is built and what it is allowed to learn from.

Core foundations for all AI systems

Every AI system carries a baseline regardless of what it does. In practice that means knowing what the system is for, who owns it, what it may and may not decide, and being able to show all of that on request.

Data management for AI

This is where AI compliance meets the data work. The questions that matter are plain ones: where did the training or retrieval data come from, was it lawful to use for this purpose, does retrieval respect the permissions of the source system, and can you say what the model saw.

Retrieval that flattens permissions is the failure we find most often. A system that indexes everything and answers from anything will surface a record the requesting clinician was never entitled to open, and it will do so silently.

The standard sets out a Responsible AI risk management process as its own discipline, rather than folding AI into the general risk register.

What that asks of a deployment

• A stated purpose and scope for each AI system, with the decisions it is permitted to influence written down.
• Human oversight placed where consequence is highest, with a named reviewer rather than a role in principle.
• Monitoring after go-live, because a model that performed in validation can drift against a changing patient population.
• A record of what the system decided and on what basis, retained long enough to investigate.
• A defined route to withdraw or decommission a system, and evidence that it was followed.

The lifecycle framing matters here. Decommissioning is explicitly in scope, and almost nobody plans for it, which is how a retired model leaves its embeddings and logs behind.

The fourth part of the standard is AI literacy, and it is the one that needs people rather than engineering.

A clinician who does not know what the system can and cannot be trusted with is a control failure, not a training gap. The same is true of an administrator who pastes a patient record into a public chatbot because nobody told them it was reportable.

What we deliver

• Sessions in English and Arabic, with attendance and completion records you can produce.
• Role-specific content: clinicians, administrators, IT, and the executives who sign off on AI procurement.
• What your deployed systems actually do, taught against your systems rather than generic examples.
• When to escalate, and what counts as an incident.
• Safe and unsafe use of public AI tools, with the data-protection consequence made concrete.

This pairs with the ADHICS security awareness obligation, which is a separate requirement. Where both apply, we deliver them as one programme rather than two overlapping ones.

We build healthcare AI systems to this standard, and we bring existing deployments up to it.

For a new system

Purpose and scope defined before the build, permission-aware retrieval, human checkpoints on consequential output, per-query audit logging tied to an authenticated identity, and a decommissioning path designed in rather than improvised.

For something already running

1. Inventory every AI-enabled system in use, including the vendor products nobody classified as AI.
2. Assess each against the standard's four parts, and say plainly where it does not hold.
3. Remediate, starting with permission-aware retrieval and audit logging, because those are the failures with patient consequence.
4. Put the risk management and monitoring process in place, with owners.
5. Deliver the literacy programme, with records.

Map each requirement against the current DoH document rather than against a summary, including ours. The standard carries a one-year revision period and a DDG contact for questions, so the version matters.