MHRA AI Healthcare Regulation: A Six-Week Contradiction Timeline. Timeline showing the regulatory sequence from the NHS England June 2026 review, through the MHRA’s July 2026 AVT guidance, to the National Commission’s September 2026 report, highlighting the emerging contradiction between public reassurance, acknowledged regulatory insufficiency and the later call for lifecycle, transparent and system-wide AI oversight.

The Hidden Burden of AVT: Automation Can Create a Second Clinical Task. Comparison of traditional clinical documentation with an AVT-supported workflow, showing that AI does not necessarily remove work where the clinician must verify, correct and assume responsibility for the machine’s reconstruction of the consultation.

Ambient Voice Technology, Large Language Models, Clinical Safety, Patient Confidentiality, Computational Transparency and Sovereignty

Public Interest Disclosure

Author: Endarr Carlton Ramdin
Public Bodies: Medicines and Healthcare products Regulatory Agency; Department of Health and Social Care; NHS England
Subject: Artificial Intelligence in Healthcare; Ambient Voice Technology; Large Language Models; Clinical AI Regulation; Patient Safety; Clinical Data Processing; Public-Sector Governance
Principal Regulatory Material: MHRA Ambient Voice Technology Guidance, 29 July 2026; National Commission into the Regulation of AI in Healthcare Recommendations, 10 September 2026
Disclosure Date: 10 September 2026
Status: Continuing public-interest disclosure concerning healthcare AI regulation, clinical safety, public-sector accountability, computational transparency and patient-data sovereignty

1. Introduction and Disclosure Basis

This disclosure concerns a fundamental regulatory mismatch between the actual architecture of contemporary artificial-intelligence systems and the language presently being used by public bodies responsible for regulating their use within healthcare.

On 29 July 2026, the Medicines and Healthcare products Regulatory Agency published guidance concerning Ambient Voice Technology products used within health and care settings. That guidance expressly permits certain AI-enabled functions to remain outside medical-device regulation where their intended purpose is characterised as administrative. Those functions include generative summarisation of clinical conversations, transformation of consultation information into structured data, production of medication and problem-list information for clinician confirmation, and drafting of summaries or letters for later clinical review. (GOV.UK)

The guidance does not establish that these processes are error-free. On the contrary, it repeatedly requires clinician review, editing, correction or confirmation before generated material enters the patient record. The architecture therefore expressly depends upon a human clinician identifying computational error after the AI system has already processed and transformed the doctor-patient interaction. (GOV.UK)

On 10 September 2026, the National Commission into the Regulation of AI in Healthcare published recommendations for a substantially broader regulatory and assurance framework. The Commission states that existing regulatory approaches were largely designed for more static products; that AI systems may evolve, perform differently in different environments and depend upon surrounding data, workflows, people and organisations; and that one-off pre-market assessment will not be sufficient. It calls instead for lifecycle regulation, system-wide responsibility, continuing monitoring, greater transparency and stronger accountability. (GOV.UK)

The same Commission also records that clinicians already perceive themselves to be overly burdened with responsibility for monitoring AI drift and intercepting inaccuracies, while lacking critical information and context necessary to discharge that responsibility properly. (GOV.UK)

The regulatory record therefore contains an increasingly serious contradiction.

The July 2026 AVT position permits clinically consequential transformations of patient information to be treated as administrative and outside medical-device regulation where their declared purpose does not cross the existing medical-purpose threshold.

The September 2026 Commission position simultaneously acknowledges that AI behaviour is contextual, evolving, system-dependent and incapable of being adequately governed solely through conventional static-product assessment.

The central issue is therefore not simply whether one MHRA document uses different language from another.

The issue is whether the public bodies responsible for protecting patients are attempting to regulate modern AI systems using regulatory abstractions that do not adequately correspond to the systems themselves.

A contemporary AVT implementation is not simply “a transcription function” or “a summary function.” It may comprise audio capture, transmission, tokenisation, inference, contextual processing, probabilistic generation, cloud execution, model-provider infrastructure, application-provider infrastructure, logging, telemetry, monitoring, support access, storage, EPR integration and human verification.

The resulting regulatory problem is straightforward:

The visible healthcare function is not necessarily the full computational system that produced the healthcare output.

Similarly:

The place where a clinical record is ultimately stored is not necessarily the place where the underlying confidential clinical information was processed.

And:

A clinician being required to inspect an AI-generated output does not establish that the upstream computation was safe, transparent or correctly governed.

This disclosure therefore examines twenty related failures and contradictions. They are not presented as twenty disconnected criticisms. They collectively concern whether the present public-sector regulatory architecture is sufficiently aligned with the technical architecture it is intended to govern.

2. Breaches          

Classification of “Breach”

For the purposes of this disclosure, a “breach” means an identified failure of regulatory design, governance, assurance, technical alignment or legal compliance arising from the interaction between healthcare AI systems and the public-sector framework intended to govern them.

A breach may therefore fall into one or more of the following classes:
(A) Legal breach — conduct or processing that may be incompatible with a specific statutory, common-law or regulatory duty.
(B) Regulatory breach — a failure, gap or contradiction within the regulatory framework or its application.
(C) Governance breach — a failure of accountability, responsibility, assurance, oversight or risk allocation.
(D) Technical-architectural breach — a mismatch between the system as technically implemented and the system as assumed or described by the regulator.
(E) Safety breach — a condition that may expose patients, clinicians or the healthcare system to avoidable risk.
(F) Transparency / sovereignty breach — a failure of inspectability, provenance, disclosure, jurisdictional control or computational sovereignty.

Classification as a breach in this document does not mean that every item has already been judicially determined to constitute unlawful conduct. The term identifies a prima facie public-interest failure requiring regulatory, legal or technical examination.

Breach 1 – Failure of Public Healthcare Regulation to Map the Actual AI System Architecture

The primary failure arises at the level of regulatory abstraction.

An AI-enabled healthcare function cannot necessarily be assessed accurately by examining only the user-facing function presented to a clinician. A transcription, summary or generated clinical document may be the final output of a much wider computational chain involving third-party models, cloud infrastructure, inference services, prompts, context construction, retrieval systems, logs, telemetry, monitoring services, APIs and support infrastructure.

The September Commission expressly calls for system-wide responsibility and system-level assurance. At the same time, its recommendations continue to contemplate regulatory treatment focused upon particular qualifying medical-device functions within multifunction or general-purpose AI systems. (GOV.UK)

That creates a structural contradiction.

A regulator cannot properly assess system-wide risk while defining the object of regulation more narrowly than the system producing the risk.

Where the underlying model, execution environment, dependencies or shared infrastructure can influence the output, those components are not technically irrelevant merely because the regulated feature is described separately at product level.

The disclosed failure is therefore the use of a regulatory abstraction that may divide a computational system at boundaries that do not exist within the actual architecture.

Evidence

• MHRA, Ambient voice technology-enabled products, published 29 July 2026. MHRA Ambient Voice Technology guidance
• National Commission into the Regulation of AI in Healthcare, Recommendations for a future regulatory framework, published 10 September 2026. National Commission recommendations
• Commission findings concerning lifecycle regulation, system-wide responsibility, foundation-model dependency and system-level assurance. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Principle of Legality
• Common Law – Rationality / Public-Law Reasonableness
• Common Law – Relevant Considerations
• Common Law – Public Accountability
• Medicines and Medical Devices Act 2021
• Medical Devices Regulations 2002
• Health and Social Care Act 2012
• DCB0129 – Clinical Risk Management: its Application in the Manufacture of Health IT Systems
• DCB0160 – Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems
• Human Rights Act 1998 – section 6
• European Convention on Human Rights – Articles 2 and 8

Breach 2 – Clinically Consequential AI Processing Classified as Administrative

MHRA's July AVT guidance expressly provides that generative summarisation of a consultation may not be a medical device where its stated purpose is the administrative documentation of what occurred during the encounter.

It goes further.

The guidance provides an example in which information from a transcript or summary is converted into structured data for problem lists, medication lists, order sets and other forms of clinical documentation. Provided that the clinician reviews and confirms the output and the product is not intended to derive new clinical information, MHRA states that the product does not have a medical purpose and is not a medical device. (GOV.UK)

The difficulty is that regulatory classification does not remove clinical consequence.

An omitted medication, incorrectly transcribed dosage, lost negative, changed chronology, omitted symptom, distorted history or incorrect structured field may affect subsequent clinical understanding even where the system was not intended to diagnose anything.

