AI Act for medical device manufacturers: adding AI evidence to an existing technical file
A manufacturer holds a technical file for a medical device under Regulation (EU) 2017/745 and adds an AI function that makes the device a high-risk AI system under Art. 6(1) of Regulation (EU) 2024/1689. Art. 11(2) requires one single set of technical documentation that holds the Annex IV content with the sectoral content, and Art. 15 supplies the test evidence behind the new sections, from the Annex I application date Deferred. This page gives the sequence, the evidence it ends with, and what follows if the file stays as it is.
Where this starts
The Medical Devices Regulation, Regulation (EU) 2017/745, is listed in Annex I Section A point 11 of Regulation (EU) 2024/1689, and the in vitro diagnostic regulation sits at point 12. A device, or the software that is a safety component of a device, is a high-risk AI system under Art. 6(1) when both conditions hold: the AI system is a product or a safety component of a product covered by the listed legislation, and that product undergoes a third-party conformity assessment under it. A device whose class under the MDR needs no notified body fails the second condition. The Art. 6(3) filter applies to Annex III only, so a system on the Art. 6(1) route has no self-assessed exit. The risk classifier runs the Art. 6(1) route on the published logic, and the Annex I manufacturers hub carries the obligation set with its dates.
The existing file follows Annex II of the MDR: device description and specification, the information supplied by the manufacturer, design and manufacturing information, the general safety and performance requirements, the benefit-risk analysis and risk management, and product verification and validation, with the post-market surveillance documentation under Annex III of the MDR. Art. 11(2) of Regulation (EU) 2024/1689 requires the provider to draw up a single set of technical documentation that contains the Art. 11(1) information, which is the Annex IV content, together with the information the MDR requires. Art. 8(2) allows the provider to integrate the testing, reporting and documentation the Act requires into the documentation and procedures that exist under the sectoral law, and Art. 17(3) allows the provider to include the Art. 17(1) aspects in the quality system the MDR already imposes. Several Annex IV sections have a counterpart in the MDR file: the general description in section 1 with the device description, the instructions for use in section 1(h) with the information supplied by the manufacturer, the risk management description in section 5 with the benefit-risk analysis, the validation and testing procedures in section 2(g) with product verification and validation, and the post-market monitoring description in section 9 with the post-market surveillance documentation. Other sections have none: the datasheets for the training, validation and testing data in section 2(d), the human oversight assessment in section 2(e), the pre-determined changes in section 2(f), the AI-specific cybersecurity measures against the Art. 15(5) attack classes in section 2(h), the degrees of accuracy per group of persons in section 3, and the appropriateness of the performance metrics in section 4. The assessor is the sectoral notified body, which under Art. 43(3) checks the Chapter III Section 2 requirements inside the MDR procedure, so each AI section reads as product-safety evidence: metric, test set, conditions, version, date and signature.
None of the AI-specific sections carries a numeric threshold from the Act. Art. 15(1) requires an appropriate level of accuracy, robustness and cybersecurity, Art. 15(3) requires the provider to declare the level and the metrics in the instructions for use, and Art. 9(8) leaves the prior defined metrics and probabilistic thresholds to the provider. No harmonised standard is cited in the Official Journal under Regulation (EU) 2024/1689 as of the anchor date, so no presumption of conformity is available for the AI requirements and the first level of the source hierarchy is empty. The declaration structure comes from the JTC 21 draft prEN 18229-2Draft, the robustness method categories from ISO/IEC TR 24029-1:2021Published, the AI-specific threat list behind Art. 15(5) from prEN 18282Enquiry, and the metric selection rationale from NIST AI RMF 1.0Published. For a device, each target is stated in the device's own performance terms, next to the clinical performance claims the MDR file already holds, and the justification is recorded before any test runs. A retrained model raises Art. 43(4): a change that affects conformity with the Chapter III Section 2 requirements or that changes the intended purpose is a substantial modification and reopens the assessment; for a system that continues to learn after placing on the market, a change the provider pre-determined at the initial assessment and recorded in the Annex IV documentation under section 2(f) is not a substantial modification. The sequence below records the pre-determined change envelope and the re-test triggers, so that a later update is assessed against Art. 43(4) from a written record.
The sequence
The work runs in the order below: the Art. 6(1) route first, then the scope of the single set and the gap table, then the tests, then the drafted sections, the consistency checks, the change envelope and the traceability matrix.
Record the device class, the notified body route under the MDR and the safety-component status of the AI function.
Record Annex I route record: product, safety-component status, conformity assessment route
[Regulation (EU) 2024/1689, Art. 6(1)(a) and (b) and Annex I Section A point 11; PR-CLS step 12]
List the MDR Annex II and Annex III content that joins the single set of technical documentation.
Record Single documentation set scope record naming the product legislation content included
[Regulation (EU) 2024/1689, Art. 11(2) and Art. 8(2); PR-11-DOC step 3]
Mark each Annex IV sub-point present, partial, absent or not applicable, with its location in the existing file.
Record Annex IV gap table: status and location per row, with the MDR file location where the content already exists
[Regulation (EU) 2024/1689, Annex IV sections 1 to 9; PR-11-DOC steps 7 and 10]
Define each metric, its target and the justification against the intended purpose before any run.
Record Metric definition sheet and target justification record, each target stated in the device's performance terms
[Regulation (EU) 2024/1689, Art. 15(3) and Art. 9(8); PR-15-ROB steps 8 to 9]
Run the held-out, shifted, perturbation, fault-injection and Art. 15(5) attack sets on the frozen device software version.
Record Accuracy, robustness, and adversarial and cybersecurity test reports (PR-15-ROB output)
[Regulation (EU) 2024/1689, Art. 15(1), 15(4) and 15(5); PR-15-ROB steps 14 to 30]
Draft the sections without an MDR counterpart from the test reports, with a source reference on each statement.
Record Section 2(g), 3, 4 and 7 drafts with a source reference on each statement; harmonised standards cited in the Official Journal listed separately, none as of the anchor date
[Regulation (EU) 2024/1689, Annex IV sections 2(g), 3, 4 and 7; PR-11-DOC steps 14 to 18]
Compare each declared value, version and test report signature with the report for the same device software version.
Record Declared metric to test report consistency table; version reconciliation rows; test report register with date and signatory
[Regulation (EU) 2024/1689, Annex IV section 2(g), 1(a) and 1(c); PR-11-DOC steps 20, 28 and 33]
Record the pre-determined change envelope and the model, data and environment changes that invalidate each report.
Record Lifecycle performance monitoring record with re-test triggers
[Regulation (EU) 2024/1689, Art. 43(4) and Annex IV section 2(f); PR-15-ROB step 45]
Build the traceability matrix: one row per testable element, with protocol, step, evidence, result and MDR file location.
Record Obligation to test to evidence traceability matrix
[PR-11-DOC step 43]
Evidence this situation ends with
| Artifact | Answers | Produced by |
|---|---|---|
| Annex IV gap and consistency report | Art. 11(1) and 11(2): each Annex IV sub-point marked present, partial, absent or not applicable, with its location in the single set | PR-11-DOC v1.0 |
| Accuracy test report on held-out and distribution-shifted sets | Art. 15(1) and 15(3): accuracy at or above the declared level, measured with the declared metrics on the frozen device software version | PR-15-ROB v1.0 |
| Robustness test report with perturbation, fault-injection and fail-safe results | Art. 15(4): outputs within the declared performance under perturbation, and the fail-safe holding the declared behaviour under an injected fault | PR-15-ROB v1.0 |
| Adversarial and cybersecurity test report covering the Art. 15(5) attack list | Art. 15(5) and Annex IV section 2(h): resistance to each named attack class, with the threat model | PR-15-ROB v1.0 |
| Declared metric to test report consistency table | Annex IV section 2(g) and Art. 13(3)(b)(ii): each declared value matches the dated and signed report for the same version | PR-11-DOC v1.0 |
| Standards and specifications list with requirement mapping | Annex IV section 7: each standard with its stage and the requirement it addresses, with no harmonised standard cited in the Official Journal as of the anchor date | PR-11-DOC v1.0 |
| Lifecycle performance monitoring record with re-test triggers | Art. 15(1) and Art. 43(4): the model, data and environment changes that invalidate each report, and the pre-determined change envelope | PR-15-ROB v1.0 |
| Obligation to test to evidence traceability matrix | Every testable element of Art. 11 and Art. 15: protocol, step, evidence, result and the MDR file location | PR-11-DOC v1.0 |
Each artifact follows a specification with a synthetic sample on the deliverables page: the three Art. 15 reports and the consistency table follow the test report specification, the gap and consistency report follows the findings register specification, the monitoring record follows the register or checklist specification, and the matrix follows the traceability matrix specification, which the traceability matrix template reproduces client-side.
If nothing is done
A device placed on the market after the Annex I application date with a technical file that holds the MDR content and no Annex IV content gives the notified body no material to assess against Chapter III Section 2 inside the MDR procedure that Art. 43(3) prescribes. Once the device is on the market, the market surveillance authority designated under the MDR, which Art. 74(3) names as the authority for Annex I Section A systems, evaluates the system under Art. 79 and, where it finds that the Chapter III requirements are not met, requires the provider under Art. 79(2) to take corrective action, to withdraw the device or to recall it within a period the authority sets. A finding against the provider obligations in Art. 16, which include the Art. 11 documentation and the Art. 15 requirements, falls in the penalty tier of Art. 99(4), with the amount set in the individual case under the Art. 99(7) criteria. The provider's own action is the corrective action under Art. 20, taken on its own initiative once it has reason to consider that the system does not meet the requirements, and the supply of the documentation on a reasoned request under Art. 21(1); Art. 18(1) requires the provider to keep the technical documentation at the disposal of the national competent authorities for the period that paragraph sets. The sequence above produces the Annex IV content before the notified body asks for it and leaves the single set in the state Art. 11(1) requires.
Services, guides and tools for this situation
The technical documentation service runs the scope record, the gap table, the section drafts and the consistency checks under PR-11-DOC v1.0, within the limits stated on what we cannot do; the Art. 15 reports follow PR-15-ROB v1.0, and the regression testing service re-runs the affected tests after a model update against the recorded change envelope and the Art. 43(4) criteria.
- Services
- Guides
- ICP hubs
Questions
What does the EU AI Act require for medical devices?
The Medical Devices Regulation, Regulation (EU) 2017/745, is listed in Annex I Section A point 11 of Regulation (EU) 2024/1689. A device, or software that is a safety component of a device, is a high-risk AI system under Art. 6(1) when it undergoes third-party conformity assessment under the MDR. The provider then meets Art. 9 to Art. 15 and Art. 17, assessed inside the MDR conformity procedure under Art. 43(3), with one single set of technical documentation under Art. 11(2).
What regulation covers an AI medical device in the EU?
Two regulations apply together. Regulation (EU) 2017/745 covers the device: its classification, the general safety and performance requirements, the technical documentation in its Annex II and the conformity assessment with a notified body. Regulation (EU) 2024/1689 covers the AI system inside the device under Art. 6(1) and Annex I Section A point 11: Art. 9 to Art. 15 and Art. 17, assessed inside the MDR procedure under Art. 43(3), with the Annex IV content added to the MDR technical documentation as one single set under Art. 11(2).
Every inquiry receives a reply within 24 hours. Scope and availability are discussed per request.