Here is a problem the previous lesson left deliberately unsolved. Validation assumes a system is stable between validated states: you qualify it, you place it under change control, and you re-qualify when someone deliberately ships a new version. But the entire point of some artificial intelligence is that it does not hold still. An AI that learns from new data after you deploy it changes its own behavior, on purpose, as a feature, and the classic regulatory model has no native slot for a system that is supposed to improve itself in the field. The FDA confronted exactly this problem for AI-enabled medical devices and produced a genuinely novel answer: the Predetermined Change Control Plan, finalized in December 2024 and revised in January 2025 for AI-enabled device software functions. The PCCP lets a manufacturer specify, in advance, the changes an AI is allowed to make to itself, the protocol by which it will make and test them, and the assessment of their impact, so that the device can evolve within pre-authorized boundaries without a new submission for every update. This lesson explains the PCCP in plain English, draws the precise line around where it legally applies, and then shows why its conceptual architecture has been borrowed across the industry as the working pattern for any production AI that learns inside a regulated workflow, while being scrupulously clear that borrowing a pattern is not the same as a drug-submission requirement.

The Problem the PCCP Was Built to Solve

Begin with the tension, because the PCCP only makes sense as a resolution of it. A traditional medical device is locked: its behavior is fixed at clearance or approval, and any significant change to that behavior requires the manufacturer to come back to the agency, often with a new premarket submission, before the change can reach patients. This works because a conventional device does not change on its own. An adaptive AI/ML device breaks the assumption at its foundation, because its value often comes precisely from continued learning: a model that improves its detection of a pathology as it sees more cases, or that recalibrates as a patient population shifts, is doing the thing it was designed to do when it changes. Forcing a fresh submission for every such change would either freeze the AI into uselessness or bury the agency and the manufacturer in continuous filings.

The FDA's insight was to move the regulatory review earlier in time. Instead of reviewing each change after it is conceived, the agency reviews, up front, the plan that governs an entire class of future changes. If the manufacturer can specify in advance what kinds of changes the AI may make, exactly how those changes will be developed and validated, and what their impact will be, then the agency can authorize that envelope of change once, and the device can move within it without returning for each step. The PCCP is, in essence, pre-authorized change: a contract, agreed before the changes happen, about what change is permitted and how it will be controlled. It is one of the most genuinely innovative ideas in modern device regulation, because it adapts the static-system assumption of traditional validation to a system whose defining property is that it does not stay static.

The Three Elements of a PCCP, in Plain English

A PCCP has a clear three-part structure, and understanding the three parts is understanding the whole framework. The first element is the description of modifications: a specific, bounded statement of the changes the AI is permitted to make to itself. This is not a blank check to change anything; it names the kinds of modifications in scope, for example retraining on new data of a specified type, adjusting certain parameters within stated limits, or expanding to a defined new input source, while everything outside that description remains a change that would require a new submission. The discipline of the description is that it draws the boundary of the permitted-change envelope precisely enough that both the manufacturer and the agency know exactly what is and is not covered.

The second element is the modification protocol: the methods by which each permitted change will be developed, tested, and validated before it goes live. If the description says what may change, the protocol says how the change will be made safely, the data management practices, the retraining procedures, the performance evaluation against pre-specified acceptance criteria, the verification and validation steps, and the controls that ensure a change actually improves or maintains performance rather than degrading it. The protocol is the engine of trust in the whole arrangement, because it is what convinces the agency that changes made within the envelope, without individual review, will nonetheless be safe and effective. The third element is the impact assessment: a structured analysis of the benefits and risks of the permitted changes, including how the modification protocol mitigates the risks, so that the agency can judge whether the envelope as a whole is acceptable. Together, the three elements answer three questions in order: what may change, how it will be changed safely, and why the resulting envelope of change is acceptable. A PCCP that is strong on all three lets an AI device improve itself in the field under control that an inspector and a reviewer can trust.

Where the PCCP Legally Applies, and Where It Does Not

This is the part of the lesson where precision is not optional, because the PCCP is widely misdescribed, and a professional who blurs the line loses credibility fast. The PCCP, as finalized in December 2024 and revised in January 2025, is a framework for AI-enabled device software functions: it lives in the medical-device world, governing software that is itself a device, Software-as-a-Medical-Device, or a software function within a device. It is a device construct, authorized through device pathways, and its native home is the regulation of products that diagnose, treat, or otherwise act as medical devices. It is not, and this must be stated plainly, a drug-submission requirement. There is no provision of the PCCP framework that obliges a sponsor preparing an NDA or a BLA to file a PCCP for the large language model that helped draft a Module 2.5 section, because that LLM is not a medical device and the drug submission is not a device submission.

