Across the published guidance reviewed here, clinicians are expected to review AI-assisted clinical documentation rather than treat an AI-generated note as automatically correct.

That does not mean every responsibility sits with the clinician.

Different responsibilities can arise at different levels:

Supplier or manufacturer
Product design, intended purpose, safety, performance, security and applicable regulatory requirements.

Healthcare organisation
Procurement, implementation, configuration, clinical-risk management, staff training, information governance and ongoing monitoring.

Clinician
Professional judgement, review of AI output and the accuracy and appropriateness of the final clinical record.

Those responsibilities can overlap.

They are also different from legal liability, which depends on the applicable law and the facts of a specific case.

The practical question is therefore narrower:

Which responsibilities has each party accepted, documented and implemented before the system is used in clinical care?

---

Four terms that are not interchangeable

Most confusion in this area comes from using one word for four different concepts.

Professional accountability concerns duties expected of a regulated healthcare professional by their professional regulator.

Regulatory responsibility concerns obligations imposed on manufacturers, sponsors, providers or organisations by a regulatory framework.

Contractual responsibility concerns what parties agree to do under a contract, subject to applicable law.

Legal liability concerns whether a person or organisation is legally responsible for loss or harm in a particular case.

This article addresses the first three where published guidance supports doing so.

It does not attempt to determine the fourth.

---

This is not a hypothetical concern

In August 2026, ABC News Australia reported a case involving an AI-assisted medical record that contained incorrect information attributed to a patient.

The report quoted Ahpra on the importance of practitioners checking AI-generated records for accuracy.

The incident does not establish legal liability.

It does illustrate why clinician review remains an operational control.

An AI-generated statement can appear plausible and enter the clinical record even when it was never actually said.

---

Three layers of responsibility

Layer	Party	Typical area of responsibility
Product	Manufacturer, developer or supplier	Intended purpose, regulatory requirements, product safety, performance, security and technical controls
Deployment	Healthcare organisation	Procurement, risk assessment, configuration, training, clinical safety, information governance and monitoring
Clinical record	Treating clinician	Reviewing AI-generated documentation and ensuring the final record meets applicable professional requirements

These layers are not mutually exclusive.

A supplier can have product obligations even where a clinician must review the note.

A healthcare organisation can have deployment duties even where individual practitioners remain professionally accountable.

And clinician responsibility for review does not automatically remove supplier or organisational responsibilities.

None of these statements, on its own, determines legal liability after an incident.

---

What published guidance says, market by market

Australia — the clearest AI-scribe-specific guidance

Ahpra states that practitioners remain responsible for delivering safe and quality care regardless of the technology used.

It specifically says practitioners must apply human judgement to AI output and that users of AI-scribing tools are responsible for checking the accuracy and relevance of records generated using AI. TGA approval does not remove that obligation.

The TGA separately states that healthcare professionals using digital scribes are responsible for obtaining informed consent and verifying information entered into the patient’s record.

The RACGP’s current AI-scribe fact sheet, last updated 27 March 2025, says AI-scribe output must be carefully checked for accuracy and that GPs remain responsible for ensuring the patient record is accurate and current.

The Australian Commission on Safety and Quality in Health Care also publishes an AI Clinical Use Guide with a specific ambient-scribe safety scenario.

Product regulation is separate

The TGA distinguishes simple documentation functions from software with a therapeutic purpose.

A digital scribe that transcribes or translates a clinical conversation without analysis or interpretation may fall outside medical-device regulation.

A product that analyses information to generate a diagnosis, differential diagnosis or treatment recommendation can meet the medical-device definition.

Where a developer adapts a general-purpose model into a medical-device function, the developer may acquire manufacturer responsibilities.

That does not remove the practitioner’s responsibility to apply clinical judgement.

Australia remains an active regulatory area

The TGA continues to review digital scribes supplied in Australia to clarify which products and functionalities meet the medical-device definition.

Its current software-regulation page says the outcomes of that review will be published shortly.

That makes this a review point for future updates.

---

United Kingdom — product and deployment responsibilities are separate

