FDA AI Medical Device Guidance: AI-DSF Draft Explained

Draft guidance explainer · Reviewed October 22, 2026 · 9 min read

The FDA's January 7, 2025 AI-enabled device lifecycle draft is distributed for comment, not for implementation. It proposes lifecycle recommendations alongside the GMLP principles and other FDA documents; it does not establish current requirements. This guide explains what the draft adds, what it does not change, and what manufacturers should already be doing.

Talk to an AI/ML regulatory expert · AI/ML Medical Device Security Service →

What the draft is, and is not

The draft is a lifecycle marketing-submission guidance. It proposes recommendations about what to include in a 510(k), De Novo, or PMA when the device contains an AI/ML component, and how to keep that submission credible across postmarket changes. It is not a standard, not a checklist, and not law - it is a draft distributed for comment, not for implementation. It does not create submission requirements or replace final guidance and applicable statutes or regulations.

It explicitly builds on:

• Final AI PCCP guidance, updated August 18, 2025 - recommendations for optional plans the FDA may authorize for specified modifications.
• GMLP guiding principles (FDA + Health Canada + MHRA, 2021) - 10 principles for the entire ML lifecycle.
• Section 524B and the 2026 final cybersecurity guidance - cybersecurity is part of the AI submission.
• ISO 14971 + AAMI CR34971 - risk management for AI/ML devices.

Scope: what counts as an AI-DSF

The draft uses the term AI-enabled device software function broadly. If the function applies any machine-learning model - supervised, unsupervised, reinforcement, foundation/LLM, or hybrid - to produce a clinical or operational output, it is in scope. That includes:

• Locked models trained once and deployed
• Adaptive models that retrain on field data
• Models that wrap a third-party foundation model or commercial API
• Generative AI features (LLM-based summarization, drafting, decision support)
• Models embedded in firmware as well as cloud-hosted models

Rule-based or deterministic algorithms are not AI-DSFs - but a hybrid system with even one ML component may fall within the draft scope for that device function.

Seven planning areas discussed in the draft

The following seven areas are this guide's planning organization of draft proposals, not seven mandatory FDA submission sections. Assess actual evidence against applicable regulations and final guidance.

1. Device description and model details

More than a block diagram. Include the model architecture (CNN, transformer, ensemble, etc.), the training and inference pipelines, where each runs (device, edge, cloud), versioning, and any third-party models or APIs in the chain. If you call OpenAI or Anthropic, that supplier is part of the device description.

2. User interface and labeling (transparency)

The draft proposes information to help users (clinicians, patients, and technicians) understand:

• What the model does and does not do
• Intended user, use environment, and patient population
• Performance characteristics, including subgroup performance where clinically relevant
• Inputs the model was trained on and the inputs it expects in deployment
• Known limitations, edge cases, and failure modes
• How and when the model is updated

A model-card-style summary in the labeling is the practical output. Plain-English explanations beat technical specifications.

3. Risk assessment

ISO 14971 plus AAMI CR34971 for AI-specific risks: data quality, dataset shift, overfitting, automation bias, model drift, adversarial inputs, and unintended population disparities. The risk file should show that AI risks were identified, evaluated, and controlled - not just IT-security risks.

4. Data management

Provenance, representativeness, independence of training/validation/test sets, labeling methodology, and any preprocessing. Reviewers ask why a dataset is appropriate for the intended population - 'we used a public dataset' is not an answer.

5. Model development and validation

Training methodology, hyperparameter selection, validation strategy, performance metrics with confidence intervals, and subgroup performance breakdowns (age, sex, race/ethnicity where clinically relevant, device type, site). The draft discusses subgroup performance; assess appropriate evidence from intended use, clinical risk, and applicable requirements.

6. Cybersecurity

For devices meeting the cyber-device definition on covered pathways, satisfy Section 524B. Assess relevant AI-specific threats under the final cybersecurity guidance, such as: data poisoning, model evasion (adversarial examples), model inversion and membership inference, training-pipeline integrity, supply-chain integrity for third-party models, and prompt injection for LLM-based features. MITRE ATLAS and OWASP ML Top 10 are optional tools for organizing relevant threats, not FDA-mandated methods.

7. Public submission summary and PCCP

A Predetermined Change Control Plan is optional, including for models with planned updates. Consider one to authorize specified changes that would otherwise require a new submission. Without applicable PCCP coverage, assess modifications under the standard change requirements. See our PCCP template guide for the structure.

What's new versus prior expectations

Most of the content has been implied by GMLP and PCCP for years. What the 2025 AI draft guidance adds:

• The draft proposes greater transparency to users. Model cards, plain-language explanations, and subgroup performance tables in the labeling.
• The draft proposes lifecycle performance monitoring, not a postmarket afterthought. The submission should describe how performance and bias drift will be monitored, what triggers retraining or labeling updates, and how those tie back to the PCCP.
• Bias is treated as safety. Subgroup disparities are a quality signal. Manufacturers are expected to define the slices they monitor and the thresholds that trigger action.
• Assess applicable AI-specific cybersecurity risks. The February 3, 2026 final guidance supports risk-based security evidence; the lifecycle draft does not establish automatic deficiencies.
• Foundation models and third-party APIs are in scope. They appear in the device description, the SBOM, the supplier-evaluation file, and the threat model.

How to prepare now

The January 2025 document is draft, not for implementation. The following are planning practices, not enforceable draft requirements:

1. Audit your current AI submissions and roadmap against the seven domains above. Note where you are thin - usually transparency labeling, subgroup performance, and AI-specific cybersecurity.
2. Stand up an AI threat model that extends STRIDE with MITRE ATLAS and OWASP ML Top 10. See our AI/ML Medical Device Security service.
3. Consider an optional PCCP so engineering can ship retrains within bounds without a new submission. Start with the PCCP template.
4. Map your risk file to AAMI CR34971 alongside ISO 14971. See the CR34971 explainer.
5. Define your monitoring slices and thresholds for performance and bias, and tie them to the PCCP change-control gates.
6. Review every third-party model and AI API as a supplier in your QMS. They belong in the SBOM and supplier evaluation file.

Frequently asked questions

Is the 2025 draft enforceable yet? No. The January 2025 document is a draft distributed for comment, not for implementation. It is not an operating standard or enforceable requirement. Apply relevant statutes, regulations, and final guidance.

Do I need a PCCP if my model is locked at clearance? No. A PCCP is optional for locked and updating models. Changes outside an authorized PCCP require assessment under applicable change requirements; not every retraining or data update requires a new submission.

Does this apply to predicate-based 510(k)s? The draft proposes recommendations for AI-enabled device software submitted through applicable pathways, including 510(k). It does not make all draft content required regardless of submission type.

What if our AI feature is provided by a third-party API? It is still your device. You own the device description, the supplier evaluation, the risk assessment, and the monitoring of that component as deployed in your product.

Where to go next

• PCCP Template & Worked Example for AI/ML Devices
• GMLP Crosswalk: 10 Principles to Engineering Controls
• AAMI CR34971 Explained
• AI/ML Medical Device Security Service

Sources

• FDA, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft, January 2025)
• FDA, Predetermined Change Control Plans for Machine Learning-Enabled Device Software Functions (Final AI PCCP guidance, updated August 18, 2025)
• FDA / Health Canada / MHRA, Good Machine Learning Practice for Medical Device Development: Guiding Principles (October 2021)
• AAMI CR34971:2023, Application of ISO 14971 to Machine Learning in Artificial Intelligence