Guide

AI in Abu Dhabi healthcare: DoH Responsible AI Standard and ADHICS V2

Two Department of Health (DoH) documents govern AI in Abu Dhabi healthcare. The Responsible AI Standard, published and effective in October 2025, applies to DoH and every licensed healthcare entity in the Emirate that develops, buys or deploys AI, whether it is built in-house, bought from a vendor or made in a research collaboration, and whether it serves clinical, financial or administrative work. It requires human-in-the-loop or human-on-the-loop oversight with escalation, fallback when the system fails, validation before deployment and monitoring after it, traceability logs, bias testing, telling patients when AI contributes to a decision, and a risk assessment under which very high-risk systems are prohibited and high-risk systems face conformity assessment before and after deployment. Compute and storage, disaster recovery included, must sit in the UAE. The Abu Dhabi Healthcare Information and Cyber Security Standard (ADHICS V2, effective August 2024) adds that health information and every copy of it stay in the country, with support given from inside it unless DoH grants an exemption. Read on 30 September 2026; not legal advice.

DoH Responsible AI Standard. The Abu Dhabi Department of Health standard, DoH/ST/DDGO/RAI/V1/2025, that sets the minimum requirements for developing, procuring and deploying AI systems across the Emirate's healthcare sector.

Written by Tayyeb Mahmud, founder and Principal Architect. Claude Certified Architect – Professional · LinkedIn profile of Tayyeb Mahmud

Checked 30 September 2026. The Responsible AI Standard, ADHICS V2 and the 2018 AI policy were read as published on doh.gov.ae; AWS's and Microsoft's region lists on their live pages. The official text of Federal Law No. 2 of 2019 could not be read from uaelegislation.gov.ae, so this page states only what the UAE government portal says of it. The Standard is due for revision in October 2026, so check for a newer version before relying on it. This page is not legal advice.

Two documents set the bar, and a vendor is inside both

Abu Dhabi regulates health AI through its Department of Health rather than through a general AI law, and it does so in two documents that were written for different purposes. The Responsible AI Standard is about the AI system: how it is designed, tested, supervised and explained [1]. ADHICS, the Abu Dhabi Healthcare Information and Cyber Security Standard, is about health information wherever it goes, and it is the one that decides where your infrastructure and your support staff can be [2]. An AI project has to satisfy both, and the Responsible AI Standard says so itself: AI systems must meet the security requirements of applicable law and regulation, ADHICS included [1].

The Responsible AI Standard applies to DoH and to every licensed healthcare entity in the Emirate that develops, procures or deploys AI. It covers tools, devices, datasets, agents and platforms used for clinical, financial, administrative and related work, and it follows a system from inception to decommissioning whether the system was built in-house, bought from a third-party vendor or produced in a research collaboration [1]. A billing model at an insurer is in scope. So is a transcription assistant a hospital buys off the shelf.

ADHICS reaches further. It applies to any entity in the Emirate that generates, accesses, stores, uses, processes or transmits health information, healthcare technology and service providers included, and it gives those providers their own control category, naming medical device and technology providers, electronic medical record providers and web and mobile applications [2]. An AI vendor selling into Abu Dhabi health therefore has ADHICS controls of its own to meet, as well as its customer's. The timeline for compliance in each category is six months from onboarding to the programme or from the standard's release, whichever comes first [2].

DoH published a policy on the use of AI in the sector in April 2018 [3]. The 2025 Standard describes itself as the minimum requirements that put DoH's AI policy into practice, and it lists a June 2025 AI policy and a July 2025 AI risk management document among its references [1]. On the date this page was checked, DoH's public policies page listed the 2018 policy, and I could not find the two 2025 documents there [4]. The detail of the risk process sits in a separate DoH protocol the Standard refers to [1], so ask DoH's Data and Digital Governance Office for the current copy before you design the risk work.

The scope is the Emirate of Abu Dhabi. A provider licensed elsewhere in the UAE should check the rules of the health regulator that licenses it, and the federal layer applies across the country: the UAE government portal describes Federal Law No. 2 of 2019 as regulating the use of information and communication technology in health care in the UAE, including its free zones [5].

What the Responsible AI Standard asks of an AI system

The Standard has four parts: core foundations for all AI systems, data management, risk management and AI literacy [1]. Most of what changes a build sits in the first two. The table reads each requirement against what it means for the system you are buying or building; the clause numbers are the Standard's own.

