A new government response shifts attention from initial approval to performance after deployment, with change-control guidance and an implementation roadmap still to come.
Britain accepted all 44 recommendations of its independent commission on artificial intelligence in healthcare on October 6, setting out a programme that would place greater emphasis on how medical software performs throughout its working life. The official announcement also opened applications for the third phase of the MHRA’s AI Airlock regulatory sandbox.
Initial priorities include draft guidance on managing changes to AI-enabled devices by December 2026 and a full implementation roadmap by spring 2027. The distinction is important: accepting recommendations establishes a policy direction, but does not mean every proposed regulatory power, approval route or reporting mechanism is already operational.
Approval and continued performance are different questions
The government’s published response identifies stronger post-market assurance, clearer evidence requirements and monitoring of changes in real-world performance as delivery priorities. It also proposes examining staged authorisation and predetermined change-control plans, alongside clearer rules on which software functions qualify as medical devices.
For a hospital, the practical issue is whether the tool being used today is still the tool whose evidence was assessed. An update can change a model, an interface or a dependency. Even without a software update, the conditions in which it operates can differ from those used during evaluation. A single performance figure cannot, by itself, explain every subsequent deployment.
This is an operational distinction rather than a claim that any named product has failed. A purchasing decision concerns a particular version, intended purpose and clinical setting. Monitoring asks whether those assumptions remain appropriate as the product and its use evolve. The two activities answer related but different questions.
What the recommendations cover
The commission’s September recommendations go beyond technical accuracy. They address human factors, representative evidence, traceability of deployed versions and the conditions required for safe use. Those conditions include cybersecurity, staff training and organisational readiness. They also distinguish temporary, closely controlled staged access from full authorisation.
That separation prevents an experimental deployment from being mistaken for unrestricted permission to use a system everywhere. Evidence gathered in a limited setting can inform a later decision, but the permitted use, safeguards and remaining uncertainty still need to be understood. An expanded authorisation would require its own basis rather than follow automatically from participation in a pilot.
The recommendations also call for clearer information-sharing across manufacturers, clinicians, providers and regulators. In practical terms, a concern observed by a user has limited value if it cannot be associated with the relevant software version and investigated by the party able to act on it. Traceability connects the report to an identifiable product rather than an undifferentiated label such as medical AI.
A regulatory sandbox is not blanket market clearance
AI Airlock’s new phase will examine post-market surveillance with developers and healthcare partners. The government says applications close in November and a webinar for prospective applicants is scheduled for October 22. The programme is intended to produce evidence and lessons for future guidance; admission does not establish that every participating product is suitable for routine clinical use.
The MHRA’s existing software-device programme provides the wider context. Regulatory status depends on the product’s medical purpose and function, not simply on whether its supplier describes it as AI. Qualification, risk classification and post-market obligations are separate parts of that assessment.
Implementation will depend on responsibilities and resources
The response assigns work across the MHRA, health departments and other health-system bodies. It envisages a programme board, clearer accountability and further guidance on cybersecurity and device information. These commitments leave an implementation task: translating a national framework into arrangements that developers and clinical organisations can actually follow.
For buyers, the resulting questions are concrete. Who receives a safety alert? Who decides whether a software change remains within the authorised scope? What evidence is retained when an update is installed? Who can suspend use when uncertainty needs investigation? These are governance questions, not substitutes for a clinical assessment of any particular tool.
October 6 therefore marks the start of a delivery phase rather than the completion of reform. The next verifiable milestones are the draft change-control guidance, the sandbox’s work and the promised roadmap. Their details will show how the proposed balance between initial evidence, controlled access and continuing oversight is to operate in practice.
