I work with SaMD teams every day. Most of them know the regulatory landscape is shifting around AI. Fewer have actually read the guidance documents. And almost none have thought through how a predetermined change control plan (PCCP) would expose the gaps in their current quality system before those gaps become a submission problem.
That's what I want to talk through here, because the window to get ahead of this is narrowing.
You don't have to be shipping AI today for this to matter
One of the first things I say when I talk about PCCP: this isn't just for teams with AI/ML already in their product. FDA has been watching how vendors respond to both finalized and draft guidance (see our breakdown of the FDA guidance on AI-enabled devices), and precedents are forming in live submission interactions right now. Building your quality infrastructure before your AI ships is significantly cheaper than retrofitting it after, and the teams further along in AI readiness are already moving.
There are three situations I see regularly. First, teams that are already shipping an AI-enabled device and plan to update it. These teams get the clearest benefit from a well-structured PCCP, but many haven't built one yet. Second, teams with AI in active development, who need to be tracking not just FDA guidance, but IMDRF, the EU AI Act, and ISO 42001, all of which are adding requirements around AI governance. Third, teams not yet building AI modules, where the quality infrastructure is still what any future PCCP will be built on top of. If that foundation isn't solid, the PCCP won't hold.
What PCCP actually is (and what it isn't)
A predetermined change control plan is exactly what the name says. Before you ship an AI-enabled device, you tell FDA in advance what specific modifications you plan to make after clearance, what protocol those changes must go through, and how each change would affect end users and clinical workflows. In exchange, FDA pre-authorizes a pathway for those changes. That means you can retrain your algorithm, expand compatible hardware, or improve performance within a specific patient cohort without filing a new 510(k) every time.
For teams that have been stuck in sequential submission cycles, this is genuinely significant. Planned well, the PCCP roadmap becomes a competitive advantage. You can iterate your product much faster than teams that need to go back to FDA with every meaningful algorithm update.
But the boundary matters as much as the pathway. A PCCP can cover performance improvements within your cleared intended use, threshold refinements, retraining on additional datasets within a defined population, and expansion to compatible acquisition hardware. What it cannot do is expand your intended use, change your patient population, or authorize modifications that meaningfully shift the risk-benefit profile. Those still require a new submission. The PCCP defines the line between what you can do unilaterally and what requires going back.
For a deeper look at how the PCCP requirement works, that post goes into the structure of the plan itself in more detail.
The three-pipeline problem most QMS architectures don't address
Traditional software development under IEC 62304 governs what I call the software code pipeline: your heuristic code base, your SDLC, your version-controlled codebase. Most QMS architectures are built around that. But the moment you introduce AI/ML, you now have two additional pipelines: the data pipeline and the machine learning pipeline.
Your data scientists own the data pipeline, ML engineers own the training and model pipeline, and software engineers own the code pipeline. And eventually all three have to produce documentation that coheres into a submission package.
When these three functions don't share a documentation framework from the start, a predictable sequence follows. Regulatory affairs gets pulled in after development. The audit trail reflects the regulatory team's interpretation of what engineers built, not the engineers' understanding of what they actually produced. The records don't adequately reflect the product. The device ends up in a technically unvalidated state, even if nobody intended that.
A PCCP is a binding agreement with FDA. But if your underlying ML processes are underdeveloped, the agreement doesn't protect you. FDA expects those processes to be solid before they accept a PCCP. This is not a documentation problem. It is an infrastructure problem.
Understanding how software development lifecycle maps to design controls for SaMD is foundational here, because the same principle applies: your development artifacts need to be traceable before they become regulatory records.
Where QMS gaps show up in practice
The three highest-risk areas I see in traditional quality systems that haven't been updated for AI/ML work are design controls, change control, and post-market surveillance.
On design controls: an AI-embedded SaMD (software as a medical device) submission typically requires 10 to 20 more records than a traditional device submission. Your design inputs need to include model performance requirements, training data requirements, validation data requirements, and data quality thresholds. None of those appear in standard design history file templates. FDA isn't going to tell you this is missing at submission time. They'll push back on the package.
On change control: a standard engineering change order process will miss data-driven changes entirely. When your team retrains on a new dataset, adjusts preprocessing parameters, or updates training class weights, those changes need to be captured as formal change records. If FDA asks for your change history and audit trail during a post-market inspection, and you can't produce it, you have a serious problem that no retroactive documentation will fix.
On post-market surveillance: a complaint log is not a performance monitoring system. FDA now expects SaMD teams to specify what data they collect, at what frequency, against what ground truth, using what statistical method, and who owns the decision when drift is detected. This is active monitoring, not reactive reporting.
The PCCP and your post-market surveillance system are not two separate compliance boxes. They are one integrated feedback loop. Real-world performance data from deployed devices should be informing your next round of PCCP modification boundaries. If that feedback loop isn't designed, your PCCP will drift out of sync with your actual product behavior.
One failure mode I've seen in actual FDA interactions deserves attention. A company's regulatory engineer cited their AI tool as the reason for a compliance decision, essentially deferring to the algorithm rather than the responsible person. FDA's response made clear that human accountability does not transfer to a model, regardless of how sophisticated the tool. The phrase "the AI told us to do it" is not a justification. Accountability stays with the team. That obligation is not negotiable.
Your ML ops pipeline is your evidence base
One framing I come back to often in my work: your ML ops infrastructure, including experiment tracking tools like MLflow, your model registry, your data versioning system, and your deployment pipeline, is not just engineering scaffolding. They are your evidence generation infrastructure.
Every run log, every model version, every dataset version, every preprocessing change: these are the artifacts that regulatory affairs needs to build your change records, your audit trail, and ultimately your PCCP documentation. If that infrastructure isn't generating clean, traceable artifacts, you cannot retrospectively create them. Some artifacts cannot be reconstructed after the fact. I've seen this situation close down PCCP options for teams that thought they were close to submission-ready.
Regulatory thinking needs to enter your architecture decisions, not your documentation phase. The question your regulatory and quality team should be asking your engineering team at the architecture stage is: how do we capture the right information now, so that we can produce the records FDA will ask for later?
What getting this right actually looks like
Teams that develop genuine PCCP competency gain something beyond compliance. They can iterate their product faster and with more confidence. They maintain performance claims over time, which builds credibility with clinicians and hospital systems. They present a cleaner story to FDA on subsequent submissions, because a company with a history of post-market shortcuts gets extra scrutiny on everything they submit afterward.
The starting point for most teams isn't writing a PCCP. It's auditing whether their current quality system is structured to support one. That means looking honestly at whether your change control process captures data-driven changes, whether your post-market surveillance plan can detect algorithm drift, and whether your development team's artifacts are making it into your quality records in a form that regulatory reviewers can actually use.
The SaMD software as a medical device pillar guide covers the broader regulatory framework that PCCP fits inside. If you're newer to the SaMD regulatory picture, that's a good place to start before going deeper on PCCP-specific requirements.
Go deeper: watch the full session
I covered all of this and more, including audience questions on PCCP scope, architectural change boundaries, and how to use AI as a review tool without creating accountability problems, in my session at the Greenlight Guru Software Enabled Devices Virtual Summit. Watch the full on-demand recording here, where I walk through the three-pipeline framework, QMS gap analysis, and practical steps for teams at each stage of AI/ML readiness.
Keep reading
If you are working through your SaMD quality and regulatory setup, these guides go deeper on the key components:
- Software as a medical device: the ultimate guide to classification, compliance, and development
- FDA guidance on AI-enabled devices: what the lifecycle management draft and finalized PCCP guidance actually say
- What is a predetermined change control plan and who needs one
- ALM and design controls: connecting your development workflow to quality records
- SaMD classification: how FDA and IMDRF categorize software as a medical device
- IEC 62304: the software lifecycle standard every SaMD team needs to understand
BONUS RESOURCE: Click here to download the 3-in-1 SaMD Gap Assessment Tool.
BONUS RESOURCE: 3-in-1 SaMD Gap Assessment Tool