The DoH Responsible AI Standard V1 (DoH/ST/DDGO/RAI/V1/2025) as read on 30 September 2026, and what each requirement means for an AI system
Dimension	What the Standard requires	What it means for an AI system
Human oversight and escalation, 3.1.1.2 [1]	Human-in-the-loop or human-on-the-loop mechanisms; systems always function under human oversight, with clear escalation protocols and decision points set by risk level.	Every output has a route to a named person, and the thresholds that send a case to that person are written down per use case rather than left to the model.
Failure handling and fallback, 3.1.2.1 [1]	Reliable operation through infrastructure failures and adversarial threats; graceful degradation and fallback procedures for continuity of care; safety testing and failure mode analysis before deployment.	When the model or its host fails, the clinical or administrative process carries on by hand, and that fallback is tested before launch rather than discovered during an outage.
Validation and monitoring, 3.1.3.1 [1]	Validation against established benchmarks before deployment, across diverse datasets; continuous monitoring after it; a significant decline must trigger review and corrective action, and results are kept for audit.	An evaluation set and pass mark agreed before build, the same checks running in production, and alert thresholds tied to a documented revalidation step.
Access control, 3.1.4.2 [1]	Role-based access, multi-factor authentication and least privilege across data, models, APIs and admin interfaces, with time-bound privileges monitored and all activity logged.	Nobody, engineers included, holds standing admin access to the model, the prompts or the data. Elevated access is granted for a period and leaves a record.
Data privacy, 3.1.4.4 [1]	Privacy by design and data minimisation; encryption at rest and in transit, anonymisation or pseudonymisation and key management across the lifecycle. Production data shall not be used to train the model.	Fine-tuning on live patient records is off the table under this clause as written. Evaluation and training sets are built separately, and a vendor's terms on training with customer data become a procurement question.
Infrastructure location, 3.1.4.5 [1]	Compute and storage for both active and disaster recovery sites situated within the UAE; remote access for development and support teams should be exclusively from within the UAE.	The model has to run in the UAE as well as the database, and so does the recovery copy. Where the supplier's engineers sit becomes part of the design.
Fairness, 3.1.5.1 [1]	Training, validation and test data that reflect the target population by age, gender, ethnicity, socioeconomic status and comorbidities; representativeness audits at set checkpoints; traceable bias mitigation.	Performance is reported by patient group, not only overall, and a gap between groups is a finding with an owner.
Transparency to patients, 3.1.6.1 [1]	Patients, clinicians and stakeholders are told when AI contributes to clinical or operational decisions; patients are told of their right to opt out where applicable, with clear consent mechanisms.	A disclosure in the patient journey, a way to opt out that the workflow honours, and plain-language summaries written for patients rather than clinicians.
Traceability, 3.1.6.2 and 3.1.7.1 [1]	Documented data provenance, model architecture and decision criteria; end-to-end traceability logs of inputs, outputs and version history; every decision, change and intervention logged and traceable to a responsible party.	Each output can be tied to the input, the model version, the prompt or configuration version and the person who acted on it.
Accountability, 3.1.7 [1]	Designated owners for each system; named people for monitoring outputs, reviewing flagged cases and overrides, and reporting adverse outcomes; clinicians should retain ultimate decision-making authority; override mechanisms and audit trails built in.	An owner per system and per risk, a review queue someone is responsible for, and an override the clinician can use without asking IT.
Data management, 3.2 [1]	Data from authenticated sources with provenance kept; every dataset mapped to a defined AI task; uniquely versioned datasets in immutable storage; datasheets or data cards held in a central registry.	Dataset versions are pinned to model versions, so a result can be reproduced, and no data is collected for an undefined future use.
AI literacy, 3.4 [1]	Continuous, role-specific training for everyone who works with AI systems, including when human judgement should prevail, with literacy metrics tracked.	Rollout includes training for clinicians on the tool's limits and override, and a way to show who has completed it.

Two clauses are easy to underestimate. The first is the training ban: production data shall not be used to train the model [1]. The second is infrastructure location, which sits in the AI standard as well as in ADHICS and names the disaster recovery site explicitly [1, 2]. The Standard also asks for energy-efficient design and a sustainability impact assessment for high-impact systems [1].

The risk tier decides how much of this goes to DoH

