QMS for AI/ML Medical Devices: Regulatory & Design Guide

This report provides a comprehensive analysis of how to build and maintain a robust Quality Management System (QMS) specifically for medical devices incorporating artificial intelligence (AI) and machine learning (ML) technologies. AI/ML-based medical devices (often considered Software as a Medical Device, SaMD) pose unique challenges that require adapting traditional medical device QMS frameworks. We review the historical context of quality management in medical device regulation, identify the current regulatory landscape for AI/ML medical devices, and examine the components of a QMS that must be tailored to AI/ML. Key findings include:

• AI/ML growth in medical devices: Chen et al. studied a historical cohort of 878 Class II AI/ML-enabled devices through March 2024; this is not a current FDA total (^[1]). AI is pervasive in imaging, diagnostics, monitoring, and decision support. In a separate 950-device study, 60 devices (6.3%) were associated with recalls (^[2]). These findings support lifecycle quality monitoring without establishing that a particular manufacturer’s QMS was deficient.

• Regulatory and standards guidance: Applicable device QMS requirements remain the foundation. FDA’s QMSR is 21 CFR Part 820; compliance and ISO 13485 certification are distinct (^[3]). The FDA’s final PCCP submission guidance describes planned model updates (^[4]). In the EU, the AI Act’s product-related high-risk rules have a separate application date from its general provisions (^[5]). Manufacturers should determine the obligations applicable to their device, market, classification, and conformity-assessment route.

• QMS structure and adaptation: Where applicable, manufacturers must maintain a QMS under the relevant jurisdiction’s requirements, covering document control, design/development controls, risk management, production controls, CAPA, supplier management, and post-market surveillance. Each of these elements requires AI-specific enhancements. For example, “design control” processes must incorporate data collection and model training as design inputs, and “design outputs” include not only software code but also trained model artifacts and validation results (^[6]) (^[7]). Risk management (ISO 14971) must explicitly consider AI-driven hazards such as data bias, adversarial inputs, model drift, and incorrect automation. Procedures must be documented for how models are trained, tested, validated, and updated, preserving traceability and reproducibility (^[7]) (^[8]).

• Data and validation: A critical QMS element is controlling the data lifecycle. High-quality, representative, and well-annotated training data are crucial for safe AI devices. The system must document data sources, preprocessing, labeling protocols, and uses. The QMS should enforce strong verification and validation (V&V) – not just unit and integration tests of software, but independent evaluation of model performance on held-out and real-world data. Recent analyses of public FDA decision summaries identified incomplete reporting of training data, demographics, and trial designs (^[9]), underscoring the need for rigorous data management in the QMS. Moreover, continuous monitoring (post-market surveillance) must detect when model performance degrades or when new use-cases arise.

• Change management: A QMS for AI/ML devices must handle frequent and planned changes more flexibly than traditional software. FDA has introduced the concept of Predetermined Change Control Plans (PCCPs) to support FDA-authorized plans for model updates (e.g. model retraining on new data) under pre-specified risk controls (^[10]) (^[11]). In practice, this means strict version control, change protocols, and documentation for any model update. The QMS must ensure each change is assessed for safety and efficacy before deployment.

• Case studies and data: Real-world evidence illustrates these needs. Recall studies identify design and software issues, while public-summary analyses highlight reporting gaps (^[1]; Early Recalls and Clinical Validation Gaps in Artificial Intelligence–Enabled Medical Devices; Benefit-Risk Reporting for FDA-Cleared Artificial Intelligence–Enabled Medical Devices). Missing information in public summaries does not establish that studies, confidential submission evidence, or internal QMS records were absent. Proposed improvements to verification, documentation, and monitoring are recommendations, rather than findings that specific QMS failures caused recalls.

• Future directions: Regulatory bodies worldwide are responding. In the US, FDA has upgraded 21 CFR 820 to the “Quality Management System Regulation” (QMSR, effective Feb 2026) (^[12]), aligning more closely with ISO concepts and emphasizing risk-based approaches. Globally, ISO/IEC 42001:2023 provides an AI management-system framework (^[13]). The EU AI Act and other AI governance efforts will further formalize QMS expectations for AI. Manufacturers must stay agile in updating their QMS, and might also leverage digital QMS tools with AI capabilities to manage the complexity.

In sum, integrating AI/ML into medical devices demands that every aspect of the QMS be re-examined and augmented for the data-driven, adaptive nature of these products. This report provides a detailed roadmap: from understanding regulatory contexts to elaborating on data management, risk control, and validation processes tailored for AI/ML, including case examples and best practices. The cited regulatory documents, scientific studies, and expert analyses provide context to guide device makers, regulators, and healthcare institutions in building or evolving their QMS for AI/ML medical devices.

The advent of Artificial Intelligence (AI) and Machine Learning (ML) in healthcare is transforming medical devices across diagnostics, monitoring, and treatment. Traditional medical equipment, such as imaging systems or physiological monitors, are now routinely augmented with AI/ML algorithms that analyze data to assist clinical decisions. Unlike conventional software, AI/ML systems can learn from data and adapt over time (either continuously in-field or via periodic updates). This iterative, data-driven nature creates unique challenges for ensuring device safety and effectiveness.

A Quality Management System (QMS) is the organizational framework that ensures medical devices are designed, produced, and maintained under control, meeting regulatory requirements and performance standards. Established QMS principles (e.g. ISO 13485:2016 and FDA’s 21 CFR 820) emphasize documentation, process controls, risk management, and continuous improvement. These principles apply to all medical devices, including software as a medical device (SaMD). However, AI/ML devices introduce new domains of risk and complexity that traditional QMS processes must explicitly address. For example, a diagnostic AI model’s performance critically depends on the data used to train it; errors in data or drift in clinical practice could lead to patient harm unless proactively managed.

This report examines in depth how to build and operate a QMS tailored for AI/ML medical devices. We first recount the background: the evolution of medical device quality regulation and the emergence of AI in healthcare. We then survey the regulatory and standards landscape, including recent FDA and EU initiatives on AI/ML devices. Next, we dissect QMS components (design controls, risk management, document control, etc.) through the lens of AI/ML, highlighting specific practices for data lifecycle management, algorithm verification/validation, change control, and post-market monitoring. Empirical data and case examples illustrate where gaps have led to device recalls or safety concerns, underscoring the stakes. Finally, we discuss future implications as AI-specific standards and guidance mature, and offer recommendations for integrating AI considerations into quality culture.

This treatise aims to be authoritative and comprehensive, with extensive citations to regulatory documents, scientific literature, and expert guidance. By providing detailed, evidence-based analysis of each aspect of the QMS, this report serves as a guide for medical device manufacturers, regulators, and healthcare leaders to understand and implement quality assurance for AI/ML-enabled products. The ultimate goal is to ensure these innovative devices deliver their intended benefits safely and effectively to patients, within a robust quality framework.

Quality Management Systems in Medical Device Regulation

A Quality Management System (QMS) in the medical device industry is a structured set of policies, processes, and procedures that organizations use to ensure their products consistently meet customer and regulatory requirements. Foundational standards such as ISO 13485:2016 (Medical devices—Quality management systems) explicitly define requirements for such a system in the context of quality assurance, production, and post-market monitoring of medical devices. Historically, FDA’s Quality System Regulation (QSR) in 21 CFR Part 820 established design, process, and corrective-action controls; references to the former QSR in this article describe that historical framework. (Note: as of Feb 2, 2026 the FDA has renamed Part 820 as the “Quality Management System Regulation” or QMSR (^[12]) while largely retaining the same elements under a more risk-based approach, aligning with ISO principles.)

