AI Policy for General Practice: A Template for UK Surgeries

A general practice AI policy should say which tools staff may use, what patient data may and may not go into them, who signs off new tools through DCB0160 and a data protection impact assessment, and when the policy is reviewed. The practice manager owns the document; a named clinical safety officer owns clinical safety.

Clinical papers and college pages cover why AI matters in primary care. What a practice manager needs is the document itself: wording they can adapt this week, with the sign-off steps in the right order. The template below is a starting point for you and your clinical safety officer to edit, not a legal or regulatory opinion.

Follow me on Instagram@sagnikteaches

Where this template draws its rules from

NHS England's guidance on AI-enabled ambient scribing products in health and care settings sets out what a setting should do, and much of it generalises to any AI tool that touches patient care. As of November 2026 it asks settings to:

Connect on LinkedInSagnik Bhattacharya

• complete DCB0160 documentation, including a safety case, hazard log and monitoring framework, and ask the supplier for its DCB0129 clinical safety case report;
• complete a data protection impact assessment and engage information governance support early;
• check the supplier against NHS England's AVT Supplier Registry, which sets supplier expectations including completion of the Digital Technology Assessment Criteria (DTAC) and registration with the medical devices regulator where applicable, and confirm the product's regulatory status as a medical device;
• assign a clinical safety officer and identify key risks such as output errors, system unavailability and missing information;
• be transparent with patients, update privacy notices before processing starts and give people the chance to object;
• ensure users review and approve outputs before acting on them, and run ongoing audits;
• train staff in the appropriate and approved use of the product, and report safety concerns through local incident management systems.

The guidance also says pilots must be time-limited (up to four months) and must not bypass compliance, and that a setting should engage its integrated care board before any pilot or commercial engagement. Read the current page, because it will be updated. The template turns those expectations into rules your staff can follow.

Subscribe on YouTube@sagnikteaches

The policy, section by section

Below is the template in a form you can copy. After each section is a note on how to fill it in and what to check. The whole policy should fit on two pages. Staff read two pages; they do not read ten.

1. Purpose, scope and owner

1.1 This policy sets out how [Practice name] uses artificial intelligence tools, so that patient information is protected, clinical care is safe and staff know what is allowed.
1.2 It applies to all partners, salaried clinicians, nurses, healthcare assistants, administrative and reception staff, locums, students and anyone else working in the practice, on any device.
1.3 Policy owner: [Practice Manager]. Clinical safety officer: [Name, role]. Data protection lead: [Name, role].
1.4 Version [1.0], approved [date], next review [date].

Name real roles, not a committee. If your practice shares a clinical safety officer or a data protection officer through a federation or a primary care network, name them and say so. An unnamed owner is the most common reason a policy goes stale.

2. Which tools staff may use

2.1 Staff may use only the AI tools listed in Appendix A, for the purposes stated there.
2.2 A tool is added to Appendix A only after the sign-off steps in section 5 are complete and recorded.
2.3 Staff must not use free or personal AI accounts, browser extensions or apps for any practice work, including drafting, summarising or translating.
2.4 Staff must not create accounts for practice use using personal email addresses or share a login.

Appendix A is a table. Illustrative for a surgery, with the status column doing the work:

The last row matters because suppliers add AI features to products you already own. A button that appears in the clinical system next month is a new tool, and should go through section 5, not into use because it was already installed.

3. Patient data rules

3.1 Patient-identifiable information must never be entered into any AI tool that is not approved for patient data in Appendix A.
3.2 Identifiable information includes names, NHS numbers, dates of birth, addresses, phone numbers, photos, free-text clinical details that could identify someone, and screenshots of clinical or appointment systems.
3.3 Where a tool is approved for patient data, enter the minimum needed for the task.
3.4 AI output is a draft. A named person reads and approves it before it is filed, sent or acted on. The person who approves it is responsible for it.
3.5 AI must not be used to make or recommend a clinical decision, triage, diagnosis, prescription or referral without a clinician reviewing the recommendation.
3.6 Do not use AI to produce letters, reports or messages containing clinical content unless a clinician has reviewed them.

A practice manager should add examples under 3.2 in their own words. "A receptionist pastes a patient's message into a chatbot to reword a reply" is the example that makes the rule real. The rule about screenshots is worth keeping; people forget that a photo of a screen contains everything on the screen.

4. Patients and transparency

4.1 The practice will tell patients when AI tools are used in their care or in processing their information, in the privacy notice, on the website and in the waiting area.
4.2 Before any tool that processes patient information is first used, the privacy notice is updated and patients have a way to object.
4.3 Clinicians using an approved scribe explain its use at the start of the consultation and record any objection. Where a patient objects, the tool is not used.
4.4 Staff are trained in how to obtain and record patient permission.

