Approval is no longer expected to be the final test for medical AI. A diagnostic algorithm can be updated after launch, encounter patient populations unlike those used in validation, or perform differently when installed in another hospital’s workflow. Regulators are responding to that reality by placing greater emphasis on medical AI lifecycle monitoring: oversight that continues after a product reaches clinicians and patients.
The shift does not mean that premarket review is becoming less important. It means authorization is increasingly being treated as a starting point for accountability rather than a permanent verdict on a fixed product. For machine learning medical devices, the central challenge is straightforward: evidence collected before market entry may not fully describe how software behaves after months or years of use in changing clinical environments.
Why medical AI cannot be treated as a static product
Many medical devices contain software, but AI-enabled tools add particular complications. A model may be modified to improve image quality, add supported scanners, refine an alert threshold or expand its intended use. Even when its underlying code does not change, the data arriving at the system can.
Hospitals differ in equipment, imaging protocols, electronic-record systems and clinical workflows. Their patient populations can also differ by age, ethnicity, disease prevalence and co-existing conditions. A model trained or tested in one set of settings may therefore face a different statistical environment in another. This is often described as data drift or distribution shift.
Clinical practice changes too. New treatments, screening policies and documentation habits can alter the signals an algorithm relies on. A tool that identifies a condition from medical images, for example, may encounter images produced by a newly deployed scanner or acquired under a revised protocol. Its premarket performance may remain relevant, but it is not a guarantee of equivalent real-world performance everywhere.
Research on clinical AI has repeatedly shown that externally validating a model across sites is difficult, and that performance can vary when systems move beyond their original development setting. That does not establish that every authorized system will degrade. It does establish why performance claims need to be checked in the settings where a tool is actually used.
From a fixed review to lifecycle oversight
Traditional AI medical device regulation has generally assessed a defined device and intended use before it is marketed. Manufacturers must still show reasonable assurance of safety and effectiveness through the relevant regulatory route. But regulators are developing ways to handle software whose future changes can be anticipated, bounded and assessed in advance.
In the United States, the Food and Drug Administration has made this idea central to its approach to AI-enabled device software. The agency’s public list recorded 1,016 AI- and machine-learning-enabled medical devices authorized through its established pathways as of its December 2024 update. Most were in radiology, with other devices spanning areas such as cardiovascular care, neurology and clinical chemistry. The list is a useful indicator of activity, although it is not a complete measure of every AI capability used in healthcare.
In August 2024, the FDA issued final guidance on predetermined change control plans, or PCCPs, for AI-enabled device software functions. A PCCP allows a manufacturer to describe planned modifications, how those modifications will be developed and validated, and the safeguards used to ensure they remain safe and effective. If the plan is accepted as part of a marketing submission, some changes within its defined scope may be made without a separate premarket submission each time.
The important limitation is that a PCCP is not a blank cheque for adaptive medical AI. It must specify the changes being proposed, the associated methodology and the impact assessment. Changes outside the authorized plan, or changes that could significantly affect safety, effectiveness or intended use, may still require a new FDA submission. In early 2025, the FDA also issued draft guidance on lifecycle management and marketing submissions for AI-enabled device software functions, reinforcing its expectation that manufacturers manage risks throughout development, deployment and modification.
What continuous monitoring can involve
In practice, post-approval oversight can combine several mechanisms:
- Change documentation: maintaining records of software versions, validation results and the rationale for modifications.
- Post-market surveillance: collecting and evaluating complaints, malfunctions, clinical feedback and other evidence from use.
- Adverse-event reporting: reporting certain deaths, serious injuries and malfunctions to regulators under medical-device reporting rules.
- Real-world performance monitoring: examining whether performance remains consistent across sites, devices and relevant patient groups.
- Corrective action: issuing safety communications, patches, field corrections or recalls when a problem is identified.
- Cybersecurity management: assessing vulnerabilities and maintaining software as new threats emerge.
Not all of this is new. Medical-device makers have long had post-market duties. What is changing is the effort to make those duties fit software that evolves more quickly than conventional hardware, and to make evidence about deployed performance more useful in regulatory decision-making.
Europe is combining medical-device and AI rules
The European Union is building a parallel, though more layered, framework. The Medical Device Regulation, or MDR, has applied to medical devices since 2021 and requires manufacturers to operate post-market surveillance systems, prepare periodic safety update reports for higher-risk devices and report serious incidents and field safety corrective actions.
The EU AI Act adds horizontal obligations for high-risk AI systems. It entered into force on August 1, 2024, but its requirements are phased in. AI systems that are safety components of products covered by EU product-safety legislation, including many regulated medical devices, are generally scheduled to become subject to the AI Act’s high-risk rules from August 2, 2027. The precise classification of a medical AI system depends on its intended purpose and the applicable product rules.
For covered high-risk systems, the AI Act includes requirements concerning risk management, data governance, technical documentation, record-keeping, human oversight, accuracy and robustness. It also requires a post-market monitoring system and establishes serious-incident reporting duties. In effect, medical AI developers serving Europe may need to satisfy both the MDR’s device-specific vigilance regime and the AI Act’s broader governance requirements.
The difficult questions have not been solved
Lifecycle oversight sounds sensible, but implementation will be demanding. Regulators must decide what evidence demonstrates that a software update is minor, and what makes it substantial enough to require fresh review. Developers need to define meaningful performance metrics without encouraging excessive collection of sensitive patient data. Hospitals need processes to identify which model version is running, detect unexpected behavior and communicate concerns to manufacturers.
Responsibility is also distributed. Manufacturers carry primary regulatory duties for device quality systems, post-market surveillance and reporting. Healthcare providers, meanwhile, are often the first to see a system fail in local practice. They may have obligations under local law and professional standards, but many lack the data infrastructure, technical staff or contractual access needed to independently audit a vendor’s model. Distributors and importers can have defined obligations as well, particularly under European device rules.
There is another practical constraint: regulators do not automatically receive a complete, standardized stream of real-world performance data for every authorized model. Adverse-event reports and manufacturer surveillance can identify important problems, but they are not the same as a continuously updated national comparison of clinical performance. Building such visibility raises questions about interoperability, privacy, reporting burden and who pays for the work.
What clinicians and patients should expect
For clinicians, meaningful oversight should make AI less opaque rather than add another layer of paperwork. Hospitals should be able to identify a tool’s version, intended use, known limitations and the circumstances in which a result needs human review. Clear labeling matters because a model validated for one clinical task should not quietly become a proxy for another.
Human oversight remains essential. An alert, risk score or image-analysis result can support a decision, but it does not eliminate the clinician’s responsibility to weigh the patient’s broader condition. Health systems also need escalation procedures: who investigates a suspected AI-related error, whether use should be paused, and how affected patients are informed when necessary.
For patients, the promise of medical AI lifecycle monitoring is not perfection. It is a stronger expectation that performance will be tested against real use, that errors will be visible rather than buried, and that software updates will receive scrutiny proportionate to their clinical consequences.
The durable regulatory change is conceptual. As software becomes a more active part of medicine, a device authorization cannot be the end of the safety conversation. It must increasingly be the point at which developers, clinicians, healthcare systems and regulators begin the work of watching what the technology does in the world.