AI in medical contexts is one of the most consequential AI use cases, and one of the most regulated. The MHRA regulates AI as Software as a Medical Device (SaMD), with classification, clinical evaluation, quality management, post-market surveillance, and engagement mechanisms shaped by both general medical device regulation and AI-specific provisions including the AI Airlock.
This article walks through what medical AI under MHRA regulation actually involves operationally for developers, healthcare organisations, and the broader ecosystem deploying AI in clinical contexts.
What counts as medical AI under MHRA remit
The MHRA's remit covers software intended for medical purposes, diagnosis, prevention, monitoring, prediction, treatment, alleviation, or compensation for an injury or disability, where that software meets the legal definition of a medical device.
Key distinctions
● AI making or substantially contributing to medical decisions, typically within remit
● AI providing clinical decision support to qualified clinicians, generally within remit, with classification depending on intended use
● AI used in clinical workflow administration without medical decision implication, generally outside MHRA remit but potentially within other healthcare governance frameworks (NHS England, NHS Digital, CQC)
● AI used in lifestyle or wellness contexts without medical intent, generally outside MHRA remit
● AI used in medical research without direct clinical application, generally outside MHRA remit but within research governance frameworks
The distinction between regulated medical AI and unregulated lifestyle or wellness AI has been the subject of significant guidance work as products in the borderline space have proliferated. When in doubt, early MHRA engagement on classification is the right pattern.
Classification
Medical AI within MHRA remit is classified by risk class, broadly aligned with international medical device classification. Class affects the regulatory pathway, the evidence required, and the ongoing obligations.
● Lower-risk classifications, typically self-declared conformity with appropriate technical documentation
● Medium-risk classifications, requiring notified body involvement in conformity assessment
● Higher-risk classifications, including in vitro diagnostic medical devices and implantable devices, with more demanding conformity assessment pathways
● AI-specific considerations, including the dynamic nature of AI models and how classification handles model updates over time
The MHRA has issued specific guidance on classification of AI software. The guidance addresses how risk class is determined when the AI's outputs influence clinical decisions, when the AI operates autonomously, and when the AI's intended use spans multiple risk categories.
Clinical evaluation
Medical AI requires clinical evaluation supporting the device's intended use. The evaluation establishes that the device performs as intended and that the benefit-risk balance is acceptable.
AI-specific clinical evaluation considerations
● Performance evaluation across the intended use population, including ages, comorbidities, demographic dimensions, and clinical contexts
● Comparator selection, what the AI is being compared against, and whether the comparator is the appropriate baseline for the intended use
● Real-world performance, laboratory or development-environment performance may differ from real-world clinical performance
● Subgroup analysis, performance variations across subpopulations relevant to the intended use
● Continued learning systems, AI that updates from new data raises specific clinical evaluation considerations as performance characteristics may evolve
Quality management system
Medical device manufacturers operate quality management systems aligned with relevant standards, ISO 13485 for medical devices, plus AI-specific considerations.
AI-specific QMS considerations
● Design controls covering AI development lifecycle, data, model development, testing, validation
● Risk management throughout the AI lifecycle, aligned with ISO 14971 and AI-specific risk frameworks
● Configuration management for AI components, model versions, training data, inference parameters
● Software lifecycle processes covering AI updates, retraining, and continued performance
● Post-market surveillance integrating AI performance monitoring with general medical device vigilance
The AI Airlock
The MHRA's AI Airlock is a regulatory engagement mechanism for AI medical devices, designed to support development of novel AI in clinical contexts with appropriate safety oversight. The Airlock provides a structured pathway for AI medical device developers to engage with the MHRA earlier and with more flexibility than traditional pathways.
For AI medical device developers, particularly those working with novel approaches, generative AI in clinical contexts, or AI applications where the existing regulatory framework may not directly anticipate the technology, the AI Airlock provides a constructive engagement route.
Post-market surveillance
Medical AI requires post-market surveillance, ongoing monitoring of device performance, adverse events, and the broader benefit-risk balance after deployment.
AI-specific post-market surveillance
● Performance monitoring across the real-world use population, with attention to performance drift over time
● Adverse event monitoring including AI-specific failure modes, hallucination in clinical contexts, performance degradation on specific subpopulations, integration failures with clinical workflows
● Vigilance reporting per MHRA expectations for medical device adverse events
● Periodic safety updates incorporating AI-specific performance and risk findings
● Coordination with NHS adoption frameworks where the device is deployed in NHS settings
The wider stakeholder environment
Medical AI in the UK operates within a stakeholder environment that extends beyond the MHRA:
● NICE, evaluating clinical and cost effectiveness for NHS adoption recommendations
● NHS England and the Centre for Improving Data Collaboration, overseeing adoption in NHS settings
● Care Quality Commission, regulating the providers using medical AI in their care delivery
● Health and Social Care Information Centre, providing infrastructure that medical AI typically integrates with
● Academic Health Science Networks and innovation pathways, supporting adoption and evaluation
● Patient and public involvement structures, increasingly important for AI deployment in NHS settings
Sequencing engagement across this stakeholder environment is part of the operating discipline that successful medical AI delivery in the UK requires. The MHRA pathway is necessary but not sufficient for clinical adoption.
The shift to make
Stop treating MHRA engagement as a regulatory hurdle to clear before doing the real work of deploying medical AI.
Start treating MHRA engagement as one part of the broader stakeholder coordination that medical AI requires, with early engagement, integration of regulatory and clinical workstreams, and sustained engagement through post-market surveillance.
Medical AI developers and the healthcare organisations adopting their products earn three durable advantages from operating this way. Faster pathways to clinical use through constructive regulatory engagement rather than late-stage regulatory pushback. Stronger clinical adoption because the broader stakeholder environment has been engaged from the start. And evidence base for sustained operation rather than the discrete event of initial approval, because medical AI's regulatory journey is ongoing, not one-time.