The regulatory question is therefore being framed around declared purpose while the patient-safety question arises from actual informational consequence.

The disclosed contradiction is:

Administrative purpose does not mean absence of clinical consequence.

Evidence

• MHRA AVT Guidance – Example 2: generative summary of a clinical conversation. (GOV.UK)
• MHRA AVT Guidance – Example 3: conversion of transcripts and summaries into structured clinical information. (GOV.UK)
• MHRA AVT examples concerning generated summaries, letters and EPR-derived information. (GOV.UK)

Legal Frameworks Engaged

• Medicines and Medical Devices Act 2021
• Medical Devices Regulations 2002
• Health and Social Care Act 2008 (Regulated Activities) Regulations 2014 – Regulation 12
• Health and Social Care Act 2008 (Regulated Activities) Regulations 2014 – Regulation 17
• DCB0129
• DCB0160
• UK GDPR – Article 5(1)(d), Accuracy
• Common Law – Duty of Care
• Common Law – Clinical Confidentiality
• Human Rights Act 1998 – section 6
• European Convention on Human Rights – Article 8

Breach 3 – Regulatory Dependence upon Intended Purpose Despite Recognition That Actual Functionality and Risk Matter

The July AVT guidance remains substantially organised around intended purpose and whether a function falls within an existing medical-purpose definition.

The September Commission, however, recognises that future classification needs to be more resilient and sensitive to clinical risk, patient benefit, technological characteristics and lifecycle behaviour. It recommends review and updating of the existing medical-device framework for software and AI-enabled products. (GOV.UK)

The significance is substantial.

A system's declared purpose does not determine the full range of consequences its computation may create.

Where a system transforms patient speech into an authoritative-looking clinical record, the actual functionality, error characteristics, downstream use and degree of reliance are material whether or not the manufacturer states that the system is merely helping with administration.

The disclosed failure therefore lies in the difference between how the product is described and what the computational transformation actually does within a clinical pathway.

Evidence

• MHRA AVT qualification guidance – 29 July 2026. MHRA AVT qualification and classification guidance
• National Commission Recommendation 1 concerning future medical-device definitions and classification. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Rationality
• Common Law – Relevant Considerations
• Common Law – Principle of Legality
• Medicines and Medical Devices Act 2021
• Medical Devices Regulations 2002
• DCB0129
• DCB0160
• Human Rights Act 1998 – section 6

PATIENT AND CLINICIAN SAFETY FAILURES

Breach 4 – Clinician Review Used as the Primary Safety Backstop for AI Error

MHRA repeatedly relies upon clinician review, editing, correction and confirmation when explaining why certain AVT-generated outputs do not require medical-device status.

That reliance establishes something important.

The regulatory architecture itself anticipates that the generated output may require correction.

The clinician is therefore not merely consuming an administrative convenience. The clinician is being placed downstream of a probabilistic computational process and required to determine whether its representation of the consultation is sufficiently accurate to become part of the clinical record.

The resulting chain is:

AI processes consultation → AI produces representation → clinician must identify any error → clinician corrects or confirms output → output enters clinical record.

The existence of the human reviewer does not remove the upstream computational uncertainty. It relocates the point at which the uncertainty must be detected.

The September Commission reinforces this concern by recording that many clinicians already feel overly burdened with responsibility for monitoring drift and intercepting AI inaccuracies while lacking critical information and context. (GOV.UK)

Evidence

• MHRA AVT Guidance – repeated requirement for clinician review, editing, correction and confirmation. (GOV.UK)
• National Commission findings concerning clinician responsibility for drift and interception of inaccuracies. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Duty of Care
• Health and Social Care Act 2008 (Regulated Activities) Regulations 2014 – Regulation 12
• Regulation 17 – Good Governance
• Regulation 18 – Staffing
• DCB0129
• DCB0160
• Health and Safety at Work etc. Act 1974
• Management of Health and Safety at Work Regulations 1999

Breach 5 – Claimed Reduction in Administrative Burden While Creating a Second Verification Burden

The policy case for AVT repeatedly relies upon the proposition that automated transcription and summarisation can reduce administrative workload and release clinician time.

That proposition cannot be established merely by measuring how quickly a machine produces text.

The clinician must first conduct the consultation, listen to the patient, assess symptoms, consider history, perform clinical reasoning and determine the appropriate response.

The same clinician may then be required to read an AI-generated reconstruction of that encounter, compare it against what actually occurred, detect omissions or substitutions, inspect generated structured data, correct errors and assume professional responsibility for the resulting record.

The relevant workload is therefore not simply:

manual documentation compared with automated documentation.

It is also:

clinical encounter plus machine-output verification compared with the previous clinical documentation process.

The September Commission's own finding that clinicians feel overly burdened by responsibility for intercepting inaccuracies directly engages that issue. (GOV.UK)

Evidence

• MHRA press release stating that AVT is intended to streamline work and support safe adoption. (GOV.UK)
• MHRA requirement for clinician review and correction. (GOV.UK)
• Commission evidence concerning clinician burden in monitoring drift and intercepting inaccuracies. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Duty of Care
• Health and Social Care Act 2008 Regulations – Regulations 12, 17 and 18
• DCB0129
• DCB0160
• Health and Safety at Work etc. Act 1974
• Management of Health and Safety at Work Regulations 1999

Breach 6 – Medical-Device Exclusion Without Demonstrated Error-Free Transcription or Summarisation

The MHRA guidance does not establish that generative transcription or summarisation is 100 per cent accurate.

Indeed, its repeated requirement for clinician correction is incompatible with any assumption of perfect accuracy.

Nevertheless, the error potential of the transformation does not itself determine whether the product becomes a medical device.

The resulting distinction is legally and technically significant.

Not classified as a medical device does not mean demonstrated to be clinically error-free.

Those are entirely different propositions.

Where the output is subsequently incorporated into the patient record, the accuracy of that representation remains clinically and legally material irrespective of its device classification.

Evidence

• MHRA AVT Guidance – clinician review and correction requirements. (GOV.UK)
• National Commission findings that AI performance may be context-dependent and require continuing monitoring. (GOV.UK)

Legal Frameworks Engaged

• Medical Devices Regulations 2002
• Medicines and Medical Devices Act 2021
• DCB0129
• DCB0160
• UK GDPR – Article 5(1)(d), Accuracy
• Health and Social Care Act 2008 Regulations – Regulation 12
• Common Law – Duty of Care

Breach 7 – Failure to Address Longitudinal Clinical Record Integrity

A clinical consultation does not exist in isolation.

Its meaning may depend upon previous symptoms, earlier consultations, existing medication, diagnostic history, prior investigations, changes over time and information already contained within the patient's longitudinal record.

A generative system may produce a linguistically coherent summary of an individual encounter while failing to preserve all of that continuity.

A plausible output is therefore not necessarily a complete output.

The clinician asked to verify the summary may themselves have limited time and may not immediately detect an omitted variable where the generated narrative remains superficially coherent.

The September Commission acknowledges that AI performance depends upon data, workflow, people and context. That recognition must also apply to clinical chronology and longitudinal state. (GOV.UK)

Evidence

• MHRA AVT functions involving generative summarisation, structured data and EPR-derived information. (GOV.UK)
• National Commission recognition of contextual dependence and deployment sensitivity. (GOV.UK)

Legal Frameworks Engaged

• UK GDPR – Article 5(1)(d), Accuracy
• DCB0129
• DCB0160
• Health and Social Care Act 2008 Regulations – Regulations 12 and 17
• Common Law – Duty of Care
• Common Law – Clinical Confidentiality
• Human Rights Act 1998 – Article 8 ECHR

TRANSPARENCY AND BLACK-BOX COMPUTATION

Breach 8 – Regulatory Demand for Transparency While Critical Computation May Remain Proprietary

The September Commission places trust, transparency and predictability at the centre of the future regulatory framework.

It expressly records that transparency in how an AI product works and interpretability of its outputs will be important to patient trust. (GOV.UK)

That creates a technical problem where the clinical output is generated through proprietary foundation-model infrastructure.

A public description of a model, a model card, benchmark data, vendor assurance documentation or user-interface warning can provide information about the system.

They are not necessarily equivalent to direct visibility into the computational process responsible for a particular disputed output.

The central question is therefore:

