FDA Predetermined Change Control Plans for AI Devices: What Section 515C, the Guidance and 21 CFR 892.2055 Require

A cleared AI medical device can't simply ship a retrained model. If the change is significant, it normally needs a new 510(k) or a PMA supplement before it reaches patients. A predetermined change control plan, or PCCP, is how a manufacturer gets those future changes authorized up front, as part of the original submission.

This post is for engineering, ML and regulatory teams building software that is, or will become, an FDA-regulated device. It covers what the statute allows, which FDA guidance is final and which is still a draft, what the first classification regulation with a PCCP built in actually requires, how the EU AI Act handles the same problem, and a release gate that checks a model update against its plan before it ships.

The short answer

A PCCP is a plan, reviewed and authorized by FDA as part of a 510(k), De Novo or PMA, that describes specific future changes to a device and how they will be developed, validated and implemented. Under section 515C of the FD&C Act, added on 29 December 2022, a change that is consistent with an authorized PCCP doesn't need a new 510(k) or PMA supplement. FDA's guidance on PCCPs for AI-enabled device software functions is final. In June 2026 FDA codified the first device type whose regulation requires a PCCP, 21 CFR 892.2055, which sets out the documentation, risk analysis and labeling, including a version history, that each update must carry.

What the law allows

Section 515C (21 U.S.C. 360e-4) came from section 3308 of the Food and Drug Omnibus Reform Act of 2022. It does three things.

• For approved devices, a PMA supplement isn't required for a change that is consistent with an approved PCCP. FDA may approve a plan describing planned changes if the device remains safe and effective without any change.
• For cleared devices, a new 510(k) isn't required for a change consistent with a cleared PCCP. Clearing the plan also requires that the device would remain substantially equivalent to its predicate.
• For predicates, a changed version can't be used. Only the version cleared or approved before any PCCP changes may serve as a predicate for someone else's 510(k).

In both cases the statute lets FDA require labeling for safe use as the device changes, notification requirements if it doesn't function as intended, and performance requirements for the changes. FDA's device regulations were amended to match: 21 CFR 807.81 now says no premarket notification is needed for a change consistent with a cleared PCCP, and 21 CFR 814.39 says the same for PMA supplements.

That last statutory point is easy to miss and matters commercially. Your version 4.7, built under a PCCP, can't be the predicate a competitor cites. Neither can it be yours for a new device, so a new product line still starts from the originally authorized version.

Which guidance is final

As of 20 October 2026:

FDA summarizes the final AI guidance in one sentence: a PCCP should describe the planned device modifications, the methodology to develop, validate and implement them, and an assessment of their impact. It applies to AI-enabled devices reviewed through the 510(k), De Novo and PMA pathways, including the device constituent part of device-led combination products.

The first regulation with a PCCP built in

On 17 June 2026 FDA published a final order adding 21 CFR 892.2055, "radiological machine learning-based quantitative imaging software with predetermined change control plan". The De Novo request arrived on 28 September 2022 and FDA classified the device into class II on 24 February 2023, so the regulation codifies a decision more than three years old. It's still the clearest public statement of what FDA expects a PCCP device to document, because special controls are binding for every later device of that type.

A search of the current Code of Federal Regulations finds the phrase "predetermined change control" in three sections: the two procedural sections above and 892.2055. Only four classification regulations in title 21 use the phrase "machine learning" at all.

The PCCP parts of 892.2055's special controls require:

1. Planned modifications and methodology. As part of design verification and validation, document the planned modifications and the methodology for developing, verifying and validating them consistent with the performance requirements in the plan.
2. Risk. As part of risk management, identify and assess the risks of the planned modifications and their mitigations.
3. Labeling. State that the device has a PCCP. Describe the modifications implemented, with current performance, inputs, validation requirements and evidence. Keep a version history, describe how modifications will be implemented, and describe how users will be told about them.

