EU AI Act requirements for medical software validation

Is your medical AI caught by the Regulation?

Article 6(1) decides it, and it asks two questions rather than one. The AI system has to be intended for use as a safety component of a product, or be a product itself, covered by the Union harmonisation legislation listed in Annex I. The product then has to be one that is "required to undergo a third-party conformity assessment" under that same legislation. Both conditions have to be met.

Annex I Section A lists Regulation (EU) 2017/745 at entry 11 and Regulation (EU) 2017/746 at entry 12. That places the EU MDR and the IVDR inside the Annex I route, so a clinical decision support component inside a Class IIa device, or a triage algorithm that is itself the device, is high risk by Article 6(1) and never touches the Annex III use-case list. A Class I device that the manufacturer self-certifies fails the second condition and is not high risk on this route.

The 2026 amendment narrowed the entry. Article 6(1a) provides that AI systems "solely used for non-safety related aspects of user assistance, performance optimisation, service efficiency, automation or convenience or quality control" do not qualify as safety components. Article 6(1b) puts the safety cases straight back in: a system "the failure or malfunctioning of which would endanger health and safety" qualifies regardless. Article 6(1c) removes products pushed into third-party assessment only by risks unrelated to health and safety, radio spectrum and electromagnetic interference being the named examples.

Article 3(14) was amended in the same round. A safety component now includes the gloss that "a component fulfils a safety function where its intended purpose is to prevent or mitigate risks to health and safety of persons or property". The argument about whether a scheduling assistant or an image pre-processing step is in scope is settled against those three paragraphs and that definition, and the reasoning belongs in the technical file in writing.

One further point of scope decides how much of the Regulation lands. Article 2(2) cuts the obligations down to Article 6(1), Article 60a and Articles 102 to 112 for products covered by Annex I Section B. MDR and IVDR sit in Section A. Machinery was moved from Section A to Section B by the 2026 amendment precisely to obtain the reduced regime. Nothing equivalent was done for medical devices, so medical AI on the Article 6(1) route carries the full Chapter III set.

When does it start to bind?

Article 113, as consolidated on 27 July 2026, sets seven application dates for different parts of the Regulation.

EU AI Act application dates, from 2 February 2025 to 2 August 2028, set against the chapters and articles each date applies to.

What applies	From
Chapters I and II, including the prohibited practices in Article 5	2 February 2025
Chapter III Section 4, Chapters V, VII and XII, and Article 78, except Article 101	2 August 2025
Articles 102 to 110	27 July 2026
Everything not otherwise excepted	2 August 2026
Article 5(1), first subparagraph, points (ba) and (bb), and Article 5(1a) and (1b)	2 December 2026
Chapter III Sections 1, 2 and 3 for Annex III systems under Article 6(2)	2 December 2027
Chapter III Sections 1, 2 and 3 for Annex I systems under Article 6(1)	2 August 2028

The last two rows are the ones that moved. Before Regulation (EU) 2026/1744 (the Digital Omnibus on AI), the original Article 113, point (c), read "Article 6(1) and the corresponding obligations in this Regulation shall apply from 2 August 2027", a single date covering the whole high-risk regime for Annex I products. The amendment replaced that limb with the split above: 2 December 2027 for the Annex III route and 2 August 2028 for the Annex I route. The recital gives the reason as "the delayed availability of standards, common specifications, and alternative guidance and the delayed establishment of national competent authorities".

Almost every summary of the AI Act published before late July 2026 still prints 2 August 2027 as the high-risk date for medical AI. That date is superseded, and the Article 6(1) route now runs to 2 August 2028. Some summaries give 2 August 2026 for the high-risk obligations instead, because before the amendment the Annex III route fell under the general application date; that use of the date is stale too, and the Annex III route now runs to 2 December 2027. The date itself is still live, as the fourth row of the table shows: 2 August 2026 remains the general application date for everything Article 113 does not except.

The commercial deadline sits earlier than 2 August 2028 in any case. Article 43(3) requires notified bodies notified under Annex I Section A legislation to apply for AI Act designation "by 28 January 2028". A device whose technical file first mentions AI in the months before 2 August 2028 joins a queue at a body that has been designated for a matter of months. If you are already planning a CE route, the sequencing question is covered on entering the EU market.

What does the Regulation ask testing to produce?