What level of computational access does the regulator actually possess when it is required to determine why a particular clinical output was generated?

Where the answer stops at a proprietary model boundary, transparency may exist around the computation without providing complete inspectability of the computation itself.

Evidence

• National Commission Chapter 3 – Trust, Transparency and Predictability. (GOV.UK)
• Recommendation 9 – transparent information for users and the public. (GOV.UK)
• Recommendation 35 – patient transparency and trust. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Public Accountability
• Common Law – Rationality
• UK GDPR – Article 5(1)(a), Lawfulness, Fairness and Transparency
• UK GDPR – Article 5(2), Accountability
• UK GDPR – Articles 12, 13, 14 and 15
• Data Protection Act 2018
• Data (Use and Access) Act 2025
• DCB0129
• DCB0160
• Human Rights Act 1998 – section 6
• European Convention on Human Rights – Article 8

Breach 9 – Explainability Required Without Defining Causal Traceability Through LLM Computation

The Commission states that patients should have confidence that AI systems are transparent and explainable at an appropriate level. (GOV.UK)

The phrase “at an appropriate level” requires much greater technical precision where large language models are involved.

A transformer-based language model receives tokenised input and produces output through multiple layers of learned weighted computation. The generated text represents the result of that process.

A general explanation that the product “summarises consultations” does not answer why one particular symptom was omitted, one medication changed, one chronology altered or one phrase generated.

The regulatory concept of explainability therefore needs to distinguish between:

• explanation of intended function;
• explanation of model architecture;
• explanation of known limitations;
• reconstruction of inputs and system configuration;
• reconstruction of tool and retrieval activity;
• and causal investigation of the actual erroneous output.

Without that distinction, “explainability” risks functioning as a broad policy term rather than a technically defined safety requirement.

Evidence

• National Commission transparency and explainability findings. (GOV.UK)
• Recommendation 9 concerning model cards, user-centred interfaces and dynamic labelling. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Rationality
• Common Law – Relevant Considerations
• Common Law – Public Accountability
• UK GDPR – transparency and accountability principles
• DCB0129
• DCB0160
• Health and Social Care Act 2008 Regulations – Regulation 17

Breach 10 – Model Cards and Master Files Cannot Automatically Substitute for Computational Inspectability

The Commission proposes model cards, benchmarks, internal guardrails, Master Files and firewalled mechanisms for providing additional information concerning underlying technology. (GOV.UK)

Those mechanisms may provide valuable regulatory evidence.

They must not, however, be confused with direct computational inspectability.

A model card can describe how a model was developed, its intended uses, tested performance and known limitations.

A Master File can provide additional confidential technical information to regulators.

Neither proposition by itself establishes that a patient-level error can be reconstructed fully through the underlying proprietary computation.

The disclosed issue is therefore not that model cards or Master Files are useless.

It is that documentation about a computational system is not necessarily equivalent to the ability to interrogate the computation that produced the disputed result.

Evidence

• National Commission Recommendation 5 concerning Master Files, model cards, internal guardrails and firewalled information mechanisms. (GOV.UK)
• Recommendation 9 concerning transparency mechanisms. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Public Accountability
• Common Law – Rationality
• DCB0129
• DCB0160
• UK GDPR – Article 5(2)
• Health and Social Care Act 2008 Regulations – Regulation 17
• Medicines and Medical Devices Act 2021

DOCTOR-PATIENT CONFIDENTIALITY, COMPUTE AND DATA SOVEREIGNTY

Breach 11 – Failure to Distinguish Clinical Data Storage from Clinical Data Execution

Doctor-patient confidentiality is engaged by the disclosure and processing of the confidential clinical conversation itself.

The relevant event is not restricted to where the final transcript is stored.

An AVT pathway may comprise:

Doctor-patient conversation → audio capture → transmission → transcription/inference computation → generated transcript or summary → clinician review → EPR storage.

The critical confidentiality stage occurs before the final storage event.

If the consultation is transmitted into third-party computational infrastructure for transcription or inference, confidential clinical information has already entered that processing environment.

The fact that the resulting transcript is subsequently stored within a UK NHS record does not answer where the consultation was actually computed.

The distinction is therefore fundamental:

Data storage is not data execution.

And:

UK data residency does not by itself establish UK computational sovereignty.

Evidence

• MHRA AVT Guidance establishing that AVT systems process clinician-patient conversations to create transcripts and summaries. (GOV.UK)
• National Commission recognition of interconnected data pipelines, deployment platforms and external dependencies. (GOV.UK)

Legal Frameworks Engaged

• Common-Law Duty of Confidentiality
• UK GDPR – Article 5
• UK GDPR – Article 6
• UK GDPR – Article 9
• UK GDPR – Article 25
• UK GDPR – Article 32
• UK GDPR – Article 35
• Data Protection Act 2018
• Data (Use and Access) Act 2025
• Human Rights Act 1998 – section 6
• European Convention on Human Rights – Article 8
• International Covenant on Civil and Political Rights – Article 17
• Convention 108+

Breach 12 – Foreign Compute and Telemetry Not Resolved by UK Storage of the Final Clinical Record

Where a consultation is processed through externally controlled infrastructure, the relevant data flow may extend beyond the final transcript.

Potential processing artefacts can include raw or buffered audio, transcript fragments, tokenised representations, prompts, generated outputs, embeddings, application logs, model logs, performance metrics, telemetry, error reports, audit events and support-access records.

The legally relevant questions are therefore not limited to where the final clinical document resides.

They include:

• Which entity receives the consultation data?
• Where is inference actually executed?
• Which cloud or model provider performs the computation?
• Which subprocessors participate?
• What patient-derived information is logged?
• What telemetry is transmitted?
• What support or debugging access exists?
• What is retained after inference?
• What international-transfer mechanism applies?
• Which foreign jurisdictions may exercise legal authority over the provider or infrastructure?

Without answers to those questions, a claim of UK data residency does not establish that the confidential clinical information remained within UK-controlled computation.

Evidence

• National Commission acknowledgement of external-provider foundation-model dependency and sovereignty risk. (GOV.UK)
• Commission requirement for greater transparency concerning model provenance, dependencies, related risks and controls. (GOV.UK)

Legal Frameworks Engaged

• Common-Law Duty of Confidentiality
• UK GDPR – Chapter V, International Transfers
• UK GDPR – Articles 5, 6, 9, 13, 14, 25, 32 and 35
• Data Protection Act 2018
• Data (Use and Access) Act 2025
• Human Rights Act 1998
• European Convention on Human Rights – Article 8
• International Covenant on Civil and Political Rights – Article 17
• Convention 108+

Breach 13 – Sovereignty Risk Acknowledged While External Foundation-Model Dependency Remains Accepted

The September Commission expressly recognises that increasing numbers of AI healthcare products may depend upon a relatively small number of external foundation-model providers and states that this creates resilience challenges and a sovereignty risk where those models are owned outside the United Kingdom. (GOV.UK)

That is a significant public admission.

The proposed response, however, is substantially based upon increased transparency concerning provenance, dependency, risk controls, procurement terms and regulatory information.

Those measures may improve visibility.

They do not necessarily remove the underlying dependency.

A health system can know that it depends upon an external proprietary model and still remain dependent upon that model.

The relevant distinction is:

Disclosure of dependency is not removal of dependency.

Similarly:

Knowledge of foreign ownership is not sovereign control of execution.

Evidence

• National Commission discussion of foundation-model dependency and sovereignty risk. (GOV.UK)
• Recommendations concerning disclosure of foundation-model provenance, risks, dependencies and continuity planning. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Public Accountability
• Common Law – Rationality
• Common Law – Relevant Considerations
• UK GDPR
• Data Protection Act 2018
• Data (Use and Access) Act 2025
• DCB0129
• DCB0160
• Health and Social Care Act 2012
• Human Rights Act 1998 – Article 8 ECHR

LIFECYCLE AND SYSTEMIC REGULATORY FAILURE

Breach 14 – Lifecycle Regulation Required for AI While Certain AVT Functions Remain Outside Medical-Device Lifecycle Regulation

The September Commission concludes that regulatory arrangements designed principally around static products and one-off assessment are inadequate for modern AI.

It expressly recommends continuing oversight across development, deployment, monitoring, updating and real-world use. (GOV.UK)

The July AVT guidance, however, excludes certain transcription, summarisation and structured-data functions from medical-device status altogether where they do not have the relevant intended medical purpose. (GOV.UK)