The elements of a typical medical device QMS include:

• Management Responsibility: Leadership commitment, quality policy, organizational structure.
• Document and Record Controls: Procedures for creating, approving, updating, and retaining documents (design history files, manufacturing records, etc.).
• Design and Development Controls: Defined procedures for design inputs, outputs, verification, and validation.
• Production and Process Controls: Ensuring manufacturing processes are controlled and validated.
• Purchase/Supplier Controls: Qualified suppliers, incoming quality checks.
• Risk Management: Application of ISO 14971 to identify hazards and implement mitigations.
• CAPA (Corrective and Preventive Action): Identifying and addressing nonconformities and potential issues.
• Internal Audits and Management Review: Ongoing monitoring and improvement of the QMS itself.

This QMS framework has historically ensured that devices—from simple mechanical implants to complex electronics—are safe and effective. It enforces traceability (e.g. material to final product), accountability, and a culture of continuous improvement. Quality records (like design history files and device master records) must be maintained and are frequently audited by regulators.

Evolution of AI/ML in Medical Devices

Artificial Intelligence and Machine Learning refer to software systems that can learn patterns from data and make predictions or decisions. In healthcare, notable examples include image analysis algorithms (for radiology, pathology, or ophthalmology), seizure or arrhythmia detectors from biosignals, predictive models for patient deterioration, and clinical decision support tools. Chen et al.’s 2025 recall analysis used a historical cohort of 878 Class II AI/ML-enabled devices through March 2024, rather than a mid-2025 or current FDA total (^[1]). These devices use data-driven algorithms for tasks that traditionally required human interpretation.

However, AI/ML devices differ fundamentally from fixed-function devices:

• Data-Dependence: The performance of an AI system is tied to its training data. Biased or limited data can lead to poor performance in certain populations.
• Adaptive Nature: Some AI systems are designed to learn and improve over time (e.g. by incorporating new patient data), which blurs the line between device and process. Traditional QMS assumed validated software is “locked” during use, but AI challenges that assumption.
• Complexity and Opacity: Many AI models (e.g. deep neural networks) are “black boxes” with limited interpretability. This increases uncertainty about how they make decisions.
• Lifecycle Changes: AI components may require frequent retraining, updates, or calibration, introducing new change-control challenges beyond typical software patches.

These characteristics raise safety and effectiveness issues that a QMS must address explicitly. For example, as one review noted, AI systems must cope with “errors or faulty input” in order to gain clinical trust (^[14]). Ensuring robustness to real-world conditions and data shifts is essential. If an AI diagnostic tool performs well initially but degrades as practice patterns evolve, regulators and manufacturers need QMS provisions to catch and manage that drift.

Quality Management for AI/ML: New Considerations

The notion of a “Quality Management System for AI/ML” is gaining attention both in industry and academia. A recent perspective argues that QMS principles should be integrated throughout the AI development life cycle – from initial research through deployment and routine use – to “close the AI translation gap” and facilitate safe, ethical implementation (^[15]) (^[8]). In practice, this means adapting standard quality processes to cover AI-specific elements:

• Augmented Design Control: Design inputs now include data requirements and algorithm specifications; outputs include trained models and performance metrics.
• Extended Risk Management: In addition to physical harm or software malfunction, risk analysis must consider biases, adversarial attacks, and degradation over time.
• Traceability for Data: Datasets themselves become controlled documents: versioned, vetted, and traceable.
• Validation Beyond Code: Verification must not only check software logic but assess statistical performance (sensitivity, specificity) on validation datasets or clinical trials.
• Change Management: QMS must accommodate model versioning. FDA’s new Predetermined Change Control Plans (PCCPs) require upfront definition of the scope and safeguards for planned model changes (^[10]) (^[11]).
• Cybersecurity Considerations: AI devices (often cloud-connected or data-intensive) must embed security risk management into the QMS (e.g. following the FDA’s new cybersecurity guidance) (^[16]).
• Post-Market Monitoring: The QMS should include continuous monitoring of real-world performance (and adverse events) of AI algorithms, triggering CAPA processes if thresholds fall outside approval claims.

Adopting these AI/QMS practices ensures that new complex threats are managed systematically, maintaining device reliability. As one commentary emphasizes, a QMS “documents processes, procedures, and responsibilities to achieve quality objectives,” and this structure can manage evolving regulatory requirements and ensure adherence to cutting-edge standards over the life cycle of AI/ML medical software (^[17]). In short, AI device QMS integrates traditional device quality assurance with data science best practices, bridging technical and clinical domains.

Medical devices with AI/ML components fall under existing regulatory regimes for medical devices, but regulators are actively updating guidance to address AI’s peculiarities. This section summarizes the key frameworks and how they relate to QMS.

United States (FDA)

In the U.S., applicable device quality-system requirements are set out in 21 CFR Part 820, the Quality Management System Regulation (QMSR), effective February 2, 2026 (^[3]). QMSR incorporates applicable ISO 13485:2016 requirements; FDA does not require ISO 13485 certificates. A third-party certificate neither replaces regulatory compliance nor exempts a manufacturer from FDA inspection. Certain device types have CGMP exemptions, which do not remove applicable complaint-file and record obligations (^[18]). Under 21 CFR 820.10(c), design-and-development requirements apply to Class II and III devices and specified Class I devices, including devices automated with computer software (^[19]). Determine applicability and exemptions from the device’s classification and regulation, rather than treating every AI product as having identical requirements. Part 4 is not the QMSR.

Beyond baseline QMS rules, FDA has issued AI-specific guidance:

• SaMD Guidance and Change Control: FDA’s 2019 discussion framework and the 2023 FDA/Health Canada/MHRA guiding principles are historical milestones. The current final marketing-submission guidance is dated August 2025 (^[4]). It recommends a PCCP describing planned modifications, the methodology to develop, validate, and implement them, and their impact. FDA reviews the plan as part of the device marketing submission. See Change Management for the plan’s components and implementation conditions.

• Good Machine Learning Practice (GMLP): IMDRF’s N88 FINAL:2025, published on 29 January 2025, sets out guiding principles for safe, effective, high-quality AI-enabled medical devices (^[20]; IMDRF/AIML WG/N88 FINAL:2025). Use these lifecycle principles to inform procedures for data management, model development, testing, and monitoring; distinguish guiding principles from binding device requirements.

• Clinical Evidence and Public Reporting: Lin et al.’s 2025 analysis examined publicly accessible decision summaries for 691 devices, identifying reporting gaps in study design, sample size, demographics, and safety assessment (^[21]). These omissions do not establish that the corresponding studies or confidential submission evidence were missing. Complete internal evaluation records and clear public reporting are recommended QMS improvements.

• Cybersecurity Guidance: In December 2022, a U.S. law mandated stronger cybersecurity for medical devices. The FDA’s February 2026 final guidance explicitly addresses "Cybersecurity in Medical Devices: QMS Considerations" (^[16]). This guidance directs manufacturers to integrate cybersecurity risk management into their QMS (e.g. via procedures for vulnerability management and secure software updates). Because AI/ML systems often use cloud or networked components and handle sensitive data, FDA expects the QMS to document cryptographic protections, network security, and incident response plans alongside traditional quality controls.

• Device Software Consensus Standards: FDA describes consensus standards used in premarket submissions as voluntary. Recognized standards can support evidence for a submission; alternative approaches may be acceptable when they satisfy applicable statutory and regulatory requirements (^[22]). IEC 62304, IEC 82304-1, and AAMI TIR45 can inform software lifecycle practices; their relevance does not make them universal FDA mandates. Distinguish this voluntary submission route from requirements incorporated into regulations, including applicable ISO 13485 requirements under QMSR (^[18]).

