FDA AI-Enabled Medical Device Guidance: Transparency, Labeling & GMLP

Guide to FDA AI medical device rules. Map GMLP, June 2024 transparency, and January 2025 draft guidance to submission and labeling artifacts.

Scenario: Documenting AI Performance for FDA Reviewers and Clinical Users

Imagine you are the VP of Regulatory Affairs or the Lead Software Quality Engineer for a digital health company that has developed a machine learning model to analyze MRI scans for lumbar spine pathologies. Your data science team has achieved excellent area-under-the-curve (AUC) results on their training datasets. The commercial team is eager to submit the 510(k) and launch the product.

However, as you compile the marketing submission, you realize that standard software documentation under IEC 62304 is no longer sufficient. You must answer complex, model-specific questions from FDA reviewers:

How did you isolate the test data to prevent data leakage and optimization bias?
What specific training and clinical validation demographics are disclosed in the user manual to ensure clinicians understand the model's limitations?
What is your plan for post-market monitoring to detect clinical "model drift" once the software is deployed across dozens of different hospital networks?

If your submission fails to address these points with structured evidence, the FDA will issue an Additional Information (AI) request, halting your review. To succeed, medical device developers must navigate a complex web of Good Machine Learning Practice (GMLP) guidelines, transparency labeling requirements, and the FDA's latest lifecycle draft guidance.

This guide provides a consolidated, actionable playbook for developers of Artificial Intelligence and Machine Learning-enabled Medical Devices (MLMDs). It maps the FDA’s expectations, GMLP principles, and transparency guidelines to concrete submission artifacts and labeling checklists, helping you clear the FDA review gate and build trust with clinical users.

The FDA AI/ML Regulatory Framework Landscape

The FDA has been building a dedicated framework for AI/ML-enabled devices, recognizing that static software validation techniques cannot fully capture the dynamic, data-driven nature of machine learning algorithms. Rather than relying on a single, catch-all regulation, the FDA regulates AI devices through a cluster of guidance documents, international standards, and public registries.

The timeline below details the four foundational pillars of this framework:

Date	Guidance / Document Title	Lead Authorities	Regulatory Status & Focus
October 2021	Good Machine Learning Practice for Medical Device Development: Guiding Principles	U.S. FDA, Health Canada, UK MHRA	Joint Principles: Defined the 10 foundational concepts for QMS and software development.
June 13, 2024	Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles	U.S. FDA, Health Canada, UK MHRA	Joint Principles: Established expectations for labeling, user interface design, and public disclosures.
January 2025	Good Machine Learning Practice for Medical Device Development (Final Document)	IMDRF (International Medical Device Regulators Forum)	International Standard: Finalized the 10-principle GMLP framework with global consensus definitions.
January 6, 2025	AI-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations	U.S. FDA (Docket FDA-2024-D-4488)	Draft Guidance: Open for public comment until April 7, 2025. Detailed specific submission content.

The January 2025 Lifecycle Draft Guidance (FDA-2024-D-4488)

On January 6, 2025, the FDA released its most comprehensive policy document for AI-enabled software: the draft guidance titled “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations” under docket FDA-2024-D-4488.

This draft guidance represents a shift from focusing solely on the pre-market submission to enforcing a total product lifecycle (TPLC) approach. Following a public webinar on February 18, 2025, and the closing of the public comment period on April 7, 2025, the guidance has become the primary roadmap for how FDA reviewers evaluate AI submissions.

Key requirements introduced in the January 2025 draft guidance include:

1. Algorithm Lifecycle Documentation

The January 2025 guidance emphasizes managing the AI-enabled device across its total product lifecycle (TPLC) — the design, data management, training, tuning, testing, and maintenance phases. FDA does not use "ALM plan" as a single named deliverable, but reviewers expect manufacturers to document the full algorithm lifecycle; in practice that documentation should outline:

