Regulating AI in UK Healthcare: Strengths and Gaps in the Government Response to the National Commission (1/3)
Introduction
On 6 October 2026, the Medicines and Healthcare products Regulatory Agency (MHRA) published the Government's response to the National Commission into the Regulation of AI in Healthcare. The MHRA launched the Commission in September 2025, chaired by Professor Alastair Denniston with the Patient Safety Commissioner, Professor Henrietta Hughes, as deputy chair, to recommend how AI in health and care should be regulated in future. The Government has accepted all 44 of its recommendations and states plainly that the current Medical Devices Regulations 2002 are no longer fit for purpose for AI. Most of the detail, however, is still to come: a cross-system Programme Board will publish an implementation roadmap by Spring 2027, and only two commitments carry firm dates before then. Having read the MHRA's response closely, I think it deserves both credit and challenge before that roadmap is finalised.
About this series
I have split my analysis into three parts, and each can be read on its own. Each part ends with its own list of references.
Part 1, What the plan gets right, covers the strengths I believe matter most for patient safety. Part 2, The gaps that put patients at risk, looks at six weaknesses, starting with the AI that NHS commissioners use to manage the health of whole populations. Part 3, Accountability, standards and the road to delivery, asks who answers when AI causes harm and why the plan should build on standards that already exist, then closes with my recommendations to the MHRA.
Where I refer to a specific recommendation, "Rec" and its number follow the numbering in the Government's response.
Part 1: What the plan gets right
Regulating AI in UK healthcare: the strengths of the Government's response to the National Commission
On 6 October 2026, the Government accepted all 44 recommendations of the National Commission into the Regulation of AI in Healthcare. In the same document, it conceded that the UK Medical Devices Regulations 2002 are not fit for purpose for AI. That is an unusually candid statement for a regulator to put in writing.
The concession sets the tone for the rest of the MHRA's response, which reads as a plan to replace the current rules rather than defend them.
This is the first of a three-part series. Here I look at what the plan gets right, and Parts 2 and 3 look at what is missing. I have ranked the strengths by a single test: how far each one reduces the risk of harm to patients.
1. Safety becomes a written obligation shared by both sides
Most AI failures in healthcare happen after deployment, in the space between a manufacturer's assumptions and how the product is actually used in a hospital or GP practice.
The plan addresses that space directly. Under the plan, manufacturers would be expected to state the operating conditions their product needs to be used safely, including the controls the deploying organisation must have in place, such as cyber security and staff training (Rec 26). The MHRA will include illustrative examples of good risk controls in its guidance (Rec 27). The Government has also committed to making it clearer, including through NHS contract terms, who delivers each of those controls (Rec 28).
At present, a product's safety assumptions often sit in technical files that the buyer never reads. Under this model they would become explicit terms, each with a named party responsible for it. Of everything in the MHRA's response, this is the change most likely to make a difference that is felt on the ward.
This mirrors what ISO/IEC 42001 already expects organisations to do when managing AI risks that originate with their suppliers. ISO/IEC 42001 is the international standard that sets out how organisations should govern and manage their use of AI. In this respect, the MHRA's plan is strengthened by mirroring an established best practice.
2. Oversight continues after approval
Traditional device regulations check a product once, before it reaches the market. AI does not stand still after that check, because its performance can drift as patient populations, clinical practice or data sources change.
To account for these dynamic model changes, the MHRA's response commits to exploring a more lifecycle-based framework (Rec 5). It also promises to build a toolkit of post-market measures, applied in proportion to risk (Rec 17).
One detail deserves attention. The Commission's recommendation, which the Government has accepted, includes real-world monitoring plans agreed at the point of approval, and a process for escalating when performance degrades even if no reportable incident has yet been observed (Rec 17a and 17d). That moves the safety system from responding to harm towards anticipating it proactively.
3. Knowing which version treated which patient
When a software version turns out to be faulty, the first question is which patients it affected. For many AI systems in use today, that question is often hard to answer.
The plan commits to work towards unique device identifiers, with version control, recorded in the electronic patient record (Rec 20). If this is delivered, a faulty release can be traced to a list of named patients whose care can then be reviewed, allowing practitioners to address the downstream risk to those patients.
4. Equity is named rather than assumed
Manufacturers will be asked to show that their devices do not create or widen disparities. The MHRA's response names the groups most at risk: children, women, ethnic minorities and other under-served populations (Rec 13).
Naming these groups matters, because many AI models perform worse for precisely the people who were under-represented in their training data. The commitment covers representative data and subgroup performance testing, both before launch and afterwards.
There is a caveat, which Part 2 takes up: the plan does not yet say how bias will be measured.
5. The self-certification loophole is addressed
Under the current rules, much medical software falls into the lowest risk class and is self-certified by its manufacturer. The Commission described the known limitations of self-declared Class I devices, and the Government will consult on a new approach to classification (Rec 1b).
A product's intended purpose would also be judged on its design and functionality, not only on its marketing claims (Rec 1c). If adopted, this would stop products from staying outside regulation simply by describing themselves carefully.
6. The foundation model underneath the product
Many new health AI products are built on large general-purpose models owned by other companies. If the underlying model is changed or withdrawn, the product built on top of it can fail without warning.
Manufacturers will be expected to disclose these dependencies together with their continuity plans (Rec 8). The MHRA will also work with the Department of Health and Social Care to build this expectation into NHS procurement and contract terms. In addition, the MHRA's response says it may pilot an optional "Master File" for general-purpose models (Rec 7). This is a supply-chain risk that many frameworks have yet to address.
7. A workable approach to AI that keeps learning
Adaptive AI raises an awkward regulatory question: if a model changes after approval, does every change need fresh approval?
The MHRA's answer is the Predetermined Change Control Plan: a plan, set out in advance, that describes how a model is allowed to change after approval. Under the proposed approach, manufacturers would be able to define a range of acceptable change, rather than only listing each specific update ahead of time (Rec 6). This would include adaptive AI (systems whose models can be updated or retrained after they are approved), but the product's intended use must stay the same.
The MHRA will publish draft guidance for public comment by December 2026, which makes this the plan's earliest dated deliverable.
8. Consequences and public visibility
The MHRA intends to implement civil sanctions, including financial penalties, for manufacturers that break the rules (Rec 22). It is also working towards a searchable public database of adverse incidents, modelled on the existing drug analysis profiles (Rec 19), and a published list of the AI medical devices authorised in the UK (Rec 37).
For patients and clinicians, this added transparency brings together information that is not currently available in one place.
9. Redress, and a first step beyond devices
A working group that includes the Patient Safety Commissioner will look at routes to redress when AI-enabled care falls short (Rec 25).
The MHRA's response also extends the expectation of a reporting culture to relevant AI tools that are not medical devices (Rec 34). It is a small step, but it shows the Government recognises that harm can come from tools outside device regulation. Part 2 explains why recognising that problem falls well short of solving it.
10. Building on what the NHS already uses
The plan does not create a parallel system. It builds on assurance tools the NHS already knows.
Delivery will be overseen by a cross-system Programme Board meeting quarterly, with a published roadmap due by Spring 2027 and annual progress reports after that. The programme covers all four UK nations.
Part 1 Conclusion
The MHRA's response is at its strongest where it treats AI safety as a responsibility shared across the whole lifecycle. Four ideas stand out: risk controls written into contracts, an escalation path in place before harm occurs, version traceability in the patient record, and disclosure of dependencies on foundation models. Some of these are ahead of many existing frameworks.
A plan is judged by what it leaves out as well as by what it includes. One category of AI is almost absent from the 44 recommendations, even though it scores every patient registered with an Integrated Care Board, often every month, and has done so for more than a decade without any product-safety oversight. Part 2 starts there.
Part 1 References
1. Medicines and Healthcare products Regulatory Agency (2026). Government Response to the National Commission's Recommendations on the Regulation of AI in Healthcare. Published 6 October 2026.
2. Medical Devices Regulations 2002 (SI 2002/618), as amended.
3. International Organization for Standardization (2023). ISO/IEC 42001:2023, Artificial intelligence: Management system.
4. NHS England. Digital Technology Assessment Criteria (DTAC).
5. NHS England Digital. Review of digital clinical safety standards: DCB0129 and DCB0160.
6. Medicines and Healthcare products Regulatory Agency. AI Airlock: the regulatory sandbox for AIaMD.