A diagnostic imaging algorithm receives regulatory clearance. Six months later, the manufacturer deploys an updated model trained on additional clinical data. The interface remains identical. The outputs appear similar. But the internal parameters have shifted; the updated algorithm weighs certain features differently, recognizes patterns its predecessor missed, occasionally reaches conclusions its predecessor would not have reached.
The regulatory question appears straightforward: is this the same device? The answer depends on where the device is marketed, how the manufacturer characterized the modification pathway in its original submission, and whether the algorithm's learning occurs within pre-specified boundaries or continues autonomously in clinical deployment.
1. Why Does the Static Device Assumption Fail?
Traditional medical device regulation operates on a premise so fundamental it often goes unstated: the device submitted for regulatory review is the device that will be marketed. A pacemaker cleared in 2020 should function identically in 2026. Changes require assessment against change control procedures, and significant modifications trigger new regulatory submissions.
This framework accommodates software updates. A manufacturer identifies a bug, develops a fix, validates the correction, and deploys it according to established procedures. The update is discrete, documented, and reviewable. Version 1.1 replaces version 1.0 at a defined point in time.
Machine learning disrupts this paradigm not through the fact of change but through its character. When an algorithm adjusts internal weights based on operational data, the modification is not discrete but continuous, not externally initiated but intrinsic to the system's function. The regulatory frameworks governing medical devices, built over decades around hardware and traditional software, did not anticipate products designed to become different from themselves.
2. How Do Algorithm Types Affect Regulatory Treatment?
The regulatory treatment of AI-enabled medical devices depends critically on distinctions that manufacturers must understand before committing to product architecture. These categories are not arbitrary; they track the framework the FDA proposed in 2019 for modifications to artificial-intelligence and machine-learning-based software as a medical device, later reinforced by the Good Machine Learning Practice guiding principles.1US Food and Drug Administration, Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) (Discussion Paper, April 2019); and US Food and Drug Administration, Health Canada & Medicines and Healthcare products Regulatory Agency, Good Machine Learning Practice for Medical Device Development: Guiding Principles (October 2021).
Locked algorithms do not change after deployment. From a regulatory perspective, they present familiar territory: the device that receives market authorization is the device that reaches patients. The compliance pathway is established, which is precisely why many manufacturers default to locked designs despite the clinical limitations this imposes.
Algorithms subject to predetermined change control plans occupy middle ground between static deployment and autonomous adaptation. The manufacturer commits, at the time of initial submission, to boundaries that the algorithm's post-market evolution must respect. Whether those boundaries, defined before clinical deployment generates the data that will shape the algorithm's trajectory, prove adequate is a question the framework raises but does not resolve.
Continuously learning algorithms adapt in real time based on operational data. The distinction from PCCP-covered modifications is fundamental: continuous learning is not pre-specified. The algorithm's post-market evolution depends on data encountered in clinical use, data the manufacturer cannot fully characterize in advance.
Predetermined change control addresses anticipated modifications implemented according to authorized protocols. It does not, and under the FDA's PCCP framework and the MDR/AI Act regime as of 2025 cannot, accommodate algorithms whose post-market evolution depends on data the manufacturer has not yet encountered.
Regulators have not yet articulated a clear pathway for truly continuously learning medical device algorithms deployed in clinical care. The FDA's December 2024 PCCP guidance explicitly contemplates "automatic implementation of modifications" but within the bounds of pre-specified change types and validation protocols.2US Food and Drug Administration, Marketing Submission Recommendations for a Predetermined Change Control Plan (FDA, December 2024) sections VI.B and VII. An algorithm that learns continuously from patient data, adapting in ways not described in its original submission, falls outside this framework.
3. What Does the FDA's PCCP Framework Require?
The PCCP construct is not solely a creature of guidance. Congress placed it on a statutory footing in December 2022, when the Food and Drug Omnibus Reform Act added section 515C to the Federal Food, Drug, and Cosmetic Act, expressly authorizing the FDA to approve a predetermined change control plan as part of a marketing submission and to treat changes implemented within an authorized plan as not requiring a new submission.3Federal Food, Drug, and Cosmetic Act, section 515C (21 USC 360e-4), added by the Food and Drug Omnibus Reform Act of 2022, section 3308 (Consolidated Appropriations Act 2023, Pub L No 117-328).
The FDA finalized its implementing guidance on predetermined change control plans for AI-enabled device software functions in December 2024, converting years of conceptual development into actionable regulatory policy. A companion draft guidance issued in January 2025 situates the plan within a total product lifecycle approach to AI-enabled devices, addressing transparency, bias, data management, and ongoing monitoring across the device's operational life, though it remained in draft form and carried no binding force at the time of writing.4US Food and Drug Administration, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft Guidance, January 2025).
A PCCP requires the manufacturer to pre-specify, at the time of initial submission, both the modifications it anticipates and the methodology for validating and deploying them, described with a degree of concreteness the guidance itself does not fully define. What constitutes sufficient specificity varies by device type and review division, and the threshold remains unpublished, meaning two manufacturers describing functionally similar modifications may face different regulatory expectations depending on product classification and submission pathway.
The December 2024 guidance expanded scope from machine learning specifically to all AI-enabled devices, aligning with the FDA's Digital Health and Artificial Intelligence Glossary (September 2024). It also clarified that automatic implementation of modifications (updates deployed without manual intervention) may fall within an authorized PCCP, provided the manufacturer discusses this approach through the Q-Submission process. The practical scope of this clarification remains uncertain: Q-Submission feedback is non-binding, and the line between a pre-specified automatic update and a continuously learning system that falls outside the framework depends on characterization choices the guidance does not fully resolve.
Several refinements warrant attention. The final guidance recommends that manufacturers consider intended use populations, including ethnicity, gender, and disease severity, when developing modification protocols. Labeling updates should document when modifications are implemented and how users are informed. And the final guidance added "tuning" alongside "training and testing" in its description of AI data categories, acknowledging the role of parameter adjustment in model development. How these population-specific considerations interact with the clinical evidence requirements already imposed by the MDR, where representativeness across intended populations must also be demonstrated, is not addressed, and manufacturers targeting both markets face overlapping but non-identical obligations whose boundaries have not been clarified.
What the PCCP framework does not do is equally significant. A manufacturer cannot submit a PCCP describing "any modifications the algorithm determines will improve performance." The modifications must be specific. The validation methodology must be predetermined. The boundaries must be defined before market authorization. When a modification falls outside these boundaries (because the change type was not anticipated, or the implementation deviated from the authorized protocol), the traditional modification analysis applies, and a new submission may be required.
4. How Do MDR and AI Act Converge?
Which Medical Devices Does the AI Act Classify as High-Risk?
The EU AI Act entered into force on August 1, 2024, introducing requirements that apply alongside, not instead of, the Medical Device Regulation.5Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (AI Act) [2024] OJ L 2024/1689. For manufacturers of AI-enabled medical devices, this creates a dual compliance obligation that neither framework alone fully addresses.
The AI Act classifies AI systems used as safety components of medical devices, or constituting medical devices themselves, as high-risk when the device requires third-party conformity assessment under the MDR.6AI Act (n 5), Art. 6(1), read with Annex I. In practice, this means MDR Class IIa, IIb, and III devices incorporating AI components face the AI Act's most stringent requirements: risk management systems, data governance obligations, technical documentation, transparency requirements, and human oversight provisions.
When Do the Requirements Apply?
The timeline is fixed. General-purpose AI model obligations became applicable in August 2025. Full high-risk AI system requirements for medical devices apply from August 2, 2027, though the European Commission's November 2025 Digital Omnibus Package proposes extending this to 2028 for products already regulated under MDR or IVDR.7European Commission, Proposal for a Regulation amending Regulations (EU) 2024/1689 and (EU) 2018/1139 as regards the simplification of the implementation of harmonised rules on artificial intelligence COM(2025) 836 final (19 November 2025).
What Does MDCG 2025-6 Resolve?
In June 2025, the Medical Device Coordination Group published MDCG 2025-6, providing authoritative guidance on the intersection of the two frameworks.8Medical Device Coordination Group, MDCG 2025-6: FAQ on Interplay between the MDR/IVDR and the Artificial Intelligence Act (June 2025). The guidance introduces "Medical Device Artificial Intelligence" (MDAI) as the standard term for AI systems used for medical purposes and addresses several questions manufacturers had raised since the AI Act's adoption.
The AI Act introduces its own modification threshold. Art. 43(4) requires new conformity assessment when a high-risk AI system undergoes "substantial modification," defined in Art. 3(23) as a change not foreseen or planned in the initial conformity assessment that affects compliance with the AI Act's requirements or modifies the intended purpose for which the AI system was assessed. Art. 43(4) carves out predetermined changes to systems that continue learning post-market, but only where those changes were documented in the initial technical documentation.9AI Act (n 5), Art. 3(23) and 43(4), second sub-para, read with Annex IV, point 2(f); cf Recital 128. For AI-enabled medical devices, this creates dual modification analysis: whether the change triggers MDR re-assessment and whether it constitutes substantial modification under the AI Act. MDCG 2025-6 acknowledges this overlap but does not resolve every boundary question, particularly where a modification falls within PCCP boundaries for MDR purposes but may nonetheless constitute substantial modification affecting AI Act compliance because the AI Act's "predetermined" carve-out and the FDA's PCCP construct describe parallel concepts with non-identical documentation thresholds.
How Does Human Oversight Apply to Medical Devices?
Art. 14 AI Act requires that high-risk AI systems be designed to include appropriate human-machine interface tools enabling effective human oversight during use.10AI Act (n 5), Art. 14. For AI-enabled medical devices, this intersects with MDR requirements for intended use and user interface design. The AI Act's human oversight obligations, including enabling users to correctly interpret outputs, decide not to use the system, and override or interrupt the system, may require documentation beyond standard MDR instructions for use. Whether existing clinical decision support interfaces satisfy AI Act human oversight requirements depends on device-specific analysis.
Can Existing MDR Compliance Systems Absorb AI Act Obligations?
Art. 8(2) AI Act contemplates integration of AI-specific requirements into existing MDR quality management systems, the specific hooks being Art. 17(3) for the quality management system and Art. 11(2) for a single set of technical documentation.11AI Act (n 5), Art. 8(2), read with Art. 11(2) and Art. 17(3). But whether that integration is practicable depends on factors the guidance does not fully resolve. Notified body designation under the AI Act proceeds according to its own timeline, and whether a manufacturer's notified body will be positioned to conduct coordinated MDR–AI Act assessment by August 2027 cannot be assumed. Similarly, while the AI Act's data governance requirements for training, validation, and testing data overlap substantially with MDR clinical evidence obligations, the AI Act adds explicit obligations regarding bias detection and correction that existing MDR documentation frameworks may not address.
What MDCG 2025-6 does not resolve is the treatment of continuously adaptive algorithms, systems that modify their internal parameters or decision logic based on data encountered during clinical deployment, without manufacturer-initiated update cycles or predetermined modification boundaries. The guidance addresses MDAI developed, validated, and deployed according to predetermined specifications, channeling any post-market learning back through predetermined change control and the post-market surveillance system rather than treating it as a distinct category. It does not provide a pathway for algorithms whose post-market behavior depends on data encountered in clinical use beyond those mechanisms. The surveillance architecture such monitoring would rely on is examined in a related analysis of post-market surveillance for SaMD.
These EU-level coordination mechanisms (the MDCG guidance, the Art. 8(2) integration flexibility, the single notified body assessment pathway) are available to manufacturers established within the EU. Swiss manufacturers face the same dual compliance obligations for EU market access but without these institutional supports.
5. Where Does Switzerland Stand?
Swiss manufacturers face the EU's dual framework requirements for EU market access while operating under a domestic regime that has not been updated to address AI-specific considerations.
Since May 2021, Switzerland has functioned as a third country for MDR purposes. The Mutual Recognition Agreement's medical device chapter remains frozen at MDD-era provisions, and no near-term update appears likely. Swiss manufacturers accessing the EU market must designate an EU authorized representative and arrange for an EU importer to place their devices on the market, structural requirements that apply regardless of AI content.
Domestically, AI-enabled medical devices fall under the Medical Devices Ordinance (Medizinprodukteverordnung, MepV), which incorporates MDR-equivalent classification and conformity assessment requirements but contains no AI-specific provisions.12Verordnung über Medizinprodukte (Medical Devices Ordinance, MepV) (SR 812.213). Swissmedic has not published guidance comparable to MDCG 2025-6, and no Swiss equivalent to the AI Act is in force or anticipated.
The Federal Council's approach to AI regulation proceeds through targeted sector-specific amendments rather than comprehensive horizontal legislation. In a decision of principle on 12 February 2025, the Federal Council resolved to ratify the Council of Europe Framework Convention on Artificial Intelligence and to confine new rules to sector-specific amendments where possible, instructing the EJPD to prepare a consultation draft (Vernehmlassung) by the end of 2026.13Schweizerischer Bundesrat, Auslegeordnung zur KI-Regulierung: der Bundesrat will die KI-Konvention des Europarats ratifizieren (Medienmitteilung, 12 February 2025). Healthcare has been named among the sectors for further regulatory work, but concrete legislative text has not yet emerged. In the interim, AI-enabled medical devices in Switzerland are governed by general MepV requirements, the revised Datenschutzgesetz (DSG) where personal data processing is involved, and product liability frameworks that were not designed with adaptive algorithms in mind.
For Swiss manufacturers, this creates an asymmetric compliance burden. Access to the EU market requires satisfying both MDR and AI Act requirements, including the MDCG 2025-6 coordination framework, without the institutional support available to EU-based competitors. A Swiss manufacturer developing an AI-enabled diagnostic must build compliance systems for the EU's dual framework while receiving no domestic regulatory guidance on how AI-specific requirements should be addressed.
The swissdamed database, with its UDI module available for voluntary registration since August 2025 and mandatory registration effective July 1, 2026, addresses device traceability but not AI-specific regulatory questions. The EUDAMED mandatory registration date of May 28, 2026, confirmed by Commission Decision (EU) 2025/2371,14Commission Decision (EU) 2025/2371 of 26 November 2025 on the notice regarding the functionality and the fulfilment of the functional specifications of certain electronic systems included in the European Database on Medical Devices [2025] OJ L 2025/2371. creates converging compliance timelines that add to administrative complexity without resolving the substantive gap in AI governance.
6. What Are the Liability Implications?
When an AI-enabled medical device produces an adverse outcome, liability analysis confronts questions that traditional frameworks did not anticipate.
The EU's revised Product Liability Directive, with national transposition due by 9 December 2026, addresses software explicitly and introduces disclosure obligations that may require manufacturers to reveal algorithmic details in litigation.15Directive (EU) 2024/2853 of the European Parliament and of the Council of 23 October 2024 on liability for defective products [2024] OJ L 2024/2853, Art. 9 (disclosure of evidence) and Art. 10 (burden of proof; rebuttable presumptions of defectiveness and causation). It also recalibrates the burden of proof: where a claimant faces excessive difficulty establishing defectiveness or causation because of the technical or scientific complexity of the product, national courts may presume one or the other, subject to the defendant's rebuttal. But the Directive does not resolve the attribution problem inherent in adaptive systems: when an algorithm's behavior reflects not just its original training but its post-market evolution, what constitutes the "defect" giving rise to liability?
Consider an algorithm cleared based on performance validated against a training dataset. Deployed clinically, the algorithm encounters patient populations or imaging characteristics not represented in training. If the manufacturer implemented predetermined modifications according to an authorized PCCP, documentation exists to trace algorithmic evolution. But if performance degradation occurs within PCCP boundaries (the modifications were implemented correctly, yet outcomes worsened for certain patient subgroups), liability allocation becomes contested.
The AI Act's transparency and documentation requirements may assist liability analysis by ensuring algorithmic evolution is recorded. But documentation of compliant modification does not resolve the question of whether the modification should have been implemented, or whether the PCCP boundaries themselves were appropriately defined.
Contractual allocation between manufacturers, healthcare providers deploying AI-enabled devices, and software developers providing algorithmic components faces similar uncertainty. Standard representations and warranties drafted for traditional medical devices may not adequately address the risks of adaptive systems. Indemnification provisions drafted on the assumption that defects are identifiable at delivery encounter products designed to change.
7. Why Do Architecture Decisions Lock In Regulatory Constraints?
For organizations developing AI-enabled medical devices, the regulatory landscape as of late 2025 presents structural choices that will constrain options for years.
Algorithm Architecture Decisions
The threshold decision concerns algorithm architecture. Locked algorithms sacrifice the potential benefits of adaptive learning but operate within established regulatory frameworks. PCCP-eligible designs require substantial upfront investment in characterizing anticipated modifications and validation methodologies, investment that may be wasted if clinical experience reveals modification needs the original PCCP did not anticipate. Continuously adaptive algorithms (systems that modify their internal parameters based on data encountered during clinical deployment, without predetermined modification boundaries) remain outside available regulatory pathways for clinical deployment.
PCCP Scope Definition
The FDA's PCCP framework requires modification boundaries defined with precision that clinical experience may later reveal as either too narrow (excluding beneficial adaptations) or too broad (undermining the specificity regulators expect). For products targeting the EU market, MDCG 2025-6 permits integration of AI Act requirements into existing MDR quality systems, but the guidance does not resolve every gap, and manufacturers may discover during notified body review that their documentation assumptions were incomplete.
Liability Allocation in Commercial Agreements
Liability allocation introduces additional complexity that standard commercial agreements rarely anticipate. When algorithmic evolution occurs within authorized PCCP boundaries yet produces adverse outcomes for patient subgroups not represented in original training data, the contractual allocation of risk among manufacturers, healthcare providers, and software component suppliers becomes contested. Supply chain integration of third-party AI components, as specialized machine learning capabilities become modular, raises questions about how risk management and clinical validation obligations flow through commercial relationships that predate comprehensive AI governance frameworks.
Swiss Manufacturers' Dual Compliance Strategy
Swiss-based manufacturers face both EU and domestic challenges simultaneously, building dual compliance systems for EU market access while receiving no domestic guidance on how AI-specific requirements should be addressed. The convergence of medical device regulation and horizontal AI governance creates compliance obligations that manufacturers cannot satisfy through template approaches. Product architecture decisions made early in development (locked versus adaptive algorithms, PCCP scope, training data composition) constrain regulatory options for years and interact with liability frameworks in ways that generic risk allocation cannot address.