The FDA has been issuing AI and machine learning guidance since 2021, and the framework has accelerated sharply since. For healthcare and life sciences organizations, understanding what the FDA expects for AI-based Software as a Medical Device (SaMD) is now a compliance requirement, not a nice-to-have, and one that runs alongside, not instead of, HIPAA’s own requirements for AI systems. The agency has already authorized well over 1,000 AI-enabled devices, and the pace of new guidance shows no sign of slowing.
Regulatory affairs and quality teams evaluating an AI-enabled product face a genuinely moving target: the FDA’s approach has evolved from a single 2019 discussion paper into a layered set of guidance documents covering premarket submissions, postmarket change management, bias and cybersecurity. Missing a document in that stack is not a paperwork problem. It can mean a submission gets flagged for missing an expectation the agency has already made explicit elsewhere.
This article walks through the FDA’s AI and ML guidance timeline, what the agency requires for AI-based SaMD specifically, the data quality expectations baked into that guidance, where FDA AI guidance intersects with HIPAA and what that intersection means for teams documenting training data provenance.
Overview of FDA AI and ML guidance documents
The FDA’s approach to AI and ML in medical devices has built up in stages rather than arriving as a single rule.
- 2019. FDA published a discussion paper proposing a regulatory framework for modifications to AI and ML-based SaMD, introducing the idea that later became the Predetermined Change Control Plan.
- 2021. The agency released its AI and ML SaMD Action Plan, committing to further guidance on algorithm change protocols, Good Machine Learning Practice and transparency.
- 2023. FDA joined the UK’s MHRA and Health Canada in publishing guiding principles for Predetermined Change Control Plans in machine-learning-enabled medical devices, an early move toward international harmonization.
- December 2024. FDA finalized its guidance on Marketing Submission Recommendations for a Predetermined Change Control Plan (PCCP) for AI-enabled device software functions, giving manufacturers a formal mechanism to pre-authorize certain algorithm modifications without a new submission for each one.
- January 2025. FDA issued draft guidance on Total Product Lifecycle (TPLC) management of AI-enabled device software functions, alongside separate draft guidance on AI and machine learning in drug and biological product development.
- November 2024 and November 2025. FDA’s Digital Health Advisory Committee, established that year, held its inaugural meeting on Total Product Lifecycle Considerations for Generative AI-Enabled Devices, then reconvened a year later on generative AI-enabled digital mental health devices specifically, evaluating a hypothetical prescription LLM therapy chatbot. Neither meeting produced final binding guidance, but both signal where FDA’s next generative-AI-specific rules are likely headed.
- 2025 through 2026. The agency has continued refining this framework, including updated cybersecurity guidance for medical devices that explicitly addresses AI-enabled and connected products.
The throughline across all of it is a total product lifecycle approach. FDA is regulating not just the moment of initial clearance, but how an AI model is allowed to change afterward and what a manufacturer has to monitor and document to keep using it safely. FDA’s own AI in Software as a Medical Device resource page tracks the current state of this guidance stack and is worth checking before any submission is finalized.
What FDA requires for AI-based SaMD
Three concepts sit at the center of current FDA expectations for AI-enabled devices.
Predetermined Change Control Plans. A PCCP lets a manufacturer describe, in advance, the specific modifications an AI model may undergo after clearance, along with the methodology used to develop and validate those changes and an assessment of their impact, so that in-scope updates do not each require a brand-new marketing submission. A PCCP is not a blank check: changes outside its defined scope, or that fail its stated validation criteria, still require a conventional submission, and deploying an out-of-scope change without one can render a device misbranded or adulterated under the Federal Food, Drug and Cosmetic Act. A diagnostic imaging device cleared with a PCCP covering periodic retraining on new hospital sites, for example, can incorporate that new data and update its model under the pre-authorized plan; the same manufacturer adding an entirely new diagnostic claim the device was not originally cleared for would fall outside any PCCP and need a new submission.
Transparency. FDA guidance calls for clear documentation of what an AI model does, the population and data it was developed on and its known limitations, information intended for both the clinicians using the device and FDA reviewers assessing it.
Performance monitoring. Because AI models can drift as real-world data differs from training data, FDA’s TPLC approach expects manufacturers to describe how they will monitor postmarket performance on an ongoing basis, not just demonstrate safety and effectiveness at the moment of clearance. A sepsis prediction model trained largely on data from one hospital system, for instance, can perform noticeably worse once deployed at a hospital with a different patient population or different lab equipment, which is exactly the kind of drift postmarket monitoring is meant to catch before it affects patient care.
Data quality requirements in FDA AI guidance
FDA’s guidance repeatedly ties device safety back to the quality of the data a model was built and validated on. That includes documented training data standards, an assessment of bias across the populations the device will actually be used on and evidence of real-world performance that reflects the device’s intended clinical setting, not just a curated validation set. Manufacturers are expected to build traceability into their documentation, in practice something close to a design history file for the model itself, covering data provenance, model design choices and validation results, so that a reviewer can trace a claim about model behavior back to the data that supports it. Bias assessment in particular means testing performance across the specific subgroups the device will actually encounter, such as age ranges, sex and race and ethnicity categories relevant to the clinical use case, rather than reporting a single aggregate accuracy figure that can mask meaningfully worse performance in a smaller subgroup.
| FDA expectation |
What it requires of the manufacturer |
| Predetermined Change Control Plan (PCCP) |
Define in advance which model changes are pre-authorized, and the validation methodology for each |
| Data provenance and traceability |
Document where training and validation data came from, and how it flows through the model’s development |
| Bias and performance monitoring |
Assess performance across relevant populations, both before clearance and on an ongoing basis after |
A device team documenting bias assessment for FDA review, for instance, needs the same underlying data lineage a HIPAA reviewer would ask for if that same training data included PHI, which is exactly where the two frameworks start to overlap. That overlap is the same one HIPAA’s expert determination pathway is built to document.
See how Limina’s de-identification and provenance tools support the training data documentation FDA reviewers expect.
One training dataset. Two regulators. One audit trail.
Document every detection and transformation in your training data, so FDA reviewers and HIPAA auditors get the provenance they expect.
Talk to Our Team
How FDA AI guidance intersects with HIPAA
The two frameworks regulate different things. FDA cares about device safety and effectiveness, HIPAA cares about PHI protection, but they meet directly at the training data question. An AI-enabled device trained on clinical data needs that data de-identified or properly authorized under HIPAA before use, and it separately needs that same data’s provenance documented well enough to satisfy an FDA reviewer asking where the training set came from and how it was validated. A manufacturer that treats these as two unrelated compliance tracks often ends up solving the same data-handling problem twice, once for each regulator. Teams building training corpora specifically for HIPAA-compliant AI training data are usually already halfway to the provenance documentation FDA expects, since Expert Determination and Safe Harbor both produce an auditable record of what was done to the data and when.
How Limina supports FDA AI compliance
Limina AI’s de-identification pipeline produces audit-ready output and documented provenance, which supports both sides of this intersection: PHI protection for HIPAA and traceable data lineage for the FDA’s documentation expectations around training and validation data. For teams working with structured clinical data or unstructured text destined for a training or validation set, that means the same de-identification step that satisfies HIPAA’s minimum necessary standard also produces the kind of audit trail a regulatory submission needs, extending through GOVERN into ongoing data provenance and oversight once the device is in the field. This matters most for pharma and life sciences teams building AI-based SaMD, where a single training corpus often has to satisfy an IRB, an FDA reviewer and a HIPAA compliance officer at once.
FDA guidance and advisory committee activity referenced above reflect the agency’s public record as of September 2026. FDA guidance evolves continuously; confirm current status before relying on this for a specific submission.
