AI scribes: safety questions to settle before clinical use

What changed

Nothing new is being reported. This is a standing explainer written from the cited official pages. It does not announce a new duty, product approval or regulatory decision about AI scribes. Sources checked 30 October 2026.

For ambient documentation, the starting question is not whether a product carries an AI label or calls itself a "documentation assistant". It is what the product is intended to do, what information it processes and how its output enters clinical work. Capturing speech, summarising a consultation and generating clinically interpretive content are different activities. A draft note requiring review presents different assurance questions from an output intended to inform a clinical decision.

The cited sources provide useful foundations: MHRA guidance on intended purpose and medical-device software, ICO guidance on AI and data protection, and NICE's evidence framework. They do not establish that every AI scribe is a medical device. They do not determine any particular product's status or suitability, and they do not provide a complete deployment checklist. The practical controls below are recommendations for applying those foundations. They are not duties attributed to the sources.

Status and dates

All four cited pages are guidance or a guidance framework, not legislation, an enforcement decision or a product-specific approval. MHRA's intended-purpose guidance discusses obligations for products classified as medical devices; it is not itself the underlying law.

These dates describe the documents, not commencement dates for any deployment duty. The ICO page attributes its review to changes made by the Data (Use and Access) Act. The cited page does not establish the detail or commencement of those changes. The ICO date in the citations is the dated update, not an inferred original publication date.

Who this affects

Suppliers should make product claims precise enough for customers to understand the supported workflow and its boundaries. Describe the intended users, setting, patient population, output and permitted uses. Intended purpose, demonstrations, contractual descriptions and user instructions should tell a consistent story. Distinguish generating documentation from providing interpretation or recommendations, where those functions exist. Evidence for producing a draft note should not silently become evidence for suggesting diagnoses or treatment.

Deploying NHS and care organisations should assess the proposed local use, not merely the supplier's generic description. A supplier's description cannot answer local questions about who checks a draft, when it becomes part of the record, staffing, patient communication or what happens during an interrupted consultation. A supplier's account of a clinician reviewing a draft is not, by itself, evidence that the local workflow lets clinicians perform that review.

Both parties need an agreed account of where supplier controls end and organisational controls begin. Who configures templates? Who controls changes? Who reviews output before it enters the record? Who investigates discrepancies? An apparently strong safeguard can fail if each party assumes the other will operate it. Useful preparation can be organised around supplier clinical safety evidence and deployment clinical safety evidence. These links give supporting context; the cited pages do not establish the applicability or detailed requirements of either standard for a specific deployment.

What this means in practice

Define the purpose before debating classification

MHRA's intended-purpose guidance explains that a medical-device purpose statement should describe the functionality, intended beneficiaries, users and setting. It connects that specificity with understanding risk and the evidence needed to support safety.

Apply that discipline to the proposed scribe even before its regulatory position is settled. Does it capture, transcribe, summarise, restructure, suggest codes or generate additional clinical content? These are questions about the proposed product, not assertions that every scribe does all of them. Does it produce only a draft, or populate the clinical record? Can its output feed referral letters, codes or later decisions? Describe the functions actually enabled, and foreseeable local uses, separately from future roadmap features. Record exclusions and any reliance on human checking. A broad claim such as reducing documentation burden leaves important questions unanswered: which documentation, for whom, and under what conditions?

MHRA's overview states that many healthcare software and AI products are regulated as medical devices. It does not say that every AI scribe is one, or that documentation products are automatically outside regulation. Seek a documented rationale for the specific product and use case rather than a category-wide assumption.

Make human review an observable control

"The clinician checks it" is a control to examine, not a complete answer. Specify who reviews the output, when, against what information, and before which downstream actions. Can reviewers identify generated material and correct it easily? Can unchecked text reach another user or system? How can users tell a draft from an accepted entry, and how do corrections reach any downstream copies?

Potential scenarios to test include omitted information or qualifications, incorrect speaker attribution, altered negation or meaning, unsupported additions, and wording that makes an uncertain statement sound definite. These are hypothetical hazards to investigate, not reported defects or incidents in any product. Weigh their clinical consequences rather than treating every textual mismatch as equally important.

Also test interruptions and abandonment. If a consultation is stopped, repeated or moved to another system, can staff identify which draft belongs to which encounter? What happens when the reviewer is interrupted or cannot resolve an ambiguity? A reasonable fallback should describe how documentation continues without the tool, and how incomplete outputs are handled.

Build this reasoning into the clinical safety case, connecting each hazard to its possible consequence, the proposed control, supporting evidence and a named owner. A review step that exists only in training materials may need different evidence from one built into the workflow. Simply recording that review is required does not show it is workable in the intended setting.

Match evidence to the proposed use

NICE's framework was updated in 2022 to include AI and adaptive, data-driven technologies. Its overview also describes early deployment standards for evidence-generation programmes. That supports considering evidence systematically. However, the cited page gives no scribe-specific tier, threshold, study design or test protocol, and no blanket permission to deploy while evidence is incomplete.

A practical evidence plan should start with the intended purpose and local workflow, and explain why its examples represent the proposed use. Consider the settings, consultation types and recording conditions included, such as overlapping speech or multiple speakers, unfamiliar terminology, communication support and complex histories, where these are within scope. Identify exclusions. Assess output quality, important omissions, correction effort and whether fallback arrangements work. These are proposed evaluation dimensions, not tests prescribed by NICE.

Distinguish readability from faithful representation of the encounter: polished prose does not show that clinically significant meaning has been preserved. Keep efficiency claims separate from safety findings. Reduced drafting time does not, by itself, show that important information remains accurate after review.

Define in advance how disagreements will be reviewed and how findings affect use. Options include narrowing the scope, strengthening review, changing the interface or postponing deployment. Keep those decisions connected to the intended purpose and the wider AI clinical safety assessment.