Article 9 is the article that names testing outright. Article 9(6): "High-risk AI systems shall be tested for the purpose of identifying the most appropriate and targeted risk management measures. Testing shall ensure that high-risk AI systems perform consistently for their intended purpose." Article 9(8) sets the condition that decides whether a test campaign is admissible: testing happens "at any time throughout the development process, and, in any event, prior to their being placed on the market or put into service", and "shall be carried out against prior defined metrics and probabilistic thresholds that are appropriate to the intended purpose".

Prior defined is the operative phrase. A metric chosen after the run, or a threshold set once the numbers are known, does not satisfy Article 9(8) however good the result is. The method for fixing thresholds before the run is set out in validating an AI model in clinical software.

Article 15 is where a team usually expects a number and does not find one. Article 15(3), in full, reads: "The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use." That is the whole accuracy obligation. The Regulation names no metric, sets no threshold and does not say who picks the metric. Article 15(2) leaves benchmarks and measurement methodologies to work the Commission is to "encourage". Choosing the metric, justifying it against the intended purpose and declaring it is the provider's job, and Article 13(3), point (b)(ii), is where the declared level, its metrics, robustness and cybersecurity have to appear for the deployer.

Article 15(5) names its five attack classes outright: data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks, and model flaws. A network penetration test of the hosting platform reaches none of them.

Article 10(3) is the sentence a data set is measured against. Training, validation and testing sets "shall be relevant, sufficiently representative, and to the best extent possible, free of errors and complete in view of the intended purpose", with "the appropriate statistical properties, including, where applicable, as regards the persons or groups of persons in relation to whom the high-risk AI system is intended to be used". Article 10(2), point (f), adds examination for biases likely to affect health and safety, and point (g) adds measures to detect, prevent and mitigate the biases point (f) found.

Which artefacts will the assessor ask for?

There is no separate AI Act conformity assessment for a device. Article 43(3) states that the provider "shall follow the relevant conformity assessment procedure as required in accordance with the relevant Union harmonisation legislation", and that the Chapter III Section 2 requirements "shall apply to those high-risk AI systems and shall be part of that assessment". The 2026 amendment added the Article 17 quality management system assessment to that sentence expressly. The MDR or IVDR review is the review, and the AI evidence is read inside it.

Article 43(3) places the provisions in this table inside the MDR or IVDR conformity assessment, and each one generates testing evidence an assessor reads there.

EU AI Act provisions read inside an MDR or IVDR conformity assessment, with the testing evidence each provision requires.

Provision	What the testing has to produce
Article 9(6) and 9(8)	Records of testing against metrics and probabilistic thresholds fixed before the run, completed before placing on the market
Article 10(2) and 10(3)	Data governance record for the training, validation and testing sets, with the bias examination and the measures taken
Article 11(2) with Annex IV	One single set of technical documentation holding both the Annex IV elements and the content required by MDR or IVDR
Annex IV point 2(g)	Test logs and test reports "dated and signed by the responsible persons", with the validation and testing data and the metrics used
Article 12(1) and 12(2)	Evidence that events are recorded automatically over the lifetime of the system, at the granularity Article 12(2) lists
Article 13(3), point (b)(ii)	Instructions for use stating the accuracy, robustness and cybersecurity levels the system was tested and validated against
Article 14(4)	Evidence that the five oversight capabilities, points (a) to (e), are available to the person assigned oversight
Article 15(3)	The declared accuracy levels and accuracy metrics, in the instructions for use
Article 15(5)	Resilience evidence covering the five named attack classes
Article 17(1), point (d)	The examination, test and validation procedures run before, during and after development, and their frequency

Article 11(2) deserves reading twice, because it is where a medical device company stops paying for the same work in two places: "Where a high-risk AI system related to a product covered by the Union harmonisation legislation listed in Section A of Annex I is placed on the market or put into service, a single set of technical documentation shall be drawn up containing all the information set out in paragraph 1, as well as the information required under those legal acts." The wording is "shall" and "a single set". Annex IV supplies nine headings that have to appear inside that one file, from the general description of the system at heading 1 through to the post-market performance evaluation system at heading 9. Building the Annex IV content as a standalone AI dossier alongside the MDR file is work the Regulation does not ask for.

Two provisions get read onto the medical route by mistake. Article 12(3) sets an itemised minimum log content, but only for the systems in point 1(a) of Annex III, so an Annex I medical system answers to Article 12(1) and 12(2) alone. Article 14(5), the four-eyes rule, is likewise limited to point 1(a) of Annex III. Copying either requirement into a medical device test plan adds scope no assessor asked for.

Where does this join the risk work you already run?

