Two regimes, two different questions
Under the MDR, the question is whether the change affects the device that was assessed. Under the AI Act, the question is whether the change was foreseen and planned when the system was assessed. Those are not the same test, and satisfying one does not discharge the other.
This matters more for AI than for conventional software, because the entire commercial logic of a machine learning product is that it improves with more data. A regulatory framework that treats every improvement as a new device is incompatible with how these products are built. Both regimes have started to accommodate that, but they have done it in different ways and on different timelines.
| EU MDR | EU AI Act | |
|---|---|---|
| What the change is called | Significant change to the approved device | Substantial modification |
| Where the trigger sits | Annex IX 4.10: changes that could affect safety and performance, or the conditions prescribed for use | Article 3(23): a change not foreseen in the initial conformity assessment that affects compliance, or that modifies the intended purpose |
| Consequence | Approval required from the notified body that issued the certificate | A fresh conformity assessment |
| Route for planned change | No general pre-approval mechanism; MDCG 2020-3 Chart C helps you assess software changes | Article 43(4): changes pre-determined at initial assessment and documented in Annex IV point 2(f) are not substantial |
The MDR trigger: Annex IX 4.10
For a device certified under the MDR, the operative provision is Annex IX section 4.10. Changes to the approved device require approval from the notified body that issued the EU technical documentation assessment certificate, where those changes could affect the safety and performance of the device or the conditions prescribed for its use.
Note how low that bar is written. It is not could harm a patient, it is could affect safety and performance. For a machine learning model, retraining on new data changes performance by definition. That is the point of retraining. So the honest starting position is that a meaningful model change is in scope for this provision unless you can show otherwise.
The practical tool most teams reach for is MDCG 2020-3, whose Chart C deals specifically with software changes and walks through whether a modification counts as a significant change in design. Two caveats are worth stating plainly. That guidance was written for the Article 120 transitional regime covering legacy certificates, so applying it to an MDR-certified device is using it as a guiding principle rather than as a directly applicable rule. And it predates the AI Act, so it does not answer the AI Act question at all.
The AI Act trigger: substantial modification
The AI Act defines substantial modification in Article 3(23). It is a change to an AI system after it has been placed on the market or put into service which was not foreseen or planned in the initial conformity assessment carried out by the provider, and as a result of which either compliance with the high-risk requirements in Chapter III Section 2 is affected, or the intended purpose that was assessed is modified.
Read that carefully, because the drafting is more generous than people expect. A change is only substantial if it was not foreseen or planned in the original assessment. Foreseeability is doing real work in that sentence. It is an invitation to plan.
That invitation is made explicit in Article 43(4), which is the provision worth knowing by heart if you build learning systems. For high-risk AI systems that continue to learn after being placed on the market, changes to the system and its performance that have been pre-determined by the provider at the moment of the initial conformity assessment, and that form part of the technical documentation under point 2(f) of Annex IV, do not constitute a substantial modification.
In other words: if you describe in advance what your model is allowed to change into, and that description is assessed with everything else, then moving within that envelope is not a substantial modification and does not trigger a fresh conformity assessment. The envelope has to be defined up front. You cannot construct it retrospectively to justify a change you have already made.
The FDA comparison, and why it is not a template
American readers will recognise this immediately as the concept behind the FDA's Predetermined Change Control Plan. The FDA finalised its PCCP guidance on 3 December 2024, covering AI-enabled device software functions, and the mechanism is well developed: you describe the modifications you intend to make, the methods you will use to develop and validate them, and the impact assessment, and the agency reviews that plan as part of your submission. In 2025 the FDA, Health Canada and the MHRA published joint guiding principles for PCCPs, which is a genuine signal of international convergence.
The EU mechanism is conceptually parallel but less mature and, importantly, narrower in what it solves. Article 43(4) addresses the AI Act. It does not, by itself, resolve your obligation under MDR Annex IX 4.10. A change can sit comfortably inside your pre-determined envelope for AI Act purposes and still require notified body approval under the MDR, because the MDR test is about effect on safety and performance rather than about whether you planned for it.
This is the single most important practical point in this article. Teams that have read about PCCPs sometimes assume a plan buys them freedom to ship. In Europe, it buys them freedom from one of two gates.
Which devices are actually caught
The AI Act reaches medical devices through the product safety route rather than the standalone high-risk list. An AI system is high-risk where it is intended to be used as a safety component of a product covered by the Union harmonisation legislation in Annex I, or is itself such a product, and that product is required to undergo third party conformity assessment under that legislation.
For medtech that translates into a reasonably clean rule of thumb. If your AI-enabled device needs a Notified Body under the MDR, which under Rule 11 means most clinical software at Class IIa and above, then it is very likely a high-risk AI system too. If you are genuinely Class I and self certified, the high-risk regime generally does not attach through this route.
The Commission and the Medical Device Coordination Group have published joint guidance on how the two frameworks interact, MDCG 2025-6, issued together with the Artificial Intelligence Board. It works through data governance, technical documentation, transparency and human oversight, accuracy and robustness and cybersecurity, clinical evaluation, conformity assessment, substantial modification and significant change, and post-market monitoring. If you are doing this work, it is the document to read alongside the two regulations.
The deadline moved, and most articles have not caught up
The AI Act's high-risk obligations were originally set to apply to AI embedded in products regulated under Annex I, medical devices among them, from 2 August 2027. That date has been renegotiated. The Digital Omnibus on AI reached provisional political agreement in May 2026 and defers the high-risk obligations for AI embedded in already-regulated products to 2 August 2028, with standalone high-risk systems under Annex III moving to 2 December 2027 and transparency obligations landing on 2 August 2026.
Two caveats, and they matter. First, this only takes legal effect once the Omnibus is formally adopted and published in the Official Journal, which was expected before 2 August 2026. Until that happens the amended dates are an agreement, not law. Second, a great deal of published material still quotes 2 August 2027 for medical devices, so if you are reading a compliance calendar written before mid 2026, check it against the current position rather than trusting it.
What the extra year does not do is make the work smaller. It changes when the gate closes, not what is behind it, and for anything with a multi-year development and certification cycle the practical planning horizon has barely moved.
What to do now
The highest leverage action is to write the change envelope before your first conformity assessment rather than after it. That means deciding, in advance, which parameters of the model are allowed to change, within what performance bounds, validated by what method, on what data, and with what criteria for rejecting a candidate update. That description is what Article 43(4) needs, and a well-written version of it also gives you a much stronger position when you discuss Annex IX 4.10 with your notified body.
It is also worth being honest internally about which changes you actually intend to make. A vague envelope drawn wide enough to cover anything is not credible and will not survive assessment. A narrow, specific envelope that matches your real release practice is far more defensible, even though it constrains you.
Finally, connect this to post-market surveillance rather than treating it as a separate workflow. The evidence that a model update performed as predicted comes from the same data collection that feeds your PMS and PMCF obligations. Teams that build one pipeline for both end up with change control that is nearly automatic. Teams that build two end up reconciling them by hand, every release.
- Assume a retrained model affects performance, and therefore engages MDR Annex IX 4.10
- Define the Article 43(4) change envelope before the initial conformity assessment, not after
- Document it in the technical documentation under Annex IV point 2(f)
- Remember that clearing the AI Act test does not clear the MDR one
- Use MDCG 2020-3 Chart C to reason about software changes, knowing its formal scope is narrower
- Read MDCG 2025-6 alongside both regulations
- Check any compliance calendar against the revised Omnibus dates before relying on it