Data Integrity Controls: Procedures to ensure training data is free from corruption, properly labeled, and representative of the clinical target population.
Version Control for Models: How different versions of the model (including minor updates that do not trigger a new 510(k)) are tracked, verified, and deployed.
Security and Bias Mitigation: Ongoing procedures to identify and address bias across patient subpopulations (e.g., race, age, gender, imaging hardware manufacturer).

2. Mandatory Performance Monitoring Plans (PMP)

A major addition is the requirement for a Performance Monitoring Plan (PMP) as part of the pre-market submission. The FDA now expects manufacturers to define how they will actively monitor the clinical safety and effectiveness of the AI device in the real world.

Trigger for Action: The PMP must define specific performance thresholds (e.g., a drop in sensitivity below a set baseline) that will trigger a formal investigation, corrective action, or algorithm retraining.
Customer Feedback Loops: Clear mechanisms for healthcare facilities to report model errors, false positives, or false negatives directly to the manufacturer's quality management system.

3. Documentation Level Tiers (Basic vs. Enhanced)

The AI-enabled device guidance builds on FDA's existing Premarket Software guidance, which tiers the documentation expected in a marketing submission into two levels: Basic Documentation and Enhanced Documentation.

Enhanced Documentation: Required for software functions where a failure or latent design flaw could present a high risk of injury or death to the patient (such as computer-aided triage software for stroke, diagnostic tools for cardiovascular blockage, or radiation therapy planning algorithms). For AI-enabled devices, the vast majority fall under the Enhanced category because clinical decisions are heavily influenced by the model's outputs.
Basic Documentation: Applies to lower-risk software functions (like administrative scheduling AI or general wellness tracking). Manufacturers must explicitly justify their documentation level choice in the submission's Software Description section, detail all clinical risks, and show how their GMLP testing mitigates those risks.

Deep Dive: Mapping GMLP to Submission Artifacts

The 10 Good Machine Learning Practice (GMLP) guiding principles, finalized by the IMDRF in January 2025, are often discussed as high-level ethical concepts. However, during an FDA audit or a 510(k) review, they must be translated into concrete engineering and quality system documents.

Here is a detailed breakdown of how each GMLP principle maps to specific technical files and artifacts:

Principle 1: Multi-Disciplinary Expertise

Regulatory Expection: The FDA expects that the software development team includes clinical practitioners, data scientists, biostatisticians, software engineers, and human factors experts.
Required Submission Artifact: Team Qualifications & Roster: Section within the Software Development Plan detailing clinical advisor engagement, data curation team qualifications, and formal training in medical device quality systems for the software engineering staff.

Principle 2: Good Software Engineering and Quality System Practices

Regulatory Expectation: The software code must be developed under established design controls, incorporating robust cybersecurity, configuration management, and regression testing.
Required Submission Artifact: IEC 62304 Compliance Report & Cyber Security File: Standard documentation of software requirements, architecture, software unit verification, and software release protocols, joined with a Software Bill of Materials (SBOM) and threat modeling.

Principle 3: Clinical Study Participants and Training Data are Representative

Regulatory Expectation: Training and validation datasets must capture the clinical diversity of the real-world population (demographics, clinical centers, disease severity) and the technological variation of clinical hardware (e.g., MRI magnet strengths, slice thickness, coil types).
Required Submission Artifact: Data Curation Protocol & Demographics Report: A technical document outlining the dataset's clinical and hardware characteristics, showing that the model was trained on diverse sources and is not overfitted to a single institution's workflow.

Principle 4: Training Datasets are Separate from Test Datasets

Regulatory Expectation: Absolute isolation between the data used to train/tune the model and the independent test sets used to validate performance. Any "data leakage" (e.g., patient scans appearing in both sets) invalidates performance claims.
Required Submission Artifact: Data Partitioning Protocol & Report: Statistical proof demonstrating that zero patient records, clinical sites, or hardware-specific datasets overlap between the training, tuning (validation), and final test sets.