NHS England’s ambient-scribing guidance expects adopting organisations to address:

• safe deployment;
• user training;
• clinical safety;
• information governance;
• review and approval of generated outputs;
• ongoing monitoring and assurance.

Clinical-risk responsibilities are also formally divided.

DCB0129 addresses manufacturers of health IT systems.

DCB0160 addresses healthcare organisations deploying and using those systems.

NHS England launched a national review of both standards in 2026. The public consultation opened on 29 June and closed on 11 September 2026.

The existing standards remain the relevant published framework while the review continues.

This matters because:

Product safety and deployment safety are related, but they are not the same responsibility.

The final clinical record may additionally fall within the professional obligations of the relevant healthcare professional.

Again, these frameworks describe responsibilities.

They do not automatically decide legal liability in a disputed case.

---

New Zealand — explicit AI guidance now exists

New Zealand should no longer be grouped with markets where no relevant AI-scribe guidance has been identified.

The Medical Council of New Zealand published Guidance on using artificial intelligence in patient care on 10 March 2026.

The guidance says:

• AI is not a substitute for clinical judgement;
• doctors remain responsible for their clinical decisions and actions;
• as far as reasonably practicable, doctors should check AI outputs for accuracy before using them for patient care or including them in patient records;
• doctors should understand the intended use, capabilities and limitations of the tools they use.

The guidance specifically recognises AI use in clinical documentation.

That gives New Zealand a clearer professional-accountability position than the previous version of this article reflected.

---

United States — keep the claim deliberately narrow

FDA regulation addresses the regulatory status of software functions, not general malpractice allocation.

The current Clinical Decision Support Software guidance is dated January 2026.

FDA issued the updated guidance on 6 January 2026 and re-issued it on 29 January 2026.

It explains how certain CDS functions may fall outside the device definition if the statutory criteria are met.

That should not be interpreted as a rule deciding whether a clinician or software vendor would be liable for a wrong clinical note.

HIPAA raises a separate issue.

Where a vendor qualifies as a business associate and handles PHI on behalf of a covered entity, HIPAA generally requires a business associate agreement containing specified protections.

HHS also confirms that business associates can be directly liable for compliance with certain HIPAA provisions. Its business-associate guidance was last reviewed on 30 July 2026.

Those are privacy and security responsibilities.

They are not a general malpractice-allocation rule.

Accordingly:

This article does not state that US federal law generally makes either the clinician or the AI vendor liable for an incorrect note.

That can depend on state law, contracts and the facts of the incident.

---

European Union, Canada and UAE

At the time of this 6 October 2026 review, we did not identify one harmonised AI-scribe-specific professional-accountability rule across these three markets that would justify importing the Australian, English or New Zealand position wholesale.

That does not mean there are no obligations.

Relevant frameworks can include:

• medical-device regulation;
• professional standards;
• privacy and health-information law;
• cybersecurity obligations;
• consumer or product law;
• organisational governance;
• contracts.

The appropriate allocation depends on the product and jurisdiction.

The absence of one AI-scribe-specific rule is not the absence of responsibility.

It means organisations should assess the frameworks that actually apply locally rather than assuming guidance transfers from another country.

---

Three themes in the guidance reviewed

AI-generated documentation still requires human review

Australia is particularly explicit.

Ahpra, the TGA, RACGP guidance and the Australian Commission all place weight on practitioners checking AI-generated documentation.

New Zealand now makes the same principle clear.

NHS England likewise expects generated outputs to be reviewed before further action.

That makes human review an important operational control.

It should not be described as:

• a legal guarantee;
• proof that every error will be found;
• a mechanism that eliminates supplier responsibility;
• a mechanism that eliminates organisational responsibility.

Product approval does not replace professional judgement

Ahpra states explicitly that TGA approval does not remove a practitioner’s responsibility to apply human oversight and judgement.

Product regulation answers one set of questions.

Professional practice answers another.

Deployment governance matters alongside individual review

NHS England’s model makes this especially clear.

Responsible deployment includes:

