# Regulatory strategy for AI/ML devices
Imagine your diagnostic algorithm flags diabetic retinopathy from a retina scan. It works. Then, six months after launch, your data science team retrains it on 40,000 new images and accuracy jumps two points. In most software, you ship the update Tuesday. In a regulated medical device, that update could be an unauthorized modification that puts you out of compliance overnight.
This is the central tension of AI in medtech: the whole value of machine learning is that it improves as it learns, but regulators approve a fixed, frozen product. This lesson maps how the FDA and the EU handle that tension, so you can build a go-to-market strategygo-to-market strategyThe strategy defining how you'll launch a product: target segments, channels, value proposition and coordinated action plan.Voir la définition complète → that survives your own model updates.
SaMD (Software as a Medical Device) is software intended for a medical purpose that performs that purpose without being part of a hardware device. An app that reads an ECG and flags atrial fibrillation is SaMD. The firmware inside an infusion pump is not (it is software *in* a device).
Most standalone AI/ML products in diagnostics, triage, and clinical fall under SaMD. That classification is your entry point into both the US and EU systems.
Two things drive how heavily you get regulated:
In the US, most SaMD reaches market through the 510(k) route (you show your device is "substantially equivalent" to an already-cleared device) or, for novel low-to-moderate risk devices, the De Novo route. Higher-risk devices need premarket approval (PMA), a much heavier lift.
The FDA has cleared hundreds of AI/ML-enabled devices already. The agency maintains a public list of AI/ML-enabled medical devices, which is the single best free resource for seeing what has actually been authorized and in which specialties. Study it before you design your submission: it tells you which predicate devices exist for a 510(kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Voir la définition complète →).
Here is the catch. Traditionally, the FDA cleared a *locked* algorithm. Change the model in a way that could affect safety or performance, and you generally needed a new submission. For a continuously-learning system, that means a regulatory filing every time you retrain. Commercially impossible.
The FDA's answer is the Predetermined Change Control Plan (PCCP). This is the most important concept in this lesson.
A PCCP lets you describe, *in advance and as part of your original submission*, the changes you plan to make to your model and how you will make them safely. If a future change falls inside the approved plan, you can implement it without a new marketing submission.
A PCCP has three parts:
1. Description of Modifications. Exactly what you intend to change. For example: "retrain on new data from the same population to maintain sensitivity" or "expand to a new age range." Vague plans get rejected.
2. Modification Protocol. The methods: how you will collect data, retrain, validate, and set acceptance criteria (the performance thresholds a new version must hit before release).
3. Impact Assessment. An analysis of the risks each change introduces and how the protocol controls them.
The FDA finalized its PCCP guidance in December 2024, which moved this from concept to operational reality. If you are building a learning system for the US, a PCCP is now your default strategy.
A PCCP is a boundary, not a blank check. Changing the intended use (say, moving from "aid to a clinician" to "autonomous diagnosis"), adding a new clinical claim, or changing the target population beyond your plan all fall outside it and require a new submission. Design the boundary deliberately: too narrow and you file constantly, too broad and the FDA rejects it.
The EU regulates the same software under the Medical Device Regulation (MDR), which fully replaced the older Medical Device Directive in 2021. The philosophy is different, and this matters for your global launch sequence.
Key differences from the US:
The practical consequence: a change that is pre-authorized under your US PCCP might still require you to go back to your Notified Body in the EU. Your update cadence may effectively be governed by the stricter of the two systems if you sell in both.
Now combine the pieces for our continuously-learning retinopathy algorithm.
Step 1: Lock the intended use narrowly at launch. Claim "aid to a trained clinician," not "autonomous screening." This lowers your risk class in both regions and keeps model updates inside the boundaries you can pre-authorize.
Step 2: Write an ambitious but defensible PCCP for the US. Include the retraining you *know* is coming (periodic refresh on new images from the same population) but exclude speculative expansions. Define hard acceptance criteria, for example: a new version must not drop sensitivity below the cleared baseline on a held-out test set representative of the intended population.
Step 3: Sequence your markets. Many AI medtech companies pursue FDA authorization first, both because the PCCP gives cleaner update rights and because the predicate system can be faster for a device with existing comparators. Treat EU entry as a separate workstream with its own Notified Body timeline.
Step 4: Build the monitoring you will need anyway. Both systems expect post-market surveillance: ongoing tracking of real-world performance. For AI, the specific risk is data drift, where the live data distribution moves away from your training data and quietly degrades accuracy.
A minimal drift monitor is genuinely simple to describe:
# Flag distribution shift between training and live inputs
from scipy.stats import ks_2samp
def drift_check(train_scores, live_scores, alpha=0.01):
stat, p_value = ks_2samp(train_scores, live_scores)
return p_value < alpha # True = significant drift, investigate
# In production this feeds your PCCP retraining trigger and
# your MDR post-market surveillance file.Regulators do not mandate this exact test, but they do expect evidence that you can detect degradation before patients are harmed. Wire your monitoring outputs directly into both your PCCP retraining triggers and your MDR surveillance documentation.
Vérification des acquis
1. What is the fundamental tension between machine learning and medical device regulation described in the lesson?
2. An app that analyzes an ECG signal and flags atrial fibrillation on its own would most likely be classified as which of the following?
3. Two AI tools analyze the same type of scan. Tool A autonomously rules out disease; Tool B suggests possible findings to a radiologist who makes the final call. Why would Tool A generally face heavier regulatory scrutiny?
4. Select ALL correct answers about the factors that drive how heavily an AI/ML SaMD product is regulated.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about FDA market pathways for SaMD.
Sélectionnez toutes les réponses correctes.
Treating the PCCP as an afterthought. It belongs in your original submission. Retrofitting one later means a new filing.
Writing a PCCP so broad the FDA rejects it. "We may change the model as needed" is not a plan. Specificity is what earns you the pre-authorization.
Assuming FDA clearance carries into the EU. It does not. They are separate authorizations with different logic (predicates versus rules, PCCP versus significant-change assessment).
Forgetting the humans. Both regimes increasingly scrutinize human factors: how a clinician actually uses the output. An algorithm that is technically accurate but nudges users toward automation bias can still fail review.
*This lesson is educational and is not legal or regulatory advice. Consult qualified regulatory counsel for any specific product.*