Principle 5: Reference Standards are Based on Best Available Clinical Methods

Regulatory Expectation: The reference standard or "ground truth" labels must be developed using a rigorous, objective clinical method (e.g., histopathology, clinical consensus panels, or multiple independent clinical reviewers).
Required Submission Artifact: Data Labeling & Truthing Protocol: A document explaining the qualifications of the annotators, the inter-rater agreement metrics (such as Fleiss' Kappa), and the formal arbitration process used to resolve labeling discrepancies.

Principle 6: Model Design is Tailored to the Available Data and Intended Use

Regulatory Expectation: The algorithm architecture, hyperparameters, and features must be selected based on the clinical task, and the model must be resilient against corrupted or noisy input data.
Required Submission Artifact: Algorithm Design Specifications: Documentation of the neural network architecture, activation functions, loss functions, optimization techniques, and a description of input data quality thresholds (e.g., rejecting blurred scans).

Principle 7: Focus on the Performance of the Human-AI Team

Regulatory Expectation: The user interface must support safe and effective human interpretation of the AI output. Usability testing must demonstrate that the clinician's decision is improved by the AI.
Required Submission Artifact: Human Factors & Usability Engineering Report: Structured results of formative and summative usability testing with representative clinical users (e.g., radiologists, clinicians), proving they can correctly interpret model confidence scores or heatmaps.

Principle 8: Testing Demonstrates Device Performance in Clinically Relevant Conditions

Regulatory Expectation: Performance validation must show statistically significant results across all clinically relevant subpopulations (such as age, sex, race, disease stages) and different clinical settings.
Required Submission Artifact: Subpopulation Sensitivity & Specificity Report: Statistical tables showing the model's sensitivity, specificity, positive predictive value (PPV), and AUC curves, with 95% confidence intervals calculated separately for each cohort.

Principle 9: Users are Provided with Essential Information (Transparency)

Regulatory Expectation: Labeling must clearly communicate model performance, training data composition, clinical limitations, and explainability mechanisms.
Required Submission Artifact: Clinical User Manual & Instructions for Use (IFU): Public documentation outlining the model's clinical parameters, input data requirements, and explicit warnings about known performance limits.

Principle 10: Deployed Models are Monitored for Performance

Regulatory Expectation: Real-world performance must be tracked to identify model drift, clinical performance degradation, or emerging bias in new populations.
Required Submission Artifact: Performance Monitoring Plan (PMP): A Quality Management System procedure detailing statistical metrics to be tracked post-market and the corrective actions to take if performance drops.

GMLP Principle Mapping Summary

GMLP Principle	Clinical / Engineering Focus	Required Submission Artifact
1. Multi-Disciplinary Expertise	Clinical and software engineering teams work together throughout the product lifecycle.	Key Personnel & Team Roster: Included in the software development plan, showing clinical advisory board input.
2. Good Software Engineering	Software design controls, cybersecurity, and configuration management follow standard practices.	Software Development Plan & System Architecture: Conformance to IEC 62304 and FDA cybersecurity guidelines.
3. Clinical Representation	Training and test data reflect the target patient population (demographics, clinical sites).	Data Acquisition Protocol: Documenting patient demographics, exclusion criteria, and diversity of imaging devices.
4. Independent Test Sets	Test datasets are strictly separated from training and tuning datasets to prevent data leakage.	Data Partitioning Protocol & Report: Proving complete separation; showing zero patient overlap between train/test sets.
5. Reference Standards	The reference standard ("ground truth") is based on clinical consensus and best available evidence.	Truthing Protocol: Detailing how annotators (e.g., board-certified radiologists) resolved disagreements to label data.
6. Model Design & Constraints	Model design matches the clinical intended use and is robust against variations in input quality.	Algorithm Design Specifications: Documentation of model architecture, hyperparameters, and sensitivity to noise.
7. Human-AI Interaction	The user interface supports safe and effective human interpretation of the AI output.	Usability/Human Factors Report: Results of human factors testing showing clinicians interpret AI outputs correctly.
8. Performance Testing	Testing demonstrates clinical performance across all intended patient subpopulations and hardware.	Subpopulation Analysis Report: Statistical performance (sensitivity, specificity, AUC) split by age, sex, and device type.
9. User Transparency	Labeling discloses model performance, training data demographics, and limitations.	Clinical User Manual / Instructions for Use (IFU): Public disclosures of model boundaries and performance gaps.
10. Post-Market Performance	Real-world performance is monitored to detect drift, bias, and unexpected failures.	Performance Monitoring Plan (PMP): Procedures for detecting drift and retraining models under quality system controls.

The June 2024 Transparency Guiding Principles & Labeling Checklist

On June 13, 2024, the FDA, Health Canada, and the MHRA jointly published “Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles”. This document emphasizes that transparency is not just about making code public; it is about providing clinical users with the contextual information they need to use the AI safely.

To comply with these transparency principles, manufacturers must revise their product labeling (Instructions for Use, user interfaces, and online documentation) to include a structured AI Disclosure Block.

Use this checklist to audit your labeling before submitting to the FDA:

Model Intended Use and Context: Clearly state what the AI is designed to do, what clinical data it requires (e.g., T1-weighted MRI scans of a specific slice thickness), and what patient populations it is cleared for.
Training and Test Data Demographics: Provide a breakdown of the datasets used to develop and validate the model. Disclose the number of clinical sites, geographical distribution, patient age range, biological sex, and racial/ethnic distribution.
Performance Benchmarks: Disclose the model’s clinical performance (e.g., sensitivity, specificity, positive predictive value) as measured on the independent test set. Include 95% confidence intervals.
Model Logic and Explainability: Explain how the model reaches its conclusions. If the model uses a "black box" deep learning architecture, disclose this, and describe what features (e.g., regional signal intensity) are heavily weighted. If heatmaps or saliency maps are generated, explain how users should interpret them.
Known Performance Gaps and Limitations: Clearly disclose where the model is known to perform poorly. For example, if your lumbar spine MRI reader has only been validated on Siemens and GE scanners, state that performance on Philips or Canon scanners is unverified and represents a known limitation.
User Actions and Safety Goggles: Include clear instructions warning clinicians that the AI is an adjunct tool and should not be used as the sole basis for clinical decision-making.

Performance Monitoring Plans (PMP) & Post-Market Surveillance

Once your AI device is cleared and deployed in clinical practice, the software enters the post-market phase. Unlike traditional static software, where performance remains identical over time, AI models are subject to clinical model drift.

Drift occurs due to changes in clinical workflows, shifts in patient demographics, software updates to diagnostic imaging hardware (e.g., a hospital updating its CT scanner's reconstruction algorithm), or changes in clinician diagnostic criteria. A model that achieved 95% sensitivity in clinical trials may drop to 85% when deployed in a rural hospital network using legacy imaging equipment.

To manage this risk, the January 2025 lifecycle draft guidance requires manufacturers to include a formal Performance Monitoring Plan (PMP). The PMP must specify the exact statistical methods and QMS processes used to identify drift:

1. Statistical Metrics for Monitoring Drift

Population Stability Index (PSI): Used to measure how much the distribution of the model's clinical input data has shifted between the training baseline and the real-world deployment. A PSI score greater than 0.25 indicates a significant shift, triggering a mandatory review of model inputs.
Kullback-Leibler (KL) Divergence: Measures the difference between the probability distributions of the model’s predictions in the clinic versus the validation dataset.
Real-World Sensitivity and Specificity Tracking: Periodically audit a sample of clinical cases where the AI output was checked against clinical outcomes or expert review to calculate ongoing diagnostic metrics.

2. Retraining and Redeployment Workflow

If drift is detected, the PMP must govern the corrective retraining cycle under QMS design controls:

+-----------------------------------------------------------------------+
|                       1. DRIFT DETECTION                              |
|   PSI > 0.25 or Real-World Sensitivity drops below specified limit    |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                    2. DATA ACQUISITION & CURATION                     |
|   Collect new representative samples from the drifted clinical sites  |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                       3. MODEL RETRAINING                             |
|   Retrain model using curated data under QMS design controls          |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                     4. INDEPENDENT VALIDATION                         |
|   Validate retrained model against a fresh, independent test set       |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                      5. REGULATORY FILING                             |
|   Deploy via PCCP protocol (no-filing) OR file a new 510(k) if outside|
|   PCCP scope                                                          |
+-----------------------------------------------------------------------+

Quantifying AI Adoption: The FDA Authorized List

To understand the practical application of these guidelines, developers should analyze the FDA's official public database: "Artificial Intelligence-Enabled Medical Devices".

Update Cadence: The FDA maintains a public list of authorized AI and ML-enabled medical devices, which is updated periodically. The database reflects clearances through October 30, 2024.
Specialty Concentration: An analysis of the late-2024 database updates confirms that AI clearances remain heavily concentrated in Radiology (predominantly under product codes like QIH for image processing software, QKB for computer-assisted detection, and QAS for radiological computer-aided triage).
Real-World Case Study: A representative clearance reflected in the October 30, 2024 update is K241108, the RemedyLogic AI MRI Lumbar Spine Reader (Remedy Logic, Inc.; product code QIH; Radiology panel). FDA cleared it as a Class II automated radiological image-processing and measurement tool that provides quantitative spine measurements from previously acquired lumbar spine MRI scans — a post-processing measurement aid rather than an independent diagnostic classifier. Entries like this illustrate exactly the lifecycle artifacts the GMLP and transparency principles target: representative, multi-site training data, a defined measurement and labeling protocol, and labeling that tells the radiologist what the model measures and where its performance has been validated.

How FDA AI Guidelines Fit with PCCP and IEC 62304

One of the most common points of confusion for digital health regulatory teams is understanding how these different guidance documents and software standards interact. They should not be treated as competing standards; instead, they represent complementary layers of a unified software quality and regulatory strategy.

+----------------------------------------------------------------------+
|                           IEC 62304                                  |
|   Standard Software Lifecycle processes (architecture, coding,       |
|   verification, risk management, configuration, and maintenance).    |
+----------------------------------------------------------------------+
                                   ^
                                   | Integrates with
                                   v
+----------------------------------------------------------------------+
|                     GMLP / Jan 2025 Draft Guidance                   |
|   Specifies AI-specific lifecycle requirements: data truthing,      |
|   independent test sets, subpopulation testing, and model drift.     |
+----------------------------------------------------------------------+
                                   ^
                                   | Enables
                                   v
+----------------------------------------------------------------------+
|                     PCCP (Change Control Plan)                       |
|   Leverages GMLP to pre-approve algorithm updates, allowing          |
|   retraining and optimization without new marketing submissions.     |
+----------------------------------------------------------------------+

IEC 62304 (The Foundation): Governs the basic software development lifecycle (SDLC) processes. It treats AI as a software system, requiring standard unit testing, integration testing, and cybersecurity controls. GMLP and the January 2025 draft guidance build upon IEC 62304 by adding specific data-science requirements (e.g., data truthing, test set isolation, hyperparameter tracking) that standard software engineering standards do not address.
PCCP (The Update Pathway): A Predetermined Change Control Plan (PCCP) is a regulatory protocol submitted within your 510(k) or PMA that outlines how you plan to retrain and update the model in the future without filing a new submission. (For a detailed guide on structuring these protocols, see our comprehensive guide on FDA predetermined change control plans (PCCP) for AI and ML devices).
GMLP (The Compliance Driver): To get an FDA-approved PCCP, you must demonstrate a mature GMLP implementation. The FDA will not grant a PCCP to a manufacturer that cannot prove a clean separation of independent test sets or a robust post-market performance monitoring plan. For a broader overview of the general AI regulatory landscape, refer to our AI and ML medical device regulatory guide, and to understand the newest Total Product Life Cycle advisory programs, see our guide on the FDA AI-enabled device software functions TPLC draft guidance.

Frequently Asked Questions (FAQs)

How many AI-enabled medical devices has FDA authorized?

As of the FDA's public database update on October 30, 2024, the FDA has authorized nearly 1,000 AI and ML-enabled medical devices through the 510(k), De Novo, and PMA pathways. The vast majority (over 75%) are cleared under the Radiology specialty, followed by Cardiovascular and Neurology.

Is the January 2025 AI-enabled device guidance final or still draft?

The guidance “Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations” published on January 6, 2025 (docket FDA-2024-D-4488) is currently a draft guidance. The public comment period closed on April 7, 2025, following a detailed FDA webinar on February 18, 2025. While draft guidances are not legally binding, they represent the FDA's current thinking, and reviewers are actively using these recommendations to evaluate submissions. Manufacturers should design their submissions to align with the draft recommendations to avoid delays.

Do the transparency principles apply to all AI devices or only ML-enabled ones?

The June 2024 transparency principles were jointly developed with a focus on Machine Learning-Enabled Medical Devices (MLMDs), as machine learning models pose unique "black box" explainability challenges. However, the FDA's general labeling regulations (21 CFR Part 801) require all medical devices to provide adequate directions for use. Therefore, any device utilizing AI—whether rule-based expert systems or deep learning neural networks—must provide clear explanations of its logic, clinical limitations, and performance boundaries to ensure safe use.

What is the difference between GMLP and standard software verification?

Standard software verification under standards like IEC 62304 focus on proving that code compiles correctly, satisfies design specifications, and contains no memory leaks or logical loops. In contrast, Good Machine Learning Practice (GMLP) focuses on model behavior and data integrity. GMLP ensures that training datasets are representative of target populations, that independent test sets remain isolated, and that clinical performance (e.g., diagnostic accuracy) is validated across diverse conditions. GMLP does not replace standard verification; it is a clinical and statistical layer built on top of standard software engineering.

How does FDA evaluate training bias in AI submissions?

The FDA evaluates training bias by looking at the diversity of the development datasets. If a model was trained on data from a single hospital system, or if the demographic distribution (age, race, biological sex) is skewed, the FDA will reject the submission or request a narrower intended use statement. Manufacturers must submit a Subpopulation Performance Report detailing performance metrics across clinical variables and prove that GMLP guidelines were followed to ensure representative data acquisition.

Action Plan for AI Device Developers

To ensure your AI-enabled device marketing submission clears the FDA review smoothly, implement the following four-step action plan:

Enforce Hard Data Separation at Day One: Write a strict data partitioning protocol before training your models. Ensure your software engineering tools physically isolate the validation and test datasets. Document that no images or clinical metadata from the test set were ever accessed during the training or hyperparameter tuning phases.
Establish an Annotation Agreement Metric: When creating your "ground truth" reference standards, document how many annotators evaluated each data point, their clinical qualifications, and the metric used to measure agreement (e.g., Cohen's Kappa). Detail the formal arbitration process used to resolve disagreements.
Draft Your AI Disclosure Block Early: Do not wait until the end of the project to write your user manual. Draft the AI Disclosure Block during the design input phase. This ensures your human factors testing can validate that clinicians can easily read and interpret the training demographics, model logic, and subpopulation performance data.
Align Your PMP with Your QMS CAPA Procedures: Design your Performance Monitoring Plan (PMP) to integrate directly with your existing Quality Management System (QMS). Ensure that if your post-market monitoring detects algorithm drift or a drop in real-world sensitivity, it automatically triggers a Corrective and Preventive Action (CAPA) file, directing your engineering team to investigate and retrain the model under established design controls.