TL;DR: Most "agentic AI" in healthcare today is either a scribe, a workflow automation, or a chatbot with a new label. The deployable parts are narrow, supervised and wired into existing systems. The hype is autonomous agents that order, prescribe or decide. In late July 2026 UK regulators drew a clear line between the two, and Abu Dhabi has had a healthcare AI policy since 2018. If you run a hospital group, clinic network or health-tech product in the UK or the UAE, the question for this quarter is not "should we buy an agent?" but "which three workflows can an agent safely touch, and who signs off its output?"
What "agentic" actually means in a clinical setting
A chatbot answers. An agent acts: it reads a record, decides a next step, calls another system and does something. In healthcare that could mean drafting a referral letter, chasing a prior authorisation, rebooking a missed appointment, or placing an order. The risk profile changes at the moment the software takes an action without a person reviewing it first.
That is also where the marketing gets loose. Gartner's June 2025 press release is titled "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027" (Gartner). That is a cross-industry forecast, not a healthcare one, and I could not retrieve the full release text for this article, so I will not repeat its detailed reasoning. The headline alone is a useful prior: a large share of agent projects are expected to be abandoned, and healthcare adds clinical safety and data-protection constraints on top.
Our point of view: autonomy is the wrong thing to shop for
Buyers keep asking how autonomous a product is. We think that is backwards. In a clinical environment, the valuable property is bounded autonomy: an agent that does a defined job, inside a defined permission set, with a human checkpoint wherever a patient could be harmed. The most deployable systems are boring. They summarise, draft, route, reconcile and remind. They do not diagnose.
The regulatory line is now unusually clear in the UK
On 29 July 2026 the MHRA published guidance, developed with NHS England, on how existing medical device law applies to ambient voice technology (AVT) in Great Britain (MHRA). Its position, in the MHRA's words, is that products "intended solely for transcription, summarising of clinical conversations, drafting letters, or suggesting clinical codes for a clinician to review are not regulated as medical devices under the current framework". Products "intended to support diagnosis, treatment or prevention, or that take automated action such as placing orders without clinician review, are regulated as medical devices".
Read that as a design rule. The same underlying model can sit on either side of the line depending on its intended purpose and whether a clinician reviews its output. The release also says the guidance "does not change the law", and that clinicians remain responsible for reviewing and verifying AI-generated transcripts and summaries before use in patient care.
NHS England's accompanying letter, signed by NHS England and the MHRA chief executive, asks boards to assure themselves on five areas (NHS England): oversight and accountability, local governance, staff training, risk management (including privacy, consent, information quality and automation bias), and commercial and procurement arrangements. Two details matter for anyone selling or buying. First, organisations should identify and review any change in a product's functionality that could alter its regulatory status. Second, contracts should give rights to monitor performance, audit compliance and manage changes in functionality "including at AI model update milestones". The letter also says NHS organisations should procure AVT products that can interface with the electronic patient record, natively or through full integration.
The practical consequence: a vendor quietly adding "auto-order" to a scribe can turn a non-device into a regulated device. Your contract and change control need to catch that.
The UAE: governance is expected, and data rules are strict
Abu Dhabi's Department of Health issued its policy on AI in the healthcare sector in 2018 (the exact day differs between the sources we checked). Per the law-firm summary we read, it applies to licensed providers and professionals, as well as to those using Abu Dhabi patient data in AI work, and expects users to have clear governance for AI, regular audits of AI functionality and reporting to the DOH (Al Tamimi & Company). An International Bar Association article from May 2026 describes the wider UAE picture, including the federal ICT Health Law, which it says requires local storage and processing of health data subject to exceptions, and the Personal Data Protection Law, under which health data is sensitive personal data (IBA). It also notes a DOH Responsible AI Standard from 2025 and a Dubai Health Authority AI policy from 2021. These are secondary summaries; confirm obligations against the primary texts with local counsel before you design anything.
For architecture, this means data residency and auditability are first-order requirements, not afterthoughts. An agent that sends patient context to a model endpoint outside the permitted boundary is a compliance problem before it is a quality problem.
What is deployable now, and what is not
Deployable with supervision:
- Ambient scribing and clinical summarisation, where a clinician reviews every output. This is the use case regulators in the UK have explicitly addressed.
- Appointment operations: reminders, rebooking after no-shows, waitlist fills. Low clinical risk, easy to measure.
- Administrative back-office work: coding suggestions for human review, claims and eligibility checks, document intake and classification.
- **Patient-facing triage of logistics, not symptoms**: opening hours, preparation instructions, how to reschedule, with a clear handoff to staff.
Not ready, in our view:
- Agents that place orders or prescribe without clinician review. In the UK this is the point at which the MHRA says a product is regulated as a device.
- Agents given broad write access to the patient record "to be helpful".
- Anything described as "fully autonomous" in a procurement deck without an answer to the question: who is accountable when it is wrong?
The risks that actually bite
Automation bias. NHS England names it explicitly. Clinicians who see a fluent summary tend to accept it. Design the review step so that checking is easy and skipping is visible.
Silent scope creep. Vendors add capabilities. Treat every model or feature update as a change request, as NHS England's contract language implies.
Integration debt. An agent that cannot read from and write back to the EPR or hospital system through proper interfaces ends up as a copy-paste tool. Standards such as FHIR and HL7 are the usual route; plan for them early.
Data boundaries. Where does inference run, what is logged, who can see prompts? In the UAE especially, answer this before the pilot, not after.
Evaluation gaps. Most pilots measure time saved and user satisfaction. Few measure error rates against a clinician-verified baseline. Without that, you cannot tell a good agent from a confident one.
A deployment pattern that holds up
- Pick a workflow, not a department. One referral pathway, one clinic's scheduling, one discharge-letter template.
- Define the permission set. List what the agent may read, what it may write, and what it may never do.
- Insert a named human checkpoint wherever output touches a patient decision.
- Log everything the agent reads and does, in a form an auditor can follow.
- Integrate properly through APIs and standards rather than screen-scraping. Our API development and integration work is mostly this problem.
- Measure against a baseline you established before launch, including error and override rates.
- Write change control into the contract so a model update cannot change risk class unnoticed.
What to do this quarter
- Inventory every AI feature already inside your clinical and admin systems. Many organisations have agent-like behaviour they have not named.
- Choose two or three low-risk workflows for supervised pilots, such as appointment operations and document intake. Our guide to business process automation shows how we scope these.
- Write an AI governance one-pager: owner, permitted uses, review requirements, incident route. In Abu Dhabi, this lines up with the expectation of clear governance and audits; in the UK, with the board assurance areas above.
- Update procurement templates with functionality-change, audit and model-update clauses.
- Settle data residency for each pilot before vendor selection. Our compliance and risk consulting team works on exactly this kind of mapping.
- Define what "success" means in clinical-safety terms, not only hours saved.
Where the underlying systems fit
Agents are only as useful as the systems they connect to. A hospital information system with clean interfaces, role-based access and an audit trail is the foundation; an agent bolted on to a fragmented stack inherits the fragmentation. For more on how we approach this, see our healthcare industry page and hospital information system overview. Our HIMS is scheduled to launch on 20 December 2026, India first, with support for FHIR/HL7, multi-currency and VAT, and in-country hosting. We make no claims here about certifications or customer outcomes. If you are weighing where an agent belongs in your roadmap, our IT strategy consulting can help you sequence it; pricing is scoped on a consultation.
Conclusion
The honest summary of agentic AI in healthcare is that the deployable systems are narrow, supervised and integrated, and the exciting ones are mostly not ready. UK regulators have now stated where the line sits, and Gulf regulators expect governance and data discipline. Teams that treat agents as bounded workflow tools, with clear ownership and change control, will get value this year. Teams chasing autonomy will mostly collect pilots.
Ready to scope a safe first agent pilot? Book a consultation and we will map your workflows, data boundaries and integration points.
