The AI Act does not replace MDR — it layers onto it. Here is how the two regimes interact for AI-based medical devices, and the documentation worth building before your next technical file update.
Two regimes, one device
For most AI-as-a-medical-device (AIaMD) products, the EU AI Act does not replace the Medical Device Regulation — it sits on top of it. If your software is a Class IIa device or above under MDR, it is almost certainly a high-risk AI system under the AI Act, and both sets of obligations apply to the same technical file.
The practical consequence is that a single conformity assessment route has to satisfy two rulebooks. The notified body that reviews your MDR technical documentation is the same body that will assess AI Act conformity, so fragmented evidence is the fastest way to lose a review cycle.
Where the two overlap
Risk management, data governance, post-market surveillance, logging and human oversight all appear in both regimes, but with different emphasis. MDR asks whether clinical risk is acceptable; the AI Act asks whether the system is robust, accurate, transparent and controllable in the hands of its intended user.
In practice, most of the AI Act's Article 9 to Article 15 requirements can be mapped onto an existing ISO 14971 risk file and IEC 62304 lifecycle — provided the mapping is written down and traceable. Teams that treat the AI Act as a separate parallel programme end up maintaining two contradicting sets of evidence.
Where the AI Act asks for more
Three areas routinely exceed what an MDR file already contains. First, data and data governance: documented provenance, representativeness, bias examination and gap analysis for training, validation and testing datasets. Second, transparency: instructions for use that state accuracy metrics, known limitations and expected performance across intended sub-populations. Third, human oversight: a designed, evidenced mechanism for the clinician to understand, override and stop the system.
Automatic logging is the fourth gap. The AI Act expects event logs sufficient to trace behaviour over the lifetime of the system — a design decision, not a documentation exercise, and one that is expensive to retrofit after a freeze.
What to build today
Start with a mapping table: every AI Act high-risk requirement against the MDR or ISO clause already covering it, with the delta stated explicitly. That table becomes the spine of the combined technical file and the artefact your notified body will ask for first.
Then close the deltas in this order — dataset documentation, performance and sub-group reporting, oversight design, logging specification, then post-market monitoring extended to model drift. Each of these has engineering consequences, so the sequence matters more than the speed.
Finally, decide your change-control philosophy early. If the product will learn or be retrained, a pre-determined change control plan is what keeps routine model updates from triggering a fresh conformity assessment.
Timing and the cost of waiting
High-risk obligations phase in over a transition period, but conformity assessment capacity does not scale with demand. The teams that will move smoothly are those whose next planned technical file update already carries the AI Act mapping, rather than those planning a separate remediation project later.
For companies pursuing EU, US and other markets in parallel, the same evidence base can serve FDA expectations on predetermined change control and transparency with modest extension — provided it is structured once, deliberately, rather than assembled per submission.