FDA’s QMSR Is Live: Why Clinical AI Teams Need Inspection-Ready Evidence, Not Just Great Models

Executive summary

On February 2, 2026, the U.S. Food and Drug Administration’s Quality Management System Regulation (QMSR) became effective, amending the medical device CGMP requirements in 21 CFR Part 820 and incorporating ISO 13485:2016 by reference.

On the same date, FDA also changed its inspection approach, stopping use of the legacy QSIT method and beginning to use the inspection process described in Compliance Program 7382.850 and retiring certain prior compliance program documents.

For clinical AI teams, it is tempting to treat QMSR as just a quality rewrite. Practically, it raises the default bar for reconstructability, the ability to reproduce what happened and why for a specific model version in the field using controlled records.

The 2026 regulatory change

FDA describes QMSR as a modernization that amends device CGMP requirements in Part 820 and incorporates ISO 13485:2016 by reference while adding FDA-specific clarifications so the incorporation does not create inconsistencies with other applicable FDA requirements. Since the effective date, February 2, 2026, it is now the baseline for inspections and quality system expectations.

FDA states it stopped using QSIT and began using the inspection process described in Compliance Program 7382.850 beginning February 2, 2026. For RA/QA leaders, that signals an inspection lens aligned to QMSR’s structure and the ISO-style evidence model FDA is now referencing.

QMSR does not, by itself, define how to validate an LLM, how to detect drift, or how to structure AI change control. Those topics still live across device and AI-specific guidance ecosystems. However, QMSR establishes the system requirement: whatever your AI lifecycle looks like, it must be controlled, documented, and reconstructable within a compliant quality system.

What QMSR changes operationally for clinical AI

Clinical AI teams often optimize for iteration speed; notebooks, experiment trackers, Git repositories, Jira tickets, and internal dashboards. QMSR and ISO-aligned thinking optimize for reconstructability under scrutiny; the ability to show, with objective evidence, what you did and why, and to reproduce that evidence later.

The shift from documentation to reconstructability.

Under a QMSR/ISO-aligned world, the practical question stops being “Do we have a story for the model?” and becomes: Can we reproduce the evidence package for the exact model version running in the field, tied to the exact data, configuration, and intended use, with a controlled decision and change history?

QMSR’s scope covers the methods, facilities, and controls used for the design, manufacture, packaging, labeling, storage, installation, and servicing of finished devices intended for human use. That broad lifecycle framing is why clinical AI teams feel it: a clinical model is no longer just “software”. It is a device lifecycle object that must be maintained through controlled processes.

Validation becomes a quality record, not a one-time milestone.

As FDA explains QMSR, its intent is to ensure products consistently meet requirements and specifications under a quality system baseline. For AI, the validation object is not only code. It is also training and test data composition, labeling policy, preprocessing, thresholds, and deployment context. If any of those change, the “story” is not enough; you need the managed record trail that shows whether the evidence still holds.

Model versioning becomes a regulated artifact, not a developer convenience.

Many teams version code extremely well but version “the full model system” inconsistently; weights, preprocessing logic, post-processing, runtime environment, and (where relevant) prompt or retrieval components. QMSR doesn’t hand you a model registry template, but it increases the cost of not having one. If you cannot map field behavior back to a controlled version and its supporting evidence, audits, investigations, and procurement escalations become slower and riskier.

Post-market signals must link back to governed actions.

QMSR’s emphasis on a quality system baseline, paired with the new inspection posture, means post-market observations are not just monitoring metrics. They become quality signals that must be interpretable, traceable, and connected to corrective actions when needed. This is especially consequential for AI systems whose performance is sensitive to data drift, workflow variation, and site heterogeneity.

Procurement due diligence will mature from metrics to evidence operations.

Clinicians and procurement teams will still ask for sensitivity/specificity and AUC. But QMSR-era readiness pushes better operational questions to the top of the buying checklist:

• What is your controlled change process for model updates?

• How do you tie a field incident to root-cause analysis across data, model version, and workflow?

• Can you show an audit trail for validation decisions and release gating?

• Those are not extra compliance questions. They are the practical mechanism by which providers reduce clinical and reputational risk when adopting AI at scale.

Actionable recommendations

Treat evidence governance as a product capability. Build an evidence spine that connects: intended use → requirements and risks → dataset lineage → model build/version → validation runs → release decision → post-market signals → corrective actions. If any link is manual, it will break under scale and under inspection.

Define the “model system” that must be controlled. Write down what counts as the regulated object for your product: weights, preprocessing, thresholds, runtime environment, and any critical configuration. Then align change control to that definition—not only to code commits. This clarifies what “the version” actually is when RA/QA, engineering, and procurement need a shared answer.

Make validation reproducible by default. Move from results decks to rerunnable validations whose outputs are tied to immutable inputs and configurations. This reduces audit time, accelerates investigations, and lowers the cost of safe iteration—because you can reproduce the evidence without recreating the past.

Procure for auditability—not only accuracy. If you are buying clinical AI, ask vendors for objective evidence: version history, traceability from claims to validation outputs, and clear escalation pathways for post-market signals. A vendor with polished dashboards but weak controlled records will create downstream operational risk for the provider organization.

For inquires please contact us.