The National Commission into the Regulation of AI in Healthcare, established by the Medicines and Healthcare products Regulatory Agency (“MHRA”), has published its recommendations for the future regulation and assurance of AI in UK healthcare. On 6 October 2026, the Government confirmed it will accept all 44 recommendations with a complete implementation roadmap expected by Spring 2027. The report is therefore the clearest indication yet of where UK healthcare AI regulation is heading.
It concludes that the current framework, weighted towards pre-market assessment, is not ideally suited to AI products that change over time, perform differently between settings and depend on the data, users and organisations around them. The Commission instead proposes a proportionate, lifecycle-based and system-wide framework, which could offer businesses more flexible routes to market. However, this would come with greater expectations around real-world evidence, monitoring, governance, transparency and accountability.
Is the AI product a medical device?
The regulatory starting point for any healthcare AI developer is whether its product qualifies as a medical device, as determined by its intended purpose.
Recommendations 1 and 2 address continuing uncertainty around this test, recommending: a review of the UK Medical Devices Regulations 2002 to clarify when administrative software, general wellbeing products and certain low-risk clinical decision-support tools fall outside medical device regulation; modernisation of the classification system, including the limitations associated with self-declared Class I devices; and that intended purpose should consider a product’s design and functionality alongside the manufacturer’s claims and promotional materials. Developers may find it harder to rely on a narrow intended purpose statement where the product’s design or promoted functionality indicates a wider clinical use.
Recommendation 4 proposes a function-based approach for products containing both medical and non-medical device functionality. For example, an ambient voice technology (“AVT”) product may provide administrative transcription alongside clinical decision-support functions. Regulatory oversight would focus on the medical device functionality rather than automatically extending to the entire product. Regulatory perimeter analysis should therefore be treated as an early product development issue, with architecture, functionality, instructions for use, promotional claims and sales demonstrations telling a consistent story about intended purpose. Please see our previous articles on some of the regulatory challenges posed by AVTs in the UK, particularly in the NHS context.
Recommendations 42 and 43 recommend earlier and more predictable MHRA engagement, including written feedback on qualification, classification, the appropriate path to market, evidence requirements and post-market expectations. A formal “classification confirmation” service could also allow manufacturers to obtain a written determination on their product’s regulatory status, reducing uncertainty, avoiding costly redesign and providing confidence to investors and customers alike. Notably, Recommendation 41 positions the Information Commission (previously the Information Commissioner's Office) alongside the MHRA, alongside other authorities in the proposed lifecycle journey map, signalling that data protection is integral to the regulatory analysis.
The MHRA will consult next year on how to qualify and classify AI-enabled devices. Businesses should monitor that consultation closely, as it is likely to affect how their products are categorised and which regulatory pathway applies.
Earlier market access, but greater lifecycle obligations
The most significant structural proposal is the shift from point-in-time approval to lifecycle regulation. Pre-market testing may not reliably predict real-world performance, given that local data, workflows, users and operating conditions affect how a product performs, and models may deteriorate or “drift” over time.
Recommendation 5 proposes rebalancing regulatory evidence across the product lifecycle; an approach that could support more flexible routes to market. Recommendations 14 to 16 take this further, recommending: staged authorisations under which suitable AI-enabled medical devices could initially be deployed within a defined scope, with wider authorisation following once specified evidence thresholds are met; extending regulatory sandboxes; and recognition or reliance pathways for products assessed by trusted international regulators.
These proposals are not straightforward deregulation. Innovation under this framework is conditional on safety, effectiveness and public confidence. Earlier market access comes with proportionate safeguards and ongoing obligations. Recommendation 17 indicates that, in return for potentially earlier access, manufacturers may be expected to provide post-market surveillance plans, undertake real-world studies, report performance on an ongoing basis and establish escalation processes where performance degradation is detected, even where no reportable incident has occurred.
Post-market compliance will need to be designed into the product and commercial model from the outset, as businesses may need the technical capability, data access and contractual rights to monitor performance across deployment sites throughout the product lifecycle.
Updating adaptive AI without repeated authorisation
The existing framework can be difficult to apply where an AI-enabled medical device is regularly updated or continues to learn after being placed on the market. Recommendation 6 proposes Predetermined Change Control Plans (“PCCPs”) where manufacturers and regulators agree the permitted scope of future changes in advance. For adaptive systems, this could involve defining boundaries within which changes may occur, supporting site-specific tuning, broad intended purposes and evidence-led expansion of use.
If implemented effectively, PCCPs could reduce the regulatory friction associated with maintaining and improving AI products, though developers would still require robust validation, monitoring, and documentation to show that updates remain within the permitted boundaries and do not adversely affect safety or performance.
The MHRA has committed to issuing draft guidance by December 2026 on managing changes to adaptive AI-enabled medical devices. Developers whose products update or evolve over time should engage with that process early.
Foundation models enter the regulatory supply chain
The report addresses the growing use of general-purpose and foundation models in healthcare products. A downstream manufacturer may depend on an underlying model developed by another company but have limited access to the technical information required for its own regulatory submission. Recommendation 7 introduces an optional “Master File” through which an upstream model provider could confidentially submit relevant technical information to the MHRA for downstream manufacturers to reference, minimising disclosure of commercially sensitive information.
Recommendation 8 proposes that manufacturers disclose dependencies on underlying general-purpose models, together with associated risks, mitigations and continuity plans. This could have significant supply-chain consequences. Contracts with model providers may need to cover access to technical information, notification of model updates and material changes, regulatory cooperation, performance monitoring, cybersecurity, and business continuity. Where the model provider sits outside the UK, those risks and mitigations may extend to data protection considerations, including international transfer mechanisms, controller and processor status and the nature of data flows between the parties. An unexpected change to an upstream model could otherwise affect the validation, safety or regulatory status of the downstream healthcare product.
Responsibility moves into contracts and procurement
The Commission notes concern that healthcare professionals and providers could become “liability sinks” because they have the clearest duties of care, even where a failure is influenced by product design or wider deployment arrangements determined by manufacturers.
Recommendation 24 calls for responsibility for managing a particular risk to sit with the party best placed to manage it. Individuals should not carry responsibility for risks they cannot identify, control or mitigate. Recommendation 25 seeks to protect patients’ access to redress where AI is used in care. Whilst these recommendations are principled, how this translates into practice (particularly when something goes wrong) will require further policy development.
Regulatory risk allocation is expected to be a more prominent aspect of negotiations with NHS and private healthcare customers. Recommendations 26 to 28 outline that manufacturers would be expected to identify the operational conditions required for safe deployment, and contracts between them and healthcare providers should expressly allocate responsibility for delivering the necessary risk controls and meeting relevant regulatory commitments.
Cybersecurity, traceability and transparency
Cybersecurity is framed as an inherent part of medical device safety, especially considering the potential to cause rapid harm to many people. Recommendation 10 recommends dedicated MHRA guidance on this across the product lifecycle, covering risks including data poisoning, malware and disruption to connected healthcare infrastructure.
Recommendation 20 encourages greater traceability, including exploring unique device identifiers with version information recorded in patient records, to support post-market surveillance, incident investigation, recalls and redress.
Transparency is another central theme. Recommendations 9 and 39 propose that developers communicate product performance and limitations clearly to both users and patients, keep labelling current as products evolve, and make relevant information accessible via user-friendly design interfaces. Recommendations 18, 19 and 22 also propose stronger post-market transparency, including improvements to adverse incident reporting, better information sharing across the supply chain and enhanced enforcement mechanisms for manufacturers that fail to comply.
For suppliers, these proposals increase the importance of technical logging, version control, accessible product information and coordinated procedures for managing safety concerns across multiple customers and deployment environments, as well as building cybersecurity considerations into regulatory evidence, contracts, monitoring and incident response as an integrated whole.
Health equity and bias
The Commission treats equitable performance as an aspect of safety. Recommendation 13 calls for MHRA guidance on health equity expectations across the product lifecycle, including consideration of the diversity of the intended population, particularly underserved groups. Recommendation 12 similarly calls for guidance on human factors, usability and expectations across the full breadth of users and settings, which is directly relevant to whether a device performs equitably in practice.
If AI-enabled devices do not perform well for all populations, trust in AI-enabled care will be weakened and existing inequalities may be compounded. The report signals that subgroup monitoring is expected as a lifecycle obligation, with further guidance prescribing minimum thresholds or methodologies for representative data.
Developers face a practical tension: sufficiently representative data is needed to identify differential performance while ensuring no more personal data is collected than necessary, requiring product regulation, clinical safety, data protection and equality considerations to be addressed together.
Public trust
The Commission’s Call for Evidence found that public trust in healthcare AI will not follow automatically from regulatory approval. Recommendation 35 calls for a proportionate, system-level approach to informing patients about AI use in their care, combining general public awareness with more active discussion where the risk warrants it, supporting patients’ reasonable expectation of being informed and the ability to opt out where possible.
The interaction between patient transparency and opt-out obligations under the proposed framework and existing GDPR requirements is likely to require review of privacy notices, lawful bases for processing health data, data protection impact assessments and mechanisms for responding to data subject rights requests.
What should businesses do now?
Although the proposals are not yet law, businesses can start preparing now. This includes clearly defining what their AI product is intended to do, putting systems in place to monitor performance after deployment, managing risks around data and third-party models, and ensuring responsibilities are clearly allocated between suppliers and users. Cybersecurity, traceability, equitable performance across diverse populations and patient-facing transparency should all be treated as integral to the product and commercial model, given that public trust will not follow automatically from regulatory approval. Organisations that build strong governance, monitoring and accountability processes across all these areas early are likely to be better placed as the regulatory framework develops.
Developers of AI-enabled medical devices should also consider applying for AI Airlock Phase 3, the MHRA’s regulatory sandbox focusing on post-market surveillance and lifecycle regulation. Applications are now open, with a prospective applicant webinar on 22 October and the first wave of innovators selected in November 2026.
If you have questions about any of the compliance considerations set out in this article, or would like to explore how they apply to your products or services, please do not hesitate to get in touch with our team. Bird & Bird’s Life Sciences and Technology practice has extensive experience advising AI, AVT and digital health suppliers on regulatory, data, and commercial matters in the UK and internationally.

/Passle/65b10a249576f7f0a5a2f163/MediaLibrary/Images/2026-08-12-12-22-01-624-6a7c6569372779c65c80df43.png)
/Passle/MediaLibrary/Images/2026-07-28-07-07-54-879-6a68554a2f7f4abc62438be9.jpg)
/Passle/MediaLibrary/Images/2026-07-30-15-23-08-547-6a6b6c5cf10dbec0100718d8.jpeg)
/Passle/MediaLibrary/Images/2026-07-27-08-51-04-398-6a671bf8a3513a74a4f37b66.jpg)