NHS AI in practice: 7 reasons pilots die (and the playbook to scale safely)

Dr Kola Tytler (MBBS CertHE MBA MRCGP)||8 min read
Featured image for NHS AI in practice: 7 reasons pilots die (and the playbook to scale safely)

AI in the NHS is no longer a fringe experiment. The NHS has published a growing set of implementation resources and “AI in practice” lessons through the NHS AI Knowledge Repository — including guidance on governance, evaluation, procurement, and safe deployment.

And yet, the pattern remains familiar:

Pilot succeeds in a small pocket. Scaling fails. Clinicians quietly revert.

This isn’t because “the model wasn’t clever enough”. It’s because the implementation system wasn’t ready.

Below is a practical, clinician-readable guide to what actually makes AI scale in the NHS — grounded in NHS implementation guidance and widely repeated board-level lessons.

The NHS reality: a pilot is not a pathway

A pilot is a test of feasibility.

A pathway is a repeatable operating model:

  • Integrated with the EPR and workflow
  • Owned by clinical leadership
  • Governed under digital clinical safety and IG
  • Measured with credible real‑world evaluation
  • Supported with training, monitoring, and an incident route

If you cannot explain how you move from pilot to pathway, you do not have an AI programme — you have a demo.

Why AI pilots die: the 7 implementation traps (and how to avoid them)

Trap 1 — Starting with a solution, not an outcome

Symptom: “We’re implementing an AI tool” is the strategy.

Why it kills scale: You end up optimising for adoption of a product, not impact on a clinical or operational problem.

Avoid it: Write a one-line outcome statement with a measurable denominator.

  • “Reduce time-to-triage for X by Y% without increasing risk.”
  • “Improve detection of X within existing pathway constraints.”

Implementation move: agree a benefits map before procurement.

Trap 2 — The basics aren’t in place (and everyone feels it)

Symptom: staff struggle with Wi‑Fi, multiple logins, slow machines, inconsistent data capture.

Why it kills scale: AI amplifies what you already have. If your foundations are weak, your outputs and trust will be weak.

Avoid it: treat “boring IT” and data quality as an AI prerequisite.

Implementation move: identify your “best datasets” and your known weaknesses early; don’t pretend every data source is equally usable.

Trap 3 — No workflow integration (the tool lives outside the pathway)

Symptom: AI output arrives via email, separate portal, or a second screen.

Why it kills scale: Clinicians do not adopt extra clicks during live work. Integration is not “nice to have” — it is the difference between a pathway tool and a curiosity.

Avoid it: insist on:

  • EPR integration where appropriate
  • clear handoff points
  • realistic time-in-motion testing (clinic, ward round, on‑call)

Implementation move: if your AI is not embedded into the clinical workflow, it will not become business‑as‑usual.

Trap 4 — Governance is treated as a wrapper, not part of delivery

Symptom: DPIA and clinical safety are started late; responsibility is unclear.

Why it kills scale: You hit a governance wall when momentum is highest.

Avoid it: build governance into the project plan from day one.

Minimum NHS‑style governance elements to expect in England:

  • Digital clinical safety assurance (DCB0160 for adopting organisations; DCB0129 evidence from suppliers where applicable)
  • Clinical Safety Officer (CSO) identified
  • DPIA completed (and updated when scope changes)
  • DTAC evidence from suppliers (where relevant)
  • A clear incident reporting pathway (including MHRA considerations where applicable)

Implementation move: treat governance and ethics as an enabler — it helps you move faster with confidence.

Trap 5 — “Trust” is assumed, not built (transparency is missing)

Symptom: staff don’t know what the AI does; patients worry about data use; rumours fill the gap.

Why it kills scale: People will not adopt what they cannot explain.

Avoid it: a simple transparency discipline:

  • What the AI does (plain English)
  • Why it’s being used (outcome, not hype)
  • Where the data goes (in‑scope vs out‑of‑scope)
  • Who remains responsible (clinician oversight)

Implementation move: publish a short “AI factsheet” for staff and patients, and update it as the tool evolves.

Trap 6 — Evaluation is misclassified, underpowered, or not credible

Symptom: “We’ll do a quick service evaluation” turns into R&D blockers, dataset delays, and confusion about approvals.

Why it kills scale: Without credible real‑world evidence, scaling becomes a political battle rather than a learning process.

Avoid it: build evaluation in early with the correct classification and stakeholders.

Practical lessons from NHS evaluation work:

  • Mixed qualitative + quantitative methods are often essential (because implementation changes behaviour and workflow)
  • Pragmatic designs are frequently more feasible than idealised trials
  • Independent AI expertise and clinical leadership matter (supplier claims often need external scrutiny)
  • Agreements on roles, responsibilities and data sharing should be explicit

