AI scribes: safety questions to settle before use

What changed

Nothing new is being reported. This is a standing explainer written from the cited official pages as they stood on the retrieval date, 28 September 2026. It addresses decisions to settle before introducing ambient documentation or an AI scribe, rather than announcing a new requirement.

The starting point is the actual function, not the product label. Capturing speech, summarising a consultation and generating clinically interpretive content are different activities. A description such as ‘documentation assistant’ does not, by itself, settle the appropriate regulatory treatment, safety evidence or data handling arrangements.

The supplied sources establish useful foundations: MHRA guidance on intended purpose and medical device software, ICO guidance on AI and data protection, and NICE’s evidence framework. The practical controls below are recommendations derived from those foundations, not a claim that the sources prescribe a single approval pathway for every scribe.

Status and dates

All four cited pages are guidance or a corporate evidence framework. None is itself a newly enacted law, an enforcement decision or product-specific approval.

MHRA distinguishes guidance from the underlying medical device regulations. Its overview says many software and AI products are regulated as devices; it does not classify ambient scribes collectively. The ICO page warns that its guidance is being reviewed following the Data (Use and Access) Act. The extract does not establish that Act’s detailed effects or commencement dates. In the citation metadata, the ICO date identifies the supplied version’s update, not an asserted first-publication date.

Who this affects

Suppliers should make product claims precise enough for customers to understand the supported workflow and its boundaries. Intended purpose, demonstrations, contractual descriptions and user instructions should tell a consistent story. 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 product’s behaviour, integration and review process need to fit the service introducing it. Supplier evidence cannot answer every question about local staffing, patient communication or responsibility for correcting records.

Both parties need an agreed account of where supplier controls end and organisational controls begin. That interface is central to an AI clinical safety assessment: an apparently strong safeguard can fail if each party assumes the other will operate it.

What this means in practice

Define the function before assessing the label

MHRA’s intended-purpose guidance asks manufacturers of medical device software to specify the function, intended beneficiaries, users and setting. It connects that specificity with risk and the evidence needed to support safety.

Apply that discipline to the proposed scribe workflow. Does it transcribe, condense, restructure or infer? Does it produce only a draft, or populate the clinical record? Can its output feed referral letters, codes or subsequent decisions? Describe enabled functions and foreseeable local uses separately from future roadmap features.

For example, a system that preserves a speaker’s words presents different assessment questions from one that turns a conversation into a clinical interpretation. This is not a classification ruling. It is a reason to document the regulatory rationale against the actual functionality and intended purpose before relying on a product category.

Turn human review into an observable control

A statement that ‘a clinician checks the note’ leaves important operational questions unanswered. Who reviews it, when, against what information, and before which downstream actions? Can reviewers identify generated material and edit it easily? What happens when the reviewer is interrupted or cannot resolve an ambiguity?

Potential failure scenarios to test include omitted qualifications, incorrect attribution between speakers, altered negation and unsupported additions. These are suggested assessment scenarios, not reported defects in any product. Consider their clinical consequences rather than treating every textual mismatch as equally important.

Define how a draft remains distinguishable from an accepted record and how corrections reach any downstream copies. A clinical safety case can connect these scenarios to controls, supporting tests, residual concerns and named owners. Merely recording that review is required does not demonstrate that it is workable in the intended setting.

Test the workflow, not just the generated text

NICE’s framework includes AI and adaptive, data-driven technologies. Its overview also describes early deployment standards for evidence generation programmes. That supports a structured evidence discussion, but the supplied extract contains neither scribe-specific performance thresholds nor a blanket permission to deploy while evidence is incomplete.

Ask what evidence supports the proposed setting, users and output. Representative testing could examine overlapping speech, unfamiliar terminology, communication support and differences in consultation format. Where relevant, investigate whether some groups encounter more consequential errors; do not infer fairness from an overall average.

Decide in advance how findings affect use. Useful decisions include narrowing the scope, strengthening review, changing the interface or postponing deployment. Time saved is a separate claim from safe documentation: a faster workflow should not obscure the time needed to identify and correct clinically significant errors.

Map the information before choosing the controls

The ICO extract identifies accountability, DPIAs, transparency, lawfulness, accuracy and fairness as areas addressed by its AI guidance. Use these as questions to investigate, while recognising that the extract does not reproduce the detailed legal tests.

Map each information object separately: captured audio, transcripts, generated drafts, accepted notes, technical logs and any data proposed for model improvement. Establish which organisations receive each object, why, where it goes, who can access it and how long it is retained. Do not assume that the handling of the final clinical note explains the handling of temporary audio or service logs.

Resolve the applicable lawful processing arrangements, responsibilities and patient-facing explanation through the organisation’s information governance process. If permission is sought from patients, distinguish that workflow from the separate analysis of legal grounds for processing. Plan how a consultation proceeds when ambient capture is not used. These are review questions, not a determination that consent is always required or always sufficient.

What remains uncertain

The extracts do not settle whether a particular scribe is a medical device, its classification, or the detailed obligations attached to a specific deployment. They provide no product evaluation, validated accuracy threshold or conclusion that human review neutralises every risk.

They also do not supply detailed data protection requirements for recordings, international transfers, secondary model training or automated decisions. Those issues cannot be resolved merely by citing the ICO overview. Its explicit review notice makes it particularly important to distinguish the page’s stated themes from assumptions about current statutory detail.

Local evidence may remain uncertain even when supplier evidence is substantial. Performance in one specialty, language or workflow may not establish suitability elsewhere. Keep unresolved questions visible, with an owner and a decision about whether each is compatible with the proposed scope of use.

Documents and controls to review

Use a connected evidence set rather than several documents that describe different products:

• Purpose and claims record: align functionality, intended users, settings, exclusions and regulatory rationale. Record the assessed product version and configuration.
• Workflow and responsibility map: show capture, generation, review, acceptance, correction and onward use. Allocate each control to a supplier or local owner.
• Safety evidence: link potential harms to tests, mitigations and residual concerns. Explain what evidence supports human review rather than merely requiring it.
• Information governance pack: bring together data flows, the DPIA assessment, processing arrangements, retention decisions and patient-facing information. Identify any proposed secondary uses separately.
• Operational controls: define training, support, incident escalation, fallback documentation and conditions for pausing use. Decide which product or workflow changes prompt reassessment.

Bring this material to the organisation’s own appointed Clinical Safety Officer where relevant to its clinical safety arrangements. Assurance AI can prepare evidence in support of that officer; it does not act as the client’s Clinical Safety Officer or sign off clinical safety documentation.

The practical objective is traceability: someone reviewing the decision should be able to follow a claim through to evidence, limitations, controls and accountability. This supports a reasoned deployment decision; it does not guarantee compliance or eliminate clinical risk.

Next-step checklist

• Define the enabled functions, intended users, settings and exclusions.
• Document the regulatory rationale against the actual intended purpose.
• Map audio, transcripts, drafts, records, logs and secondary uses.
• Test clinically consequential errors and the practicality of review.
• Allocate responsibility for corrections, escalation and fallback working.
• Resolve evidence gaps and define pause or reassessment triggers.
• Record the deployment decision, limitations and accountable owners.

For support preparing a connected evidence set for your own appointed Clinical Safety Officer, contact Assurance AI.