That creates a regulatory gap.

The September framework recognises that AI needs lifecycle assurance precisely because performance may change according to context and deployment conditions.

Yet a clinically consequential generative function can remain outside the medical-device lifecycle because of how its purpose is categorised.

The disclosed contradiction is therefore:

The architecture creates lifecycle risk, while classification can determine that the same function does not enter the corresponding medical-device lifecycle regime.

Evidence

• MHRA AVT Guidance – non-medical-device examples. (GOV.UK)
• National Commission Recommendation 5 and executive summary concerning lifecycle-based evidence and oversight. (GOV.UK)

Legal Frameworks Engaged

• Medicines and Medical Devices Act 2021
• Medical Devices Regulations 2002
• DCB0129
• DCB0160
• Health and Social Care Act 2008 Regulations – Regulations 12 and 17
• Common Law – Rationality
• Common Law – Relevant Considerations

Breach 15 – System-Wide Assurance Required While Oversight Remains Functionally Fragmented

The Commission expressly states that the future healthcare AI framework must operate at a system-wide level.

That proposition recognises that AI safety cannot be understood solely by examining isolated products.

Healthcare AI may depend upon interconnected data systems, external providers, foundation models, deployment platforms, clinical workflows, human operators and other AI-enabled products.

Nevertheless, the regulatory framework continues to distinguish individual functions according to medical-device qualification.

The result is an unresolved tension between system-wide assurance and function-level regulatory boundaries.

Where multiple functions share the same model, weights, inference infrastructure, provider, update cycle or telemetry architecture, separating them legally does not necessarily separate them technically.

Evidence

• National Commission executive summary – system-wide responsibility and assurance. (GOV.UK)
• National Commission discussion of interconnected pipelines and foundation-model dependencies. (GOV.UK)
• MHRA AVT qualification examples. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Rationality
• Common Law – Relevant Considerations
• Medicines and Medical Devices Act 2021
• Medical Devices Regulations 2002
• Health and Social Care Act 2012
• DCB0129
• DCB0160
• Health and Social Care Act 2008 Regulations – Regulation 17

Breach 16 – Common-Model Systemic Risk Cannot Be Fully Assessed Through Individual Feature Classification

The Commission recognises that increasing numbers of healthcare AI products may become critically dependent upon a comparatively small number of foundation models and states that cumulative exposure should be monitored at system level. (GOV.UK)

That admission is incompatible with any assumption that healthcare AI risk exists solely at individual feature level.

If numerous products depend upon one underlying model or provider, a defect, update, architectural change, outage, security compromise or systematic model behaviour may propagate across multiple products simultaneously.

The common dependency is therefore itself part of the risk architecture.

Regulating the individual feature without sufficient oversight of the shared substrate can consequently obscure common-mode failure.

Evidence

• National Commission discussion of cumulative system-level risk from shared foundation models. (GOV.UK)
• Commission recommendations concerning foundation-model provenance and dependencies. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Rationality
• Common Law – Relevant Considerations
• Common Law – Duty of Care
• Medicines and Medical Devices Act 2021
• DCB0129
• DCB0160
• Health and Social Care Act 2008 Regulations – Regulations 12 and 17

PATIENT AUTONOMY, CONSENT AND ACCOUNTABILITY

Breach 17 – Patient Transparency Is Incomplete Where the Actual Computational Chain Is Not Disclosed

The Commission recommends that healthcare organisations address patients' reasonable expectation of being informed when AI-enabled products are used in their care and of having the ability to opt out where possible or appropriate. (GOV.UK)

That principle becomes substantially more important in the context of AVT.

A patient participating in an apparently ordinary private consultation may reasonably understand that a doctor will make clinical notes.

That is not necessarily the same thing as understanding that speech may be captured, transmitted to computational infrastructure, tokenised, processed through a generative model, logged by one or more providers and transformed into a clinical record.

Meaningful transparency therefore concerns more than simply stating:

“AI is being used.”

It concerns the processing architecture.

At minimum, the patient-information question includes who processes the consultation, for what purpose, what information is transmitted, where it is computed, whether external providers or subprocessors are involved, whether telemetry or logs are created, what is retained and how the output is subsequently used.

Evidence

• National Commission Recommendation 35 – patient transparency and trust. (GOV.UK)
• Commission findings concerning transparency in how AI products work. (GOV.UK)
• MHRA AVT description of systems processing clinician-patient conversations. (GOV.UK)

Legal Frameworks Engaged

• Common-Law Duty of Confidentiality
• UK GDPR – Article 5(1)(a)
• UK GDPR – Articles 12, 13 and 14
• UK GDPR – Articles 6 and 9
• UK GDPR – Article 35
• Data Protection Act 2018
• Human Rights Act 1998 – section 6
• European Convention on Human Rights – Article 8
• International Covenant on Civil and Political Rights – Article 17
• Convention 108+

Breach 18 – Human Oversight Does Not Resolve Allocation of Upstream Computational Fault

The July AVT architecture places the clinician downstream of the generative system as reviewer and corrector.

That does not determine responsibility where harm arises.

A single erroneous clinical output may potentially involve:

foundation-model provider → cloud provider → AVT supplier → NHS deploying organisation → clinician → patient.

A requirement that the clinician review the output does not identify which component created the original defect.

Nor does it answer what information the clinician had available to identify it.

The September Commission's emphasis upon accountability therefore exposes a problem already embedded within the July implementation model.

If responsibility cannot be reconstructed across the computational and organisational chain, “human oversight” risks operating as a point of downstream responsibility without sufficient upstream fault attribution.

Evidence

• MHRA requirement for clinician review and confirmation. (GOV.UK)
• National Commission emphasis upon accountability and system-wide responsibility. (GOV.UK)
• Commission evidence that clinicians report insufficient information and context when expected to intercept inaccuracies. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Negligence / Duty of Care
• Common Law – Public Accountability
• Health and Social Care Act 2008 Regulations – Regulations 12, 17 and 20
• DCB0129
• DCB0160
• UK GDPR – Article 5(2), Accountability
• Medicines and Medical Devices Act 2021

REGULATORY LANGUAGE AND TECHNICAL COMPETENCE

Breach 19 – Use of “Level of Autonomy” Without First Establishing a Sufficiently Precise Computational Meaning

The Commission recommends that model-card transparency should include information concerning the “level of autonomy of the device.” (GOV.UK)

The difficulty arises before so-called agentic AI systems are even considered.

An ordinary generative language model already requires clear technical description.

A conventional LLM receives input, tokenises that input, applies learned weighted transformations across the model and generates a probabilistically selected sequence of output tokens.

That operation must be distinguished from the wider architecture that may subsequently give a system operational authority to take actions.

Triggers, external memory, tool use, planning loops, API permissions and unsupervised execution can create additional operational capability.

They are not the same thing as ordinary model inference.

The regulatory framework therefore needs first to establish what is being measured before referring to a “level of autonomy.”

Otherwise the term risks grouping fundamentally different technical properties under a single regulatory label.

The problem is not academic terminology.

If autonomy becomes relevant to risk classification, evidence, procurement or safety controls, an imprecise definition can produce an imprecise risk assessment.

Evidence

• National Commission Recommendation 9 / model-card transparency provisions referring to the level of autonomy of the device. (GOV.UK)
• Commission wider discussion of emerging AI technologies. (GOV.UK)

Legal Frameworks Engaged

• Common Law – Rationality
• Common Law – Relevant Considerations
• Common Law – Public Accountability
• Medicines and Medical Devices Act 2021
• Medical Devices Regulations 2002
• DCB0129
• DCB0160
• Health and Social Care Act 2008 Regulations – Regulation 17

Breach 20 – Regulatory Discontinuity Between June Risk Recognition, July AVT Assurance and September Reform

The chronology is itself material.

On 29 July 2026, MHRA stated that its new guidance, produced with NHS England, would provide developers, suppliers and NHS organisations with the clarity required to adopt AVT tools “safely and with confidence.” (GOV.UK)

On 10 September 2026, the National Commission published recommendations stating that current approaches were largely designed for more static products, that one-off pre-market assessment would not be enough for AI, and that regulation must become more lifecycle-based and system-wide. (GOV.UK)

The Commission is advisory and its September recommendations do not themselves revoke the July guidance. A cross-government response is still to follow. (GOV.UK)

That does not remove the contradiction.