A practical QMS approach is to document model development and updates, evaluate risks, retain verification and validation evidence, and assess the applicable cybersecurity and change-submission requirements. A PCCP is relevant when the manufacturer seeks authorization for specified future modifications; it is not a universal prerequisite for every AI-enabled device. FDA inspections assess compliance with applicable FDA regulations (^[3]).

European Union

In the EU, determine the applicable Medical Device Regulation (MDR 2017/745) or In Vitro Diagnostic Regulation (IVDR 2017/746) obligations, risk class, and conformity-assessment route. The QMS must be proportionate to the type and risk class of the device (^[23]). ISO 13485 certification is not a universal CE-marking prerequisite: harmonised standards are voluntary and, when cited in the Official Journal, confer presumption of conformity for the requirements they cover (^[24]). A compliant QMS, an ISO certificate, and device conformity assessment are distinct.

• EU AI Act scope and timeline: The adopted Act is Regulation (EU) 2024/1689. It entered into force on 1 August 2024 and generally became applicable on 2 August 2026, with exceptions. The Commission’s current timeline, following the AI Omnibus’s entry into force on 27 July 2026, gives 2 August 2028 for Annex I product-related high-risk rules (^[5]). Medical-device AI falls within Article 6(1) when it is itself a product or a safety component covered by the listed legislation and that product requires third-party conformity assessment. This is not an identical high-risk obligation for every medical AI function (^[23]). Article 17’s AI-system QMS requirements should be planned alongside applicable MDR/IVDR obligations and their respective implementation dates.

• MDR conformity assessment: Annex IX describes a QMS-based conformity-assessment route. Select the route appropriate to the device’s class and circumstances; do not assume that every device follows the same notified-body procedure. The published MDCG 2025-6 guidance explains how MDR/IVDR and AI Act requirements interact (^[23]).

• Standards and Assurance Guidance: IEC 62304 and ISO 14971 can inform software lifecycle and risk-management practices. The University of York’s Centre for Assuring Autonomy provides AMLAS, a six-stage methodology for integrating safety assurance into ML-component development (^[25]). It can be considered as an assurance method; do not confuse it with the NHS clinical safety standards or imply NHS endorsement without a specific NHS source.

• United Kingdom: Distinguish Great Britain’s UK MDR 2002, which gave effect to earlier EU directives, from the EU MDR/IVDR rules applicable in Northern Ireland (^[26]). MHRA device market requirements are separate from NHS clinical safety standards. DCB0129 addresses manufacture of health IT systems and DCB0160 addresses deployment and use; NHS England identifies compliance as mandatory within their applicable scope (^[27]). Standards used to support UKCA conformity assessment are not mandatory simply because they are designated (^[28]).

Table 1 summarizes the distinction between applicable medical-device requirements, AI guidance, and voluntary standards. Determine the device’s jurisdiction, classification, and exemptions before selecting a conformity-assessment route.

Region / Regulatory Body	Medical Device QMS Requirement	AI/ML-Specific Guidance	Key Standards / References
USA (FDA)	21 CFR 820 (QSR), now QMSR (effective 2026) – requires documented design controls, CAPA, etc ([12]).	- FDA SaMD guidance (2019+), Predetermined Change Control Plan (PCCP) final submission guidance (August 2025) for AI updates ([4]; historical 2023 guiding principles: [10]). - Good Machine Learning Practices (Principles) encouraging data and model documentation. - Postmarket surveillance and cybersecurity guidance (2026) for AI devices ([16]).	IEC 62304 (medical software lifecycle) ([6]); ISO 14971 (risk mgmt); IEC 82304-1 (health software safety); AAMI TIR45 (Agile MD software) ([7]).
EU (MDR)	MDR/IVDR QMS and conformity-assessment obligations depend on device type and risk class; Annex IX is a QMS-based assessment route ([23]). Harmonised standards are voluntary ([24]).	- AI Act, Regulation (EU) 2024/1689: Article 17 QMS obligations for high-risk systems; assess Article 6(1) scope and the separate Annex I application date of 2 August 2028 ([5]). - Published MDCG 2025-6 guidance on MDR/IVDR–AI Act interplay ([23]). - Applicable MDR/IVDR post-market and vigilance rules.	ISO 13485:2016; IEC 62304; ISO 14971; IEC 82304-1; ISO/IEC 42001:2023, the published AI management-system standard ([13]); EN ISO standards for software/MD.
UK (MHRA)	Great Britain: UK MDR 2002; Northern Ireland: applicable EU MDR/IVDR rules ([26]). Conformity-assessment routes depend on device classification; designated standards are voluntary ([28]).	- NHS DCB0129: clinical risk management in manufacture of health IT systems. - NHS DCB0160: clinical risk management in deployment and use. - Mandatory compliance within the standards’ applicable scope; distinct from MHRA device market requirements ([27]).	ISO 13485; IEC 62304; ISO 14971; DCB0129 and DCB0160 are NHS clinical risk-management standards ([27]).
International (Regulatory Forum)	IMDRF SaMD guidelines, ISO 13485:2016 recommended for all medical device QMS.	- IMDRF Good Machine Learning Practice guiding principles, N88 FINAL:2025 ([20]). - WHO AI guidance for ethics (not enforceable, but relevant for 'quality' of AI development). - ISO/IEC 42001:2023 defines an AI Management System standard (guidance for QMS of AI) ([29]).	IMDRF SaMD WG documents; ISO/IEC 42001:2023 (AI management system) ([29]); AAMI/ANSI reports on AI.

Table 1: Regulatory requirements and standards relevant to AI/ML medical device QMS. (Sources: FDA, EU AI Act, standard documents (^[10]) (^[30]) (^[29])).

Use Table 1 to identify applicable device obligations and supporting frameworks. Build documented procedures for data governance, model validation, change assessment, and monitoring into the QMS where relevant. A voluntary AI management-system standard or assurance method does not itself establish device market authorization.

This section details the specific elements of a quality management system that are especially pertinent for AI/ML medical devices. We discuss how each conventional QMS process area must be extended or adapted to handle AI/ML characteristics, with supporting citations.

Quality Policy and Objectives

At the top of the QMS, the quality policy should explicitly recognize the role of AI in the organization’s products. As one expert advises, organizations should define AI-related commitments in their quality policy to guide process development (^[31]). For instance, a manufacturer might state a policy to ensure that all AI algorithms are validated on representative clinical data and routinely performance-monitored. Aligning quality objectives (e.g. accuracy, uptime targets) with AI product characteristics helps set measurable targets.

Management must assign responsibilities related to AI quality. This includes deciding who manages data governance, who reviews model audits, and who handles cybersecurity of AI components. (ISO 13485 requires defining roles in the quality manual.) Top management reviews may need to include items like algorithm performance metrics, updates issued, and field data trends.

Document and Data Control

A robust QMS requires strict document control. For AI devices, the scope of controlled documents expands significantly. Standard QMS documents (procedures, work instructions) must be augmented by:

• Data Records and Specifications: Detailed documentation of all datasets used for training, validation, and testing. This includes data origin, inclusion/exclusion criteria, and how data is labeled or annotated. The QMS should control dataset versions (e.g. via a data management plan) and ensure only authorized, validated datasets feed into model training (^[9]).
• Model Artifacts: The trained AI models (weights, logic) themselves should be treated as release items. A design history file (DHF) entry could include the model architecture, hyperparameters, and training code. Each model version should be uniquely identified and traceable to the software version and dataset used. This parallels how hardware devices record specification revisions in the device master record.
• Software Code: Source code for the AI algorithm or pipelines must be under version control, with change logs. Standard code management and review procedures (peer review, static analysis) remain vital. Assess each software function’s intended use and the applicable device definition and exclusions; processing medical data alone does not make all code device software (^[32]; Examples of Software Functions That Are NOT Medical Devices). Separately, document and control development or quality-system tools according to their intended role and risk.