The same regulation's general special controls show what the test evidence looks like. The test dataset must be independent from training data and contain enough cases from important cohorts, such as demographic subsets, clinically relevant confounders and image acquisition characteristics, that performance and confidence intervals can be characterized for each. Labeling must summarize performance with confidence intervals and stratified sub-analyses, and describe where the device may fail, such as poor image quality or certain subpopulations.

The pattern repeats in other ML device types. The cardiovascular notification software regulation, 21 CFR 870.2380, requires a test set from at least three geographically diverse sites that weren't used in training.

FDA keeps inviting PCCPs

Since September 2025, FDA's classification and reclassification documents have carried a near-identical paragraph saying manufacturers "may wish to use" PCCPs to implement future modifications without a new 510(k) for each significant change. We found it in eight Federal Register documents published between September 2025 and August 2026. Most aren't AI devices: they include bone growth stimulators, blood irradiators, tuberculosis immune response tests and digital breast tomosynthesis systems.

That matters for planning. A PCCP isn't an AI-only tool, and FDA is signaling it in places where nobody would have expected it a few years ago. The AI guidance is simply the most detailed version.

The EU parallel

The EU AI Act reaches the same idea by a different route. Article 43(4) says a high-risk AI system needs a new conformity assessment after a substantial modification. For systems that continue to learn after being placed on the market, changes "pre-determined by the provider at the moment of the initial conformity assessment" and described in the technical documentation aren't a substantial modification. Annex IV point 2(f) says that documentation should include a detailed description of the predetermined changes and the technical solutions that keep the system compliant.

So a manufacturer selling an AI device in both markets writes the change plan twice, for two reviewers. The structures are close enough that one engineering record can feed both, as long as it's specific about what will change and how each change is validated.

Make the plan enforceable in your release pipeline

A PCCP only protects you if every update stays inside it. The failure mode isn't dramatic: a retrain that quietly drops below a subgroup threshold, a test set that shares patients with the new training data, or a release that ships without the version history the labeling requires.

This gate reads the authorized plan and one release record and fails the build when the update falls outside the plan. It uses only the Python standard library.

#!/usr/bin/env python3
"""Release gate for a model update made under a PCCP.

Checks one release record against the authorized plan and exits non-zero if
the update falls outside it. Standard library only.

Usage: python3 pccp_gate.py plan.json release.json
"""
import json
import sys


def meets(value, rule):
    if "min" in rule and value < rule["min"]:
        return False
    if "max" in rule and value > rule["max"]:
        return False
    return True


def ids(path):
    with open(path) as f:
        return {line.strip() for line in f if line.strip()}


def gate(plan, rel):
    problems = []
    mods = {m["id"]: m for m in plan["modifications"]}
    mod = mods.get(rel["modification_id"])
    if mod is None:
        return [f"{rel['modification_id']} is not a planned modification: outside the PCCP"]

    for name, rule in mod["acceptance"].items():
        got = rel["metrics"].get(name)
        if got is None:
            problems.append(f"metric {name} not reported")
        elif not meets(got, rule):
            problems.append(f"{name} = {got} fails {rule}")

    for group, rule in mod.get("subgroups", {}).items():
        got = rel["subgroups"].get(group)
        if got is None:
            problems.append(f"subgroup {group} not reported")
            continue
        if got["n"] < rule["min_n"]:
            problems.append(f"subgroup {group}: n = {got['n']}, plan needs {rule['min_n']}")
        for name, r in rule["acceptance"].items():
            if not meets(got.get(name, float("nan")), r):
                problems.append(f"subgroup {group}: {name} = {got.get(name)} fails {r}")

    overlap = ids(rel["train_ids"]) & ids(rel["test_ids"])
    if overlap:
        problems.append(f"{len(overlap)} patient IDs appear in both training and test data")

    history = rel.get("labeling", {}).get("version_history", [])
    if not any(h.get("version") == rel["model_version"] for h in history):
        problems.append(f"labeling version history has no entry for {rel['model_version']}")
    if not rel.get("labeling", {}).get("user_notice"):
        problems.append("no description of how users are told about the change")
    return problems


