Write one statement per AI system, per version, per deploying facility. Write it before go-live, keep it with your AI inventory, and reissue it whenever the model, the population or the deployment changes. Every claim should point to evidence that someone else can inspect, because that is what makes the statement auditable. The regulatory background is in the Landing Checklist.
This is a practical structure, not an official DoH or DHA form. Check what your regulator, your facility's AI governance committee and your contract require, and adapt it to fit. Under the DoH Responsible AI Standard, for example, high-risk systems need conformity assessments before and after deployment, carried out in coordination with DoH's Data and Digital Governance Office (DDGO) (clause 3.3.1.2.2.2). A statement like this one is supporting evidence, not a substitute for that assessment.
Document control
| Statement ID | [VS-2026-001] |
| AI system and version | [product name, model version, build hash] |
| Vendor / developer | [legal entity; UAE representative, if any] |
| Deploying facility | [facility name, licensing authority (DoH / DHA / MOHAP), licence number] |
| Risk classification | [tier under the facility's AI risk assessment (the DoH standard uses Very High / High / Medium / Low / Very Low), with the reasoning and a link to the assessment] |
| Medical-device status | [not a medical device / registered as ___ / assessment pending, with the reference] |
| Statement owner | [a role, not a person, e.g. Clinical AI Lead] |
| Issue date / next review | [dd Mmm yyyy] / [no more than 12 months later, or sooner on any trigger in section 7] |
| Supersedes | [previous statement ID, or "none"] |
Intended use
State what the tool is for, narrowly enough that you can test it. Everything else in the statement is measured against this.
One or two sentences: what the tool does, for whom, in which setting, and what output it produces.
Which clinical or administrative decision does the output feed into? Is the tool assistive (a human decides) or does it act on its own?
[assistive / semi-autonomous / autonomous]. The output feeds [the decision].
List the uses you have NOT validated and that users must not rely on it for. Be specific: for example, emergency department use, under-5s, or dictating prescriptions.
The user roles, the minimum training each needs, and whether patients ever see the output directly.
Target population
The UAE patient mix is unusual. A model validated elsewhere isn't validated here until it has been shown to work on this population.
Age range, care settings, and the languages and dialects patients actually use. For speech and text tools, that might include Emirati and other Gulf Arabic, Levantine and Egyptian Arabic, South Asian English, Filipino English, and Arabic–English code-switching.
The subgroups you report results for in section 4, and why. If a subgroup is too small to analyse, name it rather than leaving it out silently.
[language / dialect], [sex], [age band], [clinic type], [other relevant factor]
Groups the tool wasn't tested on, or was tested on too few of to draw conclusions.
Datasets
Keep what the vendor says about its training data separate from what you tested locally. Only the local test is yours to vouch for.
Summarise the vendor's description of its training and tuning data: sources, time period, geography and languages. Mark it as vendor-declared unless you have audited it.
Was any data from this facility's production systems used to train or tune the model? [No]. The DoH Responsible AI Standard, clause 3.1.4.4.2, says: "Production data shall not be used to train the model."
The dataset you actually tested on.
- Source and collection period: [e.g. consented consultations, Mmm–Mmm yyyy]
- Size: [number of cases / hours of audio]. Sampling method: [consecutive / stratified / random]
- Synthetic vs real: [the share of each, and how the synthetic data was generated]
- Consent and approvals: [reference for the research-ethics or data-governance approval, and the consent form version]
- Where it is stored and processed: [UAE region / on-premises, and who has access]
- Independence: [confirmation that the vendor never trained on or saw this set]
What counts as 'correct', and who decided. For example: notes written by two physicians, with a third settling any disagreement. Report inter-rater agreement.
Performance
Set acceptance thresholds before you run the test, and record when you set them. Report confidence intervals and subgroup results, not just a headline number.
| Metric | Threshold (pre-set) | Result | 95% CI | Met? |
|---|---|---|---|---|
| [primary metric, e.g. clinically significant errors per note] | [≤ x] | [value] | [lo–hi] | [Y/N] |
| [secondary metric, e.g. word error rate by language] | [≤ x] | [value] | [lo–hi] | [Y/N] |
| [safety metric, e.g. invented medication or dose] | [0 in n] | [value] | [lo–hi] | [Y/N] |
| [workflow metric, e.g. clinician edit time] | [baseline comparison] | [value] | [lo–hi] | [Y/N] |
The same metrics for each subgroup in section 2. Flag any subgroup that falls short of the threshold, and record what you did about it: restricted the tool's use, added a mitigation, or accepted the risk with sign-off.
Group the errors by type and by severity, with severity judged by clinicians. Include examples, de-identified and kept inside the UAE.
How the tool performs against the process it replaces, measured on the same cases.
Clinician role and human oversight
Who is clinically accountable for decisions made using the tool's output. In assistive use, that is the treating clinician.
What the clinician must check before accepting the output, how they correct or reject it, and whether their corrections are logged.
What users are taught before they get access: known failure modes, out-of-scope uses, and how to report an issue. Keep completion records.
How patients are told that AI is used in their care, and how they can opt out where that applies. Link the notice or the consent wording.
Deployment and data boundary
Show the regulator, and yourselves, where patient data goes. See the data-boundary reference.
The cloud provider and UAE region used for compute, storage, logs, backups and disaster recovery. Name every sub-processor that touches patient data.
Compute: [provider / region] · Storage: [provider / region] · DR: [provider / region]
Who can reach the production systems and data, from where, and how that access is controlled and logged. This includes vendor engineers, support staff and the facility's own IT team.
List every flow that leaves the country, such as telemetry, crash reports or model updates, and confirm that none of them carries health data. If one does, cite the legal exception and the approval it relies on.
State whether production data is used to train or tune the model, and the technical controls that prevent it.
Post-deployment monitoring
For example: each month, clinicians audit a random sample of outputs against the section 4 metric and threshold. Also track override rates and issues reported by users.
Sample: [n per month] · Owner: [role] · Reports to: [AI governance committee]
The values that trigger an investigation, a restriction or a rollback.
Re-run section 4 and reissue this statement after any of these: a new model version, a new site or specialty, a shift in the population or language mix, a change to the EMR or integration, or a serious incident.
Incident process
What counts as an AI incident: harm or a near miss, a clinically significant error that reached the record, a data leak, unexpected behaviour, or downtime.
Who reports, to whom, and how quickly: through internal patient-safety reporting, to the vendor, and to the regulator where its incident-reporting rules apply. Use the regulator's published timelines, not assumed ones.
The kill switch: who can suspend the tool, how fast, and what the clinical fallback is while it's off.
The contract clauses covering incident notification, cooperation with investigations, and fixing problems within agreed times.
Limitations and residual risks
A plain-language list for users: where the tool is weaker, and what it must not be used for.
What the subgroup analysis found, and the mitigations in place.
Each remaining risk, who accepted it, and when. Link to the facility's AI risk register.
Sign-off
| Role | Name | Decision | Date |
|---|---|---|---|
| Clinical lead for the deploying service | [] | [approve / approve with conditions / reject] | [] |
| Chair of the AI governance committee | [] | [] | [] |
| Information security (ADHICS / DHA owner) | [] | [] | [] |
| Data protection officer | [] | [] | [] |
| Vendor representative (attests to section 3) | [] | [] | [] |
Evidence index
Keep one row for every claim in this statement, recording the document that backs it, its version and where it is stored. If an auditor can't follow the index to the evidence, the statement isn't auditable.