A medical AI system can pass a test on Monday and behave differently when the hospital, patient population, software version or clinical workflow changes. A new UK blueprint says approval must become the start of oversight, not its finish.
The National Commission into the Regulation of AI in Healthcare published its recommendations on September 10, 2026. The independent, non-statutory advisory body proposes a lifecycle model for UK medical AI regulation, with stronger traceability, post-market evidence and enforcement.
Before market entry: regulate the medical function
The Commission asks the Medicines and Healthcare products Regulatory Agency to consider function-based regulation. A broad software platform may contain both medical and non-medical features. Oversight should focus on the functionality that actually qualifies as a medical device, instead of automatically treating the entire product as one indivisible object.
That could make regulation more proportionate, but it makes scoping critical. Developers would need to draw and maintain a clear boundary around intended purpose, inputs, outputs and clinical claims.
At approval: define the evidence that must continue
AI performance can depend on local data and workflow. The Commission therefore recommends rebalancing evidence toward the post-market phase when appropriate to risk. Pre-market evidence would not disappear. It would be paired with a plan for real-world monitoring, reporting and escalation.
For an adaptive system, the regulator should clarify which changes fit within a pre-authorized change plan and which require new review. The report also recommends staged authorizations for selected devices, with temporary conditions, transparent reporting and a defined route to full authorization.
At installation: assign the controls to real owners
A model can be safe in one environment and unsafe in another. The blueprint says manufacturers should specify the operational conditions required for safe deployment, including cybersecurity, user training and organizational readiness. Contracts between a manufacturer and healthcare provider should allocate responsibility for those controls.
A safety requirement without an owner is only a sentence in a contract.
This is the point where procurement becomes part of clinical safety. A hospital needs a named owner for monitoring, an escalation route and a rollback procedure before the system touches patient care.
During use: identify the exact model and version
Recommendation 20 calls for mechanisms that identify AI-enabled medical devices after deployment, potentially through unique device identifiers with version control. The report suggests recording that information in patient records so providers can audit outcomes involving a particular device version.
That is more demanding than recording a vendor name. If a model, threshold or intended purpose changes, the trace must preserve which version influenced which decision. Our analysis of ChatGPT access to Epic records reaches the same operational conclusion: data access and clinical accountability must be mapped at the workflow level.
After deployment: watch performance before an incident
The Commission recommends risk-proportionate post-market surveillance plans, real-world studies where needed, ongoing performance reporting and escalation when degradation appears even if no reportable incident has occurred. It also proposes improving public access to adverse-incident information and exploring automation for low-burden reports.
A useful monitoring plan therefore needs denominators. Counting failures without knowing how many patients, sites and versions were exposed can mislead. Performance should be segmented by hospital, population, device version and relevant clinical context, with thresholds for investigation and suspension.
When a signal appears: the regulator needs faster tools
The report calls for enhanced MHRA enforcement mechanisms, including earlier sharing of safety signals and possible financial penalties where manufacturers fail legal requirements and put patients at risk. The MHRA’s announcement says government and the agency will consider the recommendations and issue a formal response.
That last point prevents overstatement: this is a blueprint, not a new binding regulatory framework. The details, resources and legal changes still need government action.
A builder’s lifecycle record should fit on one page
- Purpose: the clinical function and users.
- Version: model, threshold, prompt and dependency identifiers.
- Evidence: pre-market tests plus live monitoring metrics.
- Environment: data, workflow, training and cybersecurity assumptions.
- Owners: manufacturer, provider and clinician responsibilities.
- Action: thresholds for investigation, rollback, notification and suspension.
The questions in our FDA generative-AI medical-device guide are a useful companion because they expose similar gaps around change control, evidence and human oversight.
My take: continuous approval is the real design challenge
The Commission’s strongest idea is that medical AI regulation must follow the product through change. A one-time certificate cannot explain performance drift, a new hospital population or a silent model update. The hard work is building a trace from product version to patient outcome and giving someone the authority to act when that trace turns worrying.
Primary sources
Checked September 13, 2026. The Commission’s recommendations are advisory and a government response is pending. This article is not medical or legal advice.