Rather, it creates a question concerning the evidential basis upon which confidence in AVT adoption was publicly expressed while fundamental questions concerning AI classification, lifecycle assurance, system-wide risk, transparency, foundation-model dependency and clinician burden remained sufficiently unresolved that a new national framework was already being developed.

The relevant regulatory sequence is therefore:

Existing AI regulatory architecture identified as requiring reform → AVT guidance issued to support adoption → six weeks later national recommendations call for lifecycle, transparency and system-wide regulatory reconstruction.

The issue is not that regulation cannot evolve.

Regulation should evolve where evidence requires it.

The public-interest question is whether the assurance language used during deployment adequately reflected the uncertainty and architectural deficiencies already present within the underlying regulatory framework.

Evidence

• MHRA, Ambient voice technology-enabled products, 29 July 2026. MHRA AVT publication page
• MHRA, MHRA clarifies regulatory status of ambient voice technologies used in the NHS, 29 July 2026. MHRA AVT press release
• National Commission into the Regulation of AI in Healthcare, Recommendations for a future regulatory framework, 10 September 2026. National Commission report
• MHRA press release concerning publication of the Commission recommendations, 10 September 2026. Commission recommendations press release

Legal Frameworks Engaged

• Common Law – Principle of Legality
• Common Law – Rationality / Public-Law Reasonableness
• Common Law – Relevant Considerations
• Common Law – Public Accountability
• Medicines and Medical Devices Act 2021
• Medical Devices Regulations 2002
• Health and Social Care Act 2012
• Health and Social Care Act 2008 (Regulated Activities) Regulations 2014
• DCB0129
• DCB0160
• Human Rights Act 1998 – section 6
• European Convention on Human Rights – Articles 2 and 8
• Nolan Principles of Public Life – Objectivity, Accountability, Openness and Leadership

3. Legal Frameworks Engaged

The frameworks below consolidate the public-law duties, medical-device legislation, healthcare safety requirements, clinical-risk standards, information-governance obligations, confidentiality rules, Convention rights and public-sector accountability principles engaged by the twenty breach sections above.

The central legal issue is not that every identified architectural deficiency automatically constitutes a separately adjudicated statutory offence. Rather, the disclosure identifies a cumulative regulatory architecture in which classification, clinical consequence, computational execution, confidentiality, traceability, clinician responsibility, foreign-model dependency and public-sector assurance intersect.

Accordingly, the frameworks below distinguish between direct legal duties, regulatory requirements, common-law principles, NHS information standards and international or ethical supervisory standards.

I. Common Law — Principle of Legality

Authority / Verbatim

In R v Secretary of State for the Home Department, ex parte Simms [2000] 2 AC 115, Lord Hoffmann stated:

“Fundamental rights cannot be overridden by general or ambiguous words.” (Bailii)

Legal Duty

The principle of legality is a rule of statutory interpretation protecting fundamental rights against interference through vague or general statutory language. Parliament may legislate contrary to fundamental rights, but the courts ordinarily require clear language before construing legislation as authorising such interference. (Bailii)

It is therefore not itself a general freestanding prohibition upon regulatory error. Its relevance here arises where statutory powers governing healthcare technology, patient confidentiality, medical-device regulation or data processing are interpreted or exercised in ways capable of interfering with established rights without sufficiently clear legislative authority.

Breach Identified

The disclosure identifies regulatory treatment under which confidential doctor-patient conversations may be captured, transformed through generative computation and incorporated into clinical records while significant parts of that computational chain can remain outside medical-device regulation.

Where that architecture engages confidentiality, informational privacy and patient autonomy, the Principle of Legality is relevant to whether broad regulatory powers or classifications are being treated as sufficient authority for interference with fundamental rights that Parliament has not clearly authorised.

II. Common Law — Rationality / Public-Law Reasonableness

Authority / Verbatim

In Associated Provincial Picture Houses Ltd v Wednesbury Corporation [1948] 1 KB 223, Lord Greene MR stated that intervention may arise where a decision is:

“so unreasonable that no reasonable authority could ever have come to it”. (Bailii)

Modern authority additionally recognises process irrationality where reasoning contains a serious evidential, logical or methodological defect. (Bailii)

Legal Duty

A public regulator must exercise statutory powers rationally. The court is not concerned with replacing the regulator's technical judgment merely because another conclusion was possible.

The legal question is whether the decision falls within the range of lawful and rational decisions and whether the reasoning process is coherent, evidence-based and free from material logical or methodological defect.

Breach Identified

The disclosure identifies a potential mismatch between the regulatory object and the technical object.

An AVT function can be classified according to intended purpose while the actual output arises through a wider architecture involving capture, transmission, foundation-model inference, cloud infrastructure, APIs, telemetry, logging, support access and EPR integration.

The rationality issue is therefore whether it is technically and evidentially coherent to provide system-level safety assurance where material elements of the system producing the clinical output fall outside the regulatory abstraction being assessed.

The disclosure does not assert that disagreement with MHRA establishes Wednesbury irrationality. It identifies an architectural question capable of engaging rationality where the assumed system boundary does not correspond to the actual computational system.

III. Common Law — Relevant and Irrelevant Considerations

Authority / Verbatim

The Court of Appeal in Wednesbury expressly recognised that a public authority may be reviewed where it has:

“refused to take into account or neglected to take into account matters which they ought to take into account.” (Bailii)

Legal Duty

A statutory decision-maker must consider matters legally and materially relevant to the exercise of its powers and must not allow legally irrelevant considerations to determine the result.

The precise mandatory considerations depend upon the statutory scheme, but public-law reasoning must address matters that legislation requires or that are so obviously material to the decision that failure to consider them may render the decision unlawful.

Breach Identified

The disclosure identifies the following potentially material considerations:

• actual inference location;
• underlying foundation-model provider;
• model/version dependency;
• telemetry and logging;
• subprocessors;
• external support access;
• model updates;
• computational jurisdiction;
• common-mode model dependency;
• clinician verification burden;
• longitudinal record integrity; and
• the distinction between final record storage and upstream execution.

Where safety or regulatory assurance is expressed without adequately accounting for technically material parts of that execution chain, the question arises whether all relevant considerations have in fact been incorporated into the regulatory decision.

IV. Common-Law Duty of Confidentiality — Clinical Confidentiality

Authority / Verbatim

The common-law duty of confidentiality protects information imparted in circumstances importing an obligation of confidence. In healthcare, confidential information obtained through the doctor-patient relationship is subject to particularly strong protection.

Legal Duty

Confidential patient information should not ordinarily be used or disclosed outside the circumstances in which it was provided unless there is:

• consent;
• another sufficient legal basis or statutory authority; or
• an overriding public-interest justification recognised by law.

The obligation concerns use and disclosure, not merely the final storage location of the resulting record.

Breach Identified

AVT makes this distinction central.

The relevant chain can be:

private consultation → capture → transmission → external computation → model inference → generated record → clinician verification → EPR storage

The confidential information has therefore been processed before the final clinical record exists.

The disclosure consequently identifies an unresolved confidentiality question wherever assurances concerning UK storage do not establish where, by whom and under whose authority the original confidential interaction was computationally processed.

This is the legal basis for the disclosure's distinction:

Data storage is not data execution.

V. Medicines and Medical Devices Act 2021

Authority

The Medicines and Medical Devices Act 2021 provides the statutory framework through which regulations concerning medical devices may be made and amended, including powers concerned with device safety and availability.

Legal Duty

The Act operates primarily as an enabling legislative framework rather than as a standalone cause of action establishing liability for every software or AI failure.

Its relevance lies in the exercise of regulatory authority over the medical-device regime and the requirement that the regulatory system created under those powers serve the statutory purposes governing safe medical technologies.

Breach Identified

The disclosure identifies a structural question concerning the boundary between medical-device regulation and clinically consequential AI functions characterised as administrative.

Where generative summarisation, clinical-document transformation or structured-data generation materially affects the clinical record while remaining outside medical-device classification, the question is whether the statutory regulatory architecture remains sufficiently adapted to the safety consequences of contemporary AI.

That question is particularly significant because the September Commission itself recommends modernisation of the existing framework for software and AI-enabled technologies.

VI. Medical Devices Regulations 2002 — Intended Purpose and Medical-Device Classification

Authority / Verbatim

The Medical Devices Regulations define “intended purpose” by reference to:

“the use to which the device is intended according to the data supplied by the manufacturer”. (Legislation.gov.uk)

