What a Predetermined Change Control Plan actually is, and why FDA created one

A Predetermined Change Control Plan, or PCCP, is a document you submit alongside your initial marketing application that pre-authorizes specific future changes to your AI/ML medical device, so you don't need a new 510(k), De Novo, or PMA every time the model changes. FDA finalized its guidance on this on December 3, 2024 (FDA.gov), and it solves a real problem: AI models learn and improve, but the traditional device pathway assumes a static product. Without a PCCP, retraining your model on new data technically creates a new device, and that means starting the submission clock over.

The trade FDA is offering is straightforward. You tell the agency exactly what you plan to change, how you'll test it, and how you'll know if it's safe, before you make the change. If FDA accepts that plan, you can execute those specific modifications without coming back for permission each time. It's a sensible mechanism. It's also one that quietly assumes something most buyers of AI-enabled medical devices never stop to check: that the manufacturer actually controls the model being modified.

PCCP FDA guidance: why this is happening right now

The short answer is that AI-enabled devices stopped being a niche category years ago and regulators are catching up to volume. FDA authorized 6 AI-enabled devices in 2015. By 2023 that number was 221 (MedTech Dive). A peer-reviewed review in Nature counted 1,016 total AI/ML-enabled device authorizations as of December 20, 2024 (Singh et al., 2025). The most recent public tracking puts the number at 1,451 authorized devices, with 295 cleared in 2025 alone (Medical Futurist). Notably, as of that same tracking, no device has yet been authorized that uses generative AI or is powered by a large language model, which tells you this wave is still mostly narrow, task-specific models, not chatbots reading scans.

The bigger signal is international alignment. In August 2025, FDA, Health Canada, and the UK's MHRA jointly published guiding principles for PCCPs on machine-learning-enabled medical devices (FDA.gov). Three major regulators agreeing on shared principles for the same mechanism means this isn't a US quirk you can route around by launching in Europe or Canada first. If your device roadmap touches AI/ML and you're selling in North America or planning to expand there, the PCCP conversation is coming whether you initiate it or not.

What a PCCP actually requires: three components, no shortcuts

A PCCP has three required parts, and each one gets harder to write honestly the less control you have over your own model. McDermott Will & Schulte's breakdown of the final guidance lays these out clearly (McDermott client alert):

• Description of Modifications: the specific changes you're pre-authorizing, stated precisely enough that FDA (and you, two years later) can tell whether a given update falls inside or outside the plan. "We'll improve model accuracy over time" is not a description of modifications. "We will retrain the classification model quarterly on newly labeled data from Sites A and B, holding the feature set and output classes fixed" is closer.

• Modification Protocol: the exact process you'll follow to make each pre-authorized change, including data management, retraining or re-specification procedures, and the performance testing methods used to validate the update before release.

• Impact Assessment: an analysis of the benefits and risks of each modification type, including what could go wrong and how you'd detect it, both for the device itself and for how it interacts with the rest of your product.

Read those three requirements again and notice the verb tense. Every one of them requires you to describe something you will do, not something a vendor might do to you. That distinction is where a lot of AI-enabled medical device programs are going to run into trouble, and almost nobody selling into this market is saying it out loud.

Can you write a PCCP for a model you don't control?

Here's the direct answer: if your device's AI is a third-party foundation-model API that the vendor can silently retrain, fine-tune, or deprecate on its own schedule, you generally cannot write an honest, defensible PCCP for it, because you can't bound, document, or predict changes you don't make and often can't even see. This is the gap nobody covers when they explain what a PCCP is. Greenlight Guru and IntuitionLabs both do a solid job walking through the definition and the submission mechanics, but neither one asks the question that actually determines whether you can comply: who is making the changes to the model, and do you know when they happen?

Think about what a Description of Modifications is supposed to capture. If your device calls an API from a foundation-model vendor, that vendor can push a model update behind the endpoint with no changelog entry that reaches you, no advance notice, and no obligation to tell you the training data shifted. Some vendors version-pin their models and give enterprise customers deprecation windows. Many don't, especially at the API tier most startups actually buy. If you can't name the exact modification you're pre-authorizing because you don't know what modifications are coming, your Description of Modifications is a guess dressed up as a regulatory document.

The Modification Protocol has the same problem one layer deeper. You're supposed to describe your retraining and validation process. If the retraining happens inside a vendor's infrastructure, using their data pipeline, on their schedule, "our process" is actually "their process, which we don't have visibility into." And the Impact Assessment, which is supposed to analyze the risk of each specific change, can't meaningfully assess a change you learn about after the fact, if you learn about it at all.

None of this means third-party AI is disqualifying by default. It means the vendor relationship itself becomes a regulatory artifact, and most vendor contracts weren't written with that in mind.

What to ask your AI vendor before you build a PCCP-covered device

If a PCCP is on your roadmap, the vendor due diligence conversation needs to happen before the contract is signed, not during the FDA submission. A few things worth demanding in writing:

• Model version freezing. Can the vendor guarantee you'll run a specific, fixed model version until you explicitly opt into an update? Not "we'll notify you," but a contractual commitment that the model behind your endpoint won't change without your action.

• Training data lineage. Can they document what data trained the version you're running, and will they tell you what changes when they retrain? If the answer is "that's proprietary," you have your answer about whether you can write an Impact Assessment.

• Deployment environment control. Is the model running in a shared multi-tenant environment where changes roll out globally, or can you control the update cadence for your instance specifically?