This section follows the transparency expectations in the guidance. The tutorial on telling patients and updating privacy notices covers the wording in detail. Make sure the privacy notice change happens before the first patient is recorded, not after.

5. Sign-off steps for a new tool

This is the section that turns the policy from a list of bans into a working process. Keep the sequence in order, because later steps depend on earlier ones.

5.1 Request: the member of staff completes the new-tool form (purpose, data involved, who benefits).
5.2 Screen: the Practice Manager and Data Protection Lead decide whether the tool touches patient data or clinical care.
5.3 If it touches clinical care: the Clinical Safety Officer leads the practice's DCB0160 work (safety case, hazard log, monitoring) and obtains the supplier's DCB0129 clinical safety case report.
5.4 DPIA: the Data Protection Lead completes a DPIA with information governance support before any patient data is processed.
5.5 Supplier checks: DTAC completed by the supplier; regulatory status as a medical device confirmed where relevant; data location, retention and training use confirmed in writing; a data processing agreement signed.
5.6 Decision: senior partner signs off or rejects, with reasons, and the tool is added to Appendix A with date and conditions.
5.7 Pilot: time-limited, with named users and an end date. A pilot is not a way to avoid steps 5.3 to 5.5.
5.8 Review: outcome of the pilot recorded before wider use.

Two practical points. If you lack the tools or capability for DCB0160, NHS England's guidance says to seek help from the integrated care board, so build that into your plan rather than learning it halfway through. And whether the tool counts as a medical device depends on the manufacturer's stated intended purpose; do not assume, ask the supplier to show you.

6. Incidents

6.1 Anyone who thinks patient information has been entered into an unapproved tool, or that an AI output has caused or could cause harm, tells the Practice Manager the same day.
6.2 The Practice Manager logs it, tells the Data Protection Lead and, if clinical, the Clinical Safety Officer.
6.3 The Data Protection Lead decides whether it is a reportable data breach under the practice's usual process.
6.4 Reporting in good faith will not lead to disciplinary action.
6.5 Lessons are recorded and shared at the next practice meeting.

Keep the incident log as a simple table: date, reporter, tool, what happened, information involved, action, outcome. If you have no incident template, adapt the AI incident response plan.

7. Training, audit and review

7.1 All staff read this policy at induction and annually. Users of approved tools complete the tool's authorised-use training before first use.
7.2 The Practice Manager audits use of approved tools every quarter: a sample of outputs, the incident log and the list of tools staff report using.
7.3 The policy is reviewed every six months for the first year, then annually, and after any incident or significant change to a tool or national guidance.

A filled-in example: a six-partner surgery adopts the policy

Illustrative figures only. Say a surgery with six partners, four nurses and eight administrative staff decides to write a policy after the practice manager discovers three people are using free chatbots for letters. Here is what the first month might look like.

1. Week 1. The practice manager runs a no-blame survey asking which AI tools staff already use. Five tools come up. Two are used with patient information.
2. Week 2. She adapts the template, names the roles and drafts Appendix A with one approved administrative assistant and "none" for patient data. The senior partner reviews it in a 30-minute meeting.
3. Week 3. The practice briefs all staff in two 20-minute sessions, covering the one-page never-paste rules. Free chatbots for patient information stop that day.
4. Week 4. The partners agree to consider an ambient scribe for a pilot, and the policy's section 5 starts the DCB0160 and DPIA process before any contract is signed.

Total practice manager time to this point is perhaps eight to ten hours, spread over the month. That is an estimate, not a benchmark.

A sample screening decision

To make section 5 concrete, here is a filled-in screening for a tool request, in the style of a short record.

Request: Administrative assistant wants to use an AI tool to summarise long emails from the integrated care board.
Data involved: none about patients; staff names appear.
Touches clinical care? No.
Screening outcome: DCB0160 not required; short DPIA recording that no patient data is processed; supplier terms checked for training use and retention.
Decision: Approved for non-patient use only. Added to Appendix A on [date]. Review [date].

A record this short takes twenty minutes and proves you thought about it. Compare it with a request for an ambient scribe, where the same form triggers the full path in steps 5.3 to 5.8. The point of a screening step is to keep the heavy process for tools that need it.

Why each rule is there, so you can defend it

A policy is easier to enforce when staff understand the reason, and easier to defend when someone asks why you wrote it that way. Here are the reasons behind the choices that cause the most argument.

Why free accounts are banned outright. Free and personal accounts are the usual route by which patient information reaches a tool that the practice has never assessed. The practice cannot see the terms, cannot audit use and cannot delete the data. A blanket rule is easier to explain and follow than a nuanced one, and it moves staff towards the approved route. The cost is that people will occasionally want something the approved list does not do. That is what the new-tool form is for.

