For FDA AI medical devices, two early decisions set the route. The first is which legally marketed predicate shares your intended use. The second is whether the original 510(k), De Novo or PMA should carry a predetermined change control plan (PCCP). Once FDA authorises a PCCP, pre-specified model changes can ship without a new marketing submission, provided each change is described in the plan and carried out by its protocol. A change outside the plan, or one that could significantly affect safety or effectiveness, goes back to FDA.
TechnoLynx handles the engineering side of this through its AI Governance and Trust work, building the approval evidence behind a predicate comparison and a PCCP, starting with a review of your intended use and an inventory of the model changes you expect to make after launch. TechnoLynx builds this evidence as engineering, not as policy advice or certification.
Before any pathway work, check that the function is a device software function at all. FDA applies that term to software that meets the device definition in section 201(h) of the FD&C Act. Many parts of a life sciences pipeline sit outside the regulated portion, even in companies that assume everything is constrained. Where the device definition does apply, the constraints are real, and the rest of this article is about meeting them. It sits within our broader work on AI engineering for life sciences and healthcare, and the companion piece on FDA medical device regulation for imaging AI covers where engineering validation stops and regulatory claims begin.
How do you choose a predicate for an AI-enabled 510(k), and what does a wrong pick cost?
Start from intended use. FDA can only find a new device substantially equivalent if it has the same intended use as the predicate. After that, the technological characteristics must either match or differ without raising different questions of safety and effectiveness. An AI-enabled device can even be found substantially equivalent to a non-AI device with the same intended use, provided the AI does not introduce different safety and effectiveness questions.
TechnoLynx builds the side-by-side technical and performance evidence behind a predicate comparison through its AI Governance and Trust work; the first step is a review of your intended use against the predicates your regulatory lead has shortlisted.
FDA’s draft guidance on predicate selection narrows a list of valid predicates using four best practices:
- the predicate was cleared using well-established methods, such as recognised consensus standards, FDA guidance or qualified tools;
- it continues to perform safely in use, judged against reported adverse events and malfunctions;
- it has no unmitigated use-related or design-related safety issues or emerging safety signals;
- it has not been subject to a design-related recall.
FDA also recommends that the draft 510(k) Summary include a narrative explaining how those practices drove the choice.
AI devices add one rule that catches teams out. Under section 515C(c), only the version of a device cleared before any PCCP changes can serve as a predicate. Once a later 510(k) clears a device that includes changes made under its PCCP, that newer device becomes an eligible predicate. If you plan to cite a competitor’s PCCP-enabled device, check which version you are actually comparing against.
Searching the 510(k) and De Novo databases for a comparable cleared algorithm is how we would look for both predicates and PCCP precedent. Precedent is thin. A JAMA Health Forum study (2026) of US AI-enabled devices authorised from 2023 through 2025 found 43 of 794 (5.4%) with FDA-authorised PCCPs. RegulatoryIQ’s 2026 analysis, counting every FDA-documented plan, puts the share at 1.3% in 2023 and 11.6% in the first half of 2026. Both figures show only a minority of AI-enabled authorisations carrying a PCCP. We read that as higher risk, not ineligibility. Without a precedent, your plan has to justify its own scope, and the Pre-Sub discussed below matters more.
As for the cost of a wrong predicate, intended use and technological characteristics anchor every comparison. Our judgement is that a late predicate switch reopens the substantial-equivalence sections and can mean performance testing designed against the old comparator has to be redone. That is why we would lock the predicate before the validation protocol, not after it.
What a PCCP is, and when an AI device qualifies for one instead of repeated 510(k)s
A PCCP describes planned changes to a device, how the manufacturer will develop, test and implement them, and how it will assess their impact. The statutory basis is section 515C of the FD&C Act, added by FDORA, which was enacted on 29 December 2022. FDA’s final guidance for AI-enabled device software functions was issued on 4 December 2024 and reissued with updates on 18 August 2025. TechnoLynx builds the approval evidence behind a PCCP through AI Governance and Trust, starting with an inventory of the model changes you expect to make after launch.
A modification qualifies for a PCCP when three things hold. It would otherwise need a new marketing submission, it keeps the device within its intended use, and, for a 510(k) device, it keeps the device substantially equivalent to the predicate. FDA also expects modifications to be specific and verifiable, and in general to stay within the indications for use. A PCCP is optional. You can still implement significant changes through additional submissions.
Timing matters. A PCCP can only be established inside a 510(k), De Novo or PMA submission. A Pre-Submission cannot authorise one. Adding a PCCP to a device already on the market means filing a new 510(k). Our view is that a team expecting more than a couple of retrains should design the PCCP into the first submission rather than bolt it on later.
An AI feature added to an existing device
We treat the hearing-aid case, where a machine-learned noise-separation algorithm is added to a cleared device, as a modification question before a classification question. FDA’s general change guidance requires a new 510(k) when a change could significantly affect safety or effectiveness or is a major change in intended use. A change in the device’s control mechanism or operating principle usually crosses that line. On validation evidence, FDA’s draft AI lifecycle guidance expects test data that are independent of training data and sequestered from developers. It also expects subgroup analysis by factors such as age, sex, site and acquisition equipment. We would not state the classification outcome here. That belongs in a precedent search and, if it stays unclear, a Pre-Sub.
Slide-screening and pathology algorithms
Digital pathology has a De Novo precedent for AI software. Paige Prostate was granted De Novo as a Class II device under 21 CFR 864.3750, product code QPN, as a software algorithm to assist users in digital pathology. Its cleared version was locked and not continually retrained in clinical use. The closest PCCP precedent in pathology is narrow. The 510(k) for AISight Dx (K243391) carries a PCCP for qualifying additional FDA-cleared scanners, file formats, displays and web browsers. Its listed modifications are platform components, not a diagnostic model retrain. Its acceptance criterion for new file formats is pixel-wise: the 95th percentile colour difference must stay below 3 CIEDE2000 units (ΔE00 < 3), with a clinical study as the fallback. That is a useful template for platform changes and a weak one for model changes.
The decision logic follows. If a strong direct predicate exists, we would go predicate-based 510(k) and consider bundling a PCCP for anticipated updates. If no clear predicate exists, request a Q-Submission before finalising study design. Precedent records past decisions and does not guarantee future ones.
When does retraining a locked AI classifier need a new 510(k)?
With an authorised PCCP, FDA’s test has two parts. Is the modification specified in the Description of Modifications? And was it implemented following both the methods and the performance specifications in the Modification Protocol? If both answers are yes, no new submission is needed. If either is no, you evaluate the change under 21 CFR 807.81(a)(3). Because PCCP modifications are ones that would otherwise need a submission, a new one is likely. A deviation that could significantly affect safety or effectiveness would generally make the device adulterated and misbranded.
Without a PCCP, you work through FDA’s software-change flowchart. A change that could significantly affect clinical functionality or performance specifications tied to intended use likely needs a new 510(k). A change that does not affect them is documented to file, which is the letter-to-file route. FDA’s earlier AI/ML discussion paper already anticipated that retraining with new data sets would usually fall under premarket review. Watch the testing step too. If routine verification produces unexpected results, or you need different test methods or acceptance criteria to pass, a new 510(k) is likely.
A 2026 FDA letter shows how this plays out. FDA concluded that version 3.0.0 of VirtuOst VFA, cleared in K171435, went beyond its clearance after a March 2026 inspection. FDA cited three changes that each independently required a new 510(k). One was a new machine learning model for vertebral landmarking, which FDA said “fundamentally changes how the device performs, fails, and affects patients”. Orrick’s 2026 reading is that FDA asked whether the model could perform or fail differently, not whether it was meant as an improvement.
Retrain or resubmit: a decision table
| Change | With an authorised PCCP | Without a PCCP |
|---|---|---|
| Retraining on new data from the intended-use population, same input type | In scope if described in the plan and validated per protocol | Likely new 510(k) if clinical performance could change significantly; otherwise document to file |
| New algorithm | In scope if the plan specified it | New 510(k) in the VirtuOst case |
| Acceptance criteria missed, or new test methods needed | Outside the plan; likely new submission | Likely new 510(k) |
| New disease, condition or patient population | Generally not appropriate for a PCCP | Likely new 510(k) |
| Change made solely for cybersecurity, with no other impact | Not needed in a PCCP | Document to file |
What the plan has to lock down
The vocabulary changed between FDA documents. The earlier discussion paper proposed SaMD Pre-Specifications (SPS), a “region of potential changes” around the original device, and an Algorithm Change Protocol (ACP), a step-by-step account of how those changes are made and controlled. FDA’s AI guidance is now final. It uses three components: a Description of Modifications, a Modification Protocol and an Impact Assessment. The Modification Protocol covers four areas for each modification: data management, retraining practices, performance evaluation and update procedures. FDA recommends a traceability table showing which parts of the protocol apply to each modification. The Impact Assessment compares each modified version with the unmodified device.
For an annual retrain of a classifier on new reject images, we would have the description state what changes (weights only, or more) and the data sources. The protocol should fix inclusion criteria, the training pipeline, a sequestered test set and quantitative acceptance criteria. A retrain on images outside the described scope, such as a new defect type or new imaging conditions, is not specified in the plan, whatever the metrics say. The PCCP is reviewed interactively, and the authorised version is named by title and version number in the authorisation letter.
What drift or performance-drop thresholds should a PCCP pre-specify?
We would pre-specify two different thresholds and keep them apart. In our design, a monitoring threshold decides when to retrain or audit. Acceptance criteria in the Modification Protocol decide whether the retrained model is in scope. A drift alarm is not what decides whether a change needs a submission. That decision comes from the pre-defined acceptance criteria. TechnoLynx builds the drift and regression monitoring harness under AI Governance and Trust, so the threshold is computed and logged, starting with a review of your intended use and the model changes you expect to make after launch.
FDA’s request for public comment on real-world performance still asks what should trigger additional assessment and how to define degradation. One published example comes from the MMC+ drift monitor for chest X-ray AI. Its authors set the operating threshold using Cantelli’s inequality with a per-window false-alarm probability of 0.01, which gives √99 ≈ 9.95, rounded to 10. Below 10, normalised AUROC stayed within 3 standard deviations of the reference mean. Above it, that likelihood fell sharply. The authors say deployments may choose a different false-alarm probability to match local audit capacity.
Three limits stop that number being copied straight into a PCCP. First, data drift does not always mean performance loss, and some findings even improved under drift. Second, window size has to adapt to each site’s scan volume. Third, MMC+ is relative to a reference set, and after a stabilised, audited drift its authors re-calibrate against a new one. We would treat reject-image distribution shift the same way. It is a proxy, and we would show that it moves with true performance before letting it drive retraining. FDA’s own hypothetical of automatic global retraining has drift thresholds trigger a manufacturer review, not an automatic release. How drift alarms are escalated and staffed after launch is covered in post-market surveillance for AI/ML medical software.
Cumulative change must be assessed too. The Impact Assessment has to address the individual and cumulative impact of modifications. The joint FDA, Health Canada and MHRA principles ask that cumulative changes remain appropriate over time.
Can Quality sign off a retrain without reopening the submission?
Yes, if each cycle follows the Modification Protocol the authorised PCCP already fixed and the change is one the plan describes. TechnoLynx turns that protocol into an automated evidence build under AI Governance and Trust, so each cycle produces the same artefacts from pipeline outputs, starting with a review of the Modification Protocol your authorised PCCP fixed. FDA’s hypothetical PCCP examples give a workable sequence for each cycle’s package:
- Data sufficiency review against the minimum sample size and quality criteria in the plan.
- Training with the pre-specified pipeline, then locking the model weights before validation.
- Validation on an independent test set sequestered before training, against the acceptance criteria and compared with the authorised device.
- Documentation and labelling updates, including model version history.
- Controlled deployment under the quality management system.
- Post-deployment monitoring.
Add the tested-versus-released record. FDA expects version history to show any difference between the tested model and the released one, with an assessment of its effect. Because a small software change can have system-wide effects, each change also needs a validation analysis and appropriate regression testing. That warning has history behind it. FDA’s analysis of 1992 to 1998 recalls found that 79% of software-related recalls came from defects introduced by changes made after initial distribution.
We would use one template for every cycle only if its statistical tests stay adequately powered as dataset sizes change. We would fix minimum sample sizes in the plan rather than discover underpowered cycles later. How to package the resulting evidence for auditors and procurement reviewers is the subject of building a defensible evidence pack.
Does a new GPU platform, backend or cloud move need re-validation or a new 510(k)?
We would not reuse a standard IQ/OQ/PQ template unchanged for a GPU inference platform. In our mapping, IQ verifies installed hardware, driver, firmware and runtime versions, OQ tests operating range and failover, and PQ runs powered accuracy testing under representative load; confirm it with your reviewer. Governance, audit trails and infrastructure assurance get fuller treatment in infrastructure assurance for AI/ML SaMD validation.
Under FDA’s guidance, any software modification, whatever its name or form, is a design change. FDA’s software-change guidance treats changing drivers or libraries as an “infrastructure” change whose complexity should be weighed in the decision. We would treat each backend as a separate configuration unless parity testing on the clinical metric itself, not just numerical closeness, shows equivalence within agreed tolerances. TechnoLynx builds that parity work: it identifies the backend-sensitive parts of the pipeline, ports kernels within defined tolerances and produces documented cross-backend test evidence. K243391 shows that a PCCP can pre-authorise platform components such as scanners, displays and browsers against fixed acceptance criteria. For a cloud or web move, the VirtuOst letter treated the desktop-to-web shift as an independent basis for a new 510(k) because it changed the cybersecurity threat model.
Should you request a Pre-Sub before locking the validation protocol?
Request a Pre-Sub when there is no close predicate or precedent, when the PCCP scope is unusual, or when your validation methods are novel. FDA encourages early engagement in exactly those cases, encourages a Pre-Submission for anyone proposing a PCCP, and points sponsors to the Q-Submission process for questions such as the use of non-US validation data. If a search of the 510(k) and De Novo databases turns up nothing close, you cannot infer the evidentiary bar by analogy alone.
The order that works is to build the best available precedent case first, then take that dossier into the Pre-Sub, and only then lock the protocol. Under FDA’s draft Pre-Sub eSTAR guidance, technical screening is anticipated within 15 calendar days of receipt. Analogies to devices with a different class or intended use only go so far.
Who can build the PCCP evidence and validation harness for our AI device?
TechnoLynx builds the approval-grade engineering evidence an AI device submission rests on. That covers drift monitoring and parity testing when the compute platform changes. We treat that evidence as an engineering output that a reviewer, auditor or quality lead can read and sign against, not as a policy document. Bring in a specialist when the PCCP, monitoring or backend work is new to you. When choosing a partner, ask whether they deliver reproducible artefacts traceable to each PCCP commitment. The work runs under AI Governance and Trust.
This is not regulatory or legal advice, and it is not certification or submission sign-off. A team that needs only those services should hire them directly.
FAQ
Is a 510(k) a premarket submission?
Yes. FDA counts the 510(k) premarket notification among its marketing submissions, alongside De Novo requests, PMA applications, HDEs and BLAs.
How long does FDA take to review a 510(k) with a PCCP?
RegulatoryIQ’s 2026 analysis found that Traditional 510(k)s on FDA’s PCCP list took a median of 131 calendar days from receipt to decision, against 142 days for other Traditional 510(k)s in the same product codes. Matched comparisons showed a long tail of slower PCCP reviews, averaging about 17 days longer.
What do IQ, OQ and PQ stand for?
Installation qualification, operational qualification and performance qualification: the three stages used to show that equipment is installed correctly, operates within its specified ranges and performs as required in use.
