Skip to content
Assurance AI

Deployment readiness

AI scribes and ambient documentation: deploy them with your eyes open

Ambient AI documentation is being adopted faster than any clinical software in recent memory. The tools are genuinely useful — and the failure modes are quiet ones. Deployment readiness means knowing, before go-live, how the tool fails in your service and what you will do about it.

Last reviewed: Guidance in this area changes. We re-check the primary sources when we review a page.

The problem

The risks are in the workflow, not the demo

AI scribes fail quietly. A note that reads well is not necessarily a note that is right, and the clinician reviewing it is often the busiest person in the building.

Most AI scribe deployments begin with a convincing demonstration and an enthusiastic pilot. The problems surface later: a note filed against the wrong record, a disclosure that never made it into the summary, a review step that quietly stops happening at 4pm on a full clinic day. None of these announce themselves as incidents. They accumulate in the record.

NHS organisations deploying these tools carry their own clinical risk management obligations under DCB0160, and suppliers carry theirs under DCB0129. Where the tool's intended purpose brings it within medical device rules, the MHRA's guidance on software and AI as a medical device applies as well. The supplier's evidence is an input to your deployment work — never a substitute for it.

Illustrative hazard patterns

The failures a deployment review looks for

  • Misattributed speaker

    The tool assigns a statement to the wrong person in the room — for example a relative's account recorded as the patient's own words.

  • Omitted disclosure

    A safeguarding or risk disclosure is summarised away or softened, and the omission is invisible on a quick review.

  • Invented content

    The note contains a plausible-sounding detail — a dose, a plan, a negative examination — that was never said.

  • Wrong-record filing

    The note is filed against the wrong patient, or the right patient but the wrong encounter.

  • Review under load

    The human-check step exists on paper but is not realistic at clinical tempo, so notes are filed unreviewed.

  • Silent fallback failure

    The tool is unavailable or degraded and nobody notices until the gap in the record surfaces weeks later.

Important

These are illustrative hazard patterns drawn from how this class of tool works, not findings from any real product, organisation or investigation. Your hazard log must come from your product, your workflow and your patients — which is exactly what the deployment workshop is for.

Human verification

Every AI scribe deployment names the same control: the clinician checks the note. Whether that control is real depends on how long a careful check takes, when in the consultation cycle it happens, and what the clinician does when the note is wrong in a way that is hard to spot.

A verification step that is not realistic under clinical load is not a control — it is an assumption, and it belongs in the hazard log as one.

Supplier evidence

What to ask your supplier for — and how to read it

A deployment readiness review starts with what the supplier hands you. The useful question is not 'do they have a safety case?' but 'what are they assuming about us?'

  • The supplier's intended-use statement, and whether it matches how you actually plan to use the tool
  • The supplier's DCB0129 clinical safety case report and hazard log for the version you are deploying
  • Stated assumptions and residual risks being handed to your organisation
  • How model, prompt or configuration changes are assessed and communicated to customers
  • What the supplier monitors after deployment, and what they expect you to monitor

Every supplier control that depends on local behaviour — “users will be trained”, “a clinician will review before filing” — becomes a local obligation. If it is not written down and assigned, it will not happen reliably.

What you receive

Deliverables from a deployment readiness engagement

  • A written review of the supplier's clinical safety evidence, listing the assumptions and residual risks that land with you
  • A populated local hazard log from a facilitated workshop with your clinical and operational staff
  • A drafted local clinical safety case report, structured to DCB0160, for your Clinical Safety Officer to review and sign off
  • A human-verification and fallback design that is realistic under your actual clinical load
  • A monitoring and change-review plan covering supplier updates, model changes and incident routes
  • A prioritised action list for the gaps to close before go-live

We work in support of your organisation's appointed Clinical Safety Officer. We prepare, structure and review documentation; your CSO reviews and signs it off. We do not sign off clinical safety documentation, and we do not act as your CSO unless and until formal competence, appointment and cover arrangements have been established and recorded in writing.