Why the person who approves an output is responsible for it. It prevents "the AI wrote it" from becoming an excuse. A clinician who signs a note owns it, and a receptionist who sends a message owns it. Say this plainly in the policy, because it changes how carefully people read.

Why there is no blanket ban on AI in clinical work. The template allows a scribe for clinician review, under the sign-off steps, because that is what national guidance contemplates. What it forbids is AI deciding anything clinical without a clinician. If your partners prefer a stricter line, change 3.5, but do it deliberately.

Why pilots have an end date. National guidance sets a maximum of four months for a pilot or proof of concept and says it must not be used to bypass compliance. In practice an open-ended trial becomes a permanent tool with no assessment. An end date forces the decision.

What the clinical safety officer actually does

Practice managers often worry about this role, so it helps to describe it plainly. The clinical safety officer is the named person, in most surgeries one of the clinicians, who takes responsibility for the practice's clinical risk management of a new digital tool. Check the current DCB0160 specification for the experience the role requires before you name someone. For an AI product that means leading the DCB0160 work: describing what the tool will do in your setting, listing what could go wrong and how you will notice, and recording that someone senior accepted the remaining risk.

The hazard log is the heart of it. Illustrative entries for an ambient scribe in a surgery might look like this:

The practice does not have to invent every control from nothing. The supplier's own DCB0129 safety case lists hazards from their side, and your documentation should respond to it. If your practice lacks the skills, the guidance says to seek help from the integrated care board, so ask early.

What goes in a data protection impact assessment for an AI tool

A DPIA does not need to be long, but it does need to cover the real questions. NHS England's companion information governance guidance for ambient scribing includes a DPIA template, and the main guidance suggests engaging IG and cybersecurity support early. It also asks how long each type of data is kept, naming the interaction audio, generated transcripts, user interactions and final outputs, which is a useful reminder that a scribe creates more records than the note you see. For an AI tool, make sure your DPIA answers these:

1. What personal and special category data does the tool process, and for what purpose?
2. Who is the controller and who is the processor, and is there a written processing agreement?
3. Where is the data stored and for how long? Is audio kept, and can the supplier use any data to train or improve its own models?
4. What is the lawful basis and the condition for processing health data, and how are patients informed?
5. What are the risks to patients (accuracy, access, security) and what controls reduce them?
6. How will the practice honour objections and access requests?
7. What is the exit plan, including deletion when the contract ends?

Your data protection officer, or the person who advises you on data protection, should read and sign the finished document. Keep it with the tool's approval record in Appendix A, so one reference leads to everything.

Awkward cases the policy has to cover

Real surgeries hit situations the neat sections above do not settle. Decide your answers in advance and put one line for each in the policy or the staff FAQ.

• A locum arrives with their own scribe app. Not allowed. Locums use only approved tools, and the practice tells them at induction. Say so in the locum pack.
• A clinician wants to try a new tool on "just one anonymous case". Real anonymisation of a clinical case is hard. Rule: no patient material in unapproved tools, anonymised or not, and a made-up case if they only want to test.
• A patient brings AI-generated advice or a summary to an appointment. Not a policy breach, but give staff a line: acknowledge it, check it against the clinical picture, and do not enter it into the record as fact without review.
• A patient asks for their consultation to be recorded for their own use. That is a separate question from the practice using AI. Keep it out of this policy and handle it under your recording rules.
• A staff member wants AI to help with their own writing, such as a reflective portfolio. Permitted with an approved or personal tool provided no patient information is involved. Put it in the staff FAQ.
• An AI feature turns on in an existing system after an update. Treat it as a new tool. Ask the supplier whether it is on by default, and have it disabled until section 5 is complete.

An illustrative quarterly audit

Section 7.2 promises an audit. Here is what one looks like in practice, kept deliberately light. Each quarter the practice manager spends about two hours on four checks.

1. Tool census. Ask each team lead what AI tools their team uses. Compare with Appendix A. Anything extra is investigated.
2. Output sample. For any approved scribe or drafting tool, review a sample of ten outputs for accuracy against what the clinician or staff member recalls.
3. Incident log. Look for patterns: the same tool, the same team, the same type of mistake.
4. Vendor changes. Check each approved tool's release notes or terms for changes to data use, hosting or features, and record the date checked.

Record the result in half a page and take it to the next partners' meeting. An audit that finds nothing is good, provided it looked; an audit that is never done is a gap that will show up in the worst moment.

Time and cost of the policy itself

