Shipping Model Updates Under FDA Rules: What a PCCP Demands of Your Architecture

The locked-model problem

Machine learning's core promise is improvement: retrain on new data, recalibrate, get better. Medical device regulation's core assumption is stability: the thing FDA cleared is the thing patients get. Historically these collided — a cleared AI device was effectively frozen, because a significant model change meant a new marketing submission, with the cost and calendar that implies.

Meanwhile the world drifts. Patient populations shift, clinical practice changes, upstream data pipelines evolve. A frozen model does not stay as good as the day it was cleared; it quietly degrades against reality. The regulatory framework needed a way to allow planned change without re-clearance, and that is exactly what the PCCP is.

What a PCCP actually is

A Predetermined Change Control Plan is part of your marketing submission — FDA finalized its guidance for AI-enabled device software functions in August 2025, and it applies across the 510(k), De Novo, and PMA pathways. The plan has three parts: a description of the modifications you intend to make after clearance, the methodology you will use to develop, validate, and implement each one, and an assessment of the impact of those changes.

The deal is explicit: changes covered by an authorized PCCP can ship without a new submission, provided each one is executed exactly as the plan describes. A change outside the plan — a new intended use, a new input type, a modification your validation methodology does not cover — still triggers a submission. The PCCP is a lane, not a license.

Your MLOps pipeline becomes the compliance mechanism

Read as an architect, the PCCP is a specification for your ML platform. If the plan says every model update runs a defined validation protocol against a defined dataset with defined acceptance criteria, then your pipeline must enforce that protocol — automatically, reproducibly, and with evidence. Model versioning with full lineage (data, code, hyperparameters), validation gates that block promotion on failed criteria, deployment records tying every production model to its validation run, and rollback that actually works: each of these is now the thing an auditor checks, not just good practice.

Monitoring closes the loop. The impact assessment in your plan implies you can detect when a deployed model behaves outside expectations — which means production performance monitoring against the same metrics your validation used, and an escalation path when they drift. Teams that already run disciplined MLOps find the PCCP mostly asks them to write down what they do and then never deviate. Teams that ship models by hand discover the plan is unimplementable.

A PCCP is a promise about process. Your architecture is what makes the promise keepable.

Designing for the plan before you need one

Even if your current product sits safely outside device regulation, build as if a PCCP is in your future. The ingredients — lineage-complete versioning, automated validation with explicit acceptance criteria, deployment audit trails, drift monitoring — are the same ones a rigorous engineering culture wants anyway, and retrofitting them onto a pipeline that grew organically is far more expensive than designing them in.

FDA's January 2025 draft guidance on lifecycle management for AI-enabled device software signals where expectations are heading: transparency, bias evaluation, and lifecycle discipline across the whole span from data collection to decommissioning. It is still a draft, but as a directional signal it is unambiguous — the bar for shipping AI into clinical settings is a managed lifecycle, not a cleared snapshot.