An AI scribe can change substantially without changing its brand name. A feature that once drafted a letter may later offer to send it; a summary may become a recommendation; an identified task may become an automatically executed action. Each step can alter the information, permissions and review process involved.
The governance question is not whether innovation should stop. It is whether the organisation's assessment still describes the product its staff are actually using. An approval based on yesterday's function is not an assessment of tomorrow's authority.
Watch the verbs, not just the release name
A useful change review starts with verbs. Does the software listen, transcribe, summarise, suggest, prepare, send, order, update or close? Those words reveal more about the workflow than a general label such as "assistant".
The same interface can conceal a significant transition. A button beside a generated letter may move from copying text to transmitting it through another system. The clinician may experience this as a small convenience while the organisation gains a new external-action pathway.
A change can also occur before execution. A system that selects which information deserves prominence is doing more than reproducing a conversation. That does not automatically determine medical-device status, but it does create a question about clinical influence and evaluation.
The correct assessment is function-specific. Avoid declaring an entire brand regulated, unregulated, safe or unsafe without examining what the relevant feature does and how it is deployed.
A fictional release sequence shows the boundary
Consider a fictional product introduced to draft consultation notes for clinician review. A later release identifies follow-up tasks in the conversation. Another prepares patient messages. A subsequent update can send those messages under configured permissions.
Each stage may be useful. Each also adds questions that the first assessment may not have answered: how tasks are identified, whether suggestions reflect the agreed plan, who approves recipients, what happens when delivery fails and whether a patient's reply changes the clinical situation.
The original privacy notice may describe only note generation. Staff training may cover editing text but not cancelling an action. The supplier's earlier evaluation may measure documentation fidelity rather than appropriate task execution.
This is a constructed scenario, not an allegation that a named company has expanded unsafely. It illustrates why organisations need a repeatable change process rather than relying on the fact that the vendor was previously accepted.
The July 2026 MHRA clarification makes scope explicit
On 29 July 2026, the MHRA clarified the regulatory treatment of ambient voice technologies in Great Britain. Its distinction between documentation-only functions and functions supporting diagnosis, treatment or certain autonomous actions makes intended functionality central to the assessment. See the MHRA announcement.
The clarification should not be read as a new blanket exemption for every product called a scribe. Nor should it be used to classify an individual deployment from a marketing screenshot. The supplier and deploying organisation need to establish the relevant function, intended purpose and applicable requirements.
This article's regulatory discussion was checked on 10 October 2026 and concerns Great Britain. It is not a legal determination about any particular product or permission to deploy the same function in another jurisdiction.
Reassess the workflow, not only the software component
A change in functionality can alter who performs work and who sees the information. A draft previously checked by a clinician may now appear in an administrative queue. A task previously acknowledged by a person may be marked complete by software.
Examine the local consequences. Who recognises an inappropriate suggestion? Who can pause the process? Who receives rejected actions or patient disagreements? Which team handles the work when the original clinician is absent?
The DCB0160 deployment standard, checked on 10 October 2026, is relevant to deployment and use. Supplier evidence remains important, but local workflow and integration assumptions need their own assessment.
A useful change record links each altered function to affected hazards, controls, training and tests. It should identify whether the organisation is enabling the change, restricting it or waiting for further information.
Permissions should expand deliberately
Read access, draft creation and committed action should be separable where the workflow permits. A new capability should not automatically inherit every credential already available to the application.
The NCSC's May 2026 agentic-AI guidance recommends constraining access and actions. Applied to this scenario, the practical question is which permissions the new function actually needs and how those limits are enforced outside the model.
A release should be tested with missing information, contradictory instructions and unavailable destinations. The system should make uncertain status visible rather than claim completion simply because it attempted an action.
Also test withdrawal of permission. If an organisation disables a function, confirm what happens to scheduled or already queued tasks. An off-switch is incomplete if previously authorised work continues invisibly under old assumptions.
Data use may change at the same time
A scribe that begins drawing on longitudinal records or sending information through additional services changes the data flow. Existing statements about temporary audio processing may not describe the new inputs, recipients or retention arrangements.
The organisation should review purpose, necessity, access and communication with patients and staff. A supplier's general statement that it does not train on patient data does not answer every question about inference, logs, connectors and external recipients.
The ICO's AI data-minimisation guidance, checked on 10 October 2026, provides a relevant basis for examining what information is actually necessary. The review should follow each material data type rather than rely on a brand-wide assurance.
Where the new purpose or processing arrangement differs, update the relevant assessment and notices before normal use. Staff should not be left explaining a feature with documents that describe an earlier version.
Match evidence to the expanded claim
A strong note-fidelity study can be relevant background for a system that later acts on notes. It does not by itself establish accurate task identification, appropriate recipient selection, reliable execution or safe exception handling.
The evidence register should therefore identify which function and version each study supports. A new claim may require new testing even when the underlying model has not changed, because the consequences of the output have changed.
A proposed staged evaluation would begin with an approved test environment, then supervised use within a defined scope, with expansion dependent on pre-agreed findings. It should include correction burden, unresolved work and the ability to stop or revert, not only successful demonstrations.
Security patches and clinically material behaviour changes need not follow identical processes, but neither should disappear into an uninformative "updated" label. The change-management process should be proportionate to consequence.
Preserve the clinician's ability to intervene
The user needs to understand the current task, assumptions, permissions and status. Otherwise, the nominal supervisor may be asked to take responsibility without enough information to change the course of events.
A useful educational exercise is to give a learner a fictional workflow at successive stages and ask what new information or control is required before authority expands. As described on 10 October 2026, iatroX's reasoning-focused Tutor offers a setting for exploring clinical assumptions, not certification to supervise an external agent.
The conclusion is not that scribes should remain static. It is that useful expansion deserves fresh evidence and explicit authority. Organisations should approve the work being performed, not merely remember approving the logo.
Frequently asked questions
Does an approved AI scribe remain approved when it adds new functions?
An earlier assessment does not automatically establish suitability for materially different functionality. The supplier and deploying organisation should assess the actual change and applicable requirements.
Does adding a send button automatically make software a medical device?
Not necessarily: classification depends on the function and intended purpose, not one interface element. The clinical and operational consequences still require assessment.
What is the most useful question after a major AI update?
Ask what the system can now read, decide or do that it could not do before. Then identify which evidence, permissions and local controls cover that change.