The policy is cheap compared with the tools it governs. Illustrative effort for a mid-sized surgery: eight to ten hours of practice manager time to write and adapt it, two hours of partner time to approve it, an hour of clinical safety officer time to review, and about two hours of briefing across staff sessions. Each new tool then adds its own assessment effort, which for a patient-facing clinical tool is significantly larger because of DCB0160, the DPIA and supplier checks. Those numbers are judgement calls, not guidance figures, but they show the scale: the policy is a few days; a clinical tool's sign-off is weeks.

Budget for the second item. Practices often price the tool and forget that safe adoption takes staff time. The tutorial on what a medical practice should fund first helps set that balance.

Mistakes the template is built to prevent

• "Shadow AI". Staff using personal tools because the approved route is slow. Prevent it with a quick route for low-risk tools and honest talk about why.
• Policy without owner. Nobody updates it, and it describes tools that no longer exist. Prevent it with a named owner and review date on page one.
• Pilot creep. A trial runs for a year without a decision. The guidance sets a four-month limit for pilots; put an end date in every pilot record.
• Features arriving by update. A supplier adds an AI feature. Prevent it by requiring that each new feature in an existing system goes through section 5.
• Consent by notice alone. A poster is not the same as telling a patient. Prevent it with the clinician's explanation and a recorded objection in section 4.

Adapting the template to your size

A two-doctor surgery does not need the same machinery as a 20,000-patient practice. For a small practice, combine the data protection lead and policy owner roles where your adviser agrees, keep Appendix A short, and rely on your integrated care board and any shared services for DCB0160 support. For a larger practice or a primary care network, add a short standing group that meets quarterly to review requests and the incident log.

Whatever the size, the sequence stays the same: list the tools, set the patient data rules, put sign-off before use and review on a date. For a scribe-specific sign-off, the registry, DTAC and DPIA checklist goes deeper, and the tutorial on scribe costs and free tiers helps with the budget side. If you would rather draft the policy with someone, that is what my AI implementation consultation covers, though your clinical safety officer and data protection adviser must approve the final text.

Briefing staff in an afternoon

A policy only works if people have heard it. Hold one 30-minute session for clinicians and one for administrative staff, since their risks differ. For clinicians, cover section 3.4 to 3.6 and the scribe consent steps. For administrative staff, cover the never-paste rules, with three examples from your own surgery: a patient message, a screenshot of the appointment book, a letter to a hospital. Finish each session by asking everyone to name one task they currently use AI for, so the practice learns what staff need before they go looking elsewhere.

After a month, ask three people what they must never paste and who to tell if they get it wrong. If the answers are good, the policy has landed. If not, rewrite it shorter.

Questions practice managers ask about a surgery AI policy

Does a small surgery really need a written AI policy?

Yes. Staff are likely to be using AI already, on personal phones or free accounts, and without a policy nobody has said what is allowed. A short written policy also gives you something to show if the practice is asked how it manages new technology.

Who signs off an AI tool in a practice?

The practice should name the roles in the policy: usually the senior partner or practice lead, the clinical safety officer for anything touching clinical care, and whoever advises on data protection. No tool is approved by the person who wants to use it.

Is DCB0160 needed for every AI tool?

Not for every tool, but for anything used in the delivery of care, such as an ambient scribe, you complete the practice's side of the clinical safety process. For admin tools that never touch patient data, a short assessment recording why it is not needed is usually enough. Ask your clinical safety officer.

Can reception staff use a chatbot to draft patient letters?

Only an approved tool, and only with no patient-identifiable detail in the prompt. Letters that carry clinical content should be drafted by a clinician or checked by one. Put the rule in the policy so receptionists are not left to guess.

Further reads

• Is an AI Scribe Worth It for a Small Private Clinic? — Whether a scribe is worth the effort at your size.
• How to Roll Out an AI Scribe Without Losing Patient Trust — Introducing a scribe to patients without losing trust.
• AI Scribe Costs Compared: What Small Clinics Pay in 2026 — What scribe seats cost small clinics.
• AI Dictation Software for Doctors: Dictation or Ambient Notes? — Dictation or ambient notes, and which suits a clinic.
• AI Acceptable Use Policy for a Small Professional Firm — A general acceptable-use policy to compare against.
• How to Write an AI Usage Policy for Your Small Business — The general version of an AI policy for a small business.
• Cliniko for Doctors: Fit, Cost and the AI Tools That Sit Around It — Cliniko is built for allied health. What that means for a doctor's practice, what it costs, and the AI scribes and phone tools that connect to it.
• Infection Control Audit Action Plan: Turn Findings Into Fixes With AI — Paste anonymised audit findings into AI, get grouped fixes with owners and dates, then a re-audit sheet that proves each one closed.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: NHS England guidance on the use of AI-enabled ambient scribing products in health and care settings, and its information governance guidance for the same products (fetched 4 November 2026); clinical risk management standards DCB0129 and DCB0160 and the AVT Supplier Registry as described in that guidance.