AI-Enabled Medical Devices: FDA PCCP, Lifecycle Management and Submission Basics

AI-enabled medical devices are one of the fastest-growing parts of the US market, and FDA has been building the framework for them in public: lifecycle thinking, a way to pre-authorise future model updates, and cybersecurity expectations. This guide explains the main ideas in plain language and shows which pieces are final and which are still draft as of November 2026.

What counts as an AI-enabled device

FDA uses the term AI-enabled device software function (AI-DSF) for a device software function that uses AI. It may be the whole device, such as software that reads images, or part of a larger device. These functions are regulated through the usual routes (510(k), De Novo or PMA), and the key question is the same as for any device: what is the intended use and what risk does it carry? If you are not sure whether your software is a device at all, start with Is my software a medical device?

Why AI needs a lifecycle approach

A traditional device is mostly fixed once it is cleared. AI models can drift as data changes, can perform differently in different patient groups and are often retrained. So FDA asks manufacturers to think across the total product lifecycle: design, data, validation, deployment, monitoring and change.

Predetermined change control plans (PCCPs)

A PCCP lets a manufacturer describe, in its marketing submission, certain future modifications and how they will be validated. If FDA authorises the plan, the manufacturer can make those changes without a new submission each time. The legal basis is section 515C of the FD&C Act, added by FDORA.

• Final guidance for AI-enabled devices: FDA’s PCCP guidance for AI-enabled device software functions was issued in final form in December 2024 and reissued in August 2025.
• Structure: a good PCCP has three parts: a description of the planned modifications, a modification protocol (how each change will be developed, tested and validated) and an impact assessment (benefits, risks and how risks are mitigated).
• Limits: changes outside the authorised plan are evaluated under the normal rules for device modifications, and in most cases a new submission is required. Deviating from an authorised plan can make a device adulterated or misbranded.

What is final and what is still draft

• Final: PCCP guidance for AI-enabled device software functions.
• Draft: the broader lifecycle guidance, “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations” (draft issued January 2025), and a general PCCP guidance for all device types (draft issued August 2024). CDRH’s FY2027 guidance agenda, reported in October 2026, lists finalising both as top priorities.

Build to the final PCCP structure now, and watch for the final versions of the others. Check FDA’s guidance pages before you rely on any specific wording.

A practical development checklist

1. Define intended use and users. Be specific about who uses the output and what decision it informs.
2. Manage data. Document sources, representativeness, labelling quality, splitting between training and test sets and any known gaps.
3. Validate performance. Report metrics that match the clinical question and look at performance across relevant subgroups and sites.
4. Control the software lifecycle. Apply software validation and your ISO 14971 risk management process to the model as well as the code.
5. Plan usability and transparency. Users should understand what the AI does, its limits and how it fits the workflow. See usability engineering.
6. Cover cybersecurity. Connected devices need security design, a software bill of materials and a plan for vulnerabilities. See medical device cybersecurity.
7. Monitor in the field. Define performance monitoring and how findings feed post-market surveillance and change control.
8. Decide on a PCCP early if you expect to update the model, because the plan must be part of the submission.

Common mistakes

• Treating the model as a one-off release with no monitoring plan.
• Test data that overlaps with training data, or data that does not match the intended population.
• A PCCP that is too vague to be authorised, or that lists changes with no validation method.
• Leaving cybersecurity and the quality system to a late stage.

Frequently asked questions

Does every AI device need a PCCP?

No. A PCCP is optional and makes sense when you expect to modify the device over time. Without one, changes are assessed under the usual modification rules.

Which pathway do AI devices use?

The recommendations apply to AI-enabled devices reviewed through 510(k), De Novo and PMA. The pathway depends on the device’s risk and whether a suitable predicate exists. See US FDA medical device regulations and the De Novo guide.

Is the EU different?

Yes. In the EU, AI-based devices must meet the MDR or IVDR, and the EU AI Act adds further obligations for certain high-risk systems. Plan for both if you sell in both markets.

Where does the QMSR fit in?

AI software is developed and maintained within your quality system, which since February 2, 2026 is the QMSR. See the QMSR implementation checklist.

Talk to the AptSkill team

Need training on AI-enabled devices, software validation or FDA submissions for your team? Send us a message.