What the UK’s 44 Healthcare AI Recommendations Mean for Anyone Building Clinical AI

UK healthcare AI regulation recommendations illustrated by a government report outlining 44 recommendations, with a stethoscope representing clinical AI oversight and patient safety.

The AI healthcare regulation recommendations UK ministers accepted on 6 October 2026 change when the regulatory work on an AI medical device happens. Approval is no longer the finish line. It is the point where monitoring starts.

On that date the government accepted all 44 recommendations of the National Commission into the Regulation of AI in Healthcare, the independent body the MHRA set up in September 2025. The headline shift is from one-off approval of AI medical devices to continuous assessment across their working life. Alongside the response, the MHRA opened Phase 3 of its AI Airlock regulatory sandbox, focused on post-market surveillance, with a webinar for prospective applicants on 22 October. Draft guidance on managing changes to AI-enabled devices is targeted for December 2026.

The consequence for anyone building clinical AI is practical. If a regulator can ask how a device has performed across its working life, the answer has to come from the software itself. Monitoring, change control and audit trails cannot be added at the end as documentation. They must be designed into the software from the start, which is a strength of bespoke development: when you control the architecture, you decide what every output records, how changes are released and how quickly a version can be rolled back.

This article is for digital health and medtech founders, NHS suppliers, and pharma and life sciences compliance and regulatory leads. It covers what was accepted, what post-market surveillance means in engineering terms, the dates to plan around, and a readiness checklist for suppliers ahead of binding requirements.

What was accepted: staged authorisations, lifecycle monitoring, and clearer roles across the supply chain

The government accepted all 44 AI healthcare regulation recommendations in full, less than four weeks after the Commission published them on 10 September. The Commission, chaired by Professor Alastair Denniston, drew on evidence from more than 12,000 patients, clinicians and members of the public. The government's response says the current medical device regulations are not fit for purpose for AI, because the technology has moved on considerably since the UK Medical Devices Regulations 2002 were drafted.

Acceptance sets direction rather than new law. An implementation roadmap is promised by Spring 2027, overseen by a cross-system Programme Board that meets quarterly. Three accepted changes matter most for anyone building clinical AI.

Staged authorisations

Recommendation 14 asks the MHRA to enable staged authorisations, so that promising AI tools can be used in the NHS earlier, under close supervision, while real-world evidence is gathered. Gerard Hanratty of Browne Jacobson described it to Computer Weekly as an "L-plates-style" staged authorisation model.

The recommendation is accepted, but the pathways do not exist yet. The government's commitment is that the MHRA will explore options for staged authorisation, including through proposed licensing powers and regulatory sandboxes, with further details by Spring 2027. The response also commits to supporting sandbox provisions in the government's Regulating for Growth Bill, which we looked at in our piece on UK AI regulation and Britain's AI Minister.

Lifecycle monitoring

This is the centre of the shift. Under Recommendation 5, evidence generation and oversight should increasingly happen across the product lifecycle, with less reliance on a point-in-time assessment before a device reaches the market. Under Recommendation 17, the MHRA will build on its existing post-market surveillance requirements with an enhanced toolkit of mechanisms that could be required individually or in combination. The Commission's list includes:

  • post-market surveillance and real-world monitoring plans, assessed when a device is authorised
  • real-world post-market studies where needed
  • more regular performance reporting, to regulators or publicly
  • processes for escalation when performance degradation is detected, even if no reportable incident has occurred

The evidence behind it is consistent. The Commission's Call for Evidence drew 761 responses, and in every respondent group between 61% and 68% disagreed that the current post-market surveillance framework is sufficient. For life sciences teams, Recommendation 44 adds that the Health Research Authority will clarify when monitoring and evaluating an AI tool counts as research that needs research governance.

Clearer roles across the supply chain

Recommendation 24 creates a working group of DHSC, the MHRA, the Care Quality Commission, NHS Resolution, the Professional Standards Authority and the professional regulators to make responsibility at each stage of the lifecycle clear. The changes that reach suppliers directly are more concrete:

  • Operational conditions (Recommendation 26)Manufacturers should specify, in pre-market submissions and risk management files, the conditions needed for safe deployment, including controls in the provider's environment such as cybersecurity, user training and AI readiness.
  • Contracts (Recommendation 28)The contract between manufacturer and healthcare provider should explicitly allocate responsibility for delivering those risk controls.
  • Model dependencies (Recommendation 8)Where a product depends on a general-purpose model, the manufacturer should report that dependency, its risks and mitigations, including continuity plans, in regulatory submissions and through procurement terms.
  • Clinical risk standards (Recommendation 31)Guidance under DCB0129 and DCB0160, the NHS clinical risk management standards for manufacturers and for the organisations deploying their products, will be strengthened.