Holding this line matters for two reasons. First, accuracy: a learner who tells a reviewer or a colleague that the PCCP governs their submission-drafting AI is simply wrong, and the error signals a shaky grasp of the regulatory map that undermines everything else they say. Second, the line is exactly what makes the next section legitimate. Because the PCCP is a device framework, what the broader industry takes from it is not a legal obligation but a conceptual architecture, a well-designed pattern for governing learning AI that happens to be the best-articulated such pattern any regulator has produced. The value of being precise about the boundary is that it lets you borrow the idea honestly: this is the FDA's framework for adaptive AI/ML devices, and here is why its three-part structure is useful as a voluntary working pattern far beyond the device world, said in a way that never pretends the borrowing is a requirement.

The Conceptual Framework Borrowed Across the Industry

Now the legitimate move. The PCCP's three-element architecture, describe the permitted changes, specify the protocol that makes them safe, assess the impact, is a remarkably clean answer to a problem that exists wherever AI learns or changes inside a regulated process, not only inside devices. Consider a sponsor running a production AI tool that drafts pharmacovigilance narratives, and consider that the vendor periodically updates the model and the sponsor periodically refreshes the retrieval corpus. That tool is not a medical device and no PCCP is legally required for it, but the question the PCCP answers, how do we let this system change over time under control we can defend, is exactly the question the sponsor faces. The industry's response, increasingly visible in 2026, is to adopt the PCCP's structure voluntarily as the working pattern for change control over any learning or frequently updated production AI in a regulated content workflow.

In that borrowed form, the three elements map cleanly onto non-device AI governance. The description of modifications becomes the documented statement of what changes the organization will allow to its AI workflow without a full re-validation: a model version bump within a tested family, a refresh of the retrieval corpus, a system-prompt revision within defined limits. The modification protocol becomes the change-control procedure: the eval suite re-run against acceptance criteria, the regression testing, the human review of changed behavior, the rollback plan if performance degrades. The impact assessment becomes the risk analysis of allowing those changes, tied to the consequence of the workflow the AI supports. A sponsor who governs its production drafting AI this way is not complying with the PCCP, because the PCCP does not apply, but it is using the best available conceptual template for a hard problem, and it can say so honestly: we adopted the PCCP framework as a working pattern for our non-device AI, which is precisely the language a credible professional uses.

This borrowing also points forward in the program. The applied levels build out ongoing performance monitoring, drift detection, and re-validation triggers for production AI, and they do so explicitly using the PCCP pattern as the scaffold, because it is the most coherent template the field has for the lifecycle management of a system that does not hold still. The conceptual debt is openly acknowledged: the device regulators solved the learning-AI change-control problem first and best, and the rest of the industry is adapting their solution to contexts the regulation itself does not reach.

Why the PCCP Pattern Fits the FDA-EMA Principles and the Validation Lesson

The PCCP pattern is not a free-floating good idea; it is the concrete operationalization of two principles from the FDA-EMA joint guiding principles that otherwise risk staying abstract. Model performance monitoring, the seventh principle, requires that an AI's performance be evaluated and shown adequate for its purpose, and ongoing lifecycle monitoring, the eighth, requires that this evaluation continue across the AI's operational life because models drift and contexts change. The PCCP's modification protocol and impact assessment are, in effect, a worked example of exactly these two principles: a structure that says here is how we will keep evaluating performance as the system changes, and here is how we have judged the risk of those changes. When an organization adopts the PCCP pattern for its non-device AI, it is satisfying the seventh and eighth principles with a template the regulators themselves designed, which is about as defensible a posture as a function can take.

The pattern also resolves the moving-model problem the validation lesson posed but left open. That lesson established that an LLM tool cannot be validated once and forgotten, because the vendor can update the model and the output is probabilistic, so validation must include change control over updates and ongoing drift monitoring. The PCCP framework is the most fully developed answer to how that change control should be structured: describe the changes you will permit without full re-validation, specify the protocol that re-tests performance when a change occurs, and assess the impact of the permitted-change envelope. A function that asked, after the validation lesson, what does the change-control-for-a-moving-model actually look like in practice, finds the answer in the PCCP's three elements, borrowed and adapted. This is why the three regulatory lessons of this chapter form a sequence rather than a list: the principles set the expectations, Part 11 and Annex 11 enforce the record and the validation, and the PCCP supplies the lifecycle-management pattern for the part of validation that a learning system makes hardest.

