Introduction
For years, the standard advice to a device manufacturer with an AI-enabled algorithm was blunt: if you change the model, you file a new submission. That rule made sense when "the model" was a fixed piece of software validated once and left alone. It makes much less sense for a device whose entire value proposition is that it keeps learning from new data. FDA's Predetermined Change Control Plan framework, formalized through guidance for AI-enabled device software functions, is the agency's answer to that mismatch — and it is quietly changing what regulatory affairs work looks like on any team building software as a medical device.
If you work in medical device or diagnostics regulatory affairs, or you are trying to break into that side of the field, it is worth understanding what a PCCP actually commits a company to, because the work of writing and living inside one is different from the work of a traditional 510(k) or PMA submission.
What a PCCP Actually Is
A Predetermined Change Control Plan is a section of a device submission — not a separate filing — in which the sponsor describes, in advance, the specific modifications it intends to make to an AI-enabled function after clearance or approval, the protocol it will follow to develop and validate each modification, and the impact assessment it will run before releasing it. FDA reviews and clears the plan alongside the rest of the submission. From that point forward, changes that fall within the plan's boundaries can be implemented and verified against the pre-agreed methodology without a new marketing submission for each one.
The plan itself has three components that reviewers scrutinize closely: the description of modifications (exactly what kinds of changes are in scope — a retrained model on an expanded dataset, an added input feature, a new performance threshold), the modification protocol (how the sponsor will develop, verify, and validate each change, including the data management and performance metrics used), and the impact assessment (how the sponsor evaluates whether a given change stays within the benefit-risk profile FDA already reviewed).
None of this replaces normal change control obligations. A modification that falls outside the scope the agency cleared still needs a new submission. The PCCP narrows what counts as "new," it does not eliminate the category.
Why FDA Built This Pathway
The agency's stated rationale is straightforward: locked algorithms that never update are safer to review once but can become stale, while algorithms that adapt continuously are harder to review under a framework built around single points-in-time. A PCCP is FDA's attempt to get oversight of the process by which a model changes, rather than trying to re-review every individual change after the fact. It sits alongside the agency's broader interest in software validation, cybersecurity, and real-world performance monitoring for SaMD — a PCCP is not usable in isolation from a company's overall quality system.
What Changes in the Regulatory Affairs Job
For a regulatory affairs professional, the practical shift is that "getting the device cleared" stops being the finish line for a submission and becomes the start of an ongoing obligation. Writing a PCCP well requires regulatory input at a much earlier stage of product development than a traditional submission does, because the modification protocol has to be specific enough for a reviewer to evaluate it without knowing exactly what future data will look like. That pulls regulatory affairs into conversations with data science and machine learning engineering teams earlier and more continuously than most device RA professionals are used to.
After clearance, the work does not stop. Each modification implemented under the plan needs to be documented, assessed against the impact assessment criteria, and — depending on how the company's quality system is built — tracked in a way that can be reconstructed for an audit or a future submission. Regulatory affairs is usually the function responsible for judging, in real time, whether a proposed change is actually within the cleared plan's scope or has drifted outside it. That is a judgment call with real consequences, and it now sits with people who used to only make it once, at submission time.
The Skills This Creates Demand For
Three capabilities show up repeatedly in teams doing this work well. The first is enough technical fluency in how machine learning models are trained and validated to have a real conversation with a data science team — not to build the model, but to ask the right questions about what a "modification" actually is and how performance drift gets measured. The second is comfort writing prescriptive, testable protocols rather than descriptive summaries; a modification protocol that says "we will retrain periodically and check performance" will not clear review, while one that specifies datasets, acceptance criteria, and statistical methods has a chance. The third is the ability to work convincingly with a cross-functional group — software engineering, data science, clinical, and quality — that a traditional device RA career often does not require in the same intensity.
None of this requires a computer science degree. It requires curiosity about how the technology actually behaves and a willingness to learn its vocabulary well enough to hold reviewers and engineers to the same standard.
Where the Friction Still Is
Sponsors and reviewers are both still learning what a strong PCCP looks like, and that shows up as friction in real submissions. Scoping the plan too broadly invites additional information requests; scoping it too narrowly defeats the purpose of having one, since the company ends up filing supplements anyway. Companies that already had a mature software validation and data governance practice before they wrote their first PCCP tend to have an easier time, because the plan is really asking them to formalize and commit to a process, not invent one from scratch under review pressure.
It is also worth being honest that a PCCP is not available to every AI-enabled function. It fits products whose adaptive changes can be meaningfully bounded and specified in advance; it fits less well for functions where the nature of future changes is genuinely unpredictable. Part of the regulatory affairs judgment call, well before a submission is drafted, is whether a PCCP is the right tool for a given product at all.
Documentation Burden and Quality System Implications
A PCCP does not lighten a company's overall documentation load — it redistributes it. Instead of concentrating documentation effort around discrete submission events, a PCCP spreads it across the product's post-market life, and that has real implications for how a quality system needs to be built. Every modification implemented under the plan needs traceable records: what triggered the change, what data was used, what the impact assessment concluded, and what verification and validation activities were run before release. Regulatory affairs is often the function that has to make sure this documentation trail is complete and internally consistent, even when the actual technical work is happening inside a data science or engineering team that may not be used to FDA-grade recordkeeping.
This is where companies with an already-mature software quality and data governance function tend to move faster than companies bolting a PCCP onto a looser process. If your organization's data science team is used to iterating quickly with informal validation, part of the regulatory affairs role becomes translating "good enough for an internal release" into "defensible in front of a reviewer or an auditor" — without becoming the bottleneck that makes the whole point of having a PCCP moot.
What This Means If You're Job Hunting
If you are looking at medical device or SaMD regulatory roles, PCCP experience — or credible adjacent experience with adaptive software, cybersecurity documentation, or continuous verification and validation processes — is becoming a meaningful differentiator, particularly at digital health and diagnostics companies building anything with a learning component. You do not need to have written one yourself to speak to it intelligently in an interview. Being able to explain what a modification protocol needs to contain, and why the impact assessment matters, signals that you understand where device regulatory affairs is heading rather than where it has been.
If your current role does not touch this kind of work, look for opportunities to sit in on software validation or data governance discussions even when they are not formally part of your job. That exposure is what will let you speak credibly about this the next time it comes up — in a job interview or in your own company's next submission.
It is also worth reading a handful of cleared PCCPs, where publicly summarized, alongside the agency's guidance on the topic before an interview. Being able to talk through a concrete example — what modifications a real device's plan covers, how its protocol is structured — carries more weight with an interviewer than reciting the framework in the abstract. Hiring managers in this space tend to have sat through a lot of candidates who can define a PCCP and very few who can discuss how one actually reads.
Conclusion
The Predetermined Change Control Plan is a genuine shift in how FDA thinks about oversight for a category of device that does not sit still after clearance. For regulatory affairs professionals, it moves the job earlier into development, ties it more closely to data science and engineering, and turns post-market change management into an ongoing, documented practice rather than an occasional supplement. That is more work, but it is also a clearer story for anyone building a career in medical device or SaMD regulatory affairs about where the field's technical center of gravity is moving.