What the FDA's AI Device Software Guidance Signals for Your Traceability

Every AI/ML SaMD team already knows the shape of the problem. The model that shipped in the 510(k) is not the model running in the field six months later. Training data gets refreshed. Thresholds get retuned. Performance drifts across patient subgroups in ways nobody notices until an audit or an adverse event forces the question: can you prove what changed, when, and why.

The FDA's draft guidance, "Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations," is the agency's clearest attempt yet to make that proof a submission requirement rather than a nice-to-have. FDA issued the draft on January 7, 2025 under Docket FDA-2024-D-4488, and the public comment period closed April 7, 2025. The guidance has not yet been finalized, but its expectations already describe the direction FDA review teams are working toward, and they are worth building against now rather than waiting for a final version to force the issue.

What the draft actually asks for

The guidance applies to AI-enabled device software functions, devices that implement one or more AI models as defined under the FD&C Act, and it frames its recommendations around the Total Product Lifecycle (TPLC): design, development, marketing submission, and post-market performance, treated as one continuous obligation rather than four separate milestones.

Three requirements stand out for quality and regulatory teams:

Dataset provenance and data management. Submissions should document where training and validation data came from, the quality assurance process applied to it, and how the data supports generalizability across the intended-use population. Development data and validation data need to be documented as distinct, disjoint sets, not variations on the same pool.

Transparency and bias mitigation across the TPLC. FDA wants evidence of algorithmic equity, not a one-time statement of it: performance broken out across demographic subgroups where relevant, and a clear account of how bias was identified and controlled for.

Real-world performance monitoring. Manufacturers should describe the data collection and analysis methods used to detect performance changes after the device is in use, alongside a functioning software lifecycle process for catching and addressing those changes.

None of this is entirely new. It builds on FDA's finalized Predetermined Change Control Plan guidance from December 2024 and the June 2023 guidance on premarket submission content for device software functions. What the AI-specific draft adds is a single, TPLC-wide expectation that dataset lineage and model change history are documented with the same rigor as a design history file.

Why this is a traceability problem, not a paperwork problem

A design history file built for a static device does not know how to track a model that gets retrained quarterly against a rotating dataset. A spreadsheet can log a training run once. It cannot flag when a new dataset version drifts from the demographic profile in your last submission, or surface that a validation set has started overlapping with production data. That is not a documentation gap. It is a monitoring gap, and it grows every time the model changes.

This is where continuous gap analysis across all your standards earns its place over a filing system: a QMS that only stores documents cannot tell you when your AI-specific risk file has fallen out of step with a draft guidance that has not even finalized yet. A system built to continuously map evidence against evolving frameworks can.

What to do while the guidance is still in draft

Do not wait for a final rule to start building the audit trail this guidance describes. Three things worth doing now:

1. Confirm your design history file separates development and validation datasets explicitly, with documented provenance for each.
2. Build a standing post-market monitoring plan for model performance, not just device performance, and make sure it produces evidence, not just a policy statement.
3. Map your current AI/ML documentation against the draft's TPLC structure so the gaps are visible before a reviewer finds them.

For a primer on how SaMD obligations interact with the rest of your quality system, Qualio's complete guide to software as a medical device is a useful starting point. For the FDA's own framing of its AI/ML strategy, see the FDA's AI in Software as a Medical Device resource page and the original Federal Register notice for the draft guidance.

See how Compliance Intelligence keeps AI-specific risk documentation mapped against emerging frameworks as they move, not just the ones already finalized.