AI scribes: safety questions to settle before deployment

What changed

Nothing is presented here as newly changed. This is a standing explainer written from the cited official pages as they stood on the retrieval date. That retrieval date is not separately recorded in the supplied material; the briefing date is 19 September 2026. It is not a claim that the pages have been independently checked on that date.

For ambient documentation and AI scribes, the starting point is not the product label. It is the relationship between the claimed purpose, the output produced, the people using it and the workflow in which it operates. A tool described as a documentation assistant still needs a clear account of what it does and where its limits sit.

The supplied MHRA, ICO and NICE extracts support an approach built around intended purpose, evidence and data protection. They do not establish that every AI scribe is a medical device, resolve a particular product’s classification or provide a complete deployment checklist. The practical questions below are suggested assurance work, not additional duties attributed to those sources.

Status and dates

These dates describe the documents, not commencement dates for deployment duties. The ICO extract identifies legislative change but does not supply the provisions or commencement details needed to explain its legal effect. Its citation date below identifies the dated update, not an inferred original publication date.

Who this affects

Suppliers need a coherent description of the product that connects claims, functionality, intended users, settings and supporting evidence. The MHRA intended-purpose guidance concerns software as a medical device: it calls for specificity about what the product does, whom it benefits, who uses it and where. That is also a useful discipline for structuring questions about a scribe whose regulatory position has not yet been established.

Deploying NHS and care organisations need to establish whether the proposed local use matches that description. A supplier’s account of a clinician reviewing a draft is not, by itself, evidence that the local workflow gives clinicians the information and opportunity to perform that review.

The shared task is to identify assumptions that cross the organisational boundary. Who configures templates? Who controls changes? Who reviews output before it enters the record? Who investigates discrepancies? Recording those answers is more useful than treating either procurement or a demonstration as the whole assurance process.

What this means in practice

Define the output before discussing the label

Ask the supplier to distinguish capture, transcription, summarisation, structuring and any generation of additional clinical content. These are questions about the proposed product, not assertions that every scribe performs all these functions. Specify whether the output is a draft note, a letter or another artefact, and where it can subsequently be used.

Then describe the intended patient population, users and setting. Record exclusions and any reliance on human checking. The MHRA guidance links a sufficiently specific intended purpose to understanding risk and the evidence needed to support safety. A broad claim such as reducing documentation burden leaves important questions unanswered: which documentation, for whom, and under what conditions?

The MHRA overview says many software and AI products are regulated as medical devices. It does not say all are. Seek a documented rationale for the product’s regulatory position without assuming that either the presence of AI or the word “scribe” settles it.

Translate human review into an observable workflow

Treat “the clinician checks it” as a control to examine, not a complete answer. Define what the reviewer sees, what they compare it with, how they correct it and what prevents an unchecked draft from being mistaken for an approved record.

Potential scenarios for assessment include omitted qualifications, incorrect attribution between speakers, altered meaning and unsupported additions. These are hypothetical hazards to investigate, not reported defects or incidents in the supplied sources. Consider whether the proposed review process could detect each one before the output is used.

Build this reasoning into the clinical safety case. The important connection is between a hazard, its possible consequence, the proposed control and evidence that the control works in the intended setting. A review step that exists only in training materials may need different evidence from one built into the workflow.

Separate demonstration quality from deployment evidence

NICE’s framework was updated to include AI and technologies with adaptive algorithms. The overview also describes early deployment standards for evidence-generation programmes. It supports considering evidence systematically, but the supplied extract does not specify a tier, threshold or study design for ambient documentation.

A practical evaluation should therefore explain why its examples represent the proposed use. Consider the settings, consultation types and recording conditions included, and identify exclusions. Distinguish readability from faithful representation of the encounter: polished prose does not answer whether clinically significant meaning has been preserved.

Define how disagreements will be reviewed and what findings would restrict use or trigger further testing. This makes an evaluation a basis for decisions rather than a collection of favourable examples. Keep those decisions connected to the intended purpose and AI clinical safety assessment.

Make the data pathway explicit

The ICO extract identifies accountability, DPIAs, transparency, lawfulness, accuracy and fairness as relevant areas of its AI guidance. It also highlights inferences and special category data. These themes support asking for a concrete description of the proposed processing rather than accepting a generic privacy statement.

Map what is captured, what intermediate material is created, what is retained, where it goes and who can access it. Ask separately about audio, transcripts, generated drafts, final records and any proposed use for service improvement or model development. Do not assume that all these data objects exist, or that their handling is identical.

Use that map to support examination of roles, purposes, the proposed lawful basis, relevant conditions for sensitive information and patient-facing explanations. Record the DPIA assessment and its unresolved questions. The supplied overview is not enough to prescribe a particular lawful basis or conclude that a specific arrangement is lawful.

Assess fairness in the actual use context

The ICO describes fairness across the AI lifecycle and distinguishes fairness from narrower technical measures. For a scribe, a useful evaluation question is whether the proposed test material adequately represents the people and communication conditions expected in use.

Where testing identifies differences in performance, ask how they affect documentation and what changes to scope, review or design may be needed. An overall accuracy figure should not end that enquiry. The supplied sources provide no universal acceptable error rate for AI scribes, so any local acceptance criteria need an explicit rationale.

What remains uncertain

The extracts do not determine any particular scribe’s medical-device status, establish that its evidence is sufficient or identify an acceptable level of residual risk. They also do not describe a named product’s architecture, retention arrangements or contractual allocation of responsibilities.

The ICO review notice matters: a historical update date cannot establish that every passage reflects subsequent legislative changes. The NICE overview likewise does not reproduce the detailed framework. Further examination of the applicable material is needed before drawing detailed conclusions from either.

The supplied sources do not cover the full NHS clinical safety standards or procurement requirements. This briefing should therefore inform, not replace, the wider assurance process. Keep unresolved questions visible to the organisation’s appointed Clinical Safety Officer and relevant governance owners rather than silently converting assumptions into accepted facts.

Documents and controls to review

Start with the intended-purpose statement and reconcile it with product demonstrations, instructions, contractual descriptions and the proposed local workflow. Record discrepancies, particularly where a claim depends on review, restricted users or excluded settings.

Review the regulatory rationale, evidence plan, evaluation results and hazard analysis together. Each material claim should have an identifiable evidence source or an explicit evidence gap. Preserve enough version information to understand which configuration was evaluated.

Alongside that, review the data-flow map, DPIA assessment, privacy information, retention arrangements, access controls and proposed secondary uses. Define a change-review process covering alterations to functionality, templates, integrations and processing arrangements. Decide what would prompt reassessment, restricted use or a pause; these are suggested operational controls, not thresholds supplied by the cited pages.

Next-step checklist

• Define the intended purpose, users, setting, outputs and exclusions.
• Obtain a documented rationale for the product’s regulatory position.
• Map capture, processing, storage, access and proposed secondary uses.
• Test clinically significant error scenarios and the review workflow.
• Record evidence gaps, acceptance criteria and unresolved assumptions.
• Assign owners for changes, discrepancies, escalation and reassessment.
• Agree deployment boundaries with the relevant governance owners.

For support preparing evidence for your organisation’s own appointed Clinical Safety Officer, discuss your assurance needs with Assurance AI.