A Predetermined Change Control Plan lets an AI-enabled device change after clearance without a new marketing submission. That is a genuine benefit, and it quietly destroys the assumption that "the cleared version" is one thing. The EU AI Act, separately, asks what a system actually did across its lifetime. Both questions can be answered by one record, but only if it is built per decision, because an aggregate can be computed from instances and never the other way around.
Most teams building AI-enabled devices for both markets treat FDA and EU evidence as two workstreams. They are two questions, and the questions are shaped differently: one is about a population, the other about an instance. This guide covers what a PCCP actually authorizes, the evidentiary hole it opens, what each regime asks of the same system, and the one structural decision that lets a single trail serve both.
What a PCCP authorizes
FDA finalized Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions on 4 December 2024, replacing the April 2023 draft.[1] It applies across the 510(k), De Novo and PMA pathways.[1]
The mechanism is straightforward. The PCCP is reviewed as part of the original marketing submission. Once authorized, the manufacturer can implement the modifications it describes without filing a new submission for each one, so long as each change follows the stated protocol and meets its acceptance criteria.[1][2] In substance a PCCP sets out three things: the planned modifications, a protocol covering how each is developed, validated and implemented, and an assessment of their impact on safety and effectiveness.[2]
This is a good regime. Retraining an AI model on more data is exactly the kind of improvement that should not require a fresh submission every time, and the alternative, a device frozen at its clearance state, is worse for patients.
The consequence nobody plans for
Before a PCCP, "the cleared version" named a specific artifact. After one, it names a permitted range.
A decision made in March and a decision made in September can come from different weights, both fully authorized, with no regulatory filing between them. That is the intended benefit working correctly. The side effect is that your marketing submission no longer describes the state of the system on any particular day. It describes a plan for how the system may change.
So when someone asks which version produced a specific output, the submission cannot answer. Nor can the model card, nor the validation report, because those describe intended behavior rather than what happened. We covered that gap generally in model cards are not proof. A PCCP sharpens it, because it converts a static device into one that legitimately moves.
What the EU asks of the same system
The EU AI Act does not care that FDA authorized your change. It asks a different question of the same software.
Article 12 requires that a high-risk system technically allow the automatic recording of events across the lifetime of the system, and Article 72 requires providers to run post-market monitoring that actively collects and reviews performance data over that lifetime. The obligation is continuous rather than periodic, which is the point we made in Article 12 logging and the 2028 deadline: a lifetime record cannot be authored after the fact.
Which EU date applies to you depends on your classification route, and for a device travelling the Annex I path it is 2 August 2028, as covered in Annex I or Annex III. The date is not the constraint here. The shape of the question is.
Two regulators, two shapes of question
| FDA, post-market under a PCCP | EU AI Act, Articles 12 and 72 | |
|---|---|---|
| Core question | Is the device still performing inside the envelope you pre-authorized? | What did this system actually do, across its lifetime? |
| Unit of interest | The device and its intended use | The individual event, and the system over time |
| Granularity | Aggregate performance against acceptance criteria | Automatic per-event records |
| Timing | Assessed against the protocol when changes are made | Continuous across the lifetime of the system |
| What fails without provenance | You cannot show a modification stayed inside the protocol | You cannot say which version produced a given output |
Read the last row together. Both failures have the same root cause: nothing recorded, at the time, which state of the system was in force. Neither regulator asked for a provenance system by name, and both questions become unanswerable without one.
The asymmetry that decides the design
Here is the structural point, and it is the reason this is one build rather than two.
Aggregate performance can be computed from per-decision records. A false-positive rate, a drift measure, a monthly summary against acceptance criteria: all of these are roll-ups of individual events, and if you hold the events you can produce the summary at any time, including for a window you did not anticipate.
The reverse is impossible. From a monthly performance summary you cannot recover which model version produced a particular output, on what input, on what date. That information was discarded when the summary was computed, and no amount of later analysis brings it back.
So a record designed only for aggregate reporting satisfies the FDA-shaped question and permanently forecloses the EU-shaped one. A per-decision, version-bound record satisfies both, because the aggregate is derivable. Given that one direction is free and the other is impossible, the instance level is the only defensible place to build.
What to bind to each decision
The model version and a digest of the weights that actually ran. The identity of the input the model was given. The output. The timestamp. And the identifier of the PCCP-authorized modification in force at that moment.
That last field is the one usually missing, and it is what turns a general audit trail into evidence that speaks to FDA specifically. It lets you demonstrate that a given decision came from a state of the system your authorized plan permitted, rather than asking a reviewer to accept that on trust.
The record needs to be tamper-evident for the same reason any audit trail does: one that could have been edited afterward answers a weaker question than one that could not. That mechanism is covered in what tamper-evident actually requires. None of it needs to contain patient data; digests and identifiers carry the evidentiary weight without expanding your PHI footprint.
What we are careful never to claim
RankShieldMD does not write your PCCP, does not perform your post-market surveillance, and does not determine your classification under either regime. It is not a medical device, it does not render or score clinical decisions, and it never sees PHI. Nothing here is legal or regulatory advice, and the obligations described are the regulators', not ours to interpret for you.
What we do is narrow. We bind a model version to an output at the moment it happens, in a tamper-evident, externally anchored, PHI-free record that a third party can verify without trusting us. That is evidence that supports obligations under both regimes. It is not compliance, not a clearance, and not a conformity assessment.
References
- [1] U.S. Food and Drug Administration. Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. Final guidance, 4 December 2024; Federal Register notice 2024-28361. federalregister.gov
- [2] King & Spalding. FDA Publishes Final Predetermined Change Control Plan Guidance for AI-Enabled Device Software Functions. Summarizes the finalization date, the PCCP components, and the applicable submission pathways. kslaw.com
- [3] EU Artificial Intelligence Act. Article 12: Record-Keeping and Article 72: Post-Market Monitoring by Providers. artificialintelligenceact.eu/article/72
