NHS AI governance board: what to approve first

An NHS AI governance board should approve use cases, clinical safety, data protection, supplier assurance and monitoring before a tool reaches patients or staff. The evidence is a DCB0160 safety case, DPIA, DTAC or equivalent assessment, medical-device classification and named human accountability.

This applies to trust boards, integrated care board leaders, quality committees, chief clinical information officers and senior responsible owners approving AI in patient pathways, administration, population health, clinical documentation or board reporting. It is not a product-selection checklist. It is the assurance evidence a board should expect before it signs off adoption.

Key takeaways

• NHS AI adoption is now a board issue, not only a digital team issue: NHS England announced on 8 June 2026 that 505,000 clinicians and support staff would receive Microsoft 365 Copilot access, with rollout expected by October 2026.
• Trust boards should approve the intended use, risk appetite, clinical safety case, data-protection position, patient transparency and monitoring route before deployment.
• ICBs should set the system frame where adoption affects pathway design, procurement route, interoperability, shared records, population health or regional assurance.
• The minimum evidence set is practical: DCB0160, supplier DCB0129, DPIA, DTAC or equivalent assessment, medical-device classification, equality review, cyber assurance and post-go-live monitoring.
• Human oversight has to be named and observable: the clinician or officer reviews the output, local incidents are logged, and drift or bias is monitored after launch.

NHS AI governance board decisions, not tool demos

The NHS AI adoption question changed on 8 June 2026, when NHS England announced that 505,000 clinicians and support staff would be given Microsoft 365 Copilot access. The same release said the trial covered more than 30,000 NHS workers across 90 organisations, found an average saving of 43 minutes per staff member per day or more, and expected rollout to more than 500,000 staff across the NHS by October 2026.

That does not make every local use low risk. Copilot may draft board papers or analyse service data. Ambient scribes may record consultation audio and produce clinical notes. Triage tools may route a person toward or away from care. Imaging tools may affect clinical prioritisation. Each case needs a different control set, but the board question is constant: what are we allowing this system to do, to whom, with which data, and what evidence proves it is safe enough?

NHS England's ambient scribing overview is explicitly written for senior executives and board members, and its implementation guidance tells adopters to assign a clinical safety officer, complete DCB0160 documentation and a DPIA, check regulatory status, train users, and monitor outputs after adoption (NHS England ambient scribing guidance). The article on public-sector AI go-live evidence makes the same point for local authorities: governance is the artefact set someone can inspect, not a promise that the tool is useful.

What the trust board and ICB approve

Trust boards and ICBs should not duplicate each other. The trust board owns local clinical safety, patient impact, operational risk and evidence of oversight. The ICB sets the system boundary where a tool crosses organisational lines, affects pathway design, touches shared data, or needs regional procurement and assurance. NHS England's ambient guidance tells organisations to seek local ICB help where they lack capability and to engage ICB and regional teams before pilots or commercial engagement for ambient scribing products.

The decision frame should separate five approvals:

1. Intended use. What the system may do, what it must not do, and whether it touches direct care, administration, population health or board reporting.
2. Patient and staff impact. Which groups could be harmed by errors, bias, data leakage, poor accessibility or loss of a non-digital route.
3. Clinical safety and regulation. Whether DCB0160 applies locally, whether the supplier has DCB0129 evidence, and whether MHRA medical-device rules are engaged.
4. Data protection and transparency. The lawful basis, DPIA, controller and processor roles, patient-facing explanation, opt-out or objection route where relevant, and retention rules.
5. Monitoring and accountability. The named owner, incident route, audit cadence, output review, bias monitoring and trigger for suspension.

For a trust, this should land in the quality or risk committee before full board approval. For an ICB, it belongs with the committee that owns digital, quality and population health risk, with a clear link to provider assurance. The wider UK position is still that there is no single AI statute, as set out in our UK AI regulation board guide; in the NHS, that absence makes the existing clinical, data, medical-device and CQC duties more important, not less.

Controls and evidence for go-live

The board pack should contain evidence, not a slide saying the evidence exists.

Control	Evidence the board should ask for	Owner
Intended-use boundary	One-page use-case statement naming permitted and prohibited actions, including whether the tool can suggest diagnosis, treatment, triage or coding	SRO and clinical lead
Clinical safety	DCB0160 safety case, hazard log, clinical risk management plan and supplier DCB0129 clinical safety case where applicable	Clinical Safety Officer
Data protection	DPIA, record of processing, controller and processor map, retention schedule and patient-facing transparency wording	DPO or IG lead
Supplier assurance	DTAC or equivalent assessment covering clinical safety, data protection, technical security, interoperability, usability and accessibility	Procurement and digital lead
Medical-device status	MHRA classification assessment, registration evidence, UKCA or CE position, intended purpose and instructions for use	Clinical safety and procurement
Human oversight	Named reviewer role, sampling plan, audit record of accepted or corrected outputs and escalation rule for errors	Service owner
Cyber and resilience	Secure configuration record, access controls, logging, incident route and supplier security evidence aligned to NCSC secure AI guidance	SIRO and cyber lead
Monitoring after go-live	Accuracy, safety, bias and incident metrics; review date; kill switch; route to MHRA Yellow Card or local patient-safety reporting where needed	Quality committee

CQC's July 2025 GP mythbuster gives a useful inspection lens even beyond primary care: it says assessments may look for procurement and governance evidence, risk assessment, responsible clinical safety and digital leads, human oversight, learning from errors, data protection, staff training, equity in access and bias management (CQC GP mythbuster 109). That list is close to a board assurance checklist.