Every AI system and related asset needs a risk assessment, recorded in a risk register with an owner for each risk [1]. Controls are then applied and the residual risk, what remains after them, decides the treatment. The Standard sets four outcomes [1].

Very high residual risk: Prohibited from deployment. There is no route through for a system that stays at this level after its controls.
High: Conformity assessments both before and after deployment, conducted in coordination with DoH's Data and Digital Governance Office.
Medium: Subject to the applicable AI governance policies, standards and risk reporting, with safeguards to bring risk to an acceptable level for the context and intended use. The Standard's own text calls this band limited risk.
Low and very low: Exempt from formal risk reporting, but still monitored to confirm the controls keep working.

The consequence for a project plan is direct. A system that lands in the high band carries a conformity assessment with DoH before it goes live and another after, so the tier needs deciding at the business case, not at go-live. The scoring method in the risk assessment guide, which scores one AI use case on six factors, is a reasonable way to prepare that conversation; it is not DoH's method, and DoH's own protocol decides the tier.

Beyond the tiers, each entity reports its compliance status, deviations and risks to DoH periodically and runs its own internal audits, DoH conducts periodic audits and technical assessments of regulated entities, and breaches can bring sanctions under the Disciplinary Regulations of the Abu Dhabi Healthcare Sector [1].

ADHICS: where the data, the backups and the support staff sit

ADHICS V2 was published in May 2024 and took effect in August 2024 [2]. Its cloud control, CS 1.2, is the one that shapes an AI architecture most. CS 1.2 sits in the Transitional and Service Provider categories, so it binds hospitals, centres, payers and healthcare technology and service providers rather than every entity in scope. DP 1.4 and CO 9.2 are Basic controls, which apply to every entity, and they keep health information and its copies in the UAE whatever the category [2]. Together they close most of the workarounds a supplier might suggest.

The whole cloud estate stays in the UAE (CS 1.2): The cloud environment must be physically hosted within the UAE, without any environment, infrastructure or system outside the country, including backup and disaster recovery [2].
No offshore access, analytics or support (CS 1.2): Health information in the cloud may not be opened up for access, use or support by other parties in a multi-tenant environment, by a party providing analytical services where the data or a copy is sent outside the country, or by a party providing remote support from outside the UAE [2].
Keys the host does not hold (CS 1.2): Data is encrypted at rest and in transit, the key is not provided by the cloud provider that hosts the application and data, and the provider does not store or control the entity's keys. Security controls in the cloud are tested by an independent external party [2].
Copies in any form stay in the UAE (DP 1.4): Health information and its copies, whether encrypted, anonymised, de-identified or pseudonymised, are not stored, processed or transferred outside the UAE. Only people physically present in the UAE, or holding a valid DoH licence to practise there, may access systems containing personal or health information. Exemptions are approved by the entity's management and then submitted to DoH [2].
Third parties and support from inside the country (CO 9.2): Health information is not transferred outside the UAE without a specific DoH exemption, the entity's staff and third-party staff provide assistance from within the UAE unless DoH has exempted them, and identified or de-identified health information is not shared with third parties or data processors unless DoH authorises it [2].

The anonymisation clause is the one I would read twice. A common plan for using a large language model hosted abroad is to strip identifiers first and send the rest. ADHICS names anonymised, de-identified and pseudonymised copies alongside the original, so that plan needs a DoH exemption rather than a better redaction step [2].

The support clauses matter just as much for a supplier. A follow-the-sun support desk, an offshore engineering team with production access or an observability tool that ships logs abroad each puts the estate outside ADHICS unless DoH has granted an exemption [2].

What this means for the cloud and the model

The first design decision is the region, and the recovery site has to pass the same test. AWS lists one region in the UAE, me-central-1, with three Availability Zones; its other Gulf region, me-south-1, is in Bahrain [6]. A standard AWS design that replicates to a second region for disaster recovery would put the copy in Bahrain, outside the UAE and outside CS 1.2 [2, 6]. Recovery has to stay within the UAE, across the Availability Zones of the one region or at another site in the country.

Microsoft lists UAE North in Dubai, paired with UAE Central in Abu Dhabi, and marks UAE Central as restricted: access is reserved for specific customer scenarios such as disaster recovery and has to be requested [7]. The in-country pair exists, but plan the access request before the recovery design depends on it.