• implementation controls;
• clinical-risk management;
• staff training;
• information governance;
• monitoring;
• incident management.

So the safety model cannot be reduced to:

“The clinician signed it, therefore everyone else is covered.”

The published guidance does not support that conclusion.

---

What this means if you run a clinic

Define the review process

Do not stop at:

“Clinicians must check every AI-generated note.”

Document:

• who reviews;
• when review happens;
• which note sections require particular attention;
• who can approve;
• what happens if an error is found;
• how corrections are recorded.

A defined workflow is stronger than a general instruction.

Establish the appropriate consent process

Consent requirements differ by jurisdiction.

Australia’s TGA places responsibility on clinicians using digital scribes to obtain informed consent.

New Zealand’s guidance also requires appropriate consent and transparency around AI use.

Do not copy one country’s workflow into another without checking the local rules.

Decide retention deliberately

Do not default to retaining every:

• recording;
• transcript;
• prompt;
• model output;
• debug log.

Those materials can themselves contain sensitive health information.

Define:

• why the information is retained;
• the lawful basis;
• retention period;
• storage location;
• access controls;
• deletion process;
• which audit metadata needs to remain.

Read the contract carefully

Review:

• permitted data uses;
• subprocessors;
• hosting location;
• retention and deletion;
• security obligations;
• incident reporting;
• product changes;
• audit rights;
• service availability;
• indemnities;
• limitations of liability;
• termination;
• data return.

Do not assume a contractual term automatically produces a particular legal outcome.

Monitor after deployment

Define how you will:

• sample generated notes;
• classify errors;
• investigate incidents;
• identify recurring failure modes;
• retrain users;
• review model or software updates;
• respond when functionality changes.

Governance continues after procurement.

---

What this means if you are building one

Define intended purpose carefully

“AI scribe” is not itself a regulatory category.

Function matters.

Australia distinguishes transcription from medical-purpose interpretation.

The FDA separately assesses whether particular software functions meet the device definition.

For the detailed thresholds, link to:

Is an AI Scribe a Medical Device? MHRA, FDA and TGA Compared

Do not assume the model provider carries your obligations

Using a third-party foundation model does not automatically transfer the finished product’s regulatory obligations to that provider.

Depending on jurisdiction and product function, the company developing and supplying the finished healthcare product may itself acquire manufacturer responsibilities.

Make clinician review observable

If review is part of the intended safety model, build controls such as:

• draft status;
• explicit approval;
• timestamps;
• user identity;
• version history;
• change history;
• appropriate audit logs.

These show how the workflow operated.

They do not eliminate liability.

Do not rely on disclaimers

A disclaimer can communicate limitations.

It cannot replace:

• safe design;
• intended-purpose analysis;
• risk management;
• appropriate regulatory assessment;
• user training;
• monitoring.

Keep a proportionate audit trail

Depending on the product and jurisdiction, useful records may include:

• software version;
• model version;
• configuration;
• generation timestamp;
• approval status;
• material edits;
• incidents.

Do not automatically retain raw patient audio simply for defensibility.

Retention itself requires justification.

---

The operational question worth asking

If a generated note is challenged six months from now, can we show which system produced it, which version was used, who reviewed it, what changed and what governance process applied at the time?

That question is more useful for deployment planning than trying to predict liability in the abstract.

---

Frequently asked questions

Who is responsible when an AI scribe creates an incorrect clinical note?

Responsibility can be shared across the clinician, healthcare organisation and AI-scribe supplier. Current guidance in Australia, England and New Zealand expects clinicians or users to review AI-generated documentation before relying on it, while suppliers and healthcare organisations can have separate product, regulatory, governance, privacy and contractual responsibilities. Legal liability in a specific incident depends on the jurisdiction and facts.

Does using an AI scribe transfer responsibility to the vendor?

No, using an AI scribe does not automatically transfer responsibility for the final clinical record to the vendor. Vendors can still have separate product, privacy, security, regulatory and contractual obligations.

Is the clinician always responsible for an AI-generated note?