For NHS suppliers, this extends something already familiar. As we noted in our lessons from delivering digital solutions into the NHS, a Clinical Safety Officer is essential for showing that a new pathway is at least as safe as the one it replaces. Lifecycle regulation asks for that safety case to be maintained for as long as the product is in use.

What "post-market surveillance" means in engineering terms: performance drift tracking, logging and documented change control

Post-market surveillance is the work a manufacturer does after a device reaches the market to confirm it stays safe and performs as intended. For an AI medical device, it comes down to three engineering capabilities: performance drift tracking, logging and documented change control. None of them can be added with a policy document. All three have to exist in the software.

AI Airlock Phase 3 points the same way. One of its priority topics is designing surveillance that captures deployment-context factors such as local infrastructure, workflow integration, data quality and how users interact with the device.

Performance drift tracking

An AI model's real-world performance can shift when the patients, data sources or clinical workflows around it differ from those it was validated on, even when the code has not changed. Drift tracking is how a manufacturer finds out before a clinician or patient does. In practice it means:

  • A baseline from validation, broken down by site and by relevant patient groups. Recommendation 13 asks for performance to be evaluated and monitored across relevant population groups, including children, women and underserved groups.
  • Continuous monitoring of inputs and outputs against that baseline, plus clinical outcomes or clinician overrides where they are available.
  • Thresholds and owners set in advance: what level of change triggers an investigation, who is alerted and when a model is paused or rolled back.

Logging

Recommendation 20 asks for deployed AI devices to be traceable, including version control across updates, with unique device identifiers explored as a way to record in the electronic patient record which device and version were involved in a patient's care. Recommendation 21 looks at automating low-burden reporting, including building reporting into the devices themselves. In practice that means:

  • Recording every output with the model version, an input reference, a timestamp and the deployment site, in a store that cannot be edited without trace.
  • Showing the version in the clinical interface, so it can be captured in the patient record.
  • Building reporting hooks so performance and incident data can be exported in a standard format rather than assembled by hand.
  • Minimising what leaves the deploying organisation. The Call for Evidence recorded concern that surveillance should not give manufacturers inappropriate access to patient data.

Together, these records form the audit trail a regulator or NHS trust can ask to see: what the device did, on which version and at which site.

Documented change control

AI products improve by changing, and for a medical device every change is a regulatory question. The mechanism the MHRA is developing is the predetermined change control plan (PCCP): a plan agreed in advance that sets out which changes a manufacturer can make, how each will be validated and how it will be monitored once released. The MHRA, the US FDA and Health Canada have already published five joint guiding principles for PCCPs, and Recommendation 18 adds that monitoring and reporting requirements should be built into PCCPs so a device stays safe as it iterates. In practice that means:

  • Versioning models, training data references and evaluation results together, so any release can be reproduced.
  • Gating every release on pre-specified validation tests and storing the results with the version.
  • Keeping the previous version deployable, so rollback is a configuration change rather than a rebuild.
  • Recording who approved each change and which part of the plan it falls under.

Why it has to be designed in from the start

The trap

Building the product first and leaving monitoring, change control and audit trails for the compliance team to add before an audit.

The fix

Treat drift monitoring, version-stamped logging and release gates as first-release features, because each one shapes how outputs are produced, stored and shipped.

This is where bespoke development has a structural advantage. When you control the architecture, you decide what every output records, which deployment-context signals are captured, how releases are gated and how quickly a version can be rolled back. Retrofitting those capabilities means changing how a product already in use records and ships every output. A packaged component or third-party model can still be the right choice, but the monitoring around it has to be designed deliberately, and under Recommendation 8 its dependencies and continuity risks have to be disclosed.

Dates to plan around: the 22 October webinar and the December draft guidance

Two dates matter most in the next three months: the AI Airlock applicant webinar on 22 October and the MHRA's draft guidance on managing changes to AI-enabled devices, due by December 2026.

22 October 2026: the AI Airlock Phase 3 webinar

The AI Airlock is the MHRA's regulatory sandbox for AI-enabled medical devices, launched in spring 2024. Phase 3 focuses on post-market surveillance and oversight across the lifecycle, and the webinar for prospective applicants takes place on 22 October 2026 at 10:00. Registration is on the AI Airlock page.

Applications to be considered in the current review wave need to be in before 31 October, and the first wave of innovators will be selected in November. The window stays open after that, with the next shortlisting in Spring 2027. Participation is free, but applicants fund their own studies and data access, testing plans are generally scoped to six to twelve months, and project outputs are intended to be made public.