Assess fairness in the actual use context

The ICO describes fairness across the AI lifecycle and distinguishes it from narrower technical measures. For a scribe, a useful question is whether the test material adequately represents the people and communication conditions expected in use. Where relevant, investigate whether some groups encounter more consequential errors; do not infer fairness from an overall average.

Where testing finds differences in performance, ask how they affect documentation and what changes to scope, review or design may be needed. The cited sources provide no universal acceptable error rate for AI scribes, so any local acceptance criteria need an explicit rationale.

Map the data pathway separately from documentation use

The ICO guidance identifies accountability, DPIAs, transparency, lawfulness, accuracy and fairness as relevant areas, and also highlights inferences, special category data and lifecycle considerations. Use these as questions to investigate, recognising that the overview does not reproduce the detailed legal tests.

Map each information object separately: captured audio, transcripts, intermediate material, generated drafts, accepted notes, technical logs and any data proposed for service improvement or model development. For each, establish which organisations receive it, why it is processed, where it goes, who can access it and how long it is retained. Do not assume these objects all exist, or that the handling of the final note explains the handling of temporary audio or logs. Treat secondary uses as questions needing explicit answers.

Ask the organisation's data protection and information governance team to document the applicable basis for processing, relevant conditions for sensitive information, responsibilities, transparency arrangements and the DPIA assessment, including unresolved questions. If permission is sought from patients, keep that workflow separate from the analysis of legal grounds for processing, and plan how a consultation proceeds when ambient capture is not used. Neither patient agreement nor a supplier assurance statement should be treated as a complete answer to every data protection question. The cited overview does not prescribe a lawful basis or show that any specific arrangement is lawful.

What remains uncertain

The cited pages cannot establish whether a particular scribe is a medical device, which classification applies, whether its evidence is sufficient, what level of residual risk is acceptable, or whether a processing arrangement is lawful. They contain no product evaluation, incident findings, approval decision or validated accuracy threshold, and do not show that human review neutralises every risk. They also do not describe a named product's architecture, retention arrangements or contractual allocation of responsibilities.

They do not supply detailed data protection requirements for recordings, international transfers, secondary model training or automated decisions. The ICO review notice means a historical update date cannot establish that every passage reflects later legislative changes; resolve material legal questions through appropriate current review. The NICE overview likewise does not reproduce the detailed framework. The cited sources also do not cover the full NHS clinical safety standards or procurement requirements, so this briefing should inform, not replace, the wider assurance process.

Local evidence may remain uncertain even when supplier evidence is substantial: performance in one specialty, language or workflow may not show suitability elsewhere. Supplier and deployer should agree what evidence would support the proposed scope, what unresolved findings would prevent use and when reassessment is needed. Keep unanswered questions visible to the organisation's appointed Clinical Safety Officer and relevant governance owners, each with an owner and a decision, rather than silently treating assumptions as facts.

Documents and controls to review

Bring together a connected, traceable evidence pack that connects each important claim to evidence, limitations, an owner and a deployment decision. It should not be several documents describing different products.

• Intended-purpose and claims record: reconcile functionality, demonstrations, instructions, contractual and promotional descriptions, intended users, settings and exclusions, and record the reasoning for the regulatory position. Note discrepancies, especially where a claim depends on review, restricted users or excluded settings. Record the assessed product version and configuration.
• Workflow and responsibility map: show capture, generation, draft status, review, acceptance, correction, transfer to the record, interruption handling, onward use and fallback. Allocate each control to a supplier or local owner.
• Clinical safety evidence: link foreseeable hazards to tests, mitigations and remaining limitations in the clinical safety case. Explain what evidence supports human review rather than merely requiring it.
• Evaluation plan: identify representative scenarios, acceptance criteria, evidence gaps and the limits of any conclusions drawn from testing.
• Information governance pack: data flows, processing purposes, the DPIA assessment, privacy and patient-facing information, retention, access controls and any proposed secondary uses, identified separately.
• Change, monitoring and operational controls: training, support, incident escalation, fallback documentation, tracking of consequential changes to functionality, templates, integrations and processing, and conditions for reassessment, restricted use or a pause. These are suggested controls, not thresholds supplied by the cited pages.

Where Assurance AI supports preparation, we prepare evidence for the client's own appointed Clinical Safety Officer. We do not act as that officer or sign off clinical safety documentation. This supports a reasoned deployment decision; it does not guarantee compliance or eliminate clinical risk.

Next-step checklist

• Define the intended purpose, enabled functions, users, setting, outputs and exclusions.
• Record the product-specific regulatory reasoning and unresolved questions.
• Map audio, transcripts, drafts, records, logs, processing purposes and secondary uses.
• Specify review, correction, record transfer, interruption handling and fallback.
• Test clinically consequential errors under representative consultation conditions.
• Assign owners to evidence gaps, and agree acceptance criteria and criteria for proceeding.
• Record the evaluated configuration, the deployment decision and triggers for reassessment.

For support organising this evidence for your own appointed Clinical Safety Officer, contact Assurance AI.

Primary sources

1. Crafting an intended purpose in the context of Software as a Medical Device (SaMD) — MHRA, GOV.UK, 22 March 2023. https://gov.uk/government/publications/crafting-an-intended-purpose-in-the-context-of-software-as-a-medical-device-samd
2. Medical devices: software and artificial intelligence (AI) — MHRA, GOV.UK, 6 April 2023 (updated 3 February 2025). https://gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
3. Guidance on AI and data protection — Information Commissioner's Office, updated 15 March 2023. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection
4. Overview — Evidence standards framework for digital health technologies — NICE, corporate document, 10 December 2018 (last updated 9 August 2022). https://nice.org.uk/corporate/ecd7