Written by Technical Team | Last updated 15.08.2026 | 24 minute read
Ambient voice technology is moving rapidly from experimental NHS pilots into mainstream clinical infrastructure. What began as a relatively simple proposition — listen to a consultation, transcribe the conversation and generate a draft clinical note — is developing into a much broader category of AI-enabled healthcare software. Modern ambient voice products can structure medical information, identify clinical terminology, propose codes, retrieve information from electronic patient records, prepare referral letters and potentially suggest what should happen next.
That evolution creates an important regulatory question. At what point does an AI scribe stop being an administrative tool and become a medical device?
In July 2026, the Medicines and Healthcare products Regulatory Agency (MHRA), working closely with NHS England, published specific guidance addressing that question for ambient voice technology, or AVT. The guidance does not introduce an entirely new regulatory regime for AI scribes. Instead, it explains how existing medical device law applies to this increasingly important category of software and provides practical examples showing where the regulatory boundaries lie.
For developers, product owners and digital health companies, the implications extend well beyond regulatory paperwork. The way an ambient scribe is described, the functionality exposed to users, the prompts that an underlying large language model will accept, the information presented in the interface and the actions the software can initiate may all contribute to its regulatory position.
That means medical device qualification cannot sensibly be treated as a compliance exercise carried out shortly before launch. It increasingly needs to influence product strategy, software architecture, interaction design, AI guardrails, integration design and release management from the beginning.
This matters particularly in the NHS, where ambient voice technology has become part of a wider drive to reduce administrative burden and give clinicians more time with patients. NHS England is actively encouraging adoption, has established a national Ambient Voice Technology Supplier Registry and is building out guidance covering clinical safety, information governance, procurement, implementation and monitoring.
For developers hoping to build or integrate AI scribes for NHS environments, the opportunity is substantial. So is the responsibility.
AI scribes are appealing because they attack a very visible problem in healthcare: clinicians spend a significant proportion of their working day documenting care rather than delivering it. A well-designed ambient system can capture a consultation while it happens, convert speech into text, identify speakers, organise the conversation into an appropriate clinical structure and generate a draft note that the professional can review.
The value proposition is easy to understand. Less typing during consultations can improve eye contact and patient interaction. Reducing work after clinics may help address administrative burden. Structured documentation may improve consistency. Integration with electronic patient record systems can remove repetitive copying between applications. At scale, even relatively small reductions in documentation time per appointment can become operationally significant.
The difficulty is that the technical capabilities enabling these benefits do not naturally stop at transcription. Once a system already has a transcript, an LLM, clinical context and potentially access to a patient’s record, asking the software to perform more sophisticated tasks can appear technically straightforward. A team may begin with “summarise this consultation” and soon consider “identify the likely diagnosis”, “suggest what the clinician may have missed”, “recommend investigations”, “propose a treatment plan” or “place the appropriate order”.
From a software engineering perspective, these can feel like incremental features added to the same platform. From a regulatory perspective, they may represent a fundamental change in intended purpose.
The MHRA guidance is therefore significant because it makes clear that being used by a doctor, inside a hospital or alongside an electronic health record does not automatically make software a medical device. Equally, calling something an “administrative assistant” does not necessarily keep it outside medical device regulation when its intended functionality or marketing claims demonstrate otherwise.
The central concept is intended purpose. Broadly, regulators are interested in what the manufacturer intends the software to be used for, as evidenced by the product itself and the information surrounding it. Instructions for use, labelling, functionality and promotional materials can therefore matter. A disclaimer hidden in terms and conditions cannot necessarily neutralise functionality that clearly supports diagnosis or treatment.
This creates an important discipline for product teams. The regulatory question should no longer simply be, “Does our application use AI?” AI itself does not determine medical device status. Nor does the use of an LLM, speech recognition model or generative AI system.
The better question is: What job is this product intended to perform in the clinical workflow, and what does the user reasonably expect it to do?
That distinction is especially important for generative AI because general-purpose models are inherently flexible. A conventional deterministic application might contain only the workflows explicitly designed by its developers. An LLM-based interface can sometimes be persuaded to perform tasks its designers did not originally intend, particularly when users can enter free-form prompts.
A product marketed purely for documentation might, for example, allow a clinician to ask, “Based on this consultation, what do you think the diagnosis is?” If the model responds with a diagnosis, the developer has a problem even if diagnosis was not written on the original product roadmap.
The MHRA acknowledges the distinction between intended use and accidental or inappropriate use, but it also expects manufacturers to consider foreseeable behaviour, known AI hazards and the reasonable expectations created by the way the product is designed. Developers cannot simply expose a powerful general-purpose model, declare that it is “for transcription only” and assume that a warning absolves them of responsibility for everything the system can readily do.
That is one reason the new guidance should be read as an engineering document as much as a regulatory one. It places intended purpose, product capability and risk controls into the same conversation.
The most useful aspect of the MHRA guidance is its set of practical examples showing that there is not one regulatory classification for all ambient voice products. Two systems built on similar technical foundations can have different regulatory positions because they perform different functions or make different claims.
At the simpler end of the spectrum is transcription. An ambient scribe that captures a clinician-patient conversation and creates a transcript for subsequent review is performing an administrative documentation task. Provided that it is not intended to diagnose, predict, monitor or treat disease, or perform another defined medical purpose, that functionality does not in itself make the software a medical device.
The same logic can apply to summarisation. Generative AI may transform a long transcript into a concise consultation summary without the application becoming a medical device, provided that the software is essentially representing what was already discussed rather than introducing new clinical conclusions. Crucially, the resulting note is still presented for professional review and correction.
That distinction is more important than it initially appears. Generative summarisation involves interpretation. The software decides which pieces of a conversation are important, how they relate to one another and how they should be expressed. Nevertheless, the regulatory focus is not simply whether AI transforms information. It is what the transformation is intended to achieve.
A system can also potentially structure information without crossing the medical-device boundary. It might extract an explicitly mentioned medicine and place it into a draft medication field, organise existing information into a problem list for confirmation or suggest a clinical code that directly corresponds to terminology spoken during the consultation. Where the software is organising or matching existing information rather than deducing new clinical conclusions, the activity can remain administrative.
Similarly, an AI scribe may prepare a draft discharge summary, patient letter or referral document using information obtained during the encounter and perhaps information already present in the patient’s record. Again, the important factor is whether the system is documenting existing information or using that information to generate clinical recommendations.
The boundary becomes much clearer when the application begins generating new clinical insight.
Consider a feature labelled “Generate clinical insights”. The user presses a button after a consultation and receives several possible diagnoses, recommended tests and suggested treatment options. Even if these are presented as suggestions for the doctor to consider, the application is no longer simply documenting the encounter. It is processing information for a medical purpose.
A similar issue arises where an ambient voice platform analyses a transcript and recommends a diagnosis. The presence of a doctor in the loop does not automatically make the functionality administrative. A medical device can provide clinical decision support intended for professional users.
There is also a particularly important warning for marketing teams. Functionality is not the only factor determining intended purpose. Claims can matter as well.
Imagine two technically identical summarisation products. The first is described as an administrative tool that creates consultation notes for review. The second is advertised as helping clinicians “guide diagnosis and treatment planning” or “improve patient outcomes through intelligent clinical recommendations”. The second company may have created a medical intended purpose through its claims even if the underlying software is otherwise identical.
This means product, regulatory and marketing teams need to work from the same definition of intended use. SEO pages, sales presentations, demonstration scripts and feature descriptions should not casually promise clinical capabilities that are absent from the formal regulatory strategy.
At the highest-risk end of the spectrum is autonomous action. An ambient agent might listen to the consultation, write the note, determine that certain investigations are required and automatically place orders without clinician confirmation. Such a system is not merely making documentation easier. It is performing actions that would ordinarily require clinical judgement and oversight.
Developers should therefore think of ambient voice functionality as a continuum rather than a binary category:
The line can also move over the life of the product. A release that begins as non-device administrative software can become medical-device software after a new feature is added. It is therefore unsafe to treat regulatory status as something determined once at initial launch and never revisited.
Classification becomes the next question if a product does qualify as a medical device. The MHRA guidance highlights that active medical devices used for diagnosis may fall into Class IIa under the current Great Britain framework where they provide information amounting to direct diagnosis or decisive diagnostic information. Other active devices may fall under different rules depending on their specific intended purpose and risk.
For developers, the most important takeaway is not to attempt classification based on a feature name alone. A “recommendation”, “insight”, “assistant” or “copilot” could represent very different regulatory functions depending on what information it produces and how that information is intended to influence care.
The safest product-design process therefore begins with an unusually precise intended-purpose statement. It should describe the intended users, patient population where relevant, clinical environment, data inputs, outputs, role in the workflow and the decisions or actions the output is intended to support.
That statement can then become an architectural boundary. Features should be evaluated against it before they are added, rather than regulatory interpretation being applied after the engineering work is complete.
One of the most consequential implications of the MHRA guidance is that regulatory scope needs to become enforceable in software. It is no longer sufficient for intended use to exist only in a PDF written by a regulatory specialist.
If a product is intended exclusively for administrative documentation, the architecture should actively reinforce that boundary.
This is particularly challenging where generative AI is involved. Large language models are designed to respond flexibly to natural-language requests. A clinician using an AI scribe may discover that a text box intended for rewriting notes will also answer clinical questions. The system could therefore drift from “rewrite this note in SOAP format” to “what diagnosis best explains these symptoms?” without any new model deployment taking place.
Developers need guardrails at several levels rather than relying on a single system prompt. Input classification can detect requests that appear to seek diagnosis, treatment recommendations or other functions beyond intended use. Prompt construction should narrowly constrain model behaviour. Output validation should identify prohibited content before it reaches users. The interface should avoid encouraging unsupported use cases. Audit logs should make it possible to understand how users are interacting with the system in the real world.
The architecture should also assume that generative models will occasionally produce information that was never said. Hallucination is not merely a general AI quality issue in an ambient clinical system. It can become a clinical safety hazard.
Consider a consultation in which a patient says, “My mother had breast cancer, but I have never had it myself.” A poorly performing summariser might document “History of breast cancer”. Alternatively, a conversation about whether a medicine may be required could become a note stating that the medicine was prescribed. Negation, uncertainty, family history, hypothetical discussions and temporal context are all areas where apparently small language errors can materially alter the clinical record.
Testing therefore needs to go beyond generic transcription word-error rate.
Developers should create evaluation datasets around clinically meaningful failure modes: medication names and doses; allergies; negation; dates; anatomical sites; speaker attribution; family versus personal history; diagnostic uncertainty; conditional treatment discussions; numbers and units; abbreviations; safeguarding information; and uncommon clinical terminology.
Performance should also be examined across the population likely to use the product. Ambient voice systems can behave differently with regional accents, speech impairments, people speaking English as an additional language, overlapping speakers, telephone-quality audio and noisy clinical environments.
A model that performs impressively in carefully controlled demonstrations may fail in exactly the messy environments where NHS care happens.
Another critical design decision concerns the relationship between the generated output and the clinical record. NHS guidance strongly emphasises professional review before generated information is used. Developers should therefore make review a first-class workflow rather than treating it as a disclaimer.
A robust product might clearly distinguish AI-generated draft text from approved clinical documentation, prevent drafts being mistaken for finalised records, present changes where appropriate and require an explicit clinician action before information is written to an electronic patient record.
The design should optimise the review process without removing meaningful human oversight. If checking a generated note takes as long as manually writing it, the productivity benefit disappears. But if the interface makes approval so frictionless that clinicians stop reading what they approve, automation bias becomes a safety risk.
The challenge is to design efficient scrutiny.
Integration also becomes part of safety. Copying AI-generated text from one browser window into an EPR may appear technically easy, but it introduces opportunities for wrong-patient errors, missing context and undocumented changes. Deeper integration can connect the output to a verified patient identity, preserve structured fields, record provenance and reduce manual transcription.
FHIR, HL7 and SNOMED CT can all play roles depending on the target system and workflow. Primary care environments may additionally require appropriate integration mechanisms with principal clinical systems and national infrastructure.
A mature architecture should preserve the distinction between different types of information. Raw audio, speech transcripts, intermediate model context, generated drafts, approved clinical notes and audit metadata do not necessarily require identical retention policies.
That separation can have important information-governance benefits. NHS guidance indicates that once an appropriate summary has been reviewed and accepted, original recordings and transcripts may not always need to be retained unless there is a specific reason, such as safety monitoring. Architectures that assume every piece of audio must be permanently stored can therefore create unnecessary privacy, storage and security burdens.
Developers should also understand exactly what happens to patient data when external AI services are involved. If audio is sent to one cloud service for speech recognition, a transcript to another provider for summarisation and telemetry to a third platform for monitoring, the data flows rapidly become complicated.
Questions that need technically precise answers include where each data type is stored, whether processing occurs outside the UK, which subprocessors can access it, whether customer information is used to train models, how deletion propagates across systems, how backups are handled and what happens to data after the commercial relationship ends.
An “enterprise AI” label is not an architecture.
The NHS organisation using the system will usually need to understand and control the processing taking place for individual care. Suppliers that cannot explain their own data flows in detail will struggle during assurance, regardless of how good their model demonstration looks.
A common mistake in digital health is to think that determining whether software is a medical device answers the broader question of whether it is ready for NHS deployment. It does not.
An ambient scribe that falls outside medical device regulation can still create substantial clinical, information-governance and cybersecurity risks. NHS requirements therefore extend beyond MHRA qualification.
Clinical safety is one of the most important examples. Digital health products supplied into NHS environments in England are expected to address DCB0129, the clinical risk-management standard applying to manufacturers of health IT systems. Deploying organisations have corresponding responsibilities under DCB0160.
In practice, this means safety engineering should run alongside software engineering.
The product needs identified hazards, credible hazardous scenarios, mitigations and evidence showing that risks have been reduced appropriately. An ambient scribe hazard log might include incorrect medication information, omitted red flags, wrong-speaker attribution, hallucinated diagnoses, loss of information during integration, wrong-patient record updates, delayed output, system unavailability or a clinician approving a note without adequately reviewing it.
Some controls may live in software. Others may be procedural. Some may require both.
For example, an application might reduce the risk of unreviewed AI-generated documentation through interface design and permissions, while the deploying organisation reinforces the control with training, local policy and auditing.
Developers should resist writing safety documentation retrospectively simply to satisfy procurement. A useful hazard log can reveal architecture requirements early enough to influence the product.
Information governance represents another major workstream. Ambient voice products process some of the most sensitive information possible: conversations about people’s health. Those conversations can also contain information about relatives, carers, children or other third parties.
NHS guidance expects organisations to determine a lawful basis for processing and to be transparent with patients. For individual care, explicit GDPR consent will not necessarily be the lawful basis. However, patients should be informed when ambient scribing is being used and must be able to object or dissent in the relevant circumstances.
This has direct product implications. The application needs to work when a patient does not want the ambient scribe used. The clinical workflow cannot collapse simply because recording is unavailable.
The technology must also support data protection rights where relevant. If information is retained within the AVT platform, organisations may need to locate and export it in response to a subject access request. Deletion may need to be suspended when information is subject to an active request or restriction. Retention policies should be configurable and enforceable rather than dependent on someone remembering to delete old files manually.
A Data Protection Impact Assessment is highly likely to form part of NHS implementation because ambient scribing generally involves special-category health data, novel technology and significant automated processing. Suppliers that provide clear architectural documentation, data-flow diagrams, retention controls, subprocessor information and security evidence can make that assessment considerably easier for NHS customers.
Cybersecurity deserves equal attention. An ambient voice application may connect microphones, browsers or mobile devices, cloud APIs, generative AI models and electronic patient record systems. Each integration increases the attack surface.
LLM-based systems also introduce attack classes that conventional health applications may not have needed to consider. Prompt injection is an obvious example. If an ambient system processes external text from a patient’s record or another data source, malicious or simply unusual content could potentially influence model behaviour.
Security design should therefore include traditional measures — authentication, authorisation, encryption, secrets management, vulnerability management, tenant isolation and audit logging — as well as controls specific to AI systems.
Developers should also expect customers to ask about DTAC, the Data Security and Protection Toolkit, Cyber Essentials and associated NHS assurance requirements. Being listed on the NHS England Ambient Voice Technology Supplier Registry may help demonstrate readiness and give NHS organisations access to supplier evidence, but the registry does not remove the need for local assurance or procurement decisions.
The current NHS approach makes local deployment responsibilities particularly important. An NHS trust or other organisation must still determine whether a product is appropriate for its own environment, workflows and patient population.
That means a supplier should be able to provide more than a generic global accuracy number.
Teams should be prepared to explain:
Monitoring is particularly important because AI products are not static in the same way as traditional software. A developer might keep the application code unchanged while switching to a new speech-recognition model, changing an LLM provider, modifying a system prompt or accepting an upstream model update.
Any of those changes could alter performance.
For regulated medical-device functionality, formal post-market surveillance obligations may apply. But even non-device ambient scribes require meaningful operational monitoring within NHS deployments. Teams should track output quality, incidents, latency, availability, usage patterns and potentially differences in performance between groups.
It should also be possible to reconstruct what happened when an error is reported. Observability should therefore be designed with patient safety in mind rather than limited to conventional infrastructure metrics.
“API call succeeded” is not sufficient telemetry if the API returned a clinically misleading summary.
For digital health companies, the MHRA guidance creates clarity but also forces an early strategic choice. Are you building an administrative documentation product, or are you building software that contributes to clinical decision-making?
Both can be valid products. The mistake is accidentally becoming the second while operating as though you are the first.
A documentation-focused supplier may reasonably decide that the fastest path into NHS use is to maintain a tightly controlled administrative intended purpose. That can mean deliberately refusing features that provide differential diagnoses, treatment recommendations or autonomous clinical actions, even when the underlying LLM is technically capable of producing them.
This approach should not be confused with building an unsophisticated product. There is considerable scope for valuable innovation within administrative workflows.
A strong ambient platform can perform speaker diarisation, convert complicated consultations into structured documentation, produce configurable note templates, prepare referral correspondence, extract explicitly stated information, assist with appropriate clinical coding, integrate with patient records, support multiple care settings and automate administrative workflow while remaining firmly focused on documentation.
The competitive challenge then becomes reliability, integration and usability rather than the number of generative features a vendor can add.
Alternatively, a company may conclude that clinical reasoning is central to its value proposition. Perhaps the product is intended to identify potential diagnoses, recommend investigations or help clinicians make treatment decisions. In that case, the right approach is not to bury those features behind disclaimers. It is to recognise the likely medical purpose and build the regulatory, quality and evidence strategy around it.
The dangerous middle ground is an ostensibly administrative product whose interface, marketing or unrestricted conversational capabilities routinely drift into clinical decision support.
Feature governance can help prevent that drift. Product teams should introduce a regulatory-impact checkpoint into the development lifecycle. Before a feature reaches implementation, somebody should ask whether it changes intended purpose, introduces a new medical claim, alters clinical risk, changes data processing or affects existing assurance evidence.
This becomes even more important with feature flags and modular SaaS products. A platform might contain both administrative and medical-device modules. Teams need to understand whether those functions can genuinely be separated, how users access them and whether the wider system architecture affects the regulatory assessment.
Model updates deserve the same discipline.
Many AI companies have adopted a development culture in which model improvements can be deployed rapidly. That model works poorly in safety-critical healthcare if “improvement” is defined solely through generic benchmarks.
Every significant change to the ambient pipeline should be evaluated against a clinically meaningful test suite. Teams need versioning not only for application code but also for models, prompts, configuration, templates and relevant knowledge sources.
An incident investigation becomes substantially harder if nobody can determine which model and system prompt generated a patient’s note three weeks earlier.
A strong release pipeline for clinical AI therefore needs reproducibility. Where practical, organisations should be able to identify the model version, prompt configuration, relevant software release and user actions associated with a generated output.
The broader lesson is that AI governance should be implemented as engineering infrastructure.
Regulatory requirements become much easier to manage when they map to technical controls: intended-purpose restrictions become prompt and capability controls; clinical oversight becomes approval workflows; information governance becomes retention and deletion services; post-market surveillance becomes observability; auditability becomes structured event logging; interoperability becomes tested interfaces; safety cases become traceable requirements and verification evidence.
This approach also prepares suppliers for where the market is heading.
Ambient voice technology is unlikely to remain a standalone note-taking category. The natural evolution is towards ambient clinical agents that listen, understand context and interact with surrounding healthcare systems. A consultation could eventually trigger documentation, coding, correspondence, follow-up tasks, booking activity, medication workflows and other clinical operations.
Each additional capability increases both the potential value and the potential risk.
The most successful NHS ambient platforms may therefore not be those that simply attach the most powerful LLM available to a microphone. They are more likely to be systems that combine capable models with disciplined boundaries, robust integrations, excellent human-review workflows and an architecture designed around healthcare assurance.
Developers should think carefully about where autonomy is genuinely useful. Automatically formatting a note into the correct template is very different from automatically ordering a diagnostic investigation. Sending a clinician-approved referral is very different from deciding independently that the referral is required.
The right architecture should make those boundaries explicit.
The new MHRA guidance ultimately gives the ambient voice market something it badly needed: a clearer vocabulary for distinguishing administrative AI from medical AI. That distinction should give responsible developers greater confidence rather than discourage innovation.
A transcription or summarisation system does not become a medical device merely because sophisticated AI is operating under the surface. Equally, clinically consequential functionality does not cease to be medical simply because it is presented inside a product called a “scribe”.
What matters is purpose, behaviour and context.
For companies building for the NHS, this should reshape the order in which products are developed. Instead of building an impressive AI prototype and asking compliance teams how to approve it afterwards, teams should start by defining the intended role of the system within care.
From there, they can identify regulatory status, map clinical hazards, define data flows, establish the human-review model, design the integration architecture and create measurable performance requirements. The user experience and AI functionality can then be built within those boundaries.
That may sound more restrictive than conventional AI development. In practice, it can produce better products.
A clearly scoped ambient scribe is easier to test. A product with controlled data flows is easier to deploy. A system with explicit approval states is safer to integrate. A model evaluated against realistic clinical failure modes is more useful than one optimised only for generic benchmarks. A release process that preserves traceability makes incidents easier to investigate. And a supplier that can explain all of this clearly will be easier for NHS organisations to trust.
Ambient voice technology is moving from novelty to infrastructure. As that happens, the standard for developers will rise accordingly.
The question will no longer be whether an AI model can generate a plausible consultation note. Increasingly, the question will be whether the entire system — model, interface, integrations, controls, governance and monitoring — can operate safely within real clinical care.
The MHRA’s new guidance is an important step towards answering that question. For developers, it should be treated not as another hurdle at the end of product development, but as an architectural signal for what trustworthy ambient clinical software needs to become.
Is your team looking for help with digital health development? Click the button below.
Get in touch