Implementation move: decide what success looks like and how you’ll measure unintended consequences (e.g., workload shift, deskilling, inequity).

Trap 7 — No monitoring model (and no plan for change)

Symptom: the pilot has no owner after go‑live; updates happen without impact assessment; errors are noticed anecdotally.

Why it kills scale: AI performance can drift. Workflow can change. Staff turnover happens. Without monitoring, you accumulate silent risk.

Avoid it: define a monitoring framework that includes:

  • output quality audits
  • incident and near‑miss review
  • performance dashboards (clinical + operational)
  • update control (what changes trigger reassessment)
  • decommissioning plan

Implementation move: your “pilot” should end with a runbook — not just a report.

From pilot → pathway: the NHS playbook for safe adoption (what good looks like)

Use this as a step‑by‑step skeleton. If a step is missing, the project is at risk.

Step 1 — Name the outcome (one sentence)

Outcome statement template

We are using AI to improve [process/clinical outcome] for [population] by [metric],
without worsening [safety/equity/experience], within [pathway constraint].

Step 2 — Map the pathway (before you touch the tech)

  • Where does the decision happen?
  • Who acts on the output?
  • What is the fallback when AI is unavailable?

Step 3 — Define the “minimum viable workflow”

  • Who clicks what?
  • Where does the output appear?
  • What happens in a time‑pressured scenario?

If the workflow cannot survive a busy Monday morning, it will not scale.

Step 4 — Put the basics in place

  • Access (logins, latency, devices)
  • Data quality and representativeness
  • Clinical coding realities
  • Integration constraints (EPR, interoperability)

Step 5 — Build governance into the plan (not after)

Minimum viable governance pack (England)

  • DCB0160 clinical safety case (deployment)
  • Supplier DCB0129 evidence (manufacture), where applicable
  • Named Clinical Safety Officer
  • DPIA (and a plan for changes in scope)
  • DTAC evidence (where relevant)
  • Clear incident route (clinical + digital)

Step 6 — Procure for reality, not the demo

Procurement questions that matter:

  • What integration is proven in NHS settings?
  • What is the update process and how is it governed?
  • What evidence exists in a comparable pathway?
  • What monitoring outputs are available to the adopter?

Step 7 — Train the users (and design for human factors)

A practical training stack:

  • what the tool does and doesn’t do
  • common failure modes
  • how to override safely
  • how to document oversight
  • how to report issues

Step 8 — Evaluate impact (including unintended consequences)

Build evaluation around:

  • clinical outcomes
  • safety signals
  • staff workload and time
  • patient experience and trust
  • equity impact (who benefits / who is harmed)

Step 9 — Scale intentionally (avoid “pockets of AI”)

Scaling requires:

  • resourcing (change, training, clinical leadership)
  • clarity on what projects the AI work displaces on the roadmap
  • a kill‑switch if benefits don’t materialise

Step 10 — Operate it like a service (runbook + monitoring)

AI at scale is not a project. It is a service.

Your runbook should specify:

  • owner, cadence, escalation
  • audits, dashboards, thresholds
  • update governance
  • decommissioning

Copy/paste: the board-to-ward “pre‑mortem” (10 minutes)

Use this before committing to go‑live.

Imagine it is 12 months from now and this AI implementation failed.
Write the top 5 reasons why.
For each, write the earliest warning sign we would see.
Assign one owner to monitor each warning sign monthly.

It turns vague risk into operational reality.

What this means for clinicians (especially GPs)

Clinicians don’t need to become data scientists. But if you’re asked to support AI adoption, you do need to be able to ask the right questions.

The clinician’s five questions

  1. What exactly does the tool do — and what does it not do?
  2. Where is it embedded in the pathway, and what is the fallback?
  3. What evidence exists in settings like ours?
  4. What are the risks (clinical, equity, privacy), and what mitigations exist?
  5. How will we monitor performance and act on incidents?

Where iatroX fits (clinician adoption without tab‑sprawl)

Most AI implementations fail at the “human layer”: training, confidence, and a clean knowledge trail.

iatroX is designed to support that layer:

  • Knowledge Centre routes clinicians quickly to authoritative leaf pages (e.g., NICE / NICE CKS)
  • /shared captures referenced reasoning for learning, reflection, and CPD
  • /q turns “read it once” into retrieval practice so teams stop re‑searching the same decisions

In other words: as your organisation adopts AI, clinicians still need to stay anchored to defensible guidance and retain the key decision points.

Key NHS resources worth bookmarking

Share this insight