The growth in FDA-authorized AI devices is real progress. But there is a question that number does not answer, and it is the more important one: of those 1,350+ devices, how many have a post-market monitoring protocol that would actually detect performance degradation before it reaches a patient?

That is what the Predetermined Change Control Plan — PCCP — is supposed to be the governance layer for. And in most of the Tier 2 and Tier 3 MedTech companies I work with, the PCCP is the document that exists on paper but does not function in practice.

Why PCCP Exists — And What It Is Actually For

AI models are not static. This is the foundational fact that makes AI regulation different from traditional medical device regulation, and it is the reason FDA created the PCCP framework in the first place.

A traditional medical device — a catheter, a surgical instrument, an implant — is the same device after FDA clearance that it was before. Its performance characteristics do not change based on the data it encounters in the real world. An AI model does. It gets retrained. New data changes its behavior. Edge cases it was never trained on appear in clinical deployment. The deployment population is never exactly the same as the validation population used for the 510(k) submission.

FDA's PCCP guidance exists precisely to acknowledge this. It requires manufacturers to document, before clearance, how they will manage changes to an AI model after it is already on the market — what they will monitor, what thresholds will trigger revalidation, and what types of changes are significant enough to require a new submission rather than falling within the scope of the approved PCCP.

// THE CORE PRINCIPLE

A PCCP is not just documentation of what you plan to do. It is a binding commitment, reviewed by FDA, about what types of changes your AI model can undergo without requiring a new 510(k). If your model changes in a way not covered by your approved PCCP, that change may itself require a new submission.

The Three Things a Credible PCCP Must Define

Most companies that have written a PCCP have addressed the high-level requirements. What they have typically not done is get specific enough in three areas where vagueness becomes a real regulatory problem.

01 //
What you will monitor — and what metrics
A credible PCCP names specific performance metrics that will be tracked in post-market surveillance — not general statements about "monitoring performance." It specifies whether you are tracking AUC, sensitivity, specificity, or a different metric; whether you are tracking these overall or by demographic subgroup; what data source you are using; and how frequently the monitoring occurs. Vague monitoring commitments look fine during submission and fail immediately in practice because no one knows what to actually measure.
02 //
What threshold triggers a revalidation event
This is the most commonly missing element. A PCCP needs to state, specifically, at what point a change in monitored performance is significant enough to trigger a formal revalidation. That threshold needs to be defined quantitatively — a percentage decline in a named metric, a change in confidence interval, a specific drift detection outcome — not described qualitatively as "significant degradation." Without a defined threshold, the PCCP provides no actual governance because there is no trigger that anyone is required to act on.
03 //
What constitutes a modification requiring a new 510(k)
The PCCP must define the boundary between changes that fall within its scope — and therefore can be implemented without a new submission — and changes that are significant enough to require FDA review. This is the boundary most companies have not clearly defined during development, and it is substantially harder to draw after clearance when a real modification decision is on the table and commercial pressure is high. The PCCP needs to name the types of changes (new training data, new features, architecture changes, new intended use populations) and specify which category each falls into.

The Retrofit Problem — Why Doing This Post-Clearance Is Harder

Writing a credible PCCP during the pre-submission development phase is challenging. Writing one after clearance, when the device is already in clinical deployment and commercial pressure is building, is significantly harder — and the result is almost always weaker.

Here is the practical dynamic: once a device is in the field, any proposed threshold definition is immediately evaluated against the current state of the model, not against abstract principles. If you propose a revalidation trigger of a 5% decline in sensitivity, your commercial team will immediately note that the model's current field performance is already within 4% of the validation data sensitivity, and the conversation shifts from "what is the right threshold?" to "what threshold avoids triggering revalidation right now?"

// THE RETROFIT TRAP

PCCP thresholds written post-clearance under production pressure tend to be calibrated to avoid triggering revalidation rather than to actually detect meaningful performance degradation. A PCCP written this way satisfies the documentation requirement but does not function as a governance mechanism — which is what FDA intended it to be.

The right time to define PCCP thresholds is during the validation study itself, when you have clean data, no commercial pressure, and the ability to run sensitivity analyses on what different threshold choices would actually mean in practice. That window closes at submission.

The Deployment Population Problem — Where Performance Gaps Actually Live

There is a related issue that PCCPs frequently fail to address: the validation population and the deployment population are not the same, and the PCCP monitoring specification needs to account for that explicitly.

Most AI medical devices are validated on a dataset that, even when carefully constructed, represents a narrower slice of clinical reality than the device will encounter in actual deployment. Different hospital systems have different imaging equipment, different clinical workflows, different patient demographics, and different data quality characteristics. The model's performance in deployment is a function of how well the deployment environment matches the validation environment.

A credible PCCP acknowledges this explicitly. It identifies the ways in which the deployment population may differ from the validation population, names the performance metrics most likely to be affected by those differences, and specifies how the monitoring protocol will detect drift attributable to population mismatch versus drift attributable to model degradation.

Most PCCPs treat the validation population and the deployment population as interchangeable. FDA's guidance does not, and hospital systems increasingly do not either.

What Independent Evaluation Catches That Internal Teams Miss

The PCCP gaps described above are almost never the result of negligence. They are the result of internal teams evaluating their own documentation — which means they are reading it with the same assumptions they used when writing it.

When an internal regulatory team reviews a PCCP, they know what the monitoring thresholds are supposed to mean. When an FDA reviewer or a hospital compliance team reads the same document without that context, the gaps in specificity become visible immediately.

Independent evaluation of PCCP documentation applies external eyes — someone who is reading the document the way an FDA reviewer will read it, not the way the team that wrote it reads it. The questions are different: not "does this describe what we plan to do?" but "is this specific enough to be enforceable, actionable, and sufficient as governance when something actually goes wrong?"

ClearanceAI reviews PCCP documentation as part of every medical device AI evaluation — alongside bias assessment, regulatory clause mapping, and the full 9-section compliance report. The evaluation identifies specifically where PCCP commitments are too vague to function as governance and where threshold definitions need to be tightened before they become a problem in deployment or in a regulatory interaction.

If your AI model has been cleared and has changed since clearance — or if your PCCP was written primarily to satisfy the submission requirement rather than to function as actual governance — that gap is worth addressing before an FDA inspection or a hospital procurement question surfaces it first.

The 2-minute self-assessment at clearanceai.ai is a starting point. It surfaces, without any model access or commitment, where the most common compliance gaps are likely to live in your current documentation.