8fold Governance advises that new forms of records may be needed for “transparency and explainability” of AI systems (^[33]). For example, manufacturers might generate model cards or datasheets for datasets, summarizing model purpose, training data stats, and performance. These can be QMS records demonstrating what was considered in development and can aid regulators or users in understanding the AI’s basis.

Practically, the QMS should require periodic review of these documents. Given the rapid evolution of AI, one should shorten revision cycles for manuals and procedures related to AI (to avoid outdated guidance) (^[34]). For instance, as new AI standards or security practices emerge, the QMS documents must be updated accordingly.

Design and Development Controls

In FDA/ISO terms, design controls cover translating user needs into system requirements, and ultimately into a validated product. For AI/ML medical devices, this requires special attention:

• User Needs & Intended Use: The initial design control inputs must capture not only the clinical function but also the data domain. For example, a chest X-ray AI might need clarified which imaging equipment and patient demographics it targets. The intended use statement should specify that AI is involved, and define how its outputs will be used clinically.
• Design Inputs: Along with clinical requirements, include data-related requirements: What types of data should the AI handle? What accuracy, sensitivity, and specificity thresholds are needed? How should the AI behave if encountering out-of-distribution data? Also consider regulatory constraints on the AI (e.g. explainability or security requirements). These should be documented in the design plan.
• Design Outputs: The system architecture should reflect the ML workflow. Outputs include not only software source code but also data preprocessing algorithms, the trained model files, and acceptance test procedures for model performance. All outputs must be reviewed for traceability back to inputs.

As a practical design-control recommendation, establish and control core design documentation early in agile development (^[7]). For example, initial system-level requirements and high-level architecture documents should be baselined early, then updated only through formal official changes. Lower-level details (e.g. internal model structure) may evolve faster, but the QMS must maintain records linking all changes to higher-level requirements. In practice, companies often maintain a traceability matrix that ties user needs to system requirements, to design specifications, to verification tests – now extended to include AI metrics and data traceability.

The design control process as applied to AI/ML devices has been discussed in literature. For example, Henry and Thiel (2022) describe how the former FDA design controls (historical 21 CFR 820.30) applied to an “AI/ML lifecycle” and show how traditional inputs/outputs must be expanded for AI systems (^[7]). Key points include:

• Even with agile development, initial user needs and high-level requirements should be placed under controlled revision so that changes are deliberate (^[35]).
• Iterative sprints can produce intermediate builds and user stories, but each completed increment of code ties back to a design specification in the DHF.
• Design verification for AI includes performance testing on reference data. The “definition of done” for each development sprint may include passing certain unit tests and evaluation metrics (^[36]).
• The QMS must capture the entire development pathway, often illustrated by an iterative cycle where model performance is repeatedly measured and improved.

Under current QMSR, assess design-and-development applicability under 21 CFR 820.10(c), as described in the United States section (^[19]). Design controls for AI devices mean integrating software engineering practices with the applicable QMS requirements. All ML model development must be planned, documented, and verified as part of the design history file, just like any other medical device component.

Risk Management (ISO 14971)

Risk management is central to medical device QMS. ISO 14971:2019 requires identifying hazards, estimating and evaluating associated risks, implementing control measures, and monitoring effectiveness. For AI/ML devices, some unique hazards arise:

• Data Bias and Representativeness: If training data lack diversity (e.g. racial or demographic bias), the model may perform poorly on certain patient groups, leading to misdiagnosis. This hazard (decision bias) should be documented in risk analysis. The QMS risk procedure must include evaluating data sufficiency and demographic coverage. A risk control might be to incorporate a broader training set or to flag referrals on higher-risk populations.
• Algorithmic Errors: Unlike deterministic software bugs, ML models can make unpredictable errors with low-frequency data. For example, an image classification AI might misinterpret rare conditions. Treat these errors as “software fault” hazards and evaluate their severity (e.g. false negative cancer diagnosis could be severe). Implement controls such as redundancy (double-reading by humans) or “unknown alert” outputs.
• Model Drift: Over time, the real-world data distribution may shift (new equipment, patient population changes). This is a hazard of obsolete performance. The risk analysis must consider how changes in environment can degrade the model, and implement monitoring controls (see Post-Market section).
• Adversarial Attack: AI algorithms can be susceptible to deliberate attacks (e.g. subtle image manipulations). This cybersecurity risk must be treated similarly to software hacking. The QMS should ensure threat modeling and incorporate adversarial testing if relevant.
• Opacity/Explainability: A hazard unique to “black-box” AI is that clinicians or operators may not understand why a decision was made, potentially leading to misuse. Labeling and training may serve as risk controls – the QMS should require that user manuals explain AI limitations. The risk of user overtrust can be mitigated by requiring a human-in-the-loop on critical decisions.

The QMS must ensure that risk management is not a one-time checkbox but an ongoing process. As post-market data come in, risk assessments should be revisited. FDA/IMDRF guidance on AI encourages iterative risk evaluation throughout development, programming users to monitor flagged cases (^[37]). If a new potential hazard is discovered (e.g. a drop in sensitivity on a subgroup), the QMS CAPA process should trigger hazard reevaluation under ISO 14971 and possibly label updates or retraining plans.

Strengthening AI risk management in the QMS can draw on emerging guidance. For example, Lopez Clavijo et al. emphasize using structured risk management (AAPM Task Group 100 methodology) to integrate AI tools into clinical risk processes (^[38]). The University of York’s AMLAS methodology integrates safety assurance into ML-component development (^[25]). It can inform a QMS assurance case; avoid attributing it to the NHS or treating it as a substitute for applicable clinical safety standards. Consider such frameworks to help identify, document, and mitigate AI-specific risks.

Data Lifecycle Management

For AI/ML devices, the data used to develop and evaluate the system are as critical as hardware components. A rigorous QMS must cover the entire data lifecycle. Key aspects include:

• Data Acquisition and Quality: Document where and how training data were obtained (e.g. retrospective clinical image archive, simulation data). The QMS should specify acceptance criteria for data (minimum resolution, annotation quality). Raw data that are incorporated into the training set should be subject to quality checks (accurate labels, completeness) and version control. If synthetic or augmented data are used, document generation methods.

• Data Annotation and Labeling: QMS procedures should define who (role/credentials) annotates data and how consistency is ensured. For instance, pathologists’ labels on histology images should be verified as needed. Any changes (correcting labels) go through a formal data change control process.

• Data Partitioning and Traceability: For verification/validation, QMS must ensure that training, validation, and test datasets are properly isolated (no data leakage). Each dataset partition should be documented and static after splitting. Traceability links data sample (or batch) back to source and label. Some manufacturers use data management tools (MLflow, DVC) which can integrate with a QMS to log these details.

• Privacy and Security: Patient data used in AI/ML must respect privacy regulations (HIPAA/ GDPR). The QMS needs procedures for secure data handling and de-identification. Compliance with data governance (consent management, audit logs) should be maintained.

• Data Updates and Continual Learning: If the device design includes retraining on new data (in-field learning), the QMS must control that process. For example, before releasing an updated model trained on new patient data, the QMS should require re-validation. Alternatively, if a device only gets periodic “locked” updates, each update is handled as a new device version in the QMS.