• Audit logging. Can you produce a complete, timestamped record of every inference your device made and which model version produced it, going back through your entire commercial history? FDA and post-market surveillance both eventually ask for this.

• Data retention and deprecation terms. What happens to your device's validation if the vendor sunsets the model version you validated against? Does their standard contract even address this, or does it just say they can update the service at their discretion?

Most vendor contracts, especially the standard API terms of service you click through, answer none of these clearly, because they weren't drafted for regulated medical devices. This is the same pattern we've seen play out with other compliance frameworks: a vendor claiming their tool satisfies a requirement, when what they've actually done is put a badge on their marketing page. Our piece on what ISO 42001 certification actually proves about an AI vendor covers the same dynamic from a different angle: certifications and vendor claims are a starting point for diligence, not a substitute for it.

Build, buy, or self-host: how the decision changes once a PCCP is on the table

The build-vs-buy calculus for AI in general has a well-worn set of trade-offs, and we've laid those out at length in our guide to buying versus building AI. For a device that needs a PCCP, one variable jumps to the top of that list above everything else: can you actually document, in writing, the exact modification process your model will go through, for as long as you sell the device?

If the answer is yes only for a self-hosted or open-weight model running on infrastructure you or your engineering partner control, that's not a preference, it's the requirement talking. A model you host yourself doesn't get retrained without your say-so. Its training data lineage is whatever you decide to document, because you're the one doing the training. Its deployment environment doesn't change unless you change it. None of the PCCP's three components require guesswork, because there's no third party in the loop whose roadmap you're subject to.

This is the same logic behind why Genta AI Solutions runs self-hosted, open-weight models on a client's own infrastructure for regulated or data-sensitive work, with zero data retention outside the client's environment. It's not a compliance checkbox. It's that regulated AI, whether the constraint is HIPAA, a PCCP, or both, requires the manufacturer to be the party who can answer every question a regulator asks about the model's behavior, and you can't answer for a system you don't operate. We've written about the same ownership gap in the context of what HIPAA-compliant AI actually requires beyond a signed BAA: a signed agreement from a vendor tells you they've made a promise, not that you control the thing the promise is about.

None of this means every AI-enabled device needs a from-scratch model. Plenty of narrow, well-scoped classification or triage tasks run fine on smaller, purpose-built models that a vendor can host on dedicated, version-locked infrastructure with real contractual guarantees. The test isn't build versus buy in the abstract. It's whether the specific arrangement you're signing lets you write a truthful Description of Modifications, Modification Protocol, and Impact Assessment two years from now, not just today.

What happens without an approved PCCP

Without an approved PCCP, every AI/ML model change that falls outside your original, already-cleared device specification triggers a new submission cycle, typically another 510(k), and that means new testing, new documentation, and months added to your release timeline for a change you may have already validated internally. This is the practical cost most teams underestimate. A PCCP isn't a nice-to-have regulatory formality. It's the difference between shipping a model improvement in weeks and shipping it after a multi-month submission review, repeated every time you want to retrain.

Companies that skip the PCCP conversation early often find out the hard way when their AI vendor pushes an update that changes model behavior in a way that technically falls outside the original marketing authorization. At that point the choice isn't between fast and slow. It's between an unplanned regulatory scramble and a plan you should have written a year earlier. If you're already building AI functionality into a regulated product, the operational discipline this requires overlaps heavily with the lessons we've covered in what a life sciences AI proof of concept doesn't prepare you for: the gap between a working demo and a defensible, auditable production system is almost always wider than teams expect.

If you're working through whether your current AI vendor relationship can survive a PCCP submission, that's exactly the kind of diagnostic our Discovery phase runs before we touch any code, and it's worth a conversation before you find out the hard way. For teams that conclude a rented model can't clear the bar, our full-stack AI software work is the natural next step, and we're happy to compare notes.

Frequently asked questions

What is a Predetermined Change Control Plan (PCCP) and who needs one?

A PCCP is a document submitted with your device's 510(k), De Novo, or PMA application that pre-authorizes specific future modifications to an AI/ML-enabled medical device, so you can implement those changes without a new submission each time. Any manufacturer whose device's AI or ML component is expected to change after clearance, through retraining or updated data, should consider one.

What are the FDA guidelines for change control on AI medical devices?

FDA's final guidance, issued December 3, 2024, requires a PCCP to include three components: a Description of Modifications, a Modification Protocol, and an Impact Assessment. In August 2025, FDA joined Health Canada and the UK's MHRA in publishing shared guiding principles for PCCPs, signaling international regulatory alignment on the same framework.

Is a new 510(k) required every time I update my AI model?

Only if the update falls outside the scope of an approved PCCP. If you have no PCCP, or the change exceeds what your PCCP pre-authorized, yes, a new submission is generally required. An approved PCCP that specifically covers the type of update you're making lets you skip that cycle entirely.

Can I use a third-party AI model or API and still submit a PCCP?

Sometimes, but only if the vendor contractually guarantees model version stability, documents training data lineage, and gives you visibility into every change before it happens. Most standard API terms of service don't offer this, which means the manufacturer often can't honestly describe modifications they don't control or see coming.

What happens if my AI/ML device doesn't have an approved PCCP?

Every model change outside your original device specification triggers a new marketing submission, adding months of testing and review to release a change you may have already validated. Companies that skip PCCP planning often discover this only after a vendor's model update forces an unplanned regulatory scramble.