if __name__ == "__main__":
    plan, rel = (json.load(open(p)) for p in sys.argv[1:3])
    problems = gate(plan, rel)
    print(f"{rel['model_version']} ({rel['modification_id']}): " + ("PASS" if not problems else "FAIL"))
    for p in problems:
        print("  - " + p)
    sys.exit(1 if problems else 0)

The plan is a JSON file listing each authorized modification with its acceptance criteria and required subgroups:

{
  "device": "example quantitative imaging software",
  "modifications": [
    {
      "id": "M1-retrain-same-inputs",
      "description": "Retrain on additional data from the same scanner models and protocols",
      "acceptance": {"dice": {"min": 0.85}, "mean_abs_error_pct": {"max": 5.0}},
      "subgroups": {
        "age_65_plus": {"min_n": 150, "acceptance": {"dice": {"min": 0.82}}},
        "bmi_35_plus": {"min_n": 100, "acceptance": {"dice": {"min": 0.80}}}
      }
    }
  ]
}

We ran it on four made-up release records. The numbers are invented to show each check firing; they don't come from any real device.

2.4.0 (M1-retrain-same-inputs): PASS
2.5.0 (M2-add-pediatric-use): FAIL
  - M2-add-pediatric-use is not a planned modification: outside the PCCP
2.4.1 (M1-retrain-same-inputs): FAIL
  - subgroup bmi_35_plus: n = 64, plan needs 100
  - subgroup bmi_35_plus: dice = 0.78 fails {'min': 0.8}
2.4.2 (M1-retrain-same-inputs): FAIL
  - 12 patient IDs appear in both training and test data
  - labeling version history has no entry for 2.4.2

The second result is the important one. A new patient population is a new intended use, and no amount of passing metrics brings it inside a plan that didn't list it. The gate can't judge whether a change is really "the same" modification, so keep the IDs in the plan narrow and have regulatory review any new one.

Run it as a required step before a model artifact can be promoted, and keep its output with the release. That output is the evidence that each update matched the plan FDA authorized. Here's Safeguard's interactive walkthrough of a production release gate:

What to do

1. Decide early whether you need a PCCP. It's part of the original submission. Adding one later means another submission.
2. Write modifications narrowly. Each should name what changes, what doesn't (inputs, intended use, user population), and the acceptance criteria, including per-subgroup thresholds.
3. Fix the test data rules before you train. Independence from training data and enough cases per cohort are explicit special controls in 892.2055 and 870.2380.
4. Treat labeling as a release artifact. Version history and user notification are required content in 892.2055, not marketing copy written afterward.
5. Gate every release against the plan and keep the output. If a change fails the gate, it needs a submission, not an exception.
6. If you also sell in the EU, write the predetermined changes into the AI Act technical documentation at the initial conformity assessment, per Article 43(4) and Annex IV point 2(f).

A PCCP doesn't change your cybersecurity obligations. If the device is also a cyber device under section 524B, those requirements apply to every version you ship; see our posts on what counts as a cyber device and on FDA premarket cybersecurity guidance.

The fair view

A PCCP buys speed by front-loading the work. You commit, years in advance, to exactly what you'll change and how you'll prove each change is safe, and FDA reviews that commitment as part of the submission. For a team that doesn't yet know how its model will evolve, a vague plan won't be authorized and a narrow one may not cover the change you end up needing. Some teams will reasonably choose to file new 510(k)s instead.

The other limit is the predicate rule. Every update you make under a PCCP improves your device without improving your regulatory position, because only the originally authorized version can serve as a predicate. Even so, for a product that will be retrained regularly on more data from the same kind of source, the plan is the difference between shipping updates on your schedule and FDA's.

Check yourself