Overall, data in the context of AI become “controlled components” of the device. Just as ISO 14644 for cleanrooms defines cleanliness at all stages, an AI developer’s QMS should track data lifecycle quality: acquisition, annotation, storage, processing, and archival. Inadequate data control can lead to “garbage in, garbage out,” which defeats the purpose of a medical QMS.

Software Development and Implementation

AI/ML devices are implemented as software. Thus, standard device software QMS practices apply, amplified by AI’s needs.

• Software Development Life Cycle: The QMS should document a structured development lifecycle (e.g. Agile, V-model), with IEC 62304 as a supporting standard where appropriate (^[6]). As noted, practices like Agile are permissible but must be reconciled with design control requirements (^[7]). Each version/release of the algorithm/software should go through verification testing (unit/integration testing) recorded in the QMS.

• Code Management and Security: For custom AI code (typically Python or similar), use version control and documented procedures for branching, merging, and release. Secure coding standards and code review checklists (for vulnerabilities or pretrained-library assessment) should be part of development procedures. Consider software bills of materials (SBOMs) to document third-party components. Determine any legally required cybersecurity submission content from the applicable device requirements; neither Git nor every suggested software practice is a universal legal mandate (^[22]).

• Model Implementation: Many AI models are deployed as compiled binaries or hardware accelerators, not just source code. The QMS must treat model files (e.g. TensorFlow graph, compiled inference engine) as software deliverables. Installation or integration procedures should include model integrity checks (hashing) and configuration management.

• Hardware/Software Integration: If the AI runs on a device (e.g. an imaging machine), the QMS must ensure compatibility and performance requirements (timing, resource usage) are verified. Interfacing with user interfaces, alarms, and logging must meet IEC 62366 human factors and IEC 60601 (risk transitions at hazards).

Adhering to established software QMS standards ensures that common software defects are controlled. However, QA for AI also includes non-traditional testing: for example, robustness testing with noisy or adversarial inputs, performance on outlier cases, and usability studies to see how clinicians interpret AI outputs. The results of such tests should feed back into the design control and risk management process. In effect, the QMS treats the trained model as “code” that must be rigorously tested in scenarios beyond normal operation.

Verification, Validation, and Testing

A centerpiece of the QMS is the Verification and Validation (V&V) of the device against requirements. For AI/ML devices, this includes both traditional software tests and clinical-performance evaluations:

• Device Verification: Before clinical validation, engineers verify algorithms against software requirements. Unit tests check code correctness, integration tests verify component interactions, and system tests ensure the AI runs correctly in the device environment. Automation (continuous integration) can be leveraged, but each test must be traceable to requirements in the DHF. Verification reports become part of the QMS records just as with any software feature.

• Model Performance Validation: Unique to AI is the need to statistically validate model performance. This is often done using retrospective test datasets (external to training). The QMS should include procedures for defining validation datasets (size, representativeness) and metrics (e.g. ROC curves, confusion matrix). These validation studies should be planned in the design phase and documented; their results are design verification evidence. For high-risk devices, the validation may require prospective clinical studies (which should be outlined in the QMS’s clinical evaluation plan).

• Usability/Human Factors Testing: If AI outputs are intended for clinicians, the QMS should mandate human factors testing (IEC 62366) to ensure users can understand and apply AI recommendations safely. For example, if an AI flags a CT image finding, a test of clinician interpretation and reliance could be required. QMS documentation should cover user training materials and labeling instructions specific to the AI behavior.

• Robustness and Stress Testing: The QMS should encourage stress testing under unusual conditions: e.g., feeding slightly altered inputs to check for brittle behavior, or simulating sensor noise to see how it affects outputs. Such tests help identify hidden failure modes. Results should be recorded in a “software validation report” or equivalent.

• Explainability and Transparency: Though not strictly mandated for all AI, many regulators and standards bodies emphasize understanding AI decisions. The QMS could include verification of explainability features (e.g. does the model output confidence scores or saliency maps). These become part of the design outputs.

Validation activities should be risk-informed: higher-risk tasks (like false negatives on cancer) call for rigorous testing and a justified clinical evidence plan. Lin et al. reported randomized-trial data for six of the 368 devices reporting study design (1.6%), within a total cohort of 691 devices (approximately 0.9% overall) (^[21]). These are public-reporting figures, not proof that all unreported studies were absent. As a QMS recommendation, define the evidence needed for the intended use and document validation and post-market evaluation plans.

All V&V results become QMS records (verification test reports, clinical evaluation reports). Any residual issues uncovered require CAPA action (see next section).

Post-Market Surveillance and Maintenance

After an AI device is on the market, its QMS must ensure continued safety and performance. This involves:

• Continuous Monitoring: The manufacturer should collect real-world data on device performance and user feedback. Assess adverse events and malfunctions against the reporting triggers applicable to the jurisdiction and reporter; do not assume every event is reportable. For AI, this means tracking cases where the AI’s output might have contributed to a problem (e.g. a misdiagnosis reported). The QMS should define how field data is gathered (logfiles, registries, user surveys) and how often it is reviewed.

• Model Performance Drift: A key QMS task is monitoring for model drift: subtle degradation if the data distribution changes. For example, a chest X-ray dataset might shift if a hospital upgrades its imaging equipment. The QMS should require periodic re-validation of the model on new data batches. If performance falls below the originally approved threshold, a CAPA is triggered (possibly leading to model retraining and update).

• Software Updates: Normal CAPA-driven updates (bug fixes, non-AI software patches) follow standard QMS change control. But AI-specific updates (model retraining) should follow the Predetermined Change Control Plan if one exists (^[10]). The QMS must ensure that any new model version passes verification/validation before replacing the old one in the field. Maintain a log of deployed model versions with date and location to track which patients saw which version.

• User Training and Feedback Loop: The QMS often encompasses activities for user training and documentation updates. For AI, manufacturers should train clinicians on interpreting AI outputs. The QMS can collect clinician feedback (e.g. through training evaluations or error reports) to spot usability issues. Rapid learning from user feedback can then feed back into design improvements or warning communications.

• CAPA for AI Hazards: If surveillance identifies a recurring issue tied to the AI (such as a certain image artifact causing false alarms), the QMS CAPA process must analyze root cause (possibly data-related) and update either the algorithm or the labeling/training. This is similar to bug-fixing but with additional data validation steps.

In essence, post-market actions for AI/ML devices mirror those of other devices but with extra vigilance on data and algorithmic performance. Lin et al. identified 489 adverse-event reports involving 36 of 691 devices (5.2%): 458 malfunctions, 30 injuries, and one death (^[21]). The percentage covers devices with any adverse-event reports, rather than exclusively serious adverse events; reports do not establish proven causation. A well-designed QMS provides a feedback loop from real-world use to quality decisions.

Change Management

Change control is a pillar of any QMS. For AI/ML devices, change management is particularly critical and complex:

• Baseline Locking: Before initial commercial release, the device configuration (software and model version) must be locked. The design history file should record the version covered by the applicable marketing authorization. Any subsequent changes are handled under change control procedures.

• Planned Changes (PCCP): Under FDA’s final August 2025 submission guidance, a PCCP comprises a Description of Modifications, a Modification Protocol, and an Impact Assessment (^[4]; Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions). The plan is authorized as part of the device’s marketing authorization. Implement only the specified modifications in accordance with the authorized Modification Protocol and applicable quality-system controls; modifications consistent with that authorization can proceed without an additional marketing submission. “SaMD Pre-Specifications” and “Algorithm Change Protocol” are historical framework terms, rather than interchangeable names for the complete current PCCP.