What we need from you

  • The supplier's intended-use statement, safety case report and hazard log for your version.
  • A description of the deployment: care settings, consultation types, user groups and go-live plan.
  • Your existing local clinical risk management plan, if one exists.
  • Named clinical and operational participants for the hazard workshop.
  • The name and availability of your appointed Clinical Safety Officer and data protection lead.

What is not included

  • Medical device classification determinations or regulatory submissions.
  • Clinical safety sign-off — that belongs to your appointed Clinical Safety Officer.
  • Legal advice, including data protection legal opinions.
  • Technical performance testing or validation of the model itself.
  • Any form of certification, approval or accreditation of the product or deployment.

Deployment readiness reviews start from £1,450 for one organisation, one product and one workflow — see pricing for the full offer ladder. Final scope and fees are agreed in writing before work begins.

Where this bites hardest

Settings where ambient documentation needs extra care

In mental health and neurodevelopmental services, consultations carry disclosure, nuance and multi-informant accounts that summarising tools handle badly. A softened risk statement or a misattributed observation is not a documentation inconvenience — it changes the clinical record of a vulnerable patient.

Medication-heavy pathways carry their own version of the problem: doses, titration plans and shared-care instructions transcribed almost correctly. If your deployment touches either of these areas, say so at enquiry — it changes which hazards the workshop spends time on.

FAQ

AI scribe deployment questions

Is an AI scribe a medical device?

It depends on the intended purpose the supplier claims for it. A tool that only transcribes may sit outside medical device rules; one that interprets, summarises clinically or influences decisions may not. The MHRA's guidance on software and AI as a medical device, and on crafting an intended purpose, is the right starting point — and the classification question is separate from whether NHS buyers will expect DCB0129 and DCB0160 evidence, which they usually will regardless.

Our supplier says their safety case covers everything. Is that enough?

No. A supplier safety case is written against an intended use and a set of assumptions. It cannot know your staffing model, your consultation styles, your patient population or how the tool will be configured in your service. DCB0160 exists precisely for that local layer: workflow, configuration, training, verification practice, downtime and fallback.

Who checks the notes, and is 'the clinician checks everything' a real control?

Human verification is the control everyone names and the one most likely to fail in practice. A review step that adds minutes per consultation will be skipped under load. Part of deployment readiness is designing verification that is realistic — what is checked, by whom, at what point, and what happens when it is not — rather than writing 'clinician review' into a plan and hoping.

What data protection work sits alongside the clinical safety work?

Ambient listening in a consultation is high-risk processing: expect a data protection impact assessment, a lawful basis analysis, transparency for patients, and clear retention and access rules for recordings and transcripts. The ICO's guidance on AI and data protection sets out the expectations. We flag where this work is needed and coordinate with your DPO; we do not provide legal advice.

Do you act as our Clinical Safety Officer for the deployment?

We work in support of your organisation's appointed Clinical Safety Officer. We prepare, structure and review documentation; your CSO reviews and signs it off. We do not sign off clinical safety documentation, and we do not act as your CSO unless and until formal competence, appointment and cover arrangements have been established and recorded in writing.

Primary sources

The official material this page draws on

For a running, source-checked view of regulatory developments in this area, see our Insights briefings, including AI scribes: safety questions to settle before deployment.

Keep going

Related reading

DCB0160 for deploying organisations

The clinical risk management standard your deployment work sits under.

DTAC readiness

How the same evidence feeds buyer assurance questions.

Clinical Safety Officer support

Competence, authority and resourcing for the role overseeing your deployment.

Mental health and neurodevelopmental products

Where ambient documentation hazards carry the most clinical weight.

Next step

Deploying an AI scribe? Talk to us before go-live

Tell us what you are deploying, into which service, and where you are in the programme. We will be straight with you about what a proportionate readiness scope looks like.