Always Audit-Ready:

Keeping Your AI/ML SaMD QMS in a Continuous Compliance State 

Your quality management system was built around a product that holds still. You freeze the design, verify it, release it, and the documentation you generated describes the device as it exists at that moment. That model works beautifully for hardware and for locked software. It starts to strain the moment you put a learning system into the field.

AI/ML SaMD does not hold still. The model drifts as real-world data shifts underneath it. Performance changes and planned updates roll out under a Predetermined Change Control Plan (PCCP). The QMS snapshot you captured at 510(k) clearance is already aging the day post-market deployment begins, and the gap between what your documentation says and what your model actually does only widens from there.

Staying audit-ready in this environment means treating compliance as a living state rather than a milestone you clear once. The good news is you do not need a second quality system to get there. You need to extend the one you have so it can absorb AI governance obligations from standards like ISO/IEC 42001, 42005, and 23894, and keep absorbing them as the model evolves.

Why AI/ML Breaks the Traditional QMS Model

A conventional QMS assumes a closed loop: design freeze, verification, release, then change control if something needs to move. Every change is an event you can see coming and document in advance.

Learning systems introduce open-loop risk surfaces that do not fit that pattern cleanly. Model drift, dataset shift, emergent failure modes, and PCCP-driven planned changes all create movement after release that your original documentation never anticipated. Three structural gaps tend to open up as a result.

Risk management documentation goes stale between algorithm updates, because the risk file was written against a model version that no longer exists. Post-market surveillance triggers built for adverse event reporting do not map neatly onto algorithmic performance signals like confidence drift. And supplier and data governance obligations, which now include your training data providers and labeling vendors, rarely show up in standard QMS procedures written for component suppliers.

The Standards You're Actually Operating In

Think of these as peripheral but load-bearing. They are not the spine of your QMS, but the structure does not hold without them.

ISO 13485:2016 remains your QMS backbone and the framework your FDA inspection or notified body audit lives inside. ISO 14971:2019 governs risk management and now has to stretch to cover AI-specific risk categories. IEC 62304 sets your software lifecycle and forces the question every AI/ML team eventually faces: when does a model update count as a new software version? The FDA's AI/ML guidance and PCCP framework are the US regulatory expression of how to govern adaptive AI without re-submitting for every change.

Then there are three ISO/IEC standards worth bringing into the conversation. ISO/IEC 42001:2023 defines an AI Management System (AIMS), an organizational governance framework for responsible AI. It plays a role for AI systems that is broadly analogous to what ISO 9001 plays for operational quality, though it is its own management system standard rather than a relabeled version of one. ISO/IEC 42005:2024 provides a structured method for AI system impact assessment, similar in spirit to a data protection impact assessment but focused on AI risk. ISO/IEC 23894:2023 offers technical guidance on identifying and treating AI-specific risks, the AI-native complement to ISO 14971.

These three do not replace your QMS. They pressure-test whether your QMS procedures are AI-literate enough to survive the post-market period.

Building the Continuous Compliance Architecture

The work here is integration, not reconstruction. Each piece connects an AI governance obligation to a procedure you already run.

Map your PCCP to QMS change control. Every planned modification described in your PCCP should have a matching trigger in your change control procedure. Define the thresholds explicitly in your quality plan: which drift metric values initiate a change event? The practical output is a PCCP-to-QMS trigger matrix that ties each modification type to a named document owner and a review cadence, so a planned model update never happens outside your controlled process.

Extend risk management to AI-specific hazards. ISO/IEC 23894 enumerates hazards that ISO 14971 alone does not name well: distributional shift, proxy variable misuse, feedback loops, limited explainability, automation bias. Add an AI risk annex to your risk management file that maps those categories to your 14971 severity and probability estimates. Then answer the governance question that decides whether the annex stays current: who owns it after clearance? That name belongs in your QMS org chart.

Operationalize an AIMS overlay. ISO/IEC 42001 is a management system standard, so its clause structure mirrors ISO 13485 closely: context, leadership, planning, support, operation, performance evaluation, improvement. For most SaMD vendors, the sensible move is an AIMS overlay on the existing QMS rather than a separate certified system. Absorb the elements that matter into procedures you already maintain: an AI policy that maps to your quality policy, a RACI for model owners and data stewards, supplier controls that now cover training data and inference infrastructure, and improvement mechanisms tied to model performance KPIs.

Embed impact assessment as a design input. Run an ISO/IEC 42005 impact assessment at three points: pre-development scoping, pre-submission, and at each PCCP modification cycle. The output, a record of intended-use population impacts, equity considerations, and deployment context risk, maps naturally onto your 510(k) Indications for Use and labeling review. Make it a controlled-document template triggered by your design review procedure so it happens by default rather than by memory.

Treat post-market surveillance as the heartbeat. Your PMS plan now has to capture AI performance signals, not only adverse event reports. Define a signal hierarchy: leading indicators like confidence score drift and input distribution shift, then lagging indicators like clinical outcome correlation and complaint rate by model version. Connect those thresholds back to your PCCP trigger matrix and your risk file update cadence. If you instrument this with a surveillance platform such as Grasp Health's MSO, the signal capture and trigger logic can live directly in your monitoring architecture rather than in a spreadsheet someone updates quarterly.

Who Owns Continuous Compliance

A QMS does not maintain itself, and an AI/ML QMS drifts faster than most. Assign owners explicitly. A workable split for SaMD vendors looks like this: the QA lead carries document control, audit readiness, and CAPA. The ML engineer or data scientist owns model performance monitoring and drift detection. Regulatory affairs maintains the PCCP and keeps the technical file submission-ready. Clinical or medical affairs handles benefit-risk reassessment and labeling review. Data governance owns the 42001 supplier controls and data provenance. Then set the rhythm in your quality plan with defined monthly, quarterly, and annual review cadences.

What Falling Out of Compliance Looks Like

A few failure modes show up again and again. The stale risk file, frozen at submission with no mechanism to update when the model retrains. The orphaned PCCP that exists in the 510(k) but connects to no live procedure. The shadow data pipeline, where training data updates outside supplier controls and leaves no audit trail. The missing impact loop, where the intended-use population shifts and no reassessment fires. And the audit that passes ISO 13485 surveillance cleanly but has no AI-specific controls, then stalls on the first FDA post-market question about model version governance.

Five Questions to Bring to Your Team

Before your next review, walk through these:

• Is your risk management file version-controlled to your model versions?
  

• Does your PCCP have a named owner in your QMS org chart?
  

• Do your PMS signal thresholds connect to a defined escalation procedure?
  

• Are your training data providers under formal supplier controls?
  

• Have you conducted an AI impact assessment since clearance?

If any answer is no, that is where the next gap will open.

Continuous compliance is a property of the system, not a project you finish. The three ISO/IEC AI standards are not optional complexity. They are the vocabulary your QMS needs to describe AI risk in terms regulators and notified bodies will increasingly expect to hear. If your team is working through how to wire AI governance into the QMS you already run, we'd be glad to walk through it with you.