FDA AI/ML Regulatory Checklist for Life Sciences & Healthcare

Working through FDA regulation for AI/ML-based software is one of the most common blockers I see teams hit. This checklist distills the key steps into a working reference you can actually use. It reflects current FDA guidance as of early 2025, including the January 2025 Draft Guidance on AI-Enabled Device Software Functions.

Work through each section in order. Not every item applies to every product - use the classification questions in Section 1 to scope what you actually need.

Section 1: SaMD Classification and Pathway Selection

Step 1 - Determine if your software is a medical device

  • [ ] Does the software meet the definition of a device under 21 CFR 201(h)? Software that performs a medical purpose (diagnose, treat, mitigate, prevent disease) is likely a device.
  • [ ] Does it fall under a statutory exclusion? Administrative functions, general wellness, and certain clinical decision support (CDS) tools may be excluded. Review the 21st Century Cures Act criteria carefully.
  • [ ] Is it a CDS tool? If so, check all four criteria for non-device CDS: (1) not intended for serious or immediately life-threatening conditions, (2) clinician can independently review the basis, (3) not intended to replace clinical judgment, (4) displays the basis for recommendations. Miss any one and it is likely a device.

Step 2 - Classify your SaMD

  • [ ] Use the IMDRF SaMD framework to assess significance of information provided and the healthcare situation. This is your anchor before touching FDA classifications.
  • [ ] Determine FDA device class: Class I (general controls only), Class II (special controls, typically 510(k)), or Class III (PMA required).
  • [ ] Search the FDA Product Classification database (accessdata.fda.gov) for a matching predicate or product code. AI/ML devices often land under QMF (software function) or similar codes.
  • [ ] Check if your device type has a De Novo granted - this creates a new regulatory pathway and special controls that may benefit you.

Step 3 - Select your submission pathway

  • [ ] 510(k): Requires substantial equivalence to a predicate. Most common for Class II AI tools. Predicate must share intended use and technological characteristics, or differences must not raise new safety questions.
  • [ ] De Novo: Use when no valid predicate exists but device is low-to-moderate risk. Creates a new device type. Expect 12+ months for first-of-kind AI tools.
  • [ ] PMA: Required for Class III devices (e.g., AI driving treatment decisions for life-threatening conditions). Clinical data required. Budget 2-4 years minimum.
  • [ ] Breakthrough Device Designation: Consider applying if your device provides more effective treatment or diagnosis of serious conditions. Accelerates review and increases FDA interaction.

Section 2: Pre-Submission Meeting Checklist

A Q-Sub (Pre-Sub) meeting with FDA before you finalize your submission design saves months. Request one 6-9 months before you plan to submit.

  • [ ] Draft a concise device description including intended use, indications for use, and user population.
  • [ ] Prepare 5-10 specific written questions for FDA. Avoid open-ended questions - ask for FDA's position on specific proposed approaches.
  • [ ] Include your proposed testing strategy and ask FDA to validate it before you run the studies.
  • [ ] For AI/ML devices, ask specifically about: (1) acceptable performance metrics for your use case, (2) whether a Predetermined Change Control Plan (PCCP) is appropriate, (3) algorithm transparency requirements.
  • [ ] Submit the Q-Sub package at least 90 days before your desired meeting date.
  • [ ] After the meeting, get written responses. These are not binding but are highly influential during formal review.

Section 3: Software Documentation (IEC 62304 Alignment)

  • [ ] Define your software safety class: Class A (no injury possible), Class B (non-serious injury possible), Class C (serious injury or death possible). Most diagnostic AI is Class B or C.
  • [ ] Produce a Software Development Plan covering your SDLC, development environment, and configuration management.
  • [ ] Document software requirements - functional, performance, interface, and safety requirements separately.
  • [ ] Produce software architecture documentation showing how modules interact. For AI/ML: include data pipeline, model inference components, and integration with host system.
  • [ ] Maintain a unit and integration test plan with traceability to requirements.
  • [ ] Document known anomalies with severity assessments.
  • [ ] For AI/ML specifically: document training data provenance, preprocessing steps, model architecture, hyperparameters, and versioning policy.

Section 4: Clinical Evaluation Requirements

  • [ ] Define your primary performance endpoints (sensitivity, specificity, AUC, etc.) based on clinical use case - not just what your model optimizes for.
  • [ ] Determine reference standard: Who reads the ground truth? Radiologist consensus? Pathology biopsy? This must be clinically defensible.
  • [ ] Design a test set that reflects real-world distribution: age, sex, race/ethnicity, disease severity, imaging equipment if applicable. FDA scrutinizes demographic diversity hard in 2025.
  • [ ] Plan for reader studies if your device aids a human decision-maker. Show performance of human alone vs. human + AI.
  • [ ] Address subgroup performance in your statistical plan upfront. Do not discover disparate performance at the end of a study.
  • [ ] For retrospective studies: document data collection period, exclusion criteria, and any de-identification process.

Section 5: Predetermined Change Control Plan (PCCP)

The PCCP is one of the most important tools for adaptive AI products. It lets you pre-specify the types of changes you plan to make post-clearance without requiring a new submission for each one. FDA finalized PCCP guidance in December 2024.

  • [ ] Decide early whether a PCCP is right for your product. It is appropriate if your model will be retrained on new data or updated based on real-world performance.
  • [ ] Define the Modification Protocol: what specific changes are covered, what triggers a change, what methodology will be used.
  • [ ] Define the Impact Assessment: how you will evaluate that a covered change does not degrade safety or effectiveness.
  • [ ] Define your Transparency Methodology: how users will be notified of changes and what documentation you maintain.
  • [ ] Be specific. Vague PCCPs get rejected. "We may retrain the model" is not a PCCP. "We will retrain using additional annotated data from the same imaging modality, applying the same preprocessing pipeline, with performance validated against the locked test set" is a PCCP.

Section 6: Cybersecurity Documentation

  • [ ] Produce a Software Bill of Materials (SBOM) listing all third-party components, libraries, and their versions. This is now required per the FDA's 2023 cybersecurity guidance.
  • [ ] Document your threat model: what are the attack surfaces, who are the threat actors, what are the impact scenarios.
  • [ ] Describe security controls: authentication, encryption at rest and in transit, audit logging, vulnerability disclosure process.
  • [ ] Plan for post-market security patching. How will you push updates? What is your response time SLA for critical vulnerabilities?
  • [ ] For cloud-hosted AI: document where PHI is processed, data residency, and your BAA structure.

Section 7: Post-Market Surveillance and Real-World Performance Monitoring

  • [ ] Define your post-market surveillance plan per 21 CFR Part 822 (if applicable) and your device class requirements.
  • [ ] Establish a complaint handling procedure. For AI: what constitutes an AI-related complaint vs. a general product complaint?
  • [ ] Define real-world performance metrics you will track. These should mirror your pre-market endpoints so you can detect drift.
  • [ ] Set alert thresholds: at what performance level do you escalate? Who makes the call to suspend use or notify FDA?
  • [ ] Plan for MDR (Medical Device Reporting) triggers - when AI output contributes to or fails to prevent a serious adverse event.
  • [ ] If you have a PCCP: document how real-world performance data feeds your change trigger criteria.

This checklist is a working reference, not a legal opinion. Regulatory strategy for AI/ML devices requires engaging a regulatory consultant or in-house RA team who knows your specific product and clinical context. Use this to structure your thinking and catch gaps early.

Keep reading

Further Reading