Making clinical AI work in the NHS: a practical view from the ward and the boardroom

Why this conversation matters now 

If you hold a clinical leadership role in the NHS — Clinical Director, CCIO, clinical operations lead, digital transformation lead — you are likely being asked two things at once: Show progress on AI, and do not put patients at risk. 

Those two asks are compatible, but only if the work happens in the right order. 

In September I spent a morning at the Royal Society of Medicine (RSM) with more than 50 senior NHS colleagues, working through what makes clinical AI succeed in practice and what stops it. Below are some of my key findings from the discussions organised around the decisions you are actually being asked to make. 

Explore more insights from the dialogue in our full white paper: Read the white paper.

Start by redefining what a successful pilot means 

Nearly everyone in the room could name a pilot that performed well and then went nowhere. The phenomenon has a name — pilotitis — and two consistent causes: lack of funding tied to implementation and lack of alignment amongst teams. 

The most practical idea to come out of the discussion was implementation debt. Software teams talk about technical debt: shortcuts taken early that cost more to fix later. AI deployments accumulate the same thing. During the excitement of a pilot, the difficult questions get deferred. How is this trained into the workforce? How does it sit in the workflow? Who owns governance? What happens when the product updates? 

Align the people who use it with the people who fund it 

The people who commission a pilot are frequently not the people who use the tool. I have seen pilots where clinicians were genuinely impressed by a tool’s value while the person signing the contract was not aligned at all — and the reverse. Define that alignment at pilot stage. Build awareness and checkpoints into the pilot design and be explicit about where the checkpoint sits. 

Sometimes the barrier is as simple as discoverability. We rolled out a pilot where the question that mattered most turned out to be whether anyone knew the tool existed. 

Measure the right thing. When we say a pilot succeeded, what we should mean is that adoption happened. That is the number that predicts whether the tool survives contact with the organisation. 

Design for the workflow, because friction decides everything 

I will restate a point I have made in clinical settings many times, because it is the most practical thing I know about AI adoption: 

On a typical on-call shift I will see 50 to 70 patients. A tool that needs a separate login, extra navigation, manual re-entry of data that already exists in the record, or more than a few seconds to return something useful, will not be opened. That is not resistance to technology. Every unnecessary step is time not spent with a patient. 

People working under pressure take the path of least resistance. That is true in every profession. The implication for you as a clinical leader is straightforward and, I think, encouraging: friction is diagnosable and fixable. 

What to do when adoption is low

If your sanctioned tool is not being used six months in, resist the instinct to mandate. Mandating use of a tool clinicians do not trust produces documentation, not clinical benefit — and it creates a false impression of governance, which is worse than low adoption. 

Map the workflow instead. Count the steps between a clinician having a question and the tool giving them a usable answer. Then reduce them. Jan Herzhoff, PhD, President of Elsevier’s global health business, made a point at the event that I think about often: do the full due diligence before deployment, and then make the thing as simple to use as you possibly can. Both halves matter, and the second is the one that gets skipped. 

Recognise that AI is already in your organisation 

Here is the gap that receives too little attention in NHS AI strategy: personal adoption has run far ahead of institutional adoption. 

Clinicians are using AI today. So are patients and care teams. General-purpose chatbots are being used to check differentials, review drug interactions and sense-check decisions — on personal devices, outside any governance framework, with no audit trail and no visibility to the organisation whose patients are affected. Meanwhile, fewer than half of healthcare organisations report having effective AI governance in place. 

Those two findings sit together uncomfortably. The tools are in use. The governance frequently is not. 

This is why I think the most effective response is provision rather than restriction. Policy that forbids AI use without offering a credible alternative does not reduce risk, but instead relocates the risk somewhere you cannot see it.

Define what trustworthy looks like before you procure 

When I speak to organisations about procuring clinical decision support, my advice is to define what you want before you look at what is available. Here are a few questions that I suggest taking into consideration.

Answer those and you have defined your acceptable risk. When you find a tool that sits inside it, you have a winner — and a defensible position. 

Where specialist tools differ from general-purpose models 

As a Clinical Executive at Elsevier and a practising physician, these are the questions we asked when building our product, ClinicalKey AI. 

It is grounded in peer-reviewed clinical literature and returns its answers with the sources attached. You can follow a recommendation back to the study it came from, look at how that study was conducted, and decide whether it applies to your patient. That is a deliberate design choice, and it is the one I would defend if I did not work here. 

The wider point matters more than the product. A general-purpose model gives you a conclusion. What clinical practice needs is a conclusion you can interrogate — because when a clinician asks whether they can trust a tool, what they are usually asking is whether they could stand behind a decision made with it. An answer with its evidence attached lets you answer that. An answer without does not. 

Put the five questions above to us. Put them to everyone else on your shortlist. That is a better use of your time than any vendor article, including this one. 

Liability: what to tell your clinical teams 

The liability question comes up in every conversation I have about clinical AI, and clinicians are often carrying more anxiety about it than the legal position warrants. 

The standard is reasonableness 

The governing test is the same one that applies across your practice. Did you act reasonably, given the information available? If you reviewed what the tool provided, the recommendation was plausible against the clinical evidence, and you documented your decision, your exposure is no greater than with any other clinical input. 

Risk rises in two situations. When output is accepted without review. And when staffing levels or patient load make meaningful review impractical. The second is an organisational accountability — which means it is one you can act on. 

What contracts can and cannot do

A persistent misunderstanding in procurement is that liability can be allocated by contract to wherever the parties prefer. It cannot. Where the law places responsibility, it stays. What a contract can do is ensure every party has stated plainly what the tool does and does not do, what evidence it rests on, what its limitations are, and where clinical responsibility sits. Get those conversations onto paper early, because parties often believe they are aligned until they try to write it down. 

Keeping the risk where it belongs

The organisations that manage this well define their acceptable risk before procurement, and choose partners who provide due diligence, continuous performance evaluation and a route for reporting concerns. That reduces the risk sitting with the trust and keeps it where it should sit. It is also what makes the case land in a boardroom. 

Track the legal landscape

The UK Jurisdiction Taskforce (UKJT) publication of July 2026 sets out the law on AI liability including healthcare, with some interesting variance against what the Medical Protection Society has said on the same question, and the Law Commission is reviewing aspects now. On clinical safety, DCB0160 applies whether or not a tool is a medical device — and it has been under consultation, which is a live opportunity for clinical leaders to shape the standards they will work under. It is also worth pointing your teams to the current General Medical Council (GMC) guidance and their own indemnity organisation. 

What convinces an NHS board 

If you are the person taking an AI proposal to a board, the discussion produced clear guidance on what lands.

One further point worth carrying into board conversations. As well-validated clinical decision support becomes widespread, it starts to become the standard of care. The organisation that has not deployed equivalent capability may find that is the position it has to defend. The question shifts from why are we doing this to why have we not. 

Six things you can act on

A final thought 

The morning closed on a reflection I have thought about often since. The culture of curiosity that has driven medicine forward for centuries needs to survive the arrival of these tools. 

That is a training question, a governance question and a leadership question all at once. It means clinicians who understand what a tool was built on and where it runs out. It means organisations that give their people something worth trusting. And it means holding the line, clearly and without ambiguity, that the clinician decides. 

None of that is beyond us. The technology will keep moving, and there is good reason to think we can move the governance, the training and the culture with it — for the benefit of every patient we serve.