Not in the sense that every responsibility sits with the clinician. Clinicians can have professional responsibilities for reviewing the final record, while suppliers and healthcare organisations can simultaneously have separate product, regulatory, privacy, governance and contractual obligations.

Who should review an AI-generated clinical note before it is filed?

The appropriate clinician or authorised healthcare professional should review the AI-generated note before it is relied upon or entered into the final clinical record, subject to the organisation’s workflow and applicable professional requirements.

Does regulatory approval protect a clinician from responsibility?

No, regulatory approval does not automatically remove a clinician’s professional responsibility. Ahpra states that TGA approval does not remove the practitioner’s responsibility to apply human oversight and judgement.

What does the RACGP say about AI-scribe responsibility?

The RACGP says clinicians remain responsible for ensuring patient records are accurate and current when using an AI scribe. AI-generated output should therefore be checked for accuracy before it becomes part of the patient record.

What does NHS England expect when healthcare organisations use AI scribes?

NHS England expects healthcare organisations to address safe deployment, user review, training, clinical safety, information governance and ongoing assurance when using ambient-scribing systems.

What is the difference between DCB0129 and DCB0160?

DCB0129 covers clinical-risk management for manufacturers of health IT, while DCB0160 applies to healthcare organisations deploying and using health IT. The standards are currently under review, and the 2026 consultation closed on 11 September 2026.

What does New Zealand guidance say about AI scribes?

The Medical Council of New Zealand says doctors remain responsible for their clinical decisions and should check AI outputs for accuracy before using them in patient care or patient records.

Does the US have one rule deciding whether the clinician or AI-scribe vendor is liable?

No single US federal rule determines clinician-versus-vendor liability for an incorrect AI-generated clinical note. FDA rules address the regulatory status of software functions, HIPAA covers certain privacy and security responsibilities, and liability can depend on state law, contracts and the facts of the incident.

Who is the manufacturer if an AI-scribe product uses a third-party LLM?

Using a third-party LLM does not automatically make the model provider the manufacturer of the finished healthcare product. Depending on the jurisdiction and functionality, the company adapting the model into a regulated medical-device function may acquire manufacturer responsibilities.

Do the EU, Canada, New Zealand and UAE have the same AI-scribe accountability rules?

No, AI-scribe accountability rules are not the same across these markets. New Zealand now has explicit professional AI guidance, while the EU, Canada and UAE apply their own combinations of medical-device, professional, privacy and governance frameworks.

Does a disclaimer protect an AI-scribe supplier from liability?

A disclaimer does not automatically protect an AI-scribe supplier from liability. Its legal effect depends on applicable law, contractual terms, regulatory obligations and the facts of the case. It should not replace product safety or governance controls.

Should clinics keep the original AI-scribe recording?

Not necessarily. Audio recordings and transcripts can create additional privacy, security, consent, storage and retention obligations, so clinics should define a retention policy based on their jurisdiction and workflow.

---

Where this leaves accountability

AI-assisted documentation does not create one simple chain of responsibility.

It creates several overlapping ones.

The supplier may have product obligations.

The healthcare organisation may have deployment and governance duties.

The clinician may have professional responsibilities for reviewing and approving documentation.

Privacy, security and contractual obligations can operate alongside all three.

None of those statements, by itself, determines who would be legally liable if harm occurred.

That requires case-specific legal analysis.

What organisations can do before deployment is:

• define responsibilities;
• build genuine review into the workflow;
• understand the product’s regulatory status;
• establish appropriate governance;
• define proportionate audit and retention controls;
• review contractual allocation;
• monitor performance after deployment.

That is the governance work worth doing before an error occurs.

---

About the author

Nikita is a Marketing & Research Analyst at KastHunt Consulting LLP, working across LinkedIn, SEO, digital marketing and healthcare technology research. 

With a background in healthcare and management, she is interested in healthcare AI, digital health, market intelligence, and emerging healthcare technologies.

She writes about healthcare AI, digital health trends, healthtech markets, and the practical side of communicating complex healthcare technology.

Questions or corrections: info@kasthunt.com

---

Related reading

---

Sources

---