The Regulations similarly define a medical device by reference to purposes including diagnosis, prevention, monitoring and treatment. (Legislation.gov.uk)

Legal Duty

The present regulatory scheme consequently attaches considerable significance to the manufacturer's intended purpose when determining whether software falls within medical-device regulation.

The Regulations do not, however, establish that software falling outside medical-device status is therefore clinically harmless, error-free or outside all other safety and legal obligations.

Breach Identified

This distinction is central to Breaches 2, 3, 6, 14 and 15.

The MHRA AVT approach may classify generative documentation functions as non-medical where their intended purpose remains administrative and the clinician subsequently confirms the output.

The disclosure identifies the resulting distinction:

Administrative purpose does not mean absence of clinical consequence.

An omitted medication, changed dosage, altered chronology, lost negative or omitted symptom can affect subsequent clinical care regardless of whether the software was marketed as performing diagnosis.

The legal issue is therefore not that MHRA has ignored the present Regulations; rather, it is whether the existing statutory classification mechanism adequately captures the clinical risk created by contemporary generative processing.

VII. Health and Social Care Act 2012 — Digital Clinical-Safety Standards

Authority

NHS England states that digital clinical safety is established within the statutory information-standards architecture under section 250 of the Health and Social Care Act 2012 and that DCB0129 and DCB0160 provide the applicable clinical-risk-management standards. (NHS England)

Legal Duty

The statutory information-standards framework provides the legal infrastructure within which national clinical-safety standards are issued and applied.

Subsequent legislation, including the Health and Care Act 2022 and Data (Use and Access) Act 2025, has strengthened the mechanisms by which information standards can apply across healthcare organisations and technology providers. (NHS England)

Breach Identified

AVT cannot therefore be treated exclusively as a medical-device-classification question.

Even where a function is outside medical-device regulation, the clinical-risk consequences of the health IT system remain capable of engaging the NHS digital clinical-safety architecture.

The disclosure's system-wide argument therefore maps directly onto the statutory information-standard framework.

VIII. DCB0129 — Clinical Risk Management in the Manufacture of Health IT Systems

Authority / Verbatim

NHS England states:

“DCB0129 defines clinical risk management requirements for manufacturers of health IT systems”. (NHS England)

NHS England further explains that manufacturers are expected to implement proportionate clinical-risk processes, maintain safety documentation and appoint a Clinical Safety Officer. (NHS England)

Legal Duty

DCB0129 requires systematic clinical-risk management during the manufacture and maintenance of health IT.

The process includes identifying hazards, assessing risks, documenting controls and constructing the clinical safety case supporting safe release.

Breach Identified

The disclosure identifies hazards that cannot necessarily be understood by considering the visible AVT application alone.

Where safety depends upon:

AVT supplier → cloud infrastructure → model provider → inference service → integration layer → clinician

the manufacturer's clinical-risk analysis must accurately represent the dependencies capable of causing or amplifying clinical harm.

A safety case that stops at the application interface while material model or infrastructure dependencies remain outside the analysed boundary risks creating an incomplete hazard model.

IX. DCB0160 — Clinical Risk Management in Deployment and Use

Authority / Verbatim

NHS England describes DCB0160 as establishing:

“clinical risk management requirements for care organisations that deploy and use health IT systems.” (NHS England)

Legal Duty

The deploying health or care organisation must assess and manage the risks arising from implementation and use within its particular clinical environment.

NHS England expressly explains that the deploying organisation must understand the manufacturer's DCB0129 assessment and then perform its own deployment-level assessment. (NHS England)

Breach Identified

This directly engages the disclosure's clinician-burden and system-boundary analysis.

A healthcare organisation cannot meaningfully assess deployment risk unless it knows enough about:

• upstream computation;
• known failure modes;
• model changes;
• data flows;
• provider dependencies;
• telemetry;
• operational controls; and
• escalation mechanisms.

If those elements are unavailable because they sit behind proprietary or external infrastructure, the deploying organisation may be required to assure a system for which it possesses incomplete technical visibility.

X. Health and Social Care Act 2008 (Regulated Activities) Regulations 2014 — Regulation 12: Safe Care and Treatment

Authority

Regulation 12 requires regulated care and treatment to be provided safely, including through assessment of risks and taking reasonably practicable steps to mitigate identified risks.

Legal Duty

Registered providers must identify and manage risks affecting the health and safety of service users.

The duty is concerned with the practical delivery of safe care and is not extinguished simply because a particular digital function falls outside medical-device classification.

Breach Identified

Where an AI-generated summary or structured clinical record may contain omission, substitution or distortion, the deployment architecture must contain sufficient controls to prevent those errors creating avoidable clinical harm.

Clinician review may form one control.

The disclosure's challenge is that clinician review cannot itself establish that all upstream risks have been identified or controlled.

XI. Health and Social Care Act 2008 Regulations — Regulation 17: Good Governance

Authority

Regulation 17 requires providers to operate effective systems and processes for assessing, monitoring and improving the quality and safety of regulated activities and for assessing and mitigating risks.

Legal Duty

Governance must therefore be evidential rather than merely declaratory.

Providers require systems capable of showing:

• what technology was used;
• what risks existed;
• what controls applied;
• what incidents occurred;
• what information was processed;
• and how safety performance was monitored.

Breach Identified

AVT based upon external generative infrastructure raises a direct governance question where the organisation cannot fully reconstruct:

input → model/version → retrieval/context → inference → output → modification → clinical record

The disclosure therefore treats traceability and computational provenance as governance requirements rather than optional technical detail.

XII. Regulation 18 — Staffing

Authority

Regulation 18 requires sufficient numbers of suitably qualified, competent, skilled and experienced persons to be deployed in the provision of regulated activities.

Legal Duty

Where staff are expected to operate or supervise technologies that introduce new safety tasks, the organisation must ensure the workforce is capable of performing those functions.

Breach Identified

The MHRA AVT model repeatedly relies upon clinicians identifying and correcting generated inaccuracies.

That creates a genuine operational safety task.

The September Commission itself records concern that healthcare professionals can become burdened with monitoring drift and intercepting inaccuracies without adequate information or context.

The legal question is therefore not simply whether a human remains “in the loop”, but whether the human has the time, information, training and technical visibility necessary to perform the safety function allocated to them.

XIII. Regulation 20 — Duty of Candour

Authority

The statutory duty of candour requires registered providers to act openly and transparently with service users in relation to care and treatment and establishes specific duties where qualifying safety incidents occur.

Legal Duty

The provision concerns disclosure and communication when care has resulted in the relevant harm threshold; it should not be treated as a general requirement to disclose every technical feature of every AI system.

Breach Identified

It nevertheless becomes relevant where an AI-supported clinical process contributes to a notifiable safety incident.

Meaningful candour may require the provider to know whether AI was involved, what output it produced, which version operated and how the output influenced subsequent care.

Without execution provenance, even the factual reconstruction necessary for candour may become difficult.

XIV. UK GDPR — Article 5: Principles Relating to Processing

Authority / Verbatim

Article 5 requires personal data to be processed:

“lawfully, fairly and in a transparent manner”.

It further requires personal data to be:

“accurate and, where necessary, kept up to date”.

Article 5(2) makes the controller responsible for, and capable of demonstrating, compliance.

Legal Duty

Healthcare-AI processing must therefore remain lawful, fair, transparent, purpose-bound, appropriately minimised, accurate, retained appropriately and protected.

Accuracy is particularly significant where generative AI transforms patient speech into a clinical document rather than simply storing the original information unchanged.

Breach Identified

A generated clinical record creates a new accuracy problem.

The source consultation may be accurate while the machine-generated representation is not.

The disclosure therefore identifies a potential chain:

accurate patient statement → inaccurate AI transformation → clinician fails to detect error → inaccurate clinical record

Classification outside medical-device regulation does not remove the Article 5 accuracy obligation.

XV. UK GDPR — Articles 6 and 9: Lawful Processing and Health Data

Authority

Article 6 requires processing to have an applicable lawful basis.

Article 9 imposes additional conditions upon processing special-category personal data, including data concerning health.

UK GDPR defines data concerning health as information relating to physical or mental health that reveals information about a person's health status. (Legislation.gov.uk)

Legal Duty

Healthcare processing therefore requires both:

Article 6 lawful basis

and, where special-category data are processed,

an applicable Article 9 condition.

