In January 2025 the FDA published the document the AI-device field had been waiting for: a single draft guidance that tries to describe, end to end, what it expects of a device with an artificial-intelligence component — from the data used to build the model through the evidence in the marketing submission to the monitoring that follows the device into clinical care. This page walks through what the draft guidance is, how its recommendations are organized, and — just as important — what its still-draft status does and does not mean. As of July 2026.
At a glance
| Attribute | Detail | Source |
|---|---|---|
| Title | AI-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations | 3 |
| Type | Draft guidance — non-binding, "not for implementation" | 3 |
| Issued | January 7, 2025 (announced January 6, 2025) | 12 |
| Docket | FDA-2024-D-4488 | 2 |
| Comment window | Closed April 7, 2025 (90 days) | 2 |
| Status as of July 2026 | Draft; awaiting finalization | 4 |
| Issuing centers | CDRH, CBER, CDER, Office of Combination Products | 3 |
What is the guidance trying to do?
The FDA framed the document plainly in its announcement: "The guidance, if finalized, would be the first guidance to provide comprehensive recommendations for AI-enabled devices throughout the total product lifecycle" 1. That phrase — total product lifecycle, or TPLC — is the organizing idea. Rather than treating a device as a fixed artifact judged once at clearance, the TPLC view follows it across design, development, validation, deployment, and the monitoring that keeps it safe as data and practice shift.
The document itself states its dual purpose: it "provides recommendations on the contents of marketing submissions for devices that include AI-enabled device software functions including documentation and information that will support FDA's review," and, to support that, "also provides recommendations for the design and development" of those devices 3. In other words, it is both a submission checklist and a development philosophy in one.
Scope: what counts as an AI-DSF?
The guidance applies to an AI-enabled device software function (AI-DSF) — a software function that uses artificial intelligence and meets the statutory definition of a device. Two boundaries follow from that. First, the software has to be a device in the first place; functions that fall outside the device definition sit outside this guidance. Second, the guidance addresses the device's software function specifically, wherever the AI sits in the product. The category it attaches to is Software as a Medical Device, and the guidance was issued jointly across the FDA's device, biologics, and drug centers, signalling that AI-DSFs increasingly appear in combination products as well as stand-alone software.
The guidance is also risk-based in how much it asks for: the depth of documentation scales with the device's risk and the role its AI plays, so a lower-stakes measurement aid and a high-stakes diagnostic are held to proportionate rather than identical evidence. And it is deliberately technology-general within that scope, addressing AI-enabled device software functions broadly rather than singling out one model class. That breadth matters for what comes next: generative and large language models are largely absent from authorized devices today, but if and when they arrive as devices, the same lifecycle logic — data, validation, transparency, monitoring — would apply to them.
The document's map: thirteen sections plus appendices
The draft runs to thirteen numbered sections and six appendices. Read as a map, it tells you exactly what the FDA wants a submission to cover 3:
| Section area | What it asks a manufacturer to document |
|---|---|
| Scope and TPLC general principles | Where the guidance applies and the lifecycle logic behind it |
| Marketing-submission content overview | How the pieces assemble into a review-ready submission |
| Device description | Quality-system documentation and a clear account of the device |
| User interface and labeling | How the device communicates to users, including a model card |
| Risk assessment | The hazards specific to an AI-DSF and their mitigations |
| Data management | How training, tuning, and test data were sourced and split |
| Model description and development | What the model is and how it was built |
| Validation | Performance validation against the intended use |
| Device performance monitoring | Post-market tracking of real-world performance |
| Cybersecurity | Protection of the model and its data pipeline |
| Public submission summary | The plain-language summary that reaches the public list |
The appendices are where the guidance turns concrete, including a Table of Recommended Documentation, transparency and usability design considerations, an Example Model Card, and an Example 510(k) Summary with Model Card 3.
Transparency and bias, made a requirement of evidence
The most consequential shift in the draft is that it treats fairness as something to be evidenced, not asserted. The guidance sets out "FDA's current thinking on strategies to address transparency and bias throughout the TPLC of AI-enabled devices, including by collecting evidence to evaluate whether a device benefits all relevant demographic groups (e.g., race, ethnicity, sex, and age) similarly, to help ensure that these devices remain safe and effective for their intended use" 3.
Why the emphasis? Because the current baseline is thin. In a cross-sectional census of devices authorized in 2024, only 29.2% reported both sensitivity and specificity and just 15.5% provided demographic data 6. The draft guidance is, in effect, the FDA's answer to that gap — a request for the exact disclosures most 2024 summaries omitted.
Data, representativeness, and the model card
Much of the guidance's weight lands on data. It asks for "an explanation of how the data is representative of the intended use population and indications for use," spelling out that this includes disease conditions such as "positive/ negative cases, disease severity, disease subtype, comorbidities, distribution of the disease spectrum" and patient-population demographics 3. This is the documentation that lets a reviewer — and later a clinician — judge whether a model was tested on patients resembling their own.
The proposed vehicle for communicating much of this is the model card: a structured summary the guidance suggests can be integrated into device labeling "to clearly communicate information about an AI-enabled device," with a worked example in the appendices 3. For a deployed tool, a model card is what turns a black box into something a care team can actually appraise — and the guidance does not leave its format to chance, supplying both an Example Model Card and an Example 510(k) Summary with Model Card so manufacturers can see the target 3. A separate appendix on usability evaluation extends the same logic to how clinicians interact with the output, on the premise that a correct result presented in a confusing interface can still cause harm.
What it pulls together
The reason the FDA calls this its first comprehensive lifecycle guidance is that the pieces existed before only in fragments. The document itself opens by placing itself in that lineage: it builds on the earlier guiding principles for Good Machine Learning Practice and the transparency principles for machine-learning devices, and on a public workshop on a patient-centred approach to AI-enabled devices 3. What is new is the attempt to tie design, development, maintenance, and documentation into one set of recommendations a reviewer can follow end to end, rather than asking manufacturers to stitch the guidance together themselves. For a health system, that consolidation is the practical value: it is a single reference for what a well-documented AI device should be able to show.
Monitoring, cybersecurity, and life after clearance
Because the framework is lifecycle-wide, it does not stop at market entry. The guidance addresses device performance monitoring — the tools and instructions "to monitor and manage device performance ... when ongoing performance monitoring and management by the user is considered necessary for the safe and effective use of the device" — and asks for a clear description of a device's known limitations 3. This is the submission-side counterpart to what deployed systems call algorithmovigilance, and it exists because model performance can decay through model drift once real-world inputs diverge from the training distribution. A dedicated cybersecurity section rounds out the picture, treating the model and its data pipeline as an attack surface in their own right.
The guidance also asks for something buyers rarely see spelled out: an explicit "description of all known limitations of the AI-enabled device," including weaknesses that fall short of a formal contraindication or warning 3. For a deploying health system, that limitations statement is among the most useful documents a vendor can hand over, because it names the conditions under which the tool should be trusted least — the edge cases, the under-represented populations, the inputs it was never validated on. A guidance that makes limitations a first-class part of the submission is, in practice, arming the people who will run the device in a clinic.
How does it fit with the PCCP and GMLP?
The lifecycle guidance is one piece of a set. It repeatedly points to the Predetermined Change Control Plan (PCCP), describing it as "an approach for manufacturers to prospectively specify and seek premarket authorization for intended modifications to an AI-DSF (e.g., to improve device performance) without needing to submit additional marketing submissions" 3. The PCCP has its own final guidance 5; where the lifecycle draft tells you how to describe and validate a device now, the PCCP tells you how to pre-authorize the changes you will make to it later. We unpack that mechanism in the companion guide on PCCPs in practice. Both build on the earlier Good Machine Learning Practice principles the guidance cites as its foundation 3.
Still a draft — read it accordingly
Three cautions frame how to use this document.
First, it is draft guidance, which the FDA states does "not establish any rights for any person and is not binding on FDA or the public" 3. Even when final, an FDA guidance describes current thinking rather than enforceable law; a draft is one step further back, and its specifics can change.
Second, the timeline is open. The comment window closed April 7, 2025 2, and as of July 2026 the guidance remains a draft awaiting finalization 4. Manufacturers preparing submissions in the interim often align to the draft as a signal of FDA expectations while tracking for the final text — a live question we follow in the global AI in health regulation tracker.
Third, this is orientation, not regulatory advice. Whether and how the guidance applies to a specific device — its risk class, its pathway, its intended use — is a determination for regulatory affairs and counsel. Confirm the current status of the guidance and any obligations before relying on this summary for a submission.
Sources and method
The framing and dates come from the FDA's January 6, 2025 announcement 1 and the Federal Register notice of availability, which carries the docket number and comment deadline 2. The section structure and every quoted recommendation are drawn directly from the draft guidance document itself 3, with its current draft status confirmed on the FDA guidance page 4. The companion PCCP guidance is referenced for the change-control mechanism 5, and the 2024 transparency baseline comes from a peer-reviewed census 6. For the numbers behind the device landscape this guidance governs, see our FDA AI-enabled device list tracker and the tracker of FDA-cleared AI devices by year and specialty. We revisit this page every ninety days and whenever the guidance is revised or finalized.