Is the January 2025 FDA lifecycle document final guidance?

FDA labels it draft guidance. It is nonbinding and not for implementation. Use it as current proposed agency thinking and preserve that status in the control record.

Is the August 2025 PCCP guidance legally binding?

It is final FDA guidance containing recommendations. The marketing authorization creates binding obligations. Applicable statutes and regulations do too. Record that distinction instead of writing the guidance as a mandate.

Does every AI tool at a device manufacturer enter device scope?

Function and intended use determine the analysis. Inventory internal assistants too, then document their actual quality impact and their privacy/security impact under the appropriate controls.

What should happen to a failed checklist row?

Assign an owner and interim measure. Set a target date and retest. Preserve the failed result and closure evidence. Deleting the failure weakens the operating history.

Can one clean gateway test close the checklist?

It closes only the named request-layer test for routed HTTP traffic. Data suitability and device validation require separate evidence. Clinical performance and quality-system operation do too. Complaint conclusions and regulatory decisions remain separate.

FDA AI/ML Guidance AI Compliance Checklist for Device Software

A release ticket says model updated while the intended-use field and validation link remain blank. That ticket fails this FDA AI/ML guidance AI compliance checklist before anyone debates model accuracy. I want each check to produce either a pass or an out-of-scope result, with remediation required otherwise, plus an owner and dated evidence. A seven-row sheet taped beside the release monitor should tell the quality lead which gate stopped the build and who must clear it.

TL;DR

Grade each check as pass or out of scope, and mark every other result remediate. Record the owner and date. Link the evidence and open action.
Preserve source status. The January 2025 lifecycle document is draft guidance. The August 2025 PCCP document is final guidance. The QMSR is binding.
Test actual releases and field events. Policy pages and retention settings show design intent but leave operation unproved.
Limit gateway credit to authenticated HTTP model traffic that traverses the enforcement point.

Check 1: classify the AI-enabled function

Owner: regulatory affairs with the product owner.

Pass condition: the inventory identifies the AI-enabled device software function and intended use. It names the user, patient population, operating environment, and output role. It also records the applicable marketing pathway and the rationale for functions treated as internal or device-adjacent.

Evidence: approved function inventory and intended-use statement. Retain the architecture diagram, submission reference, and dated classification decision. The FDA's January 2025 lifecycle and marketing submission draft guidance covers AI-enabled device software documentation across the total product lifecycle. Mark it as draft guidance. It is nonbinding and not for implementation.

Remediate when: one vendor approval covers several materially different functions or the deployed endpoint lacks a named owner.

Check 2: connect risk and data to validation

Owner: design quality with both leads responsible for clinical and ML work.

Pass condition: each released function links intended use to the risk analysis and development and evaluation data. It also links the validation protocol to acceptance criteria. Retain the results, limitations, and approval. Evaluations cover the populations and operating conditions named in the approved plan.

Evidence: data lineage record and dataset version. Retain the exclusion rationale and test protocol. Add the signed result, unresolved-anomaly disposition, and release approval. The FDA page on Good Machine Learning Practice guiding principles points to the January 2025 IMDRF final principles and a total product lifecycle approach.

Remediate when: the validation report names a model family while production telemetry shows only a moving alias. Use AI data lineage for audit to join evaluated sources to the released artifact.

Check 3: place every modification on an approved path

Owner: regulatory affairs with change control.

Pass condition: each proposed change is compared with the authorized device and any applicable PCCP. The release packet identifies the planned modification and executed methodology. It retains validation results and the impact assessment. It also records approval and deployment. A change beyond the authorized boundary receives a regulatory assessment before release.

Evidence: change request and PCCP reference. Retain the protocol output and impact assessment. Add the decision, approver, deployment timestamp, and rollback plan. The FDA's August 2025 final PCCP guidance recommends planned modifications and an associated methodology to develop and validate them. It also recommends an impact assessment. It applies to covered devices reviewed through 510(k) and De Novo pathways, as well as PMA.

Remediate when: the ticket relies on a vendor release note without a device-specific impact assessment.

Check 4: operate inside the QMSR

Owner: the quality-system owner.

Pass condition: AI development and release records use the manufacturer's controlled QMS procedures. Complaint handling and corrective action feed back into risk management and change control. Record retention and access follow approved procedures.

Evidence: procedure identifiers and training records. Retain the controlled templates and complaint links. Add the corrective-action record, management approval, and retrieval-test output. The QMSR final rule took effect February 2, 2026. Revised 21 CFR Part 820 incorporates ISO 13485:2016 by reference and includes additional FDA requirements. Section 820.35 addresses control of records and complaint records.

Remediate when: AI governance sits in a separate workspace with no controlled link to the device QMS. I would fail that arrangement on custody alone.

Check 5: reproduce the production configuration

Owner: software release engineering with design quality.

Pass condition: a reviewer can identify the active device version and every material model dependency for a selected UTC timestamp. The record includes configuration and endpoint. It identifies the provider version where available and the prompt or preprocessing version under control. It also records the activation event and rollback target.

Evidence: signed release manifest and deployment log. Retain the environment record, dependency resolution, and correlated field event. Test one selected event instead of relying on a configuration screenshot. The tamper-evident audit log guide describes an independent write path for request evidence.

Remediate when: latest is the only model identifier or the application can rewrite its own final audit record.

Check 6: trace a postmarket signal to closure

Owner: complaint handling, supported by the leads for safety and regulatory affairs.

Pass condition: a selected complaint or performance signal traces through intake and evaluation. The record follows the investigation and reportability assessment. It then covers correction, corrective action if applicable, and closure. The trace identifies the active software and model configuration.

Evidence: complaint record and telemetry. Retain the investigation notes and clinical or engineering review. Add the reportability decision, action record, and effectiveness check. Use a stable correlation identifier under approved privacy controls.

Remediate when: the team can retrieve the complaint but loses the version that handled the affected input. A closed ticket with an empty configuration field remains open evidence work.

Check 7: document the routed HTTP boundary

Owner: enterprise architecture with security engineering.

Pass condition: the route diagram shows authenticated application -> HTTP policy point -> approved model endpoint. Tests cover an approved request and a disallowed destination. They also cover sensitive content and missing identity context. Record retrieval is tested separately. Each expected outcome is declared before execution.

Evidence: route inventory and identity schema. Retain the policy version and staged events. Add the integrity result, protected-store permissions, and exception ticket. Embedded inference and local models stay outside this route. Direct browser use and opaque vendor-managed inference require separate controls. Device validation and clinical conclusions remain organizational responsibilities. QMS decisions and submissions do too.

Remediate when: applications can call the provider around the policy point or the supplied identity resolves only to a shared relay account.

DeepInspect

DeepInspect evaluates authenticated HTTP requests deliberately routed by a manufacturer-controlled application to an LLM. Using the identity and workflow context supplied by that application, it can permit or deny the request after any required redaction. It can also inspect the response and record the policy version and decision.

The resulting signed, tamper-evident event supports Check 5 and Check 7, plus request evidence used in a postmarket trace. It leaves embedded inference and identity proofing with the manufacturer's qualified teams. Those teams also retain validation and PCCP execution. Complaint handling, QMS ownership, and regulatory submissions remain with them. Book a technical deep dive at deepinspect.ai.