FDA-Regulated AI and Software as a Medical Device: A Governance Primer

A Governance Question, Not Just a Legal One

Your legal team is not the right team to own your FDA SaMD obligations. They can interpret the regulation, advise on submission strategy, and review compliance documentation. But the gap that exposes health technology organizations to FDA enforcement risk is not in their legal analysis. It is in the operational infrastructure — or the absence of it — that the regulation requires organizations to build and maintain.

Consider what an FDA inspection actually examines. Inspectors do not audit legal memoranda. They audit whether the processes described in your submission documents actually exist in practice: whether your performance monitoring system generates the data your PCCP says it will generate, whether the change control authority documented in your quality management system has actually been exercised as described, whether your post-market surveillance data is being collected at the frequency your label and submission documents claim.

The gap between what organizations file with FDA and what they have actually built is exactly where enforcement actions originate. And it is exactly the governance infrastructure gap this post addresses.

Is Your Clinical AI a Medical Device? The Classification Question Has a Governance Answer

Under FDA's framework, Software as a Medical Device is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. The 21st Century Cures Act created specific exemptions for Clinical Decision Support software that displays or analyzes information for clinician review without replacing clinical judgment. But these exemptions are narrower than most organizations assume.

AI systems that acquire and analyze medical images or signals, that provide diagnosis or treatment recommendations with the intent that they replace or significantly influence a clinical judgment, or that determine patient-specific risk in ways that drive clinical action fall within the SaMD definition. The clinical intent of the system, not its technical architecture, is the determining factor.

The governance implication is that classification cannot be answered only by reading the regulation. It requires clinical, product, and regulatory teams to jointly assess how the AI system is actually positioned and used in clinical workflows — not how it is theoretically described in marketing materials. Organizations that have classified their AI tools based solely on vendor assurances or surface-level regulatory review have a gap that an FDA inspection or a litigated adverse event will surface.

The Predetermined Change Control Plan: A Governance Document, Not a Regulatory Filing

The Predetermined Change Control Plan is the most governance-significant development in FDA's AI/ML SaMD framework. Formalized in FDA's April 2024 final guidance, the PCCP allows developers to pre-approve a defined set of post-market algorithm changes so that updates falling within those parameters do not require a new marketing submission. It is a mechanism that solves a real problem: AI models need to evolve with real-world data, and the standard 510(k) cycle was not designed for continuous learning systems.

But the PCCP is being misread by most organizations as primarily a regulatory benefit — a way to avoid future filings. That misreading obscures what the PCCP actually requires organizations to build.

A PCCP has two mandatory components. The Software Performance Specifications define the performance parameters within which algorithm changes are permitted: the accuracy thresholds, the subgroup performance bounds, the input domain constraints. The Performance Assessment Plan defines how the organization will monitor performance in the real world, detect when the system approaches or crosses those bounds, and govern the decision to deploy a change or trigger a new submission.

"The PCCP is not a regulatory shortcut. It is a governance commitment. You are telling FDA what performance you will maintain, how you will monitor it, and who has authority to make changes. Those commitments require infrastructure to be real."

The Performance Assessment Plan is, in governance terms, a monitoring architecture document. It requires the organization to specify what data is collected about AI system performance in deployment, at what frequency, analyzed by whom, reported to which decision-making body, and what threshold triggers a mandatory review versus a permitted update versus a new submission. That is a governance operating cadence, not a compliance filing.

Post-Market Surveillance: What It Actually Requires as a Legal Obligation

Post-market surveillance for SaMD is not an industry best practice. For devices meeting certain criteria under 21 CFR Part 822, it is a legal requirement. FDA can order post-market surveillance for higher-risk devices, and the agency's clear expectation for AI/ML SaMD is that developers maintain continuous performance monitoring in real-world deployment contexts — not just the controlled conditions of pre-market validation.

The distinction between validation and surveillance is the governance gap most organizations underestimate. Pre-market validation tests the AI system against a curated dataset under defined conditions. Post-market surveillance monitors the same system as it encounters the full diversity of real-world clinical environments: patient populations that differ from training cohorts, clinical workflows that differ from validation settings, EHR data quality that differs from structured research datasets.

