SaMD Postmarket Surveillance: Continuous Monitoring Requirements for Clinical AI

From Premarket Clearance to Ongoing Lifecycle Oversight

Historically, medical device compliance centered on a single premarket clearance event, followed by adverse event reporting when problems surfaced. FDA's 2021 AI/ML-Based SaMD Action Plan changed this posture for AI-enabled devices by introducing a Total Product Lifecycle approach, which explicitly calls for monitoring real-world AI/ML performance after deployment rather than treating premarket clearance as the end of the compliance obligation. The 2021 Good Machine Learning Practice guiding principles, jointly issued by FDA, Health Canada, and the UK MHRA, reinforce this by including monitoring of deployed model performance among the ten guiding principles for medical device development. The IMDRF SaMD Clinical Evaluation framework similarly treats clinical evaluation as a lifecycle-based process rather than a single premarket event. Together, these frameworks establish that postmarket surveillance for clinical AI is an ongoing operational function, not a document that gets filed once and revisited only during audits.

What Current Guidance Actually Requires

The regulatory obligations that already apply to SaMD remain in force for AI-enabled devices. 21 CFR Part 803 requires manufacturers to report certain adverse events within specified timeframes, and 21 CFR Part 822 authorizes FDA to require postmarket surveillance studies for devices meeting specific risk criteria, though this authority is not universal and depends on device-specific risk determinations. What is new is the layer added by FDA's draft guidance on Predetermined Change Control Plans, issued in April 2023, which asks manufacturers to describe in advance how they will monitor device performance in the field, including methods for detecting performance degradation. A PCCP effectively requires an organization to define acceptable performance boundaries before deployment, which means monitoring infrastructure must be built to detect deviation from those specific boundaries, not generic anomalies.

Manufacturers should also account for the finalized Quality Management System Regulation, which replaces the prior Quality System Regulation and aligns U.S. requirements with ISO 13485:2016 ahead of a 2026 compliance date, since monitoring documentation and recordkeeping practices will need to fit within this updated quality system structure. It is worth noting that no single FDA guidance document currently mandates a specific technical standard for real-time drift detection or audit logging. Expectations are distributed across TPLC, GMLP, and PCCP guidance and remain principle-based rather than prescriptive, which is precisely why many organizations default to periodic manual review instead of continuous technical monitoring.

Operationalizing Monitoring Inside the Quality System

Building the technical capability is only part of the compliance obligation. Monitoring plans should be defined and documented prior to deployment, consistent with FDA's expectation that PCCP-covered changes and their associated monitoring methods be pre-specified rather than developed reactively after a problem occurs. This means engineering, clinical, and regulatory functions need to agree in advance on what counts as a performance boundary, what triggers an alert, and what happens operationally when that alert fires.

Organizations should map existing quality system procedures, including CAPA, complaint handling, and medical device reporting, to automated monitoring outputs so that continuous monitoring augments existing processes instead of creating a parallel, duplicate review track. Data governance controls also need to address patient privacy when production inputs and outputs are retained for drift analysis, since retention sufficient for retrospective performance review can create exposure if not scoped carefully. Cross-functional ownership matters here because postmarket monitoring for clinical AI spans quality, clinical, and technical functions simultaneously, and a monitoring program owned solely by engineering tends to miss the quality system integration that regulators expect to see documented.

Runtime Governance as the Operational Layer

The gap between principle-based FDA expectations and day-to-day operations is where runtime governance becomes relevant. Runtime governance refers to controls that operate on a deployed AI system while it is running in production, rather than controls applied only at design time or during periodic review cycles. In practical terms, this includes runtime monitoring of model behavior, policy enforcement against predefined performance boundaries, and audit logging that records what a model did, under what configuration, and when.

These capabilities map directly to the technical components described above: a PCCP-defined performance boundary is only meaningful if a runtime control can detect when production behavior crosses it, and an audit log is only useful for FDA inspection if it is tamper-evident and tied to a specific model version. Trussed AI provides runtime governance and security for enterprise AI systems, including runtime monitoring, policy enforcement, and audit logging, which are the categories of control referenced throughout this guidance framework. Organizations evaluating how to close their postmarket surveillance gap should treat runtime governance as infrastructure that sits underneath their existing quality system, not as a replacement for it.