The engineering control that matters most is also the easiest to understand. If the AI makes a claim, the reviewer should be able to see the source. Our work on anti-hallucination source checks explains one deterministic pattern: if a claimed quotation cannot be found in the source text, the output fails before a human can approve it.

Framework mapping for health AI

There is no single NHS AI approval stamp. Boards have to map a use case across overlapping frameworks and decide which evidence proves each duty is met.

Framework or regulator	What it asks in plain English	Board evidence
NHS clinical safety standards	Does the product influence, support or manage direct care, and has clinical risk been assessed? NHS England Digital's DCB guidance says DCB0129 and DCB0160 are legally mandated or strongly recommended depending on context (DCB0129 and DCB0160 guidance).	DCB0160 safety case, hazard log, CSO sign-off and supplier DCB0129
DTAC and NHS supplier assurance	Does the digital technology meet minimum NHS baseline standards at procurement or due diligence? NHS England describes DTAC as covering clinical safety, data protection, technical security, interoperability, usability and accessibility (NHS England medical devices and digital tools).	Completed DTAC or equivalent assessment, with exceptions recorded
MHRA medical-device regulation	Does the tool have a medical purpose or influence clinical decision-making? MHRA says software, including AI, is often regulated as a medical device in health and social care (MHRA software and AI as a medical device).	Intended-purpose assessment, registration evidence and change-monitoring route
NICE evidence standards	Is there enough evidence that the digital health technology offers benefit to users and the system? NICE's ESF is for evaluators and decision makers in health and care (NICE evidence standards framework).	Evidence tier, local validation plan and benefits measurement
ICO and UK GDPR	Is personal data processed lawfully, fairly and transparently, and is the DPIA live? ICO says most AI processing is likely to be high risk and a DPIA is usually required (ICO accountability and governance in AI).	DPIA, transparency notice, controller map and human-review route
NCSC secure AI guidance	Has the system been designed, deployed and operated with AI-specific cyber threats in view? NCSC's guidance covers secure design, development, deployment, operation and maintenance (NCSC secure AI guidance).	Threat model, logging, access control, supplier assurance and incident plan
ATRS for public-sector transparency	Should the public know how an algorithmic tool supports decisions? GOV.UK says ATRS is mandatory for central departments and some ALBs, and recommended for the wider public sector (GOV.UK ATRS Hub).	Publishable transparency record or documented decision not to publish

The AI and Digital Regulations Service is the practical navigation layer for adopters. Its all-guidance page lists required steps on clinical risk management, CQC registration, post-market surveillance, monitoring safety and effectiveness, equality duties, UK GDPR, the common law duty of confidentiality and cyber resilience.

Mistakes that expose patients and boards

The common failure is to treat AI assurance as procurement paperwork. It is not. It is the board's ability to reconstruct why the use was approved, which evidence was accepted, who owned each residual risk, and what happened after launch.

Five mistakes deserve particular attention:

• Approving a product, not a use case. The same tool can be low risk when drafting meeting minutes and high risk when producing a discharge summary.
• Relying on supplier self-certification. NHS England's ambient guidance says medical-device assessment should be independently conducted, not based only on supplier self-declarations.
• Treating pilots as exempt. The same guidance says ambient-scribing pilots should be time-limited and should not be used to bypass compliance.
• Leaving the human role vague. "Clinician in the loop" is not enough. The board needs the review point, the reviewer role, the evidence record and the escalation route.
• Ignoring local population effects. Accent, language, disability, digital exclusion and access to non-digital routes are not side issues in healthcare. They are part of safety and equity assurance.

There is also a subtler board failure: accepting productivity claims without deciding what safety evidence would make the claim usable. The Copilot rollout may save staff time. Ambient scribes may reduce documentation burden. Neither benefit answers whether a patient can understand the use, whether a clinician corrects the output, whether a model works for the local population, or whether the trust can explain a harmful error.

Next step: turn assurance into evidence

For the next board cycle, ask for a one-page register of all AI use cases, including unapproved or informal tools. Put each into one of three bands: administration only, clinical documentation or workflow support, and patient-affecting decision support. The evidence threshold should rise at each band.

Then run the board through five questions:

1. Do we know every AI use case currently in operation or pilot?
2. Can we name the owner, clinical safety officer and information governance lead for each one?
3. Does the evidence pack contain DCB0160, DPIA, supplier assurance, medical-device status and monitoring?
4. Where outputs affect care, can a clinician review, correct and reject the output before it acts?
5. Can we explain the use to patients, staff, CQC and our ICB without relying on supplier language?

If any answer is unclear, start with the free Board AI Scorecard. It gives the board a structured baseline and exposes which evidence is missing. For a deeper evidence review, the AI governance diagnostic maps live use cases against the controls above and turns them into a board-ready action plan.

Last reviewed: 18 June 2026.

Sources: NHS England Copilot rollout, 8 June 2026, NHS England guidance on AI-enabled ambient scribing products, CQC GP mythbuster 109, NHS England Digital DCB0129 and DCB0160 guidance, NHS England medical devices and digital tools, MHRA software and AI as a medical device, NICE evidence standards framework, ICO accountability and governance in AI, NCSC guidelines for secure AI system development, GOV.UK ATRS Hub, AI and Digital Regulations Service adopters' guidance.