The second decision is where the model runs, and it is a separate question from where the data sits. A region that hosts your database does not necessarily run the model you want, and a managed model endpoint can process requests outside the region you selected. Which managed models actually run inside a UAE region, and on which deployment types, is set out in the guide to which models run in Gulf regions, with the date each fact was checked. Under the Responsible AI Standard and ADHICS together, inference on patient data has to happen in the UAE [1, 2].

The third decision is who can touch the system. The Standard asks for human oversight, escalation and an override on every output that matters [1], which in practice means the model proposes and a deterministic check or a named person decides. ADHICS then asks that the people doing support and holding privileged access are in the UAE [2]. Write both into the operating model before a supplier is chosen, because they change who you can hire as much as what you build.

Questions to put to any AI supplier selling into Abu Dhabi health

Each question below has an answer that can be checked against the two standards. Take the answers in writing, dated, because both documents are on revision cycles: the Responsible AI Standard is due for revision in October 2026 and ADHICS in May 2027 [1, 2].

Which risk tier is this system, and who signed that off?: If the answer is high, ask what the supplier contributes to the conformity assessment before and after deployment [1].
Where do compute, storage, backup and recovery sit, by region name?: All four, named. A primary site in the UAE with a recovery copy elsewhere fails both standards [1, 2].
Where does inference run?: Name the model, the region and the deployment type. A model reached over a global endpoint is not in the UAE because the application is.
Who can reach the system, and from where?: Support, engineering and administrative access, with the country each operates from. Offshore support needs a DoH exemption under ADHICS [2].
Who holds the encryption keys?: Not the hosting provider, under CS 1.2 [2].
Will our production data train your model?: The Standard says production data shall not be used to train the model [1]. Get the supplier's terms on training in the contract.
What happens when the model fails?: Ask to see the fallback procedure and the test that proves it [1].
What does the patient see?: The disclosure, the opt-out and the plain-language explanation, in the languages your patients read [1].
What evidence can we give DoH?: Validation results, monitoring records, traceability logs and the risk register, produced by the system as it runs rather than written for the audit [1].

Where 1AYM fits

For an Abu Dhabi provider, insurer or health technology vendor, this is the work we would do. AI governance implementation turns the Standard into controls that run: the risk register and tiering, named owners, human review and override where the decision warrants it, traceability logs and the evidence DoH can audit. Production AI systems builds the system itself in a UAE region, with the fallback, monitoring and residency tests above, and hands it over with a runbook your own team can operate. For health work we build and test on synthetic or de-identified data by default, under identities the client issues, and the statement of work keeps access as narrow as the scope. ADHICS still asks for support from inside the UAE unless DoH grants an exemption, so ask any supplier, us included, which of its people would work from inside the UAE and what exemption would cover anyone who would not.

We have made this kind of region decision before. For a government-accredited EdTech in the Middle East we replatformed the production database into Google Cloud's Doha region, me-central1, to meet that client's residency requirements. Doha is in Qatar, which is the point: residency is decided per jurisdiction and per sector, and the same design would fail ADHICS for an Abu Dhabi health estate. We have also built Arabic-language AI, including bilingual Arabic-English search and Arabic document OCR, which matters when explanations have to reach patients in plain language. Clients in the Gulf can contract locally through 1AYM's UAE entity, and if the job is already scoped, we can resource it on contract from the collective of associates who work with 1AYM, held to the same standard.

For engineers: residency tests, keys, logs and fallback

The controls behind the build, each tied to the clause it answers. The clause numbers are the Responsible AI Standard's (RAI) and ADHICS V2's own.

