FDA change control plans for AI medical devices: what engineering teams need to build

What the FDA finalised

In December 2024 the FDA finalised its guidance on marketing submission recommendations for PCCPs for AI-enabled device software functions¹². The idea is simple: describe the changes you plan to make in your original submission, and if the plan is authorised, you can make those changes within its bounds without a new submission each time¹.

Commentators note two points. The final guidance broadened scope from machine-learning devices to AI-enabled device software functions generally, while staying most relevant to ML. And it stayed close to the 2023 draft in structure¹². Like all FDA guidance, it is non-binding, but it signals what reviewers expect.

In January 2025 the FDA also published a broader draft guidance on lifecycle management and marketing submissions for AI-enabled devices, covering the total product life cycle³⁴. Law-firm analyses highlight its focus on transparency, bias, data quality, human factors, change management and cybersecurity⁵.

The three parts, as engineering work

The platform a PCCP assumes

1. Data lineage end to end. Every training example traceable to its source, version and consent basis. In clinical settings that usually means a governed data layer, often OMOP-based for retrospective data, with the quality controls in my OMOP data quality post.
2. Locked, representative test sets that are never trained on, stratified by the subgroups you committed to monitor.
3. Reproducible pipelines. Code, data snapshot, environment and random seeds versioned together, so any model can be rebuilt.
4. Automated acceptance gates that encode the protocol's criteria. A candidate model that misses a threshold on any committed subgroup does not ship. This is the same discipline as evaluation sets that predict production, with higher stakes.
5. Controlled rollout and rollback, with real-world performance monitoring after release.
6. An audit trail linking each deployed model to its data, tests, results and approvals.

Common mistakes I'd avoid

• Writing the plan before the platform exists. A PCCP describing a pipeline you don't have is a promise you can't keep.
• Scoping too broadly. Narrow, well-tested change types are easier to authorise and to execute than open-ended ones.
• Ignoring subgroup performance. Average accuracy can improve while a subgroup gets worse. Commit to the subgroups that matter clinically and monitor them.
• Treating it as a regulatory document only. The best plans are written jointly by regulatory, clinical and engineering leads, and the engineering team owns the protocol.

Beyond the US

Teams selling into Europe face the EU AI Act alongside medical device regulation, with high-risk obligations for AI in regulated products now pushed to August 2028 under the Digital Omnibus, as I cover in the EU AI Act after the Digital Omnibus. The good news is that the same platform, with lineage, locked tests, gates and audit trails, serves both.

How I can help

I design clinical data and ML platforms that can support a change control plan: governed data, reproducible training, evaluation gates and audit trails. See healthcare data architecture, or analyse your challenge and bring the result to a call.