Consent is not the only basis available in healthcare, and NHS processing frequently relies upon statutory/public-task and health-care provisions.

Breach Identified

AVT necessarily processes highly sensitive information where clinical conversations are captured and transformed.

The relevant compliance question consequently extends beyond the final EPR.

It includes each processing operation involving:

• capture;
• transmission;
• transcription;
• tokenisation;
• inference;
• logging;
• storage;
• telemetry;
• debugging;
• support access; and
• onward processing.

Every component of the execution chain must therefore sit within the lawful processing architecture.

XVI. UK GDPR — Articles 12–15: Transparency and Access

Authority

Articles 12–14 establish transparency and information requirements concerning personal-data processing, while Article 15 establishes the data subject's right of access to personal data and specified information concerning processing.

Legal Duty

Transparency must provide meaningful information about the processing actually occurring.

The obligation cannot necessarily be satisfied merely by saying that “AI is used” if that statement conceals materially different processing relationships involving additional controllers, processors, subprocessors or international execution.

Breach Identified

The disclosure therefore distinguishes:

notification that AI is present

from

transparency about the computational processing of the patient.

For AVT, meaningful transparency can require identification of who processes the consultation, for what purpose, which providers receive information, what is retained and whether patient-derived information leaves the primary NHS environment.

XVII. UK GDPR — Article 25: Data Protection by Design and by Default

Authority / Verbatim

Article 25 requires controllers to implement:

“appropriate technical and organisational measures”

designed to implement data-protection principles effectively and integrate necessary safeguards into processing. (Legislation.gov.uk)

Legal Duty

Data protection must therefore be designed into the processing architecture rather than added solely through policy documentation after deployment.

Article 25 expressly makes the obligation relevant when the means of processing are determined and during the processing itself. (Legislation.gov.uk)

Breach Identified

This directly engages the disclosure's architectural argument.

If confidential NHS information must leave the controlled environment for external proprietary inference before safeguards can operate, then data protection cannot be assessed solely at the storage or user-interface layer.

The relevant design boundary extends to the execution environment itself.

XVIII. UK GDPR — Article 32: Security of Processing

Authority / Verbatim

Article 32 requires:

“appropriate technical and organisational measures to ensure a level of security appropriate to the risk”. (Legislation.gov.uk)

It expressly includes the ongoing confidentiality, integrity, availability and resilience of processing systems and services. (Legislation.gov.uk)

Legal Duty

Security is therefore a property of the complete processing system.

It includes not only database security but also the confidentiality and integrity of the infrastructure through which personal information is transmitted and processed.

Breach Identified

Where AVT relies upon external model endpoints, cloud providers or shared infrastructure, security analysis must follow the patient information through that execution chain.

The fact that the final clinical record is securely stored within an NHS system does not establish the security of every upstream processing operation that produced it.

XIX. UK GDPR — Article 35: Data Protection Impact Assessment

Authority

Article 35 requires a DPIA where processing, particularly involving new technologies, is likely to result in a high risk to individuals' rights and freedoms.

The GDPR framework specifically recognises new technology and large-scale sensitive-data processing as circumstances capable of requiring prior risk analysis. (Legislation.gov.uk)

Legal Duty

A DPIA must examine the nature, scope, context and purposes of processing, assess necessity and proportionality, identify risks and document measures intended to address them.

Breach Identified

An adequate AVT DPIA therefore needs to map the actual data-execution architecture.

A DPIA describing:

patient conversation → NHS record

would be materially different from one accurately recording:

patient conversation → AVT application → cloud infrastructure → foundation model → telemetry/logging → generated content → clinician → NHS record.

The disclosure therefore treats computational mapping as integral to meaningful impact assessment.

XX. UK GDPR — International Transfers / Data (Use and Access) Act 2025

Authority

The Data (Use and Access) Act 2025 substantially amended the UK's international-transfer regime.

Its explanatory material confirms that the UK GDPR continues to regulate transfers of personal data to third countries and establishes revised mechanisms for approved transfers, safeguards and specified derogations. (Legislation.gov.uk)

Legal Duty

The relevant legal question is whether personal data are transferred for processing outside the United Kingdom and, where so, whether the current statutory conditions governing that transfer are satisfied.

The analysis must distinguish corporate ownership from actual international transfer: foreign ownership alone does not establish an unlawful transfer.

Conversely, UK storage alone does not prove that no international processing or transfer takes place.

Breach Identified

This is the foundation of Breach 12.

An AVT architecture may generate:

• audio buffers;
• transcripts;
• prompts;
• tokens;
• outputs;
• logs;
• telemetry;
• embeddings;
• error records; and
• support information.

The relevant question is where each of those objects is processed and which legal entities can access them.

The disclosure therefore does not equate foreign ownership with illegality. It requires the actual processing and transfer architecture to be established.

XXI. Data Protection Act 2018

Authority

The Data Protection Act 2018 forms part of the UK's comprehensive statutory data-protection framework and supplements the UK GDPR. Its legislative purpose includes ensuring that data-protection rights remain effective as advanced processing technologies develop. (Legislation.gov.uk)

Legal Duty

The Act provides domestic statutory machinery governing data protection, regulator powers, exemptions, enforcement and specialised processing regimes.

It must therefore be read with the UK GDPR rather than treated as an alternative to it.

Breach Identified

The disclosure engages the DPA 2018 because the AVT architecture involves automated processing of identifiable health information within public healthcare and potentially across multiple processors and technical systems.

Its relevance is particularly strong where questions arise concerning compliance, enforcement, accountability and the interaction between data subjects and public healthcare controllers.

XXII. Human Rights Act 1998 — Section 6

Authority / Verbatim

Section 6(1) provides:

“It is unlawful for a public authority to act in a way which is incompatible with a Convention right.” (Legislation.gov.uk)

Legal Duty

Public authorities performing public functions must act compatibly with Convention rights unless primary legislation prevents them from acting differently.

The Human Rights Act therefore directly engages public bodies such as NHS organisations and regulatory authorities where their actions fall within the statutory scope.

Breach Identified

The disclosure concerns decisions by public bodies governing the use of AI in publicly delivered healthcare.

The HRA layer therefore arises where regulatory or deployment decisions affect:

• life and physical safety;
• informational privacy;
• clinical confidentiality;
• patient autonomy;
• and respect for private communications.

The Act does not establish that every defect identified in the disclosure is automatically a Convention violation. It establishes the public-authority framework through which Convention compatibility must be assessed.

XXIII. European Convention on Human Rights — Article 8

Authority / Verbatim

Article 8 protects the individual's right to respect for:

“private and family life, his home and his correspondence.”

Legal Duty

Medical information and confidential communications fall within the sphere of private life protected by Article 8.

State interference must have a lawful basis and satisfy the applicable requirements of legitimacy, necessity and proportionality.

Positive obligations may also arise requiring public authorities to provide effective protection for privacy.

Breach Identified

A confidential patient consultation is intrinsically private.

Where speech is captured and transmitted to AI infrastructure, the Article 8 question does not begin only when a transcript is stored.

It begins with the processing of the confidential interaction itself.

The disclosure's sovereignty and execution analysis is therefore directly relevant to determining which entities obtain access to that protected information and under what legal authority.

XXIV. European Convention on Human Rights — Article 2 — Scope-Dependent

Authority / Verbatim

Article 2 provides:

“Everyone's right to life shall be protected by law.”

Legal Duty

Article 2 can impose positive obligations upon public authorities where there is a sufficiently serious and foreseeable risk to life.

It should not be treated as engaged by every software error or every instance of inaccurate clinical documentation.

Breach Identified

Article 2 is therefore scope-dependent within this disclosure.

It may become materially engaged where defective AI processing, systemic failure or inadequate safety controls create a real and sufficiently serious threat to life in a clinical pathway.

For ordinary record inaccuracies or lower-level informational harms, the stronger immediate frameworks are clinical-safety law, negligence, UK GDPR and Article 8.

XXV. Common-Law Negligence / Duty of Care

Authority

The common law requires reasonable care where the applicable conditions for a duty of care are satisfied.

Within clinical care, established professional duties operate alongside statutory patient-safety obligations.

Legal Duty

Reasonable care must be exercised against foreseeable injury.

Where multiple parties contribute to a technological care pathway, attribution depends upon their respective duties, control, knowledge and causal contribution rather than simply upon which person last interacted with the patient.

