Locked vs. Adaptive AI/ML Algorithms: What FDA Clearance Really Means and How to Update Without Starting Over

Your AI Algorithm Got FDA Clearance. Now What Happens When It Learns Something New?

Congratulations -- your AI-powered medical device cleared FDA. That is a genuine milestone. But if your team is already talking about retraining the model, improving sensitivity, or pushing a performance update, you need to understand one concept before you touch a single line of code: what it means for your algorithm to be locked.

This is not a technicality. Getting it wrong can expose your company to enforcement action, invalidate your clearance, and -- most critically -- put patients at risk. Here is what you actually need to know.

What 'Locked' Means Under FDA's Framework

FDA's 2021 guidance document, 'Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD): Action Plan,' and the earlier 2019 proposed regulatory framework both use the term 'locked' to describe an algorithm whose logic, parameters, and outputs are fixed after the device is deployed. A locked algorithm produces the same output for the same input, every time, without modification based on new data encountered in the field.

When you submitted your 510(k) or De Novo request, FDA reviewed a specific version of your algorithm -- its architecture, training data characteristics, performance validation data, and intended use. That reviewed version is what is cleared. The cleared algorithm is, by definition, locked.

This matters because FDA regulates medical devices under 21 CFR Part 820 (Quality System Regulation, now aligned with ISO 13485 under the 2024 Quality Management System Regulation) and evaluates software changes under the 21 CFR 807.81(a)(3) standard -- which requires a new premarket submission when a change could significantly affect safety or effectiveness.

When a Change to Your Algorithm Requires a New Submission

FDA's 'Deciding When to Submit a 510(k) for a Software Change to an Existing Device' guidance (2017) is the foundational document for this analysis. It lays out a decision framework for determining whether a software modification triggers a new 510(k). For AI/ML devices, the analysis is more nuanced but the core question is the same: does the change introduce new risks or affect clinical performance?

Changes that almost certainly require a new submission include:

• Retraining the model on new data that materially changes its performance characteristics
• Modifying the algorithm's intended use or indications for use
• Changing the model architecture in ways that affect outputs
• Expanding the patient population or imaging modality the algorithm was validated on
• Updating decision thresholds that alter sensitivity or specificity

Changes that may not require a new submission -- but still require documented evaluation -- include bug fixes that do not affect clinical function, UI changes, and backend infrastructure updates that leave the model itself untouched. Even these require a formal change control analysis under your QMS.

The Predetermined Change Control Plan: Your Strategic Exit Ramp

Here is where forward-thinking regulatory strategy pays off. FDA introduced the concept of the Predetermined Change Control Plan (PCCP) specifically to address the operational reality that AI/ML algorithms need to evolve. The 2023 draft guidance on PCCPs outlines how sponsors can prospectively define the types of changes they anticipate making -- and the performance guardrails and validation protocols they will follow -- so that certain future modifications do not require a new premarket submission.

A well-constructed PCCP submitted with your initial 510(k) or De Novo essentially pre-negotiates with FDA the conditions under which your algorithm can be updated without triggering a new review. This is not a loophole. It is a rigorous commitment to:

• Defining the specific modifications you anticipate (e.g., retraining on additional scanner types)
• Establishing performance boundaries that must be maintained
• Describing the validation methodology you will use to confirm the change stays within those bounds
• Committing to transparency through your labeling and post-market monitoring

If you did not include a PCCP in your original submission, you can still submit one as a separate 510(k) or as part of a subsequent modification submission. It is never too late to build this infrastructure -- but it is always more expensive to do it reactively.

Post-Market Obligations Do Not Stop at Clearance

Even with a locked algorithm, your obligations under 21 CFR Part 803 (MDR) and 21 CFR Part 806 remain active. If real-world performance data surfaces unexpected failure modes -- demographic subpopulations where the algorithm underperforms, for example -- that information may require you to act, even if the model itself has not changed. Your post-market surveillance plan should include AI-specific metrics tied to the performance claims in your cleared submission.

What Founders and Regulatory Teams Get Wrong

The most common mistake we see at ADB Consulting is companies treating their cleared AI algorithm the way they treat cleared hardware -- as something static that just gets used. AI models are living artifacts. Your team needs change control processes, algorithm version governance, and a regulatory trigger analysis workflow before the first post-clearance update ever happens. Waiting until the engineering team has already retrained the model is the wrong time to ask the regulatory question.

Ready to Build a Regulatory Strategy That Scales With Your Algorithm?

At ADB Consulting and CRO Inc., we help medical device companies navigate AI/ML regulatory submissions, draft Predetermined Change Control Plans, and build the internal frameworks that keep cleared devices compliant as they evolve. Whether you are pre-submission or already cleared and looking ahead, we can help you move faster without cutting corners.

Book a free discovery call with Andre Butler today at adbccro.com. Let's make sure your next algorithm update does not become your next regulatory problem.

For related guidance, see our Software as a Medical Device regulatory support.