A PCCP pre-clears how an AI device can change

A cleared AI-enabled device that later needs an updated model normally faces the same fork every modified device faces: does this change need a new marketing submission, or can the manufacturer's own change-control record carry it? FDA's guidance, finalized December 2024 as Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, offers a third option for this one category of device: a Predetermined Change Control Plan, authorized inside the original marketing submission, that names in advance a bounded set of future modifications FDA has already reviewed and doesn't need to see again when they happen. A PCCP doesn't excuse a device from the ordinary modification analysis. It's a narrow, pre-negotiated exception carved out of it — and it only covers the modifications the plan actually named.

Three things the plan has to contain

The guidance structures a PCCP around three required components. The Description of Modifications states, specifically, what future changes the manufacturer intends to make without a new marketing submission — a retraining on an expanded dataset, an updated performance threshold, a defined recalibration — not an open-ended commitment to “improve the model over time.” The Modification Protocol lays out the methods that will develop, validate, and implement each named modification: how data gets managed, how retraining runs, how performance gets re-evaluated, and how the update itself gets released. The Impact Assessment then ties the two together, weighing the benefits and risks the named modifications and their protocol actually introduce. A submission that names a modification without a protocol specific enough to verify hasn't given FDA a plan to authorize — it's given the agency a promise.

The scope widened from ML to AI between draft and final

FDA's 2023 draft guidance covered a narrower category: Machine Learning-Enabled Device Software Functions, models built specifically to keep learning from new data after clearance. The December 2024 final guidance broadened that scope to AI-Enabled Device Software Functions generally, reaching AI techniques that don't necessarily retrain themselves on real-world data at all. The final guidance also swapped its own language throughout, from “training and test data” to “training, tuning, and testing data” — a small wording change that matters because it names the intermediate step, model tuning, that the draft's two-part framing had left out of the record a PCCP has to document.

A PCCP pre-answers a question, it doesn't retire it

21 CFR 807.81(a)(3)'s own two-prong test still runs underneath every AI device modification, PCCP or not — a PCCP is best understood as FDA pre-answering that test for a specific, bounded set of future changes, rather than a device category exempted from it. A modification implemented exactly as the authorized plan describes, using the validated protocol, doesn't need the two-prong analysis run fresh, because FDA already ran it against the plan itself. A modification that drifts outside what the plan actually named — a different kind of retraining, a threshold change the protocol didn't anticipate — falls straight back to the ordinary new-submission question, and the PCCP offers it no cover at all.

The Q-Submission program is where the plan gets shaped, not just filed

FDA's guidance recommends using the Q-Submission program to get feedback on a draft PCCP before it's finalized inside the marketing submission itself — the same program a well-built Q-Sub request is built to use for any question a sponsor would rather resolve before committing it to a filing. A PCCP drafted cold, without that feedback, risks a reviewer pushing back on a modification protocol's specificity or an impact assessment's assumptions at the point where a rewrite costs the most: after the marketing submission has already been filed.

Where this meets the rest of the file

A PCCP's modification protocol still has to answer to the device's own software classification once a named modification is actually implemented — IEC 62304's own class-scaled documentation doesn't relax because the change was pre-authorized rather than freshly submitted, and neither does the underlying hazard analysis a modification of this kind can touch. The plan authorizes the change; it doesn't substitute for the development-process record the software's own class already requires when that change actually ships.

A PCCP-scoping worksheet built around these three components — a named modification, a specific protocol, and an impact assessment tied to both — is previewed in the launch catalog. If your program structures a PCCP differently, the shelf takes that correction directly.