An AI system that performed well in validation and is performing differently in deployment generates the Medical Device Reports that create FDA enforcement exposure. An organization with robust post-market surveillance detects performance drift before it generates adverse events and before FDA detects it through MDR patterns. An organization without post-market surveillance discovers the same problem through a regulatory action or a patient harm event.

Where SaMD and NIST AI RMF Overlap: Why That Matters for Your Organization

The NIST AI RMF's MEASURE function addresses continuous evaluation of AI system performance in deployment: defining metrics, establishing monitoring processes, stratifying performance across affected populations, and creating reporting paths to decision-makers. FDA's post-market surveillance requirements address the same operational space from a different regulatory direction.

This is not a coincidence. Both frameworks are responding to the same underlying reality: AI systems that perform acceptably at deployment can degrade over time as patient populations, clinical workflows, and data distributions shift. The regulatory and governance responses to this reality converge on the same operational requirement — continuous monitoring with defined thresholds and documented decision authority.

For health technology organizations building toward both NIST AI RMF alignment and FDA SaMD compliance, this convergence is a design opportunity. A monitoring infrastructure that collects real-world performance data, stratifies by relevant subgroups, generates alerts at defined thresholds, and routes findings to a named decision authority can be designed to satisfy the MEASURE function and the post-market surveillance obligation simultaneously. This is not just more efficient; it creates a single, coherent operational system instead of two parallel programs that neither team fully owns.

The same convergence exists between the PCCP's Performance Assessment Plan and the NIST AI RMF MANAGE function, which addresses how organizations prioritize and respond to identified risk findings. And for organizations subject to the EU AI Act, Article 72 post-market monitoring requirements overlap with both. Organizations that map these converging obligations before building their monitoring systems avoid the common failure of implementing three governance programs that describe the same process in different language, satisfy no regulator's expectations fully, and generate organizational confusion about who owns the work.

The Governance Question FDA Will Ask That Your Policy Cannot Answer

When FDA inspects a regulated AI device, the question they are functionally asking is not "do you have documentation?" It is "does your documentation reflect what you actually do?" The enforcement pattern in AI SaMD cases is not primarily organizations that lacked policies. It is organizations whose policies described processes that did not operationally exist.

The governance question, translated into operational terms, is this: if an FDA investigator arrived at your organization tomorrow and asked to see the records of your AI system's performance monitoring for the past ninety days, the change control decisions made under your PCCP for the past year, and the post-market surveillance data that informed your most recent labeling review, could you produce them?

If the answer is no — or if the answer is that the data exists in fragmented form across multiple teams without a clear audit trail — then your SaMD compliance posture is a policy posture, not an operational one. The exposure is not in what you filed. The exposure is in the gap between what you filed and what you built.

The same question applies to health systems deploying vendor AI SaMD. Your vendor's regulatory clearance does not transfer their post-market obligations to you. As a deployer, you bear obligations for how you deploy, configure, and monitor the AI system within your clinical environment. Those obligations require governance infrastructure on your side of the relationship, including contractual clarity about which monitoring obligations the vendor fulfills and which you must maintain independently.

Key Takeaways

• FDA SaMD classification is a governance determination, not only a legal one. Clinical, product, and operations teams must jointly assess how AI systems are actually used. Classification must be revisited at product change events, not treated as permanently settled.

• The Predetermined Change Control Plan is a governance architecture document. Its Software Performance Specifications define the performance bounds the AI system must maintain; its Performance Assessment Plan defines the monitoring, reporting, and change authority infrastructure required to keep it there. Both must be operational before the PCCP is submitted.

• Post-market surveillance for SaMD is a legal obligation, not an industry best practice. Organizations with no continuous monitoring infrastructure have an open compliance gap regardless of their clearance status.

• FDA's post-market surveillance requirements and the NIST AI RMF MEASURE function address the same operational space. Monitoring infrastructure can be designed to satisfy both, along with EU AI Act Article 72 requirements, simultaneously.

• The governance question FDA will ask is operational, not documentary. The exposure is in the gap between what documentation says and what the organization has actually built.

• Health systems deploying vendor AI SaMD bear their own post-deployment obligations. The vendor's clearance does not transfer their monitoring responsibilities. Governance infrastructure is required on both sides of the relationship.