A residency test in CI: Tag every store, queue, cache, log sink, backup vault and model endpoint with its region, and fail the pipeline on anything outside the UAE. Include the tools teams forget: error tracking, tracing and LLM observability services, which may hold data outside the UAE by default (RAI 3.1.4.5.1; ADHICS CS 1.2 items 2 and 3).
Key custody: ADHICS CS 1.2 item 5 says the key must not be provided by the cloud provider that hosts the application and data, and item 8 that the provider does not store or control it. Items 7 and 12 ask for a cloud service that lets the entity generate or configure its own keys. Read literally, a key generated by the host's own managed key service may not satisfy item 5, so settle the key architecture, such as an external key manager or HSM the host does not supply, with the entity's security office early.
Traceability records: Log each request with the input, the output, the model version, the prompt or configuration version, the dataset version the model was evaluated on, and the user and any reviewer who acted on it, in storage inside the UAE (RAI 3.1.6.2.3, 3.1.7.1.3, 3.2.4).
Fallback paths: Timeouts and a circuit breaker around every model call, with the process falling back to its manual route when the model or its region is unavailable. Test the fallback in a game day before launch (RAI 3.1.2.1.2 and 3.1.2.1.3).
Escalation in code: Route by confidence and by risk: low-confidence, out-of-scope and high-impact outputs go to a named reviewer's queue, and nothing is written to a clinical record without a check that is not the model. Sample confident outputs too, so the gate is tested on what it lets through (RAI 3.1.1.2, 3.1.7.2.3).
Monitoring by patient group: Track accuracy and error rates per group as well as overall, plus data drift against the evaluation set, with thresholds that open a revalidation ticket automatically (RAI 3.1.3.1.3, 3.1.5.1, 3.2.3.3).
Access: Role-based access and MFA on data, models, APIs and admin consoles; just-in-time elevation that expires; every privileged action logged. Keep engineers' access to production from inside the UAE, or record the DoH exemption that allows otherwise (RAI 3.1.4.2; ADHICS DP 1.4 item 3, CS 1.2 item 3).
Code and dependency review: Secure code review against a recognised framework such as OWASP or NIST, and automated vulnerability scanning before deployment and at each major update, for third-party AI software as well as your own (RAI 3.1.4.3.1).
Datasets as versioned artefacts: Immutable, uniquely versioned datasets with a change log, each linked to the models trained or evaluated on it, and a datasheet recording source, preprocessing, annotators, intended use and limits (RAI 3.2.4 and 3.2.5).

Sources

Abu Dhabi healthcare AI questions

What is ADHICS?

The Abu Dhabi Healthcare Information and Cyber Security Standard, issued by the Department of Health. Version 2 (DOH/SD/ICSO/ADHICS/V2/2024) was published in May 2024 and took effect in August 2024. It applies to any entity in the Emirate that generates, accesses, stores, uses, processes or transmits health information, including healthcare facilities, payers and healthcare technology and service providers, and it keeps health information and its copies in the UAE. Its cloud control additionally requires hospitals, centres, payers and technology providers to host cloud environments, backups and disaster recovery included, within the UAE.

Does the DoH Responsible AI Standard apply to AI vendors?

The Standard applies to DoH and to licensed healthcare entities in Abu Dhabi that develop, procure or deploy AI, and it covers systems sourced from third-party vendors. Vendors meet it through the entity's procurement and due diligence, and directly through ADHICS, which has its own control category for healthcare technology and service providers such as electronic medical record providers and web and mobile applications.

Can an Abu Dhabi health provider use a large language model hosted outside the UAE?

Not with health information, as the two standards read on 30 September 2026. The Responsible AI Standard requires compute and storage for AI systems, recovery sites included, to be in the UAE, and its clause states no exemption route. ADHICS says health information and its copies, including anonymised and pseudonymised ones, are not stored, processed or transferred outside the UAE unless DoH approves an exemption. This is a reading of the standards, not legal advice.

Can we anonymise patient data and then send it abroad for AI processing?

ADHICS names encrypted, anonymised, de-identified and pseudonymised copies alongside the original and keeps them in the UAE, with exemptions approved by the entity's management and then by DoH. So anonymisation on its own does not open that route. Ask DoH about an exemption before designing around one.

Which AI systems does the Standard prohibit?

Those assessed as posing a very high residual risk after controls are applied. High-risk systems may be deployed but face conformity assessments before and after deployment, coordinated with DoH's Data and Digital Governance Office. The detailed method sits in DoH's AI risk management protocol, which the Standard refers to.

Does the Standard apply in Dubai?

Its scope is DoH and licensed healthcare entities in the Emirate of Abu Dhabi. A provider licensed in Dubai or another emirate should check the rules of the health regulator that licenses it, and federal law, including Federal Law No. 2 of 2019 on ICT in health, applies across the UAE and its free zones.

Will the Standard change?

Probably. Version 1 was published and took effect in October 2025 with a one-year revision period and a revision date of October 2026. ADHICS V2 is due for revision in May 2027. Check doh.gov.ae for the current versions; this page reflects them as read on 30 September 2026.