• Unplanned Changes: If issues require an out-of-cycle update (e.g. a critical vulnerability or discovered bias), document the change, assess risk, and perform appropriate verification, validation, and regression testing. For a device subject to 510(k) requirements, assess whether the change could significantly affect safety or effectiveness or constitutes a major change in intended use (^[39]). FDA’s software-change guidance includes documented assessment pathways for changes that do not require a new 510(k), even without a PCCP (^[40]). Changes outside an authorized PCCP need the applicable submission assessment; PMA devices have their own change/supplement requirements. Do not equate every software update with a new submission or use a PCCP to bypass authorization conditions.

• Documentation: Every change (code patches, parameter tweaks, retraining events) must be logged in the master record. The QMS should ensure that customers or users are notified (via labeling or software update notes) of any change that could affect use. Change control forms within the QMS should capture the reason, verification, validation, and approval of every AI-relevant change.

Regulators are focusing on change control because AI devices theoretically could adapt indefinitely. The QMS must therefore marry agility with safe governance, ensuring that changes only happen through controlled processes. Embedding these controls in the QMS (with evidence of review and approval) is vital for audit and for patient safety.

Understanding the practical implications of QMS decisions is aided by examining real examples and data. The following cases and studies illustrate common pitfalls and successes in AI/ML medical device quality management.

Case Study 1: Early Recalls of AI-Enabled Devices – Lee et al.’s 2025 JAMA Health Forum study matched 950 AI-enabled devices to FDA recall entries in November 2024. Sixty devices (6.3%) were associated with 182 recall events, and 79 events (43.4%) occurred within 12 months of clearance (^[2]). Validation status was classified from public FDA summaries. Devices without reported validation were associated with more and larger recalls, but the authors identify reliance on public validation reports as a limitation. The study does not establish that confidential evidence or internal QMS records were absent, that a particular QMS was deficient, or that stronger QMS processes would necessarily have prevented those recalls.

Case Study 2: Public Reporting of Evaluation Data – Lin et al.’s 2025 analysis examined public decision summaries for 691 devices. Study design was unreported for 323 devices (46.7%), sample-size reporting was missing for 368 (53.3%), and demographic information was missing for 660 (95.5%) (^[21]). The six devices reporting randomized-trial data represent 1.6% of the 368 reporting study design, approximately 0.9% of the full cohort. These are transparency findings, rather than established deficiencies in internal QMS documentation or confidential submissions. Recommended improvements include complete internal records of data sources and evaluation methods, together with clear public reporting where appropriate.

Case Study 3: Sleep-Well Baby (SWB) Project – The UMC Utrecht perspective describes an in-house ML model for real-time sleep-wake state monitoring in preterm infants between 28 and 34 weeks gestational age, rather than respiratory monitoring (^[41]). It describes development and technical/clinical validation against observed sleep-wake states, bedside operation in the neonatal ICU, and readiness for planned clinical impact studies. Bedside use and planned studies should not be represented as proof of improved patient outcomes. The paper uses ISO 15189 as inspiration for a healthcare-user QMS and stresses quality responsibilities at the deploying institution alongside manufacturer processes.

Case Study 4: Public Device Review Evidence – FDA’s public Caption Guidance De Novo review identifies Caption Health, Inc. as the applicant and describes software risk analysis and verification/validation evidence (^[42]). GE HealthCare subsequently announced an agreement to acquire Caption Health (^[43]). The public review illustrates documented testing practices. Keep conclusions about testing evidence within the scope of that review.

These examples support recommendations to document evaluation methods, improve public transparency, and maintain lifecycle monitoring. They distinguish reported associations and development experience from demonstrated QMS failures or proven clinical outcomes.

Having examined requirements and evidence, we now turn to practical integration of AI/ML considerations into each QMS element. The following analysis connects ISO 13485 (or 21 CFR 820) clauses and typical QMS processes to AI-specific actions, illustrating how companies should adapt their QMS.

Table 2 below outlines major QMS elements and supplemental AI/ML considerations for each.

QMS Element (ISO 13485 Clause)	Conventional Focus	AI/ML Adaptations and Considerations	Guidance/References
Design Controls (7.3)	Define user needs, design inputs (requirements), design outputs; verify and validate design.	Include data requirements as inputs: Define data types, volumes, sources needed. Algorithm design: Document model architecture, feature set. Outputs: Save trained model artifacts; record performance metrics. Verification: Add ML-specific tests (e.g. validation on hold-out data).	FDA 21 CFR 820.30; Henry & Thiel (2022) ([7]), AAMI TIR45 (agile)
Document and Record Control (4.2.4 / 4.2.5)	Control documents and records (papers, drawings, software) via versioning, approvals.	Track data & model docs: Control datasets, annotations, and model files with revisions. Model cards & datasheets: Create transparency documents for each algorithm version. Faster updates: Review schedules for QMS docs may be shortened to adapt to AI tech pace ([34]).	ISO 13485:2016, 4.2.4 / 4.2.5; MDSAP Audit Model; Overgaard (2023) QMS defn ([17])
Risk Management (7.1)	ISO 14971 hazard analysis, risk evaluation and control.	Include AI hazards: Document risks like bias, drift, adversarial attacks, overfitting. Controls: Design redundancy (e.g. human review), data validation checks, anomaly detection systems. Periodic review: Re-assess risks when software/data change.	ISO 14971:2019; IEC TR 80002-1 guidance ([6]), AMLAS; Chen et al. (2025) recalls ([44])
Design/Dev Planning (7.3.2)	Maintain design plans and development procedures.	AI-specific planning: Include ML lifecycle methods in project plan (data gathering, model training, tuning). Toolchain documentation: List software frameworks, data engineering tools used. GMLP: Adopt good ML practice principles in plans (e.g. data quality steps).	AAMI TIR45; IMDRF GMLP guiding principles ([20])
Design Verification (7.3.6)	Perform verification of design to ensure outputs meet inputs (requirements).	Performance verification: Beyond code testing, verify model metrics (accuracy, ROC, confusion matrices) meet clinical requirements. Edge cases: Test robustness with noise/outliers. Traceability: Link validation results to design docs.	FDA SaMD guidance; Lee et al. (JAMA HF) recall analysis ([45])
Design Validation (7.3.7); applicable clinical evaluation	Validate that device meets user needs (orientation, environment), including clinical trials if needed.	Clinical validation: Plan and execute studies on end-to-end accuracy and outcomes, not just bench metrics. Real-world testing: Pilot deployments for feedback. User training in validation: Evaluate usability of AI alerts.	IEC 62304; IMDRF SaMD clinical evaluation guidance; Lin et al. (2025) FDA review gaps ([9])
Production and Process Controls (7.5)	Ensure manufacturing processes are controlled and documented.	Data processing controls: If device retrains in field, processes for data pipeline controls. Software config control: Detailed build instructions for AI software. Cloud deployment: If using remote models, ensure secure transfer processes are part of production.	21 CFR 820.70; IEC 62304 software configuration practices
Purchasing & Supplier Control (7.4)	Qualify/integrate suppliers of materials/components.	Third-party AI components: Evaluate off-the-shelf ML libraries or pre-trained models for compliance (e.g. open-source model licensing risk). Data sources: Ensure third-party data sets (if any) meet privacy and quality specs.	FDA 21 CFR 820.50; cybersecurity guidance; Censinet blog on SBOM ([46])
Corrective & Preventive Action (8.5)	Identify and correct nonconformities; take preventive actions.	AI-specific CAPA: If a model fails in use (e.g. systematic misdiagnosis), CAPA triggers model update. Root cause: May involve data re-annotation or algorithm tweaking, documented step-by-step. Preventive: Monitor model drift trends and adjust before failures.	ISO 13485:2016; PCCP concepts (risk-based changes) ([11])
Feedback (8.2.1), Complaints (8.2.2), Regulatory Reporting (8.2.3)	Collect feedback, adverse events, and monitor product in market.	Performance monitoring: Systematically gather outcome data; update AI performance dashboards. Complaint handling: Include AI-specific symptom categories (e.g. "algorithm error"). Reporting obligations: Assess jurisdiction-specific reporting triggers and deadlines.	EU MDR Article 83 and Annex III: post-market surveillance ([23]); US 21 CFR Part 803: medical device reporting ([47]); Overgaard (2023) QMS lifecycle ([15])
Internal Audit (8.2.4) and Management Review (5.6)	Ensure QMS is functioning via audits and management reviews.	AI audit topics: Audit data management practices, model update logs, and compliance with PCCP. Training: Confirm staff have AI/ML competency. Management Review Inputs: Include KPIs for AI product performance and quality findings from real-world data.	ISO 13485:2016 8.2; QMS standards (FDA QMSR FAQs) ([12]) ([17])

