AI Tools & Governance
What AI can actually do in your practice — and the governance stack you are accountable for. Explained in partner language, with no vendor in the room.
General information for GP partners, not legal advice. Verify anything you act on with your LMC, DPO, and defence organisation.
Why now
AI has moved from conference slides to consulting rooms. By December 2025, 28% of GPs were already using AI at work — and in the same RCGP/Nuffield Trust survey, 84% raised the lack of regulatory oversight as a concern. The profession is adopting and worrying at the same time. Both instincts are right.
28%
of GPs already use AI at work
RCGP / Nuffield Trust, December 2025
84%
raise lack of regulatory oversight as a concern
The same survey — adoption and anxiety, together
June 2026
CQC starts piloting its new GP framework
Expect technology governance to feature
The pressure is real. The 2026/27 contract was imposed — rejected by 98.9% of GPs in the April referendum — and practices are hunting for capacity anywhere they can find it. AI tools are marketed as exactly that: time back from documentation, letters, and inbox work. Some of it is true. But the workload case for adopting is also the case for adopting blind — and blind adoption concentrates risk on one place: the partnership.
Here is the uncomfortable structure of it. The practice is the data controller, so data protection accountability is yours. The practice deploys the tool, so the clinical safety duty (DCB0160 — more below) is yours. The CQC registration is yours. The contract signature is yours. The supplier sells the tool; you own the consequences of using it.
And the guidance that exists was not written for you. NHS England's ambient scribing guidance (version 2, April 2026) is explicitly addressed to CIOs, CCIOs, and IG professionals — roles a three-partner practice does not have. LMC guidance is good but regional and mostly scribe-focused. Vendor “governance packs” answer one question: how to approve their product. This guide walks the whole stack, in partner language, with no product to sell you.
The honest framing
None of the governance below is a reason not to adopt AI. It is the difference between adopting it as a managed decision — evidenced, insured, and defensible — and discovering the stack for the first time in an incident review or a CQC interview. Most of it is proportionate paperwork, done once per tool and kept current.
Already using AI? Start where you are
If tools are already live in your practice — officially or unofficially — nothing here says switch them off tonight. Run the readiness checker at the end of this guide, find your gaps, and close them in order: DPIA, human-check rule, MDO letter first. Retrofit is routine; pretending is what fails.
What AI can actually do today
Strip away the marketing and four categories of AI tool are doing real work in general practice today. Each is genuinely useful. Each has a failure mode you need to know before you rely on it.
Ambient scribes
Listens to the consultation and drafts the note — often letters, codes, and actions too. Genuinely good at:structured, complete documentation; giving you the patient's face back instead of the screen; time saved on typing.
Honest limits:mishears drug names and doses; can drop or flip negatives (“no chest pain” becoming “chest pain”); can generate plausible content that was never said; misses everything that happened without words. The clinician who files the note remains fully responsible for it — and a scribe that summarises rather than transcribes is generally in medical-device territory (see the device line below).
Document processing and summarisation
Reads incoming letters, discharge summaries, and reports; classifies, codes, routes, and summarises them. Genuinely good at: volume — the daily document pile is exactly the shaped, repetitive work this handles well.
Honest limits:a missed abnormal result inside a summarised letter is still a missed abnormal result, now with fewer human eyes on the original. You need a defined audit-sample process and a clear answer to “who checks what the AI filed, and how often?”
Triage and navigation support
Structures the patient's request, suggests urgency and routing. Genuinely good at: consistent data capture at the front door; making demand visible and manageable.
Honest limits: this category influences who is seen and when— the highest-stakes decision in the building. It carries the same governance stack as a scribe, turned up: firmly medical-device territory, a heavier DPIA, digital-exclusion and equity questions, and safety-netting that must not depend on the patient's ability to describe themselves well in a form.
Admin automation
Rotas, task routing, templates, non-clinical letters, inbox sorting. Genuinely good at: the lowest-risk wins — work with no direct clinical influence.
Honest limits:“admin” is not the same as “no patient data”. Check what actually flows through the tool. And the biggest admin-AI risk in most practices is unofficial: staff pasting patient details into free consumer chatbots. That is a data protection incident, today, whether or not you knew.
The pattern across all four
AI drafts; clinicians decide.Every safe deployment in general practice today has a human check between the AI's output and anything that enters the record or reaches a patient. The governance stack below is largely about making that rule real — written, trained, audited — rather than assumed.
The governance stack at a glance
Seven layers sit between “this demo looks great” and “this is running safely in my practice”. You do not need to become an expert in any of them. You need to know what each one is, when it applies, what is yours to do, and what to ask — which is exactly how each section below is structured.
| Layer | The question it answers | Who carries it |
|---|---|---|
| DTAC | Has the product met the NHS baseline? | Supplier evidences it; you check it |
| UK GDPR & DPIA | Is the data use lawful and risk-assessed? | The partnership — you are the data controller |
| DCB0160 | Is your deployment clinically safe? | Your Clinical Safety Officer |
| MHRA device status | Is the product itself regulated? | Supplier holds it; you verify it |
| Cyber Essentials & DSPT | Is the security posture sound? | Both of you |
| Indemnity | Who stands behind you when it goes wrong? | You — ask your MDO in writing |
| CQC | Can you evidence all of the above? | The partnership |
It's less than it looks
In practice the stack collapses into a handful of questions and one folder of evidence. Practices cleared it for online consultation systems and cloud telephony without ceremony — AI adds the device question and the clinical safety officer duty, and sharpens the rest. Work through it once, properly, and every subsequent tool is faster.
DTAC — the NHS baseline
What it is
The Digital Technology Assessment Criteria— NHS England's baseline bar for digital health tools. A supplier completes evidence across clinical safety, data protection, technical security, interoperability, and usability and accessibility. It is an evidence pack, not a badge: the buying organisation assesses it.
When it applies to you
DTAC is not a legal duty on your practice. When an ICB procures a tool at scale, the ICB runs the DTAC assessment. But when your practice buys directly — which is how most AI scribes are being adopted — nobody runs it unless you ask. That makes it your cheapest due-diligence instrument: the questions are already written, and a serious supplier has the answers ready.
What you as a partner must do
- Make completed DTAC evidence your minimum ask of any supplier, before the demo charms anyone.
- Treat the phrase “DTAC certified” with suspicion — there is no official DTAC certificate. What exists is the supplier's evidence and a buyer's assessment of it.
- Actually read the clinical safety and data protection sections. They pre-answer half of your DPIA and DCB0160 work below.
What to ask the supplier
- “Send us your completed DTAC evidence — all sections, not a summary.”
- “Which NHS organisations have assessed it, and when was it last updated?”
- “What changed in the product since that evidence was written?” (AI products update constantly; year-old evidence may describe a different tool.)
Data protection — you are the controller
What it is
Under UK GDPR the practice is the data controller: the organisation that decides why and how patient data is processed, and the one accountable when it goes wrong. The AI supplier is normally your processor, acting on your written instructions. That hierarchy does not shift because the supplier is bigger than you, or because the ICB liked the product. Controller accountability — including ICO enforcement — sits with the partnership.
The DPIA (Data Protection Impact Assessment) is the structured risk assessment the law requires before processing that is likely to result in high risk. New technology applied to health data — an AI tool listening to consultations, or reading your document flow — is close to a textbook trigger.
When it applies to you
Any AI tool that touches identifiable patient data, including audio of consultations. And a pilot counts: “we're just trying it” is processing. The DPIA comes before the first patient's data flows, not after the pilot proves popular.
Who signs it off
This trips practices up. Your DPO advises — every practice must have one — but the DPO does not own the decision. The controller signs off the DPIA, and the controller is the partnership. A partner's name goes on it. If the DPIA leaves a high risk you cannot mitigate, the law says consult the ICO before going live — not proceed and hope.
What you as a partner must do
- DPIA completed, DPO's advice recorded, signed off by the partnership — before the pilot.
- Privacy notice and patient-facing information updated: patients should know AI is in use and be able to object — with a workable path for the consultation where someone says no, and no loss of access to care.
- A proper data processing agreement with the supplier that matches what the DPIA says actually happens.
- Check the training clause: your patients' data should not be training the supplier's models unless you have knowingly agreed to it (the right answer is usually that you have not).
What to ask the supplier
- Where is data processed and stored — UK, EEA, elsewhere?
- Is consultation audio retained after the note is generated? For how long, and who can change that setting?
- Is our data used for model training, in any form?
- Who are the sub-processors, and do we get notice of changes?
- What do you provide to support our DPIA — and can we speak to a practice that has completed one for this product?
Clinical safety — DCB0160 and the CSO duty
The duty most partners have never heard of
There are two clinical risk management standards for health IT. DCB0129 binds the manufacturer — the supplier holds that one. DCB0160 binds the organisation that deploys the system — and when your practice switches on an AI tool, that organisation is you. Almost every partner has heard of DPIAs; very few have heard of DCB0160. It is the gap an incident investigation finds first.
What it is
DCB0160 is the national information standard for clinical risk management when health IT is deployed and used. In plain terms it asks: what could this system do to patients in your hands, and what have you done about it? It requires a named Clinical Safety Officer (CSO) — a registered clinician trained in clinical risk management — plus a deployment safety case and a hazard log: the living list of what could go wrong, how badly, and what controls you have in place.
Since 7 July 2025 this is a legal requirement, not good practice: section 95 of the Health and Care Act 2022 changed the duty on organisations from “have regard to” these information standards to “must comply with” them.
When it applies to you
Whenever the practice deploys health IT — which includes AI scribes, document processors, and triage tools. The supplier's DCB0129 safety case covers their product in the abstract; it cannot cover your rooms, your staff, your workflows, or the corner-cutting that happens on a busy Monday. That deployment context is precisely what DCB0160 exists to assess.
What you as a partner must do
- Nominate a CSO. In a practice this is usually a GP or an experienced nurse who completes clinical safety training. Some ICBs offer CSO support or shared arrangements to practices — ask yours before assuming you are on your own.
- Build the hazard log for each tool: wrong-patient errors, dropped negatives, missed results in summaries, automation bias, downtime. Ask the supplier for their hazard log to seed yours — then add what only you know about your practice.
- Write the human-check rule down — a clinician verifies every AI output before it enters the record — train it, and audit that it still happens after the novelty wears off.
- Feed incidents and near-misses back into the hazard log and your significant event process. The safety case is a living document, not a signing ceremony.
What to ask the supplier
- “Send us your DCB0129 clinical safety case and the name of your Clinical Safety Officer.”
- “Share your hazard log so we can build our DCB0160 deployment assessment from it.”
- “What known failure modes should our clinicians be trained to catch — and what is your process for telling us about new ones?”
The medical device line
What it is
Software with a medical purpose can be a medical device, regulated by the MHRA. For AI tools the line runs through what the software does with clinical information, and it is sharper than most vendors' marketing suggests. Pure verbatim transcription — speech in, the same words out — is generally not a device. The moment the tool summarises, structures, codes, or advises, it is interpreting clinical information, and — as NHS England's ambient scribing guidance sets out — products with those features generally qualify as medical devices and need to be registered with the MHRA, with a device class matching their risk.
| What the tool does | Device status | What that means for you |
|---|---|---|
| Verbatim transcription only — speech to text, nothing added | Generally not a medical device | The rest of the stack (DPIA, DCB0160, cyber) still applies in full |
| Summarises the consultation into a clinical note | Generally regarded as a medical device | Ask for MHRA registration, the device class, and the intended purpose statement |
| Suggests clinical codes or structures the record | Likely a medical device | Same asks — and check your use matches the stated intended purpose |
| Triage, prioritisation, or decision support | A medical device, and typically a higher classification | Expect UKCA/CE marking and published clinical evidence before you touch it |
Why it matters to you
- An unregistered device is a supplier red flag you can check. If a summarising scribe has no MHRA registration, the supplier either does not know the rules or is ignoring them. Neither belongs in your consulting room.
- The intended purpose statement is your boundary. A device is regulated, tested, and insured for its stated purpose. Use it beyond that — a transcription tool “informally” drafting management plans — and the risk of that use shifts from the supplier to you.
- Everything else reads across. Device status feeds your DPIA, your hazard log, your MDO conversation, and what CQC will expect you to have understood before deploying.
What to ask the supplier
- “Is this product registered with the MHRA as a medical device? What class, and what is the registration number?”
- “Send us the intended purpose statement in writing.” — then check your planned use sits inside it.
- “If you say it is not a device: explain why, in writing, given it summarises clinical information.”
Cyber Essentials and the DSPT
What they are
The DSPT (Data Security and Protection Toolkit) is the annual self-assessment against national data security standards required of organisations with access to NHS patient data — your practice already completes one every year. Cyber Essentials is the government-backed security certification: the basic level is self-assessed, and Cyber Essentials Plus is independently audited.
When they apply to you
An AI tool adds a new pipe carrying patient data out of your building — often including consultation audio, the most sensitive recording a practice has ever routinely made. That changes your own DSPT answers, and it makes the supplier's security posture your problem: a breach at your processor is still your breach to report and explain.
What you as a partner must do
- Update your DSPT to reflect the new data flows — do not let it describe the practice you were before the AI arrived.
- Verify the supplier's evidence: their DSPT status and Cyber Essentials certificate (Plus is better), not their assurances.
- Sort your own hygiene around the new tool: multi-factor authentication, named accounts rather than shared logins, and access removal the day someone leaves.
What to ask the supplier
- Cyber Essentials or Cyber Essentials Plus — and a copy of the certificate?
- What is your DSPT status this year?
- If you are breached, how quickly do you notify us, and in what form? (You have your own clock for onward reporting the moment you know.)
- When was your last penetration test?
Indemnity — ask yours in writing
What it is
Two layers protect you. CNSGP, the state scheme, covers clinical negligence arising from NHS primary care work — including care in which an AI tool played a part. Your MDO (MDU, MDDUS, MPS) covers what CNSGP does not: GMC referrals, inquests, disciplinary processes, non-NHS work. An AI-related incident can touch both layers at once — a claim about the missed finding, and a regulatory process about how the note was made.
When it applies to you
From the first consultation where an AI tool touches the record. The MDOs have published positions on AI use — but positions differ between organisations, carry conditions, and change as the technology does. And here is the gap: one 2025 survey found only 42% of practitioners knew their MDO's stance on AI. The majority are relying on cover they have never actually confirmed.
What you as a partner must do
- Write to your MDO. Name the tool category, how it is used, and your checking workflow. Ask whether your cover extends to that use and on what conditions.
- File the written reply in your governance folder. A reassuring phone call is not evidence; a letter is.
- Repeat when the use changes — a scribe extended into coding, a document tool extended into triage. Cover confirmed for one use is not cover for the next.
- Ask every partner and salaried GP to check their own position — MDO membership is individual, and a partnership can straddle two or three organisations with different stances.
What to ask your MDO
- “We use [category of tool] in this way, with this checking process. Does our cover extend to this use?”
- “Are there conditions — for example, verification of every note before filing?”
- “Does using a tool outside its stated intended purpose affect our position?”
- “Can we have that in writing?”
What CQC will expect
What it is
CQC does not approve AI tools, and there is no AI inspection checklist. What CQC assesses is whether your practice is safe and well-led — and a partnership that has adopted AI without being able to show how it assessed and governs it has a well-led problem, not a technology problem.
When it applies to you
Now, and increasingly. CQC is piloting its new GP assessment framework from June 2026. As assessment activity rebuilds around it, recent technology adoption is a natural line of questioning: what did you introduce, who decided, and where is the evidence? The practices that struggle in that conversation are not the ones that adopted AI — they are the ones that cannot show their working.
What you as a partner must do
- Decide at partnership level and minute it. The minutes of the meeting that weighed the evidence and approved the tool are your single most useful well-led exhibit.
- Keep one governance file per tool: DPIA, safety case and hazard log, MDO letter, DTAC evidence, MHRA status, training records, patient information, incident log. Everything this guide has covered lands in that folder.
- Close the loop:show that incidents involving the tool feed your significant event process, and that someone reviews the tool on a cycle rather than assuming week one's assessment still holds.
The one-folder test
A useful internal standard: could you hand an inspector — or a coroner, or an ICO case officer — one folder that tells the whole story of each AI tool, this week, without a scramble? If yes, you have governance. If it would take a fortnight of reconstruction, you have gaps. The checker below makes this concrete.
Before you sign
The governance stack tells you whether a tool can be deployed safely. The buying decision is a different question: whether this contract, at this price, from this supplier, is a good deal for your practice. Partners sign these contracts — so here is the pathway, then the questions.
Define the job and the success measures
What problem is this tool solving, for whom, and how will you know? Pick measures you can actually count: minutes saved per session, documentation time, notes requiring correction, incidents.
e.g. “Reduce documentation time per consultation, measured over 4 weeks, with a note-quality audit of 20 consultations per clinician.”
Shortlist and demand the evidence pack
Before any demo sways you: completed DTAC evidence, the DCB0129 clinical safety case, MHRA device status and intended purpose in writing, DSPT status, Cyber Essentials certificate, and insurance details.
A supplier who hesitates over any of these has answered your question.
DPIA and privacy notice — before the pilot
A pilot is still processing patient data. Complete the DPIA, record your DPO's advice, sign it off as the controller, and update the privacy notice and patient-facing information.
Clinical safety case and named CSO
Your DCB0160 duty: a named, trained Clinical Safety Officer, a deployment safety case, and a hazard log. Ask the supplier for their hazard log to seed yours — but the deployment risk is yours to own.
MDO letter and contract review
Write to your medical defence organisation describing exactly how you will use the tool, and file the reply. Have the contract's liability, data-return, and exit terms reviewed before signature.
Run a time-boxed pilot
Small group, fixed end date, named lead, patients informed, incident route agreed. Audit a sample of AI-generated output against the source. Measure against the step 1 criteria — not the brochure.
Decide, document, and keep reviewing
Take the decision at a partnership meeting and minute it. File everything in one governance folder. Book a review cycle — tools change, contracts renew, and national guidance is moving quickly.
And the contract questions themselves, grouped. None of them are hostile — a good supplier answers all of these easily, and how a salesperson reacts to being asked is data in itself.
You have more leverage than you think
The AI-scribe market is crowded and suppliers need reference sites in general practice. Asking for the full evidence pack, honest data terms, and a real pilot does not make you a difficult customer — it makes you the kind of practice good suppliers want to be able to name. The ones who push back are self-identifying.
Beyond scribes — same stack, higher stakes
Most of the noise is about ambient scribes, so most of the governance thinking has followed them. But the next wave is already in procurement conversations: triage tools that shape who gets seen and when, document AI that decides what a GP never has to read, and workflow automation threaded through the whole patient journey. Nothing new is required of you — it is the same seven layers — but every layer carries more weight.
- Device status rises. A tool that influences clinical priority is decision support — firmly a medical device, typically at a higher classification, and worth expecting published clinical evidence for, not just a registration number.
- The DPIA gets heavier. Triage processes data from every patient who contacts you, including those who never get seen — and automated prioritisation of care is the kind of processing that demands the fuller risk analysis.
- The hazard log changes character. A scribe error usually has a clinician between it and the patient. A triage error is the pathway: the deteriorating patient routed to a routine slot. Safety-netting has to live in the system design, not in hope.
- Equity becomes a safety issue.Patients who struggle with forms, English, or digital access must have a route that works — and CQC's access focus makes this inspectable, not theoretical.
- Exit gets harder. Switching off a scribe means typing again. Switching off the system your front door runs on is an operational event — which is why the exit questions in the contract section stop being boilerplate here.
A rule of thumb
If a tool merely describes care that happened, your governance is about accuracy. If a tool shapes care that will happen — who is seen, how fast, by whom — treat it as a high-risk deployment and walk every layer of the stack at full depth before going live.
Check your readiness
Twelve questions, one per weak point we see in real adoptions. Answer for your practice as it is today — not as the action plan intends it to be by spring.
AI-Governance Readiness Checker
Twelve questions across the governance stack. Answer honestly — the point is to find the gaps before an incident or an inspector does.
Your answers stay on this page. Nothing is stored, sent, or shared — leaving or refreshing the page clears them.
Data protection & DPIA
Clinical safety (DCB0160)
Device status & DTAC
Cyber security
Indemnity
Governance & buying
Your readiness (0 of 12 answered)
Answer all 12 questions to see your overall rating. Area ratings appear as you go.
Data protection & DPIA
UnansweredClinical safety (DCB0160)
UnansweredDevice status & DTAC
UnansweredCyber security
UnansweredIndemnity
UnansweredGovernance & buying
UnansweredGreen: everything answered yes. Amber: partial cover. Red: significant gaps. This is a self-assessment prompt, not a compliance audit — general information, not legal advice.
What to do with an amber or red
Nothing here is fatal, and most gaps close with a letter, a template, or a training session rather than a consultant. Take the result to your next partnership meeting, give each amber or red area a named owner and a date, and re-run the checker when the actions land. Finding the gaps yourself, now, is the whole point.
Glossary
The governance alphabet, decoded:
Ambient scribe
An AI tool that listens to the consultation and drafts the clinical note (and often letters and codes). “Ambient” because it works in the background rather than by dictation.
DTAC
Digital Technology Assessment Criteria
NHS England's baseline assessment for digital health tools, covering clinical safety, data protection, technical security, interoperability, and usability and accessibility. Suppliers complete the evidence; the buying organisation assesses it. There is no official “DTAC certificate”.
Data controller
The organisation that decides why and how personal data is processed — for practice data, that is the partnership. Controllers carry the legal accountability under UK GDPR, including for what their processors do.
Data processor
An organisation that processes personal data on the controller's instructions — usually the AI supplier's role. A written data processing agreement between you is mandatory.
DPIA
Data Protection Impact Assessment
A structured assessment of privacy risk, legally required before processing that is likely to result in high risk to individuals. New technology applied to health data almost always qualifies. Signed off by the controller — the partnership — with the DPO's advice recorded.
DPO
Data Protection Officer
The statutory adviser on data protection that GP practices must have. The DPO advises on the DPIA; they do not sign it off for you — that accountability stays with the partnership.
DCB0129
The clinical risk management standard for manufacturers of health IT. The supplier must hold a clinical safety case for their product. Ask to see it — but note it covers their product, not your deployment.
DCB0160
The clinical risk management standard for organisations deploying health IT — including GP practices. It requires a Clinical Safety Officer, a deployment safety case, and a hazard log. The practice-side duty most partners have never heard of.
CSO
Clinical Safety Officer
A registered clinician, trained in clinical risk management, who owns the DCB0160 process for the deploying organisation. In a practice this is usually a GP or nurse with specific training — the supplier cannot hold this role for you.
Hazard log
The living record of what could go wrong with a health IT deployment, how likely and severe each hazard is, and what controls you have in place. Central to the DCB0160 safety case.
MHRA
Medicines and Healthcare products Regulatory Agency
The UK regulator for medical devices. Software that interprets or summarises clinical information for a medical purpose can be a medical device — pure verbatim transcription generally is not.
Intended purpose
The manufacturer's formal statement of what the product is for. It defines the boundary of regulated, supported use — using a tool beyond its intended purpose shifts risk from the supplier to you.
UKCA / CE marking
Conformity marking showing a device has met the applicable regulatory requirements for the UK (UKCA) or Europe (CE, still recognised in Great Britain for many devices). Higher-risk devices need a conformity assessment body involved.
DSPT
Data Security and Protection Toolkit
The annual self-assessment against national data security standards required of organisations with access to NHS patient data — your practice already completes one. Check your supplier's DSPT status too, and update yours when a new tool changes your data flows.
Cyber Essentials
A government-backed cyber security certification. The basic level is self-assessed; Cyber Essentials Plus is independently audited. A reasonable minimum to expect of any supplier handling your patients' data.
CNSGP
Clinical Negligence Scheme for General Practice
The state indemnity scheme covering clinical negligence liabilities arising from NHS primary care work. It does not cover everything — regulatory proceedings, inquests, and non-NHS work are why you still need your MDO.
MDO
Medical Defence Organisation
MDU, MDDUS, MPS and others. They have published positions on AI use — but positions differ and change, which is why this guide's advice is to get yours in writing for your specific use.
Automation bias
The human tendency to over-trust machine output — checking the first ten AI notes carefully and the next thousand barely at all. The main failure mode of “human checks everything” rules, and worth naming in your hazard log.
Practice AI governance checklist
The stack as a to-do list — things to review, delegate, or put on the partnership agenda. Your ticks are saved in your browser only.
If you only do three things this month
- Take the inventory — find every AI tool actually in use, including the unofficial ones.
- Write to your MDO about the tools you are using and file the reply.
- Ask who your Clinical Safety Officer is. If the room goes quiet, you have found your gap — and you are in the majority, which is exactly why it is worth fixing first.
A reminder before you act on any of this
This guide is general information for GP partners — not legal, regulatory, or indemnity advice. The positions summarised here (MHRA, CQC, NHS England, the MDOs) are moving, and your circumstances are your own. Verify anything you rely on with your LMC, your DPO, your defence organisation, and your ICB before acting.
Sources and further reading
- NHS England guidance on AI-enabled ambient scribing products (v2, April 2026)
- RCGP / Nuffield Trust: GPs' use of AI at work (December 2025)
- CQC: new GP assessment framework update (2026)
- Londonwide LMCs guidance on AI tools in general practice (May 2025)
- DCB0129 / DCB0160 clinical risk management standards (NHS England information standards)
- ICO guidance on data protection impact assessments
Last reviewed: 9 July 2026. All links checked at that date.
General information for GP partners, not legal advice. Built by an NHS GP partner who builds AI tools.