FDA's evolving guidance on adaptive AI: reading between the lines

PCCP is a strategy document

The Predetermined Change Control Plan (PCCP) framework lets sponsors pre-authorize a defined envelope of model updates. Most teams treat it as a compliance artifact drafted at the end of a submission. The teams that treat it as a strategy document — written first, with input from product and commercial — ship five to ten times more updates per year without a new submission.

What to include in the envelope

Define the modification types you can plausibly justify — retraining on new sites, threshold tuning, minor architecture changes. Define the acceptable performance corridor for each. Define the monitoring cadence and the rollback protocol.

The FDA reviewers we have spoken with reward specificity. Vague envelopes get narrowed. Specific envelopes get approved as written.

Post-market surveillance is the price of admission

A PCCP without a serious monitoring plan will not survive review. Real-world performance dashboards, drift detection, and a documented escalation path are now considered baseline.

Build regulatory into the release process

The best AI-enabled device teams treat every release like a controlled experiment. The regulatory lead sits in the release meeting. Deployment gates require sign-off. This sounds slow. It is what actually enables speed at scale.

Scoping the change envelope realistically

The temptation when drafting a predetermined change control plan is to scope the envelope as broadly as possible, requesting flexibility for every conceivable future modification. In practice, an overly broad envelope invites more reviewer scrutiny and a longer back-and-forth, because the agency needs confidence that the monitoring plan can actually detect problems across that entire scope.

A narrower, well-justified envelope tied to a specific, well-understood performance metric tends to move through review faster and gives the company a cleaner precedent to expand from in a later submission. Founders often discover, after the fact, that the modest first envelope was the faster path to iteration speed, not the constraint they feared it would be.

The monitoring plan is where credibility is won or lost

A change control plan is only as strong as the monitoring plan behind it, and reviewers scrutinize whether a company can actually detect performance drift in the field before it causes harm, not just whether the statistical methodology looks sound on paper. Companies that describe a monitoring plan in the abstract, without a concrete data pipeline already built to support it, tend to draw more questions.

The stronger submissions come from teams that have already built and tested their drift-detection infrastructure internally, using retrospective data, before the submission is filed. This turns an abstract commitment into a demonstrated capability, which is a meaningfully different conversation with a reviewer.

Real-world performance data as an ongoing obligation

Clearance under an adaptive framework is not a one-time event; it comes with an ongoing obligation to collect and report real-world performance data, and companies that treat this as a compliance checkbox rather than an operational function tend to fall behind on reporting cadence within the first year. This is a genuine operational cost that needs a budget line and a named owner, not a shared responsibility that quietly falls to no one.

The teams handling this well have built post-market surveillance into their core product analytics rather than as a separate compliance system, which means the same infrastructure that tracks performance drift for the business also generates the regulatory reporting artifacts, cutting duplicated effort substantially.

Making regulatory a gate in the CI pipeline

The companies most comfortable operating under an adaptive AI framework have restructured their engineering release process so that a regulatory review checkpoint sits inside the normal software release pipeline, rather than as a separate, occasional process that engineering has to remember to trigger. This means every model update is automatically checked against the boundaries of the approved change envelope before it ships.

For founders building toward this framework, the practical starting point is not the regulatory submission itself but the internal engineering discipline: version every model, log every training data change, and make the connection between a specific release and its underlying evidence trivial to reconstruct. That discipline is what a future submission will actually be graded on.