Table 2: Mapping of QMS elements to AI/ML-specific actions. Design verification addresses outputs against inputs; design validation addresses the specified application or intended use. Clause mapping can be checked in FDA’s MDSAP Audit Model. FDA citations to former 820.30, 820.50, and 820.70 in this table are historical QSR references; current obligations are assessed under QMSR. Manufacturers should augment each process with these considerations to ensure robust quality for AI devices. (Sources: regulatory standards and expert sources (^[7]) (^[6]) (^[17]) (^[11]).)

In Table 2, the left column lists standard QMS process areas (clause numbers refer to ISO 13485). The table shows how each area can be expanded for AI/ML devices. For example, under “Risk Management,” manufacturers must add new hazard categories like “algorithmic bias” or “model drift,” and define control measures. Under “Design Controls,” one must include datasets and model versions as part of the design history. The rightmost column references guidance such as FDA rules or standards relevant to each point.

This mapping should guide companies in performing a gap analysis of their existing QMS. For instance, if an internal audit finds that “data versioning” is not part of document control, that is a gap to address. Many of these AI-specific actions are currently recommended practices (from sources like the FDA’s PCCP guidance or ISO 42001). Assess which practices are recommendations and which implement applicable statutory or regulatory requirements.

AI Explainability, Transparency, and Ethics

While not always a formal QMS requirement, explainability and ethics are crucial for trust. The QMS can foster transparency by enforcing documentation of the AI’s logic and decision boundaries. Labeling requirements should be treated as part of the QMS: e.g. device labeling must include information on the AI’s intended use limits and failure modes. Ethical considerations (e.g. fairness, equity) can be incorporated into risk management and quality objectives. For instance, a QMS preventive action could be conducting an equity audit (testing AI across demographics) and documenting the outcomes.

Industry groups and regulators emphasize “trustworthy AI.” A QMS approach to ethics might involve an “AI ethics review” step in design control where biases are assessed. While not strictly mandated under medical device QMS standards yet, building this into the QMS (perhaps under “management responsibility” or “design inputs”) is forward-looking.

Tools, Automation, and a Digital QMS

Manufacturers are increasingly using digital QMS platforms (often called eQMS) to manage records, workflows, and audits. Many such platforms now incorporate AI assistants (ironically) for tasks like document review or identifying nonconformities patterns. When building an AI device QMS, leveraging software tools can improve consistency. For example, version control systems for code and data can be linked to the QMS, ensuring traceability. Quality management software can alert when a dataset or software component has been updated, triggering the needed verification workflows.

However, the key is to not overly automate without oversight: AI-based tools assisting in QMS must themselves be validated (if they produce decisions affecting compliance). The QMS should include a “software tools qualification” procedure for any AI used in quality processes.

To reinforce the analysis, here we present aggregated data and findings relevant to QMS for AI/ML devices:

• Historical Device Cohort. Chen et al.’s recall study used 878 Class II AI/ML-enabled devices through March 2024 (^[1]). This historical cohort is not the number of devices on FDA’s current list, and it does not by itself substantiate a current total or exponential annual growth.

• Recall Evidence. Lee et al. identified 60 devices with recalls among 950 devices (6.3%) in their November 2024 database matching (^[2]). Chen et al. examined recall root causes in a different historical cohort (^[1]). These studies support attention to design and software issues; they do not establish which internal QMS controls were absent or demonstrate that QMS deficiencies caused each recall.

• Public Reporting Gaps. Lin et al. examined benefit-risk reporting in public FDA decision summaries (^[21]). Lee et al. classified reported validation from public summaries when analyzing recall associations (^[2]). Missing public information must be distinguished from absent studies, confidential submission evidence, or deficient internal records. Complete internal documentation and clearer public reporting are recommended improvements.

• International Guidance Trends. Our review of regulations found a consistent trend: wherever AI/ML devices are in play, quality system requirements are being updated. The FDA’s 2026 cybersecurity QMS guidance (^[16]), the EU AI Act Article 17 (^[30]), and published guidance inform how to document applicable AI quality controls. For example, the FDA’s QMSR FAQ explicitly recognizes the shift: “the revised part 820 is now titled the Quality Management System Regulation (QMSR)” (^[12]), acknowledging broader responsibilities beyond simply “Quality System.”

• Published Frameworks. ISO/IEC 42001:2023, published in December 2023, is an AI management-system standard (^[13]). IMDRF N88 FINAL:2025, published on 29 January 2025, provides GMLP guiding principles for medical-device development (^[20]; IMDRF/AIML WG/N88 FINAL:2025). MDCG 2025-6, issued in June 2025, addresses MDR/IVDR–AI Act interplay (^[23]). These documents have different roles: AI organizational governance, medical-device ML lifecycle principles, and EU regulatory interpretation. Use them where relevant without treating them as interchangeable marketing certificates.

As AI/ML technologies continue to advance, the future of QMS for medical devices will involve even tighter integration of data science with quality assurance. Important trends include:

• Regulatory Harmonization: Expect further global alignment. FDA, EU, Canada, and others are collaborating on PCCP and GMLP. International bodies (IMDRF, WHO) may produce consensus standards on AI risk management. Manufacturers should design their QMS to satisfy multiple jurisdictions’ requirements, potentially through modular documentation (e.g. one QMS chapter covers EU AI Act, another FDA, etc.).

• Continuous Learning Systems: Future systems that learn during use will need device-specific regulatory assessment and controlled update processes. Avoid inferring authorization for unrestricted learning from authorization of a device or PCCP. This will require formalizing continuous quality assurance processes: e.g. automated performance checks embedded in the device, with corrective retraining catches in the QMS loop.

• AI-Assisted QMS: Interestingly, AI itself may help manage QMS complexity. Some quality software now uses machine learning to predict nonconformity trends or to recommend audit foci. For instance, anomaly detection algorithms could flag unusual incident reports. In the long term, a mature QMS for AI devices might include AI-driven analytics of quality data to proactively identify risks (a “Quality 4.0” vision).

• Standards Evolution: Standards will adapt. Already, work is underway on extending ISO/IEC 62304 to better address machine learning, and on creating sector-specific AI standards (e.g. for anesthesia monitoring). Advocacy from manufacturers and trade groups will shape these updates. Component standards like IEC 60601 (safety of medical electrical equipment) may get annexes on AI considerations (some proposals exist).