Reading a Production AI Change the PCCP Way

To make the pattern concrete, walk a single realistic event through it. A sponsor uses a governed enterprise AI tool to draft ICSR narratives in pharmacovigilance, and the vendor announces a model upgrade. Without a PCCP-style pattern, the function faces an unstructured judgment call: adopt the upgrade and hope, or freeze and forgo the improvement, with no defensible basis for either. With the borrowed pattern in place, the event is governed in advance. The description of permitted modifications already states whether a vendor model upgrade within the same family is inside or outside the envelope the function pre-agreed. If it is inside, the modification protocol specifies exactly what happens next: the eval suite re-runs against the pre-set acceptance criteria for narrative accuracy and coding fidelity, regression testing confirms previously correct behaviors still hold, a human reviews a sample of changed output, and a rollback plan stands ready if any acceptance criterion fails. The impact assessment, written before the upgrade, already established that changes of this kind, controlled this way, carry acceptable risk for the narrative-drafting workflow.

The difference between the two scenarios is the difference between defensible and indefensible AI lifecycle management. In the unstructured case, an inspector who asks how the function controlled the model upgrade hears that someone decided it seemed fine, which is precisely the reconstructed-from-judgment non-answer that data-integrity regulation exists to prevent. In the PCCP-patterned case, the function shows a pre-written description, protocol, and impact assessment, the eval results from the actual upgrade, the regression evidence, the human review record, and the decision to proceed or roll back, all captured contemporaneously in the validated system. The output narratives may read identically in both cases, but only one function can show that the system which produced them stayed within a controlled, pre-authorized envelope of change. That is the entire value of the pattern, and it is available to any function willing to adopt it, with no requirement, because it is simply the most coherent way yet devised to govern AI that does not hold still.

The Monday Meaning of the PCCP for a Non-Device Professional

For a regulatory or pharmacovigilance professional who will never file a device submission, the PCCP still has three concrete meanings worth carrying. The first is vocabulary: when a colleague, a vendor, or a slide deck invokes the PCCP, you can place it precisely, as the FDA's December 2024 / January 2025 framework for adaptive AI/ML device software functions, with its three elements, and you can correct the common error of treating it as a drug requirement. That precision is itself a mark of competence in a field crowded with people who use the term loosely.

The second meaning is the template. When your function needs to govern a production AI tool that learns or updates, you do not have to invent a change-control structure from nothing; you can adapt the PCCP's three elements, describe the permitted changes, specify the protocol, assess the impact, as a ready-made and regulator-designed scaffold, and you can document honestly that you did so. The third meaning is the trajectory. The PCCP is one of the clearest signals of where AI regulation is heading: toward lifecycle governance of systems that change, toward pre-authorized envelopes of change rather than per-change review, and toward the expectation that anyone running a learning AI in a regulated context can show how its evolution is controlled. The professional who understands the PCCP now, both its precise legal home and its borrowed conceptual reach, is reading the future of the field a few years early, and that is exactly the position the awareness level of this program is built to put you in before the applied levels turn the pattern into operational workflows.

Key Takeaways

• The Predetermined Change Control Plan (PCCP), finalized December 2024 and revised January 2025 for AI-enabled device software functions, solves the problem that adaptive AI changes its own behavior on purpose. It moves regulatory review earlier in time, authorizing a pre-specified envelope of future change so a device can improve itself in the field without a new submission for every update.
• A PCCP has exactly three elements: the description of modifications (what the AI may change), the modification protocol (how each change is developed, tested, and validated against acceptance criteria), and the impact assessment (why the envelope of change is acceptable). Together they answer what may change, how it changes safely, and why that is acceptable.
• The PCCP is a device construct and not a drug-submission requirement. It governs Software-as-a-Medical-Device and device software functions through device pathways; no provision obliges a drug sponsor to file a PCCP for an LLM that drafts a Module 2.5 section, and blurring this line signals a shaky grasp of the regulatory map.
• The conceptual three-part architecture has been borrowed across the industry as a voluntary working pattern for any learning or frequently updated production AI in a regulated content workflow. The description becomes the permitted-change statement, the protocol becomes the eval-and-regression change-control procedure, and the impact assessment becomes the workflow risk analysis, adopted honestly as a pattern, never claimed as compliance.
• The PCCP pattern operationalizes the FDA-EMA principles of model performance monitoring and ongoing lifecycle monitoring and resolves the moving-model problem the validation lesson left open. It is the most coherent regulator-designed template for governing AI that does not hold still, which is why the applied levels build their drift-detection and re-validation workflows on it.