Breach Identified

This is central to Breach 18.

The relevant chain may involve:

foundation-model provider → cloud provider → AVT manufacturer → healthcare organisation → clinician → patient

Placing a clinician downstream as reviewer does not by itself establish that the clinician created, could identify or could reasonably prevent an upstream computational defect.

The disclosure therefore engages negligence primarily as an allocation-of-responsibility and causation problem, rather than assuming that every AI error automatically establishes negligence.

XXVI. Health and Safety at Work etc. Act 1974

Authority / Verbatim

Section 2 requires every employer, so far as reasonably practicable, to ensure:

“the health, safety and welfare at work of all his employees.” (Legislation.gov.uk)

Legal Duty

The duty includes safe systems of work and necessary information, instruction, training and supervision. (Legislation.gov.uk)

Breach Identified

This framework is engaged by the workforce strand rather than by medical-device classification itself.

Where AVT is deployed specifically to reduce workload but simultaneously imposes an additional continuous verification obligation upon clinicians, the resulting system of work must be assessed realistically.

The relevant comparison is not simply:

manual documentation versus automated documentation

but potentially:

clinical work + AI-output verification + correction + responsibility for missed machine errors.

XXVII. Management of Health and Safety at Work Regulations 1999

Authority

The Regulations require employers to assess risks to employees arising from work activities and implement appropriate preventive and protective measures.

Legal Duty

Risk assessment must address the actual system of work rather than an abstract description of the technology involved.

Breach Identified

Where clinicians are expected to detect hallucination, omission, chronology distortion, medication error or model drift, the organisation must consider the cognitive and operational load created by that responsibility.

This framework therefore supports the disclosure's proposition that a purported administrative-efficiency technology can create a secondary verification workload capable of itself requiring organisational risk assessment.

XXVIII. International Covenant on Civil and Political Rights — Article 17

Authority / Verbatim

Article 17 protects individuals against:

“arbitrary or unlawful interference with his privacy, family, home or correspondence”.

Legal Duty

Article 17 creates an international obligation upon the United Kingdom to protect privacy against arbitrary or unlawful interference.

It is not, by itself, equivalent to a directly incorporated domestic damages cause of action against every processor or supplier.

Breach Identified

The Covenant provides an international privacy framework against which the processing of confidential healthcare conversations can be assessed.

Its relevance is strongest where the architecture creates uncertainty concerning:

• who receives the information;
• where it is processed;
• what is retained;
• and what foreign entities or jurisdictions can obtain control over it.

The directly enforceable domestic analysis remains principally grounded in the UK GDPR, DPA 2018, common-law confidentiality and Article 8/HRA.

XXIX. Convention 108 / Convention 108+ — Data Protection and Automated Processing

Authority

The Council of Europe Convention establishes international principles governing the automated processing of personal data. UK legislative material expressly recognises the United Kingdom's historical participation in Convention 108. (Legislation.gov.uk)

Legal Duty

The Convention operates as an international data-protection framework concerned with lawful processing, data quality, safeguards and protection of individuals in automated data systems.

Its domestic relevance is interpretative and supervisory rather than a substitute for the directly enforceable UK GDPR and Data Protection Act framework.

Breach Identified

AVT is precisely an automated-processing architecture operating upon highly sensitive personal information.

The Convention therefore reinforces the principle that technological transformation of health information remains subject to safeguards throughout processing, rather than protection attaching only to the final stored record.

XXX. Nolan Principles of Public Life — Objectivity, Accountability and Openness

Authority / Verbatim

The Nolan Principle of Objectivity requires public office-holders to act:

“using the best evidence and without discrimination or bias.”

Accountability requires them to submit to necessary public scrutiny.

Openness requires decisions to be made:

“in an open and transparent manner.” (GOV.UK)

Legal Duty

The Nolan Principles are ethical standards of public administration, not standalone statutory causes of action.

They nevertheless apply broadly across public office and public services, including health and care. (GOV.UK)

Breach Identified

They are particularly relevant to the disclosure's final chronology.

The public was told that AVT guidance would support safe and confident adoption while, within weeks, the National Commission published a report identifying the need for substantial reform concerning:

• lifecycle regulation;
• system-wide assurance;
• transparency;
• foundation-model dependency;
• clinician burden;
• accountability; and
• sovereignty.

The public-interest issue is not that evolving regulatory policy is improper.

The issue is whether statements of assurance accurately communicated the degree of known architectural uncertainty existing at the time.

That brings objectivity, accountability and openness directly into the public-governance mapping of the disclosure.

Consolidated Legal Finding

Taken together, these frameworks show why the disclosure cannot properly be reduced to a disagreement over whether a particular AVT feature is technically classified as a medical device.

The legal architecture operates at several levels simultaneously:

Medical-device law asks whether the software falls within the statutory regulatory definition.

Clinical-safety law and DCB0129/DCB0160 ask whether the health IT system and its deployment create adequately identified and controlled clinical risks.

Data-protection law follows the patient's information throughout collection, transmission, transformation, inference, storage and onward processing.

Common-law confidentiality attaches to the confidential clinical information itself rather than only to its final storage location.

Public law asks whether regulatory decisions properly correspond to the evidence, statutory purpose and material characteristics of the technology being regulated.

Human-rights law protects the patient at the level of privacy, confidential communication and, in sufficiently serious circumstances, physical safety.

Employment safety law becomes relevant where the safety architecture reallocates computational uncertainty to clinicians as a continuing verification burden.

International and public-life principles provide additional supervisory standards concerning privacy, transparency, evidence, accountability and public confidence.

The resulting legal architecture therefore mirrors the central technical finding of this disclosure:

The legal character of an AI healthcare system cannot be determined solely from the label attached to its visible function where the underlying computational architecture performs a wider sequence of clinically consequential processing.

The decisive regulatory question is consequently not merely:

What does the product claim to do?

It is also:

What computation actually occurs, upon whose data, under whose control, through which infrastructure, with what clinical consequence, and with what ability to reconstruct responsibility when the output is wrong?

Until those two architectures regulatory and computational correspond, the safety, confidentiality, transparency and accountability problems identified throughout this disclosure remain unresolved.

4. Central Disclosure Finding

The twenty breaches disclosed above arise from one common structural problem.

The regulatory model does not yet map cleanly onto the computational architecture of the systems it is attempting to regulate.

The existing framework divides functions into categories such as medical and administrative, while the underlying computation may operate through shared models, shared weights, common infrastructure, external providers and common failure mechanisms.

It relies upon clinician review as a safeguard while simultaneously acknowledging that clinicians are already burdened by the obligation to identify drift and inaccuracies.

It requires transparency and explainability while accepting technical architectures in which significant components of the underlying computation may remain proprietary.

It recognises sovereignty risk while continuing to contemplate dependency upon externally owned foundation models.

It requires lifecycle and system-wide assurance while maintaining regulatory boundaries that can exclude individual AI functions from medical-device regulation.

It recognises patient expectations of transparency while AVT introduces an additional question that cannot be answered by storage location alone: where, by whom and under whose computational control was the confidential doctor-patient interaction actually processed?

The disclosed issue is therefore not simply whether MHRA has produced imperfect guidance.

It concerns whether public-sector healthcare oversight presently possesses a sufficiently accurate technical model of the systems over which it is exercising regulatory authority.

Where regulatory classification, safety assurance and public representations are founded upon an abstraction that does not accurately correspond to the underlying architecture, the resulting problem moves beyond software design.

It becomes a question of public-law rationality, clinical governance, patient safety, confidentiality, transparency and the lawful exercise of public regulatory responsibility.

The central finding is therefore:

A public healthcare regulator cannot provide coherent assurance over artificial intelligence unless the regulatory architecture first corresponds to the computational architecture actually processing the patient, the consultation and the resulting clinical record.

AI Oversight Gap: System-Wide Risk Versus Function-Only Regulation. Diagram showing the mismatch between the full computational architecture of an AI healthcare system and the narrower feature-level focus of regulation, illustrating how system-wide risk may remain insufficiently captured when oversight is limited to visible functions such as transcription or summarisation.

Storage Is Not Execution: Doctor-Patient Confidentiality Is Engaged Where the Consultation Is Processed. Process diagram showing that confidentiality and sovereignty concerns arise at the point of transcription and inference computation, not merely at the point where the final clinical record is stored, and emphasising the distinction between UK data storage and UK-controlled execution.