December 2026: draft guidance on managing changes to AI-enabled devices

Under Recommendation 6, the MHRA will issue draft guidance on predetermined change control plans for public comment by December 2026. It is the only one of the 44 actions with a 2026 date. The proposed approach lets manufacturers define boundaries for the scope of allowable change, rather than only pre-specifying individual modifications, with clear approaches for adaptive AI-enabled devices, as long as the device's intended use does not change. Because it is a draft for comment, suppliers with a live product have a chance to shape it. The other 43 actions, including the implementation roadmap and a consultation on how AI devices are qualified and classified, point to Spring 2027.

A readiness checklist for suppliers ahead of binding requirements, which have not yet been published

The AI-specific requirements that will follow these recommendations have not been published, and none of them is binding yet. General post-market surveillance duties are different: the Medical Devices (Post-market Surveillance Requirements) (Amendment) (Great Britain) Regulations 2024 came into force on 16 June 2025 and already apply to software and AI that qualify as medical devices placed on the Great Britain market since then. This checklist prepares for the AI-specific layer on top.

1Make your post-market surveillance plan AI-specific

Extend the plan you already need under the 2025 regulations to cover drift, deployment context and performance across patient groups (Recommendations 13 and 17).

2Define drift metrics, thresholds and owners

Decide in advance what level of change triggers an investigation, who is alerted and when a model is paused (Recommendation 17).

3Stamp the model version on every output

Make the version traceable from each output through to the patient record, and build reporting hooks so incidents can be reported without manual assembly, including through the MHRA's Yellow Card scheme (Recommendations 20 and 21).

4Write your change boundaries before the December guidance

Draft which changes you expect to make, how each will be validated and how it will be monitored, so you can map it onto the PCCP guidance when it arrives (Recommendations 6 and 18).

5Document operational conditions for deployers

Specify in your risk management file the infrastructure, training and readiness controls a provider needs to use your product safely (Recommendation 26).

6Agree who does what in the contract

Allocate responsibility for each risk control between you and the provider explicitly (Recommendation 28), and keep it consistent with your DCB0129 and their DCB0160 obligations.

7Disclose general-purpose model dependencies

If your product relies on a third-party foundation model, record the dependency, its risks and your continuity plan (Recommendations 7 and 8).

8Confirm how your product qualifies and is classified

The MHRA will consult on qualification and classification by Spring 2027 (Recommendation 1), and the Commission specifically flagged the limitations of self-declared Class I devices. Start from the current MHRA guidance on software and AI as a medical device and record your reasoning.

Approved once, monitored forever: is your clinical AI built for it?

Monitored forever, in practice, means monitored for as long as the device is in service. Before the December guidance arrives, check three things in your product: can it detect performance drift, can it tie every output to a model version, and can you release and roll back changes under a documented process?

At Imobisoft, we design and build AI solutions around the systems, data and compliance obligations our clients already have. That can include the monitoring, logging and change control that lifecycle regulation will ask for.

Talk to us about clinical AI

Frequently asked questions

What are the AI healthcare regulation recommendations UK ministers accepted?

They are 44 recommendations from the National Commission into the Regulation of AI in Healthcare, published on 10 September 2026 and accepted in full on 6 October 2026. They move AI medical device regulation from one-off approval to continuous assessment across a device's working life.

What are staged authorisations for AI medical devices?

Staged authorisations are a proposed route for promising AI tools to be used in the NHS earlier, under close supervision, while real-world evidence is collected. The recommendation was accepted, but the MHRA is still exploring how the pathways would work.

What does post-market surveillance mean for AI medical devices?

It means monitoring a device's safety and performance after it reaches the market. For AI, that comes down to performance drift tracking, logging every output against a model version and documented change control.

What is the December 2026 draft guidance on AI device changes?

It is the MHRA's draft guidance on predetermined change control plans, due for public comment by December 2026. It proposes letting manufacturers set boundaries for allowable changes to an AI device, as long as its intended use stays the same.

When is the AI Airlock Phase 3 webinar?

The webinar for prospective applicants is on 22 October 2026 at 10:00. To be considered in the current review wave, apply before 31 October 2026. The window stays open after that, with the next shortlisting in Spring 2027.

Are the new AI medical device requirements binding yet?

Not the AI-specific ones, which have not been published. General post-market surveillance duties have applied in Great Britain since 16 June 2025.

Sources

Have a project in mind? Let’s get to work.

Let’s chat about how we can help you. Fill in the details and we’ll get back to you as soon we can.