Article 9(10) is the provision to read: "For providers of high-risk AI systems that are subject to requirements regarding internal risk management processes under other relevant provisions of Union law, the aspects provided in paragraphs 1 to 9 may be part of, or combined with, the risk management procedures established pursuant to that law."

Article 9(10) is permissive. The AI Act aspects "may be part of, or combined with" what you already run under MDR or IVDR. The Regulation does not say an existing risk management system satisfies Article 9, and it never names ISO 14971. As a practical observation rather than a citation, two things in Article 9 have no counterpart in a device risk file built the usual way: Article 9(2), point (a), extends the analysis to fundamental rights alongside health and safety, and Article 9(8) requires testing against prior defined metrics and probabilistic thresholds. Those are the two places the existing file usually has to grow.

Article 17(3) repeats the pattern for the quality system: a provider already subject to quality management obligations under sectoral Union law "may include the aspects listed in paragraph 1 as part of the quality management systems pursuant to that law". Article 17(1) lists thirteen aspects, (a) to (m). The Regulation does not name ISO 13485 either, so any mapping from the thirteen aspects onto an existing quality manual is an engineering judgement that you write down and defend on its own merits.

Article 72(4) completes the set for post-market monitoring, with an express condition attached: the AI elements may be integrated into the systems and plans already existing under Annex I Section A legislation, "provided that it achieves an equivalent level of protection". Article 72(3) then puts the post-market monitoring plan inside the Annex IV technical documentation rather than beside it.

Serious incident reporting is narrowed for devices. Article 73(10) limits the AI Act notification to incidents under Article 3, point (49)(c), the infringement of obligations under Union law intended to protect fundamental rights, because death and serious harm to health already travel through MDR and IVDR vigilance. A provider that routes every AI malfunction through both channels is generating duplicate regulatory correspondence.

Where does EU AI Act work go wrong?

• Accuracy is reported as one headline figure in a slide deck and never declared in the instructions for use with its metric, which is the only thing Article 15(3) actually asks for.
• Metrics and thresholds are set after the evaluation runs, so the campaign cannot evidence the "prior defined" condition in Article 9(8).
• Test evidence exists as notebooks and CI output. Annex IV point 2(g) names "test logs and all test reports dated and signed by the responsible persons", and unsigned artefacts have to be reconstructed under audit pressure.
• The AI documentation is written as a second dossier beside the MDR file, against the single set that Article 11(2) requires.
• The risk file covers health and safety and stops there, while Article 9(2), point (a), extends the analysis to fundamental rights.
• Data governance evidence describes the training set only. Where the system trains no model, Article 10(6) still binds the testing data sets to Article 10(2), (3) and (4).
• Cybersecurity evidence covers infrastructure, and Article 15(5) names data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws as the AI-specific classes to address.
• A continuously learning system ships without the pre-determined changes described at Annex IV point 2(f), so every model update risks being read as a substantial modification under Article 43(4) and triggering a fresh conformity assessment.
• Logging is designed after the architecture is fixed, although Article 12(1) requires the system to technically allow automatic recording of events over its lifetime.

The penalty tier that these reach is Article 99(4), point (a): failure of the provider obligations in Article 16 carries administrative fines "of up to EUR 15 000 000 or, if the offender is an undertaking, up to 3 % of its total worldwide annual turnover for the preceding financial year, whichever is higher". Article 16, point (a), is what pulls Articles 9 to 15 into that tier, and Article 99(6) caps the fine for an SME at the lower of the two figures rather than the higher. An AI Act finding of this kind is closed by evidence produced before the MDR or IVDR conformity assessment opens, which is when producing it costs least.

What do we run against the EU AI Act?

The work starts at Article 6(1), because the classification decides the size of everything after it. We record why the system is or is not a safety component against Article 6(1a) to (1c) and the Article 3(14) definition, then build the test programme for the requirements that classification binds: metrics and thresholds fixed and reviewed before the evaluation, data set characterisation against Article 10(3), adversarial and robustness runs against the five classes in Article 15(5), and oversight checks against the five capabilities in Article 14(4).

What that produces is the artefact list above, written into the technical documentation structure Article 11(2) requires rather than into a second file. Medical device software testing covers the execution, and validation documentation covers how the evidence is filed.

Every article number, annex point and date above was read on 2 September 2026 from the consolidated text of the Regulation as at 27 July 2026, 02024R1689 at the EU Publications Office, and from Regulation (EU) 2026/1744, which amended it.