• Training and Workforce: A QMS is only as effective as the people implementing it. The rise of AI devices drives demand for “quality engineers” with data science knowledge. Organizations may establish cross-functional teams (data scientists, clinicians, quality engineers) within the QMS structure. Training programs will need to cover both quality principles and AI technical skills.

• Ethical and Societal Impact: Beyond regulation, society’s concern with AI ethics will influence QMS. We may see formal “AI ethics audits” integrated into quality reviews, checking for bias mitigation, transparency, and accountability. Transparency obligations (e.g. the EU AI Act’s data governance requirements) may affect the information provided to authorities and users; assess the applicable disclosure obligations rather than assuming the entire QMS must be public.

In conclusion, building a QMS for AI/ML medical devices is not a one-time task but an evolving discipline. Companies must continuously update their QMS to reflect new knowledge, data, and regulatory expectations. Institutions deploying AI devices must also develop organizational QMS-like safeguards to ensure these tools benefit patients safely (^[8]). The future promises both stricter oversight and new tools to help manage complexity – but the core QMS principles of documentation, review, and improvement will remain essential in safeguarding the quality of AI-driven care.

As AI and machine learning become integral to medical technology, the Quality Management System underpinning medical device manufacturing must adapt comprehensively. This report has explored the foundations, adaptations, and evidence for constructing an AI/ML-focused QMS. The key points are:

• Integration with applicable QMS requirements: Determine whether the AI function is a device and which jurisdiction, class, and exemptions apply. In the US, QMSR is Part 820; in the EU, distinguish device QMS obligations and conformity assessment from voluntary harmonised standards and ISO certification (^[18]; Harmonised standards). Procedures should address relevant data and algorithmic elements, as illustrated in Tables 1 and 2.

• Regulatory alignment: Use current FDA requirements and guidance when planning quality controls. For the EU AI Act, distinguish general application from the separate product-related high-risk timeline and assess Article 6(1) scope (^[5]; MDCG 2025-6: FAQ on interplay between the MDR/IVDR and the Artificial Intelligence Act). Do not treat every AI device as subject to identical high-risk obligations or assume a voluntary AI standard guarantees regulatory readiness.

• Evidence-driven quality: Recall studies and public-summary analyses support attention to evaluation, documentation, and monitoring (^[2]; Benefit-Risk Reporting for FDA-Cleared Artificial Intelligence–Enabled Medical Devices). Interpret their reporting gaps and associations within the studies’ limitations. As a QMS recommendation, treat data curation, model testing, and validation as core quality activities.

• Lifecycle management: AI/ML systems require continuous lifecycle oversight. The QMS must track model versions, manage updates via predetermined change protocols, and enforce ongoing surveillance of performance―ensuring any drift or novel hazard is caught. An FDA-authorized PCCP provides a framework for specified modifications implemented within its authorized conditions; other changes require the applicable submission assessment.

• Collaboration and transparency: Both manufacturers and healthcare users share responsibility. Vendors’ QMS must be complemented by healthcare organizations’ quality measures (e.g. the ISO 15189-inspired approach for clinical AI) (^[8]). Open reporting (of data and adverse events) is critical; one study found that most reviewed public decision summaries lacked demographic information (^[9]), a public-reporting limitation that should not be equated with missing confidential submission evidence.

• Looking ahead: The QMS for AI/ML medical devices will mature alongside AI itself. We foresee machine learning being used within QMS tools (predictive analytics for quality), and QMS concepts feeding into new AI guidelines and ethical frameworks. As regulators worldwide implement AI-specific rules, a strong QMS will be a competitive advantage, not just a compliance checkbox.

In summary, building a Quality Management System for AI/ML medical devices means extending quality assurance into the data and algorithm realms. It requires cross-disciplinary expertise—combining regulatory knowledge, clinical insight, and data science. This report lays out the landscape and concrete steps, with extensive references to current regulations, studies, and expert guidance, to inform stakeholders in this critical endeavor. By following these principles, manufacturers can better ensure that AI-driven medical devices achieve their promise safely and reliably, now and in the future.

• USA FDA. Quality Management System Regulation – Frequently Asked Questions. (Update Feb 2, 2026) https://www.fda.gov/medical-devices/quality-system-qs-regulationmedical-device-current-good-manufacturing-practices-cgmp/quality-management-system-regulation-final-rule-amending-quality-system-regulation-frequently-asked (^[12]).

• Lee B, Kramer P, Sandri S, et al. Early Recalls and Clinical Validation Gaps in Artificial Intelligence–Enabled Medical Devices. JAMA Health Forum 2025;6(8):e253172 (^[45]).

• Chen W-P, et al. Regulatory Insights From 27 Years of AI/ML-Enabled Medical Device Recalls in the US. J Med Internet Res (2025);27:e67552. (July 11, 2025) (^[44]).

• Lin JC, et al. Benefit-Risk Reporting for FDA-Cleared AI-Enabled Medical Devices. JAMA Health Forum 2025;6(9):e253351 (^[9]) (^[48]).

• Overgaard SH, et al. Implementing quality management systems to close the AI translation gap and facilitate safe, ethical, and effective health AI solutions. npj Digit Med 6, 218 (2023) (^[17]) (^[15]).

• Bartels R, et al. A perspective on a quality management system for AI/ML-based clinical decision support in hospital care. Front Digit Health 2022;4:942588 (^[8]) (^[49]).

• Henry E, Thiel S. Using Existing Regulatory Frameworks to Apply Effective Design Controls to AI/ML in Medical Devices. Biomedical Instrumentation & Technology 2022;56(4):114–118 (^[7]) (^[50]).

• FDA CDRH News Release. Guiding Principles for Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices. Oct 24, 2023 (^[10]) (^[11]).

• FDA. Artificial Intelligence and Machine Learning (AI/ML)-Enabled Medical Devices. (device listings) https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-aiml-enabled-medical-devices (^[51]).

• IMDRF. Good machine learning practice for medical device development: Guiding principles. IMDRF/AIML WG/N88 FINAL:2025, 29 January 2025 (^[20]).

• ISO/IEC. ISO/IEC 42001:2023 – Information technology — Artificial intelligence — Management system. Published December 2023 (^[13]).

• FDA. Cybersecurity in Medical Devices: QMS Considerations and Content of Premarket Submissions. Final Guidance Feb 2026 (^[16]).

• FDA. Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. Final guidance, August 2025 (^[4]; Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions). The separate 2023 joint guiding principles are cited above; they are not a finalization of a 2019 draft guidance.

• 8foldGovernance. Expert Insights: How AI will impact your ISO 13485 Quality Management System. July 18, 2025 (^[33]) (^[31]) (^[34]).

• 8foldGovernance. The Latest Guidance for AI and Machine Learning in Medical Devices (V2). June 17, 2024. (See sections on AMLAS and standards) (^[52]).

• MedDeviceOnline. Narayanan S, Mhatre A. Building the AI-Enabled Medical Device QMS for European Compliance. Feb 6, 2026 (^[53]) (^[54]).

• IEC/ISO Standards: IEC 62304:2015 (Medical device software lifecycle), IEC 82304-1:2016 (Health software safety), ISO 14971:2019 (Risk management).

• AAMI. TIR45:2012 – Guidance on the use of AGILE practices in the development of medical device software.

• NHS England. Clinical risk management standards: DCB0129 (manufacture) and DCB0160 (deployment and use of health IT systems). (^[27]).

Use the linked original publications and current regulator documents to check source scope and dates; historical sources do not establish current device authorization or universal compliance.

• European Commission. MDCG 2025-6: FAQ on interplay between MDR/IVDR and the Artificial Intelligence Act. June 2025 (^[23]).