Summary
Four things are worth watching every week once an ambient scribe is in service. How often a draft is edited before signing, how often one is abandoned, how many consultations produced no note at all, and whether anybody has raised a concern. Each maps to a duty that survives the purchase. DCB0160 makes clinical risk management of the deployed product the deploying organisation's own, held by a named Clinical Safety Officer against a hazard log that stays live. The UK GDPR duties run continuously, and a personal data breach reaches the ICO within 72 hours. Most published guidance covers choosing a product rather than running one, which is the half that lasts years rather than weeks.
Almost everything written about buying an AI scribe stops at the signature. The frameworks, the registry, the questions to put to a vendor and the device status all describe a decision taken once, and then the guidance goes quiet on the years that follow.
The duties do not go quiet. Clinical risk management of a deployed product belongs to the organisation deploying it, and it is a standing obligation rather than a document filed at go live. This page is about the half nobody writes down.
See it in your clinicEvery draft, every edit and every approval on one record, so the numbers below are a report rather than an audit.
Request a demo| Signal | What a change in it suggests | Where the duty sits |
|---|---|---|
| Edit rate before signing | A rising share of drafts needing correction is the earliest sign the model has drifted, or that a new clinic, accent or specialty is outside what it handles well | DCB0160, your hazard log |
| Abandoned drafts | A note started and never signed is a consultation whose record was written somewhere else, usually in a hurry and later | Records quality, and your own clinical governance |
| Consultations with no note at all | Silent capture failure. The page looks correct and the clinician assumes the note exists | DCB0160, and the supplier under DCB0129 |
| Concerns raised by clinicians or patients | The only signal that arrives in words rather than numbers, and the one most likely to describe a hazard nobody modelled | Your incident process, and the ICO within 72 hours if personal data was involved |
What changes on the day it goes live
Before go live the question is whether a product is safe enough to deploy, and it is answered by reading documents and asking a vendor questions. After go live the question is whether the product is still behaving the way it behaved in the pilot, and no document answers that. Only the record of what it produced does.
The shift matters because the two questions have different owners. Choosing is usually done by a small group over a few weeks. Running is done by everybody who touches the record, every day, for as long as the contract lasts, and the signals that something has changed arrive quietly and in the wrong place.
The buying half is covered elsewhere and this page assumes it. How an NHS organisation actually buys one covers the routes to market and the registry, and the two clinical safety standards cover who owes which before anybody signs.
The four things worth watching every week
A clinic does not need a dashboard of forty metrics to run an ambient scribe safely. It needs four numbers it can read in a minute, and a named person whose job it is to read them. Everything else is detail that follows once one of the four moves.
The first three are counts the system already knows. The fourth is the one that will not appear in any report unless somebody asks for it, and it is usually the one that matters most.
How an ambient scribe actually fails
The failure people expect is a fabricated sentence, and it does happen, but it is the easiest kind to catch because a clinician reading their own consultation notices a claim that was never made. The failures that survive review are quieter than that.
A note that is accurate and incomplete passes a tired reader. So does a note where a negative became a positive, where one speaker's words landed under the other's name, or where a medication dose carried the right drug and the wrong number. The hazard is not that the model writes nonsense. It is that it writes something plausible, and plausible is what a reflex sign-off cannot distinguish from correct.
Capture failure is the other half, and it leaves no artefact to review at all. A consultation that produced no note looks identical to a consultation nobody has got to yet, which is why a count of consultations without notes is worth more than it sounds.
What the published studies found on fabricated content is worth reading before writing a hazard log, and our review of the hallucination research sets out the numbers and their limits. The mitigations come back to the same control, which is that a clinician reads and approves before anything is saved.
The duty that does not end at purchase
DCB0160 is the deploying organisation's clinical risk management standard, and the word deploying is doing the work. It is not satisfied by a supplier's paperwork, and it is not finished when the system is switched on. It requires a named Clinical Safety Officer, a clinical risk management file for the deployment, and a hazard log that is maintained rather than archived.
A hazard log that has not changed in a year is not evidence of a safe deployment. It is evidence that nobody has looked. New clinics, new specialties, a new model version from the supplier and a change in who reviews notes are each a reason to revisit it, and each is the kind of change that happens without anybody filing a form.
The MHRA settled the device question for ambient voice technology on 29 July 2026, and summarising a consultation does not by itself make a product a medical device. That is a narrower finding than it is often quoted as. It removes one regulatory route. It removes none of the clinical safety duties above, and a supplier that cites it as though it clears the field is telling you something about how they read guidance.
When something goes wrong, who you tell
Three routes exist and they are not alternatives to each other. The first is internal, through whatever incident process the organisation already runs for a clinical event, and it should be the same process rather than a separate one for anything involving software. A parallel process for AI is how an incident gets logged twice or not at all.
The second is the supplier, because a defect that produced one bad note in your clinic is producing them elsewhere, and a supplier who hears about it late cannot act on it. Put the expectation in the contract rather than relying on goodwill, including what they owe you back when a defect is found by somebody else.
The third applies only when personal data was involved, and it is time limited. A personal data breach that meets the threshold reaches the Information Commissioner's Office within 72 hours of the organisation becoming aware of it. Seventy two hours is short, and it runs from awareness rather than from confirmation, which is a distinction worth settling before a weekend rather than during one.
What we are not claiming
None of this is a substitute for your own clinical governance, and a page on a vendor's website is not a clinical risk management file. The standards named here are summarised rather than reproduced, and where a decision turns on the detail, the source documents linked below are what govern it rather than this description of them.
We are not a registered medical device and we do not claim to be. The note is a draft, the clinician is the author, and nothing reaches a patient without a person approving it.
Where wai sits
wai is built so a clinician makes every clinical decision. It drafts the note, the letters and the coding for review, shows its working so a reviewer checks reasoning rather than trusting output, and holds every patient-affecting action for approval. Every read of a patient record is logged against a named role.
That design is what makes the four signals above readable rather than reconstructable. A draft, the edits made to it and the approval that followed sit on one record, so the edit rate and the abandoned count are a report rather than an audit project.
Request our hazard log and our safety case before the demo. A supplier who will not hand those over early, including us, has told you where they are in the process. Clinicians still decide what enters the record.
Request our hazard log and our safety case before the demo, not after the order.
Request a demoFrequently asked questions
What should a clinic monitor after deploying an AI scribe?
Four things weekly. The share of drafts edited before signing, the number abandoned without signing, the number of consultations that produced no note at all, and any concern raised by a clinician or a patient. The first three are counts the system already holds. The fourth has to be asked for, and it is the one most likely to describe a hazard nobody modelled.
Does DCB0160 apply after the system is live?
Yes. DCB0160 is the deploying organisation's clinical risk management standard and it is a standing duty rather than a go live gate. It requires a named Clinical Safety Officer, a clinical risk management file for the deployment and a hazard log that is maintained. A hazard log unchanged for a year is evidence nobody has looked, not evidence of safety.
How does an AI scribe fail in a way that survives review?
Quietly. A note that is accurate but incomplete reads correctly to a tired clinician, as does one where a negative became a positive, where one speaker's words landed under the other's name, or where a dose carried the right drug and the wrong number. Capture failure is worse again, because a consultation that produced no note leaves nothing to review.
Who do we tell when an AI scribe causes a patient safety incident?
Use the incident process the organisation already runs for clinical events rather than a separate one for software, tell the supplier because the same defect is affecting other clinics, and where personal data was involved, notify the Information Commissioner's Office within 72 hours of becoming aware.
Does the MHRA decision of 29 July 2026 remove these duties?
No. It found that summarising a consultation does not by itself make a product a medical device, which removes one regulatory route. The clinical safety standards and the data protection duties are unaffected, and a supplier citing it as though it clears the field is telling you how they read guidance.
How often should the hazard log be revisited?
Whenever something changes that the original assessment did not cover. A new clinic, a new specialty, a new model version from the supplier, or a change in who reviews notes before signing. Each of those happens without anybody filing a form, which is why a date in the diary is worth more than a trigger that relies on somebody noticing.
Is a pilot enough to satisfy the ongoing duties?
No. A pilot establishes whether a product behaves acceptably in a narrow setting for a short period. The duties described here attach to the deployment for as long as it runs, and the signals worth watching are precisely the ones that change after a pilot ends and usage broadens.
Sources
The hazard log before the demo
Fifteen minutes on your workflows. If it is a fit we reply within 24 hours.
Partner with us
See it on your own patients, then build it with us
Thirty minutes on your own patients, doctors and rules, in your market. We reply within one working day, and the clinics that partner with us early shape what we build next.
See what wai does between the visits