# Which AI and cybersecurity rules reach the product, and from when?

## Introduction

A medical device or in vitro diagnostic medical device (IVD) that runs software may have to meet two further bodies of law: the Artificial Intelligence Act, Regulation (EU) 2024/1689 (AI Act), and EU cybersecurity law. Some of these rules attach to the product and some to the company, and they take effect on different dates.

The answers decide what the company puts in its technical documentation, the evidence file showing that the device meets the law. They also decide what its notified body, the independent organisation that certifies the device, will assess.

Two questions come first. The first is whether the software is an artificial intelligence (AI) system in the Act's sense, which turns on how it produces its output. The second is whether that AI system is high-risk, the category to which the Act's main requirements for providers attach.

Those two answers set which duties apply and from which dates. They also decide how the AI evidence is added to the file the company already keeps under the Medical Device Regulation, Regulation (EU) 2017/745 (MDR), or the In Vitro Diagnostic Medical Device Regulation, Regulation (EU) 2017/746 (IVDR).

Four illustrative products run through the book. The triage tool, AI-enabled software from a German company that suggests how soon urgent care patients should be seen, carries the AI Act questions. The other three are a near-patient cardiac troponin test from a Swiss company and a wearable cardiac monitor from a US company. The fourth is a spinal implant certified under the former Medical Devices Directive.

The AI Act is cited in its consolidated text of 27 July 2026, which includes the amendments made that month. The sources were checked on 30 September 2026.

## In short

AI software in a medical device or IVD is high-risk under the AI Act where a notified body, the independent organisation that certifies devices, has to assess the device. The software must also be the device itself or a safety component of it, meaning a part that protects health or safety, or whose failure would endanger them. Whether a notified body takes part depends on the device's class under the MDR or IVDR, and the AI Act does not raise that class. The class the company already plans for therefore decides this condition. ([AI Act Art. 6(1)][AI Act]; [MDCG 2025-6, Q4][MDCG 2025-6])

For such a device, the high-risk requirements in Chapter III, Sections 1 to 3, of the Act apply from 2 August 2028. Systems that are high-risk because their use appears in Annex III, the Act's separate list of high-risk uses, must meet the same requirements from 2 December 2027. For a high-risk device, the AI Act information and the device information form one set of technical documentation. The notified body assesses it inside the MDR or IVDR procedure the device already follows. ([AI Act Art. 11(2), 43(3), 113][AI Act])

The cybersecurity requirements for the device itself are in Annex I of the MDR or IVDR, the general safety and performance requirements. Where the device's AI system is high-risk, Article 15 of the AI Act adds its own. The Cyber Resilience Act, the EU's general cybersecurity law for products with digital elements, does not apply to products the MDR or IVDR applies to. NIS 2, the second directive on network and information security, may apply to the company itself, through the national law of the Member State where the company is established. ([MDR Annex I s. 17.2][MDR]; [AI Act Art. 15][AI Act]; [CRA Art. 2(2)][CRA]; [NIS 2 Art. 2(1), 26(1)][NIS 2])

## 1. Which texts decide, and what is the guidance worth?

Regulation (EU) 2026/1744, the Digital Omnibus on AI, amended the AI Act. It was published on 24 July 2026 and entered into force on the third day after publication, 27 July 2026 on the authors' count. ([Regulation (EU) 2026/1744, title, Art. 4][Omnibus]; [AI Act overview page][AI overview])

The AI Act applies to providers that place AI systems on the Union market, wherever they are established. The provider develops an AI system, or has one developed, and places it on the market under its own name or trademark. The deployer uses an AI system under its authority, except in a personal non-professional activity. ([AI Act Art. 2(1)(a), 3(3), 3(4)][AI Act])

MDCG 2025-6, on how the MDR, the IVDR and the AI Act fit together, is a June 2025 joint document of the AI Board and the Medical Device Coordination Group (MDCG). It treats the device manufacturer as the provider under the AI Act, and treats the AI Act deployer as a different role from the user under the MDR. It says its views are not legally binding, and that only the Court of Justice of the European Union can give binding interpretations. ([MDCG 2025-6, title page, p. 1, Introduction][MDCG 2025-6])

The MDCG endorsed documents page, read on 29 September 2026, lists no revision of MDCG 2025-6. The amended Act has overtaken two of its statements. Its question 31 gives 2 August 2027 for Annex I high-risk systems, where the amended Act gives 2 August 2028. Its question 34 expects the post-market monitoring template to be set by an implementing act, whereas the amended Act now provides for Commission guidance. ([MDCG endorsed documents][MDCG list]; [MDCG 2025-6, Q31, Q34][MDCG 2025-6]; [AI Act Art. 72(3), 113][AI Act])

Guidelines on classifying high-risk AI systems, due under Article 6(5) by 2 February 2026, appeared as a draft on 19 May 2026. The final version will follow a consultation that closed on 23 July 2026, and will guide enforcement without being legally binding. ([AI Act Art. 6(5)][AI Act]; [Draft classification guidelines page][Draft classification page]; [High-risk guidelines page][High-risk page])

Our reading, the label for the authors' own interpretation, is that the draft guidelines show the Commission's current view. Technical documentation that relies on them needs checking against the final version.

## 2. Is the software an AI system?

An AI system is a machine-based system designed to operate with varying levels of autonomy, which may adapt after deployment. For explicit or implicit objectives, it infers from the input it receives how to generate outputs that can influence physical or virtual environments. The outputs include predictions, content, recommendations or decisions. ([AI Act Art. 3(1)][AI Act])

The Commission's guidelines of 29 July 2025, C(2025) 5053 final, split that definition into seven elements. They say they have no binding force, and that only the Court of Justice can give an authoritative interpretation. ([C(2025) 5053 final, title page, paras. 7 and 9][Definition guidelines])

| Feature of the software | How the guidelines treat it |
|---|---|
| Adapts or learns after deployment | May, but need not, do so to be an AI system |
| Follows predefined, explicit instructions, without learning, reasoning or modelling at any stage | Basic data processing |
| Solely intended for descriptive analysis, hypothesis testing and visualisation | Also outside the definition |
| Any other case | Assessed on its architecture and functionality against the seven elements; no automatic determination or exhaustive list is possible |

([C(2025) 5053 final, paras. 23, 46, 47, 61 and 62][Definition guidelines])

Our reading is that whether the software is an AI system is decided by checking a description of how the product reaches its output, supplied by whoever owns the algorithm, against the seven elements. Where the outcome depends on whether a fixed set of rules counts as inference, the product is a borderline case.

## 3. When is a device's AI system high-risk?

An AI system is high-risk under Article 6(1) where two conditions are both met. It is intended as a safety component of a product covered by the legislation in Annex I, or is itself such a product. And that product has to undergo third-party conformity assessment under that legislation before it is placed on the market. This holds whether or not the AI system is placed on the market separately. Annex I lists the MDR at point 11 and the IVDR at point 12 of its Section A. ([AI Act Art. 6(1); Annex I, Section A][AI Act])

Conformity assessment is the process demonstrating whether the MDR or IVDR requirements relating to a device have been fulfilled. A notified body is a conformity assessment body designated under the MDR or the IVDR. ([MDR Art. 2(40), 2(42)][MDR]; [IVDR Art. 2(32), 2(34)][IVDR])

MDCG 2025-6 treats an AI system in a device as high-risk where it is a safety component or is itself the device, and a notified body assesses the device. The AI Act does not raise the device's class, so the MDR or IVDR class decides whether a notified body takes part, and the Commission's draft guidelines take the same view. The guidance applies these conditions class by class in a table, summarised below, which is not exhaustive. ([MDCG 2025-6, Q2, Q4][MDCG 2025-6]; [Draft classification guidelines, part 2, para. 26][Draft classification])

| Device | Notified body involved, and the conditions met? |
|---|---|
| MDR classes IIa, IIb and III | Yes |
| Annex XVI products | Yes, except non-invasive class I Annex XVI products, which a footnote excludes |
| MDR class I sterile, with a measuring function, or a reusable surgical instrument | Yes |
| Other MDR class I devices | No |
| IVDR classes B, C and D | Yes |
| "IVDR Class A (non-sterile)" | No |
| A row printed "IVDR Class A)", with no sterility wording | Yes |
| In-house devices | No |

([MDCG 2025-6, Table 1][MDCG 2025-6])

Our reading is that the row printed "IVDR Class A)" concerns the class A devices that do go to a notified body.

### What makes a feature a safety component

A safety component fulfils a safety function for a product or AI system. That means its intended purpose is to prevent or mitigate risks to health and safety of persons or property. A component whose failure or malfunction endangers the health and safety of persons or property is one too. ([AI Act Art. 3(14)][AI Act])

| Provision | Effect |
|---|---|
| Article 6(1a) | AI systems used solely for non-safety aspects of user assistance, performance optimisation, service efficiency, automation, convenience or quality control do not count as safety components |
| Article 6(1b) | An AI system whose failure or malfunction would endanger health and safety counts as a safety component after all |
| Article 6(1c) | A product that needs third-party assessment solely for risks other than health and safety, such as radio-spectrum risks that do not affect them, does not meet the second condition |

([AI Act Art. 6(1a) to (1c)][AI Act])

Our reading is that a workflow or scheduling feature inside a device can fall under the Article 6(1a) exclusion, unless its failure would endanger health or safety, in which case Article 6(1b) makes it a safety component. The device's risk management file shows whether its failure would do so.

**Figure 10.1. Does the AI system in the product reach the high-risk tier through Annex I, and what still applies if it does not?**

![Figure 10.1](figures/figure-10-1-does-the-ai-act-reach-it.svg)



## 4. Can the product also fall in Annex III, and which duties apply whatever the class?

Annex III is the second route into the high-risk tier. Its point 5(d) covers, among others, systems intended "to be used to dispatch, or to establish priority in the dispatching of, emergency first response services, including by police, firefighters and medical aid". The clause ends "as well as of emergency healthcare patient triage systems". ([AI Act Annex III, point 5(d)][AI Act])

Our reading is that the syntax leaves open whether the point reaches a triage system as such, or only the setting of priority in dispatching.

A device that also falls in Annex III still follows the MDR or IVDR conformity assessment procedure. Article 49(1) covers providers of Annex III high-risk systems, other than those in point 2. They register themselves and the system in the Article 71 EU database before placing it on the market. ([AI Act Art. 43(3), 49(1), 71(1)][AI Act])

Article 6(3) lets an Annex III system fall outside the tier where it poses no significant risk of harm to health, safety or fundamental rights. It must also meet one of four listed conditions, such as a narrow procedural task. An Annex III system that performs profiling of natural persons is always high-risk. A provider relying on Article 6(3) documents its assessment before placing the system on the market, registers under Article 49(2), and gives the assessment to national competent authorities on request. ([AI Act Art. 6(3), (4), 49(2)][AI Act])

Our reading is that a device that is high-risk through Annex I alone does not register under Article 49(1), because that provision names Annex III systems.

MDCG 2025-6 says the Article 5 prohibitions and the Article 50 transparency duties do not depend on the device's class. What each prohibition covers depends on its own wording. ([MDCG 2025-6, Q4][MDCG 2025-6])

| Duty | What it requires | Limit |
|---|---|---|
| Article 5, for example point (1)(f) | Prohibits AI systems that infer emotions of a person in workplaces and education institutions | Excepts systems intended for medical or safety reasons |
| Article 50(1) | Systems that interact directly with people are designed so that people are told they are dealing with an AI system | Falls away where this is obvious to a reasonably well-informed, observant and circumspect person, given the context |
| Article 4(1) | Providers and deployers support the AI literacy of their staff and others who operate or use the systems on their behalf | None stated |

([AI Act Art. 4(1), 5(1)(f), 50(1)][AI Act])

## 5. From when do the obligations apply?

Article 113 staggers the dates, given here as checked on 30 September 2026.

| Provisions | Apply from |
|---|---|
| Chapters I and II | 2 February 2025, except certain prohibitions, from 2 December 2026 |
| The notified body section of Chapter III, the penalties chapter and some others | 2 August 2025, except Article 101 |
| The Act in general | 2 August 2026, subject to the earlier and later dates |
| Chapter III, Sections 1 to 3, except Article 6(5), for high-risk systems in Annex III | 2 December 2027 |
| Chapter III, Sections 1 to 3, for high-risk systems under Article 6(1) and Annex I, which includes devices | 2 August 2028 |

([AI Act Art. 113][AI Act]; [AI Act Service Desk timeline][Service Desk])

Our reading is that Article 50 applies from the general date of 2 August 2026, because none of the earlier or later dates in Article 113 names it.

Article 49 sits in Section 5 of Chapter III, which Article 113 does not date. Our reading is that the text leaves open whether registration applies from the general date of 2 August 2026 or from 2 December 2027. Article 16(i), in Section 3, makes registration a provider obligation, and Section 3 applies to Annex III systems only from the later date. ([AI Act Art. 16(i), 113][AI Act])

Article 111(2) covers systems already on the market before Chapter III applies. Apart from the Article 5 prohibitions, the Act applies to them only if their designs change significantly from that date. Providers and deployers of high-risk systems intended for use by public authorities take the necessary steps to comply by 2 August 2030. ([AI Act Art. 111(2)][AI Act])

Our reading is that, for an Annex I device, the date from which Chapter III applies is 2 August 2028, as MDCG 2025-6 reasons in question 31. On the same reading, a hospital in a public health system may be a public authority, so systems intended for its use may fall under the 2 August 2030 deadline.

Article 2(13) lets specific requirements in Articles 9 to 15 and 17 to 25 be limited for Article 6(1) systems. Two conditions apply: the sectoral law gives equivalent or higher protection, and the limit does not reduce the Act's overall level of protection. The delegated acts are due by 2 August 2027. ([AI Act Art. 2(13)][AI Act])

The Commission's proposal COM(2025) 1023 would move the MDR and the IVDR to Section B of Annex I. For Section B products, only Article 6(1), Article 60a and Articles 102 to 112 apply in full. On 29 September 2026 the procedure, 2025/0404(COD), stood at "Awaiting committee decision". ([COM(2025) 1023, Art. 4][COM 1023]; [AI Act Art. 2(2)][AI Act]; [Legislative Observatory, 2025/0404(COD)][OEIL 0404])

Our reading is that, because the MDR and IVDR are in Section A today, a plan follows the Section A rules and is reviewed if the proposal advances. The consolidated text of the AI Act and the Legislative Observatory page for the procedure give the current position.

## 6. Which requirements apply to a high-risk AI system, and how do they join the device file?

A high-risk AI system has to meet the requirements in Section 2 of Chapter III. Its intended purpose and the generally acknowledged state of the art are taken into account. ([AI Act Art. 8(1)][AI Act])

| Requirement | What it asks |
|---|---|
| Risk management, Article 9 | A continuous process across the lifecycle, with testing against metrics defined in advance |
| Data governance, Article 10 | Training, validation and testing data that meet the quality criteria, with origin and collection documented |
| Technical documentation, Article 11 | Drawn up before placing on the market, containing at least the Annex IV elements |
| Record-keeping, Article 12 | Automatic logging of events over the system's lifetime |
| Transparency and oversight, Articles 13 and 14 | Output that deployers can interpret using clear instructions, and a design that lets people oversee the system |
| Accuracy, robustness and cybersecurity, Article 15 | An appropriate level of each across the lifecycle, with accuracy metrics declared in the instructions |

([AI Act Art. 9(1), (2), (8), 10(1), (2), 11(1), 12(1), 13, 14, 15(1), (3)][AI Act])

The provider has to ensure the system meets the requirements, have an Article 17 quality management system and pass the relevant conformity assessment. ([AI Act Art. 11(1), 16][AI Act])

The quality system is proportionate to the provider's size, in particular for a small or medium-sized enterprise (SME), a start-up or a small mid-cap enterprise (SMC). The provider has in any event to keep the degree of rigour and the level of protection needed for the system to comply. Recommendation (EU) 2025/1099 defines the SMC. SMEs, start-ups and SMCs may use a simplified Annex IV form, which the Commission is to establish and notified bodies have to accept. ([AI Act Art. 3(14b), 11(1), 17(1), (2)][AI Act])

Five provisions govern how the AI evidence joins the device file:

| Provision | Choice or instruction | What it says |
|---|---|---|
| Article 8(2) | Choice | Providers remain responsible for full compliance with the sectoral law, and may integrate the AI testing, reporting, information and documentation into what they already have under that law |
| Article 9(10) | Choice | AI risk management may be part of, or combined with, risk procedures under other Union law |
| Article 17(3) | Choice | The Article 17 aspects may sit in a quality management system kept under sectoral law |
| Article 72(4) | Choice | The monitoring elements can join an existing device monitoring system and plan, if the protection is equivalent |
| Article 11(2) | Instruction | A high-risk AI system related to a Section A product has a single set of technical documentation, holding the AI Act and the sectoral information |

([AI Act Art. 8(2), 9(10), 11(2), 17(3), 72(4)][AI Act]; [MDR Art. 10(2), 10(9)][MDR]; [IVDR Art. 10(2), 10(8)][IVDR])

MDCG 2025-6 strongly encourages the Article 8(2) integration, and accepts that the AI quality and risk elements can be built into the device systems. ([MDCG 2025-6, Introduction, Q6, Q7][MDCG 2025-6])

Our reading is that, where the Act gives a choice, the AI processes may stay separate from the device processes, while the technical documentation has to be a single set. A separate AI Act file kept beside the device file does not fit Article 11(2) as written.

### Who assesses it, and under which procedure

A high-risk AI system covered by Section A legislation follows the conformity assessment procedure that legislation requires. The Section 2 requirements and the Article 17 quality management system are assessed within that procedure, together with specified points of Annex VII to the AI Act. ([AI Act Art. 43(3)][AI Act])

A body notified under the MDR or IVDR may assess the AI requirements if its notification assessed its compliance with Article 31(4), (5), (10) and (11) of the AI Act and evidences that compliance. Such a body has to apply for AI Act designation by 28 January 2028. ([AI Act Art. 43(3)][AI Act])

Recital 17 of the amending Regulation says a single application and unified assessment should be available where the sectoral law establishes one. ([Regulation (EU) 2026/1744, recital 17][Omnibus])

Where other law also requires an EU declaration of conformity, as the MDR and IVDR do, a single declaration covers all of it. The CE marking then indicates conformity with that law too. The provider keeps the technical documentation, the quality system documentation and the declaration for 10 years after placing on the market. A provider established outside the Union appoints an authorised representative in the Union by written mandate, before making the system available on the Union market. ([AI Act Art. 18(1), 22(1), 47(1), (3), 48(4), (5)][AI Act])

**Figure 10.2. What the AI Act adds to an MDR or IVDR file, and how each part joins it, for selected requirements.**

![Figure 10.2](figures/figure-10-2-what-joins-the-device-file.svg)



## 7. Which standards support the AI requirements?

A high-risk AI system that conforms with harmonised standards is presumed to meet the Section 2 requirements, to the extent the standards cover them. The standards' references have to be published in the Official Journal. ([AI Act Art. 40(1)][AI Act])

The European Committee for Standardization (CEN) and the European Committee for Electrotechnical Standardization (CENELEC) announced on 31 July 2026 the publication of EN 18286:2026. They call this quality management system standard, which serves no particular sector, "the first harmonized European standard" for AI Act purposes, supporting Article 17 in particular. The Commission's harmonised-standards page, read on 29 September 2026, listed no reference to it. The presumption needs that reference in the Official Journal. ([CEN-CENELEC, EN 18286 news item][EN 18286])

Public enquiries on draft standards for AI risk management (prEN 18228), cybersecurity (prEN 18282) and logging (prEN 18229-1) closed in July and August 2026. ([JTC 21, 9 July 2026][JTC 21 July])

Our reading is that, for each Section 2 requirement not covered by a presumption of conformity, the file needs a written argument that the notified body assesses. The Official Journal shows whether a standard's reference is published, and chapter 5 covers that check.

## 8. When does a change to the model need a new assessment?

A substantial modification is a change after placing on the market that the provider did not foresee or plan in the initial conformity assessment. It affects compliance with the Section 2 requirements or changes the intended purpose, and it requires a new conformity assessment. For a system that keeps learning after release, changes pre-determined at the initial assessment are not a substantial modification. They are described in the technical documentation under Annex IV point 2(f), with the technical solutions that keep the system compliant. ([AI Act Art. 3(23), 43(4); Annex IV, point 2(f)][AI Act])

How a device change reaches the notified body depends on how the device was certified:

| Device | How a change reaches the notified body |
|---|---|
| MDR class III, and class IIb implantables other than the Article 52(4) types, holding an EU technical documentation assessment certificate | Changes that could affect safety and performance need the body's approval under Annex IX Section 4.10 (IVDR 4.11) |
| MDR class IIa, and other class IIb devices, assessed on a representative device | On our reading no such certificate is issued, so Annex IX Section 2.4 applies: the body is told of planned substantial changes to the quality system or device range, and decides whether further audits are needed |
| Device still certified under the directives | MDCG 2020-3 rev.1 treats a security update as non-significant if the risk/benefit ratio is not negatively affected, and an algorithm change that may alter diagnosis or therapy as significant |

([MDR Annex IX s. 2.4, 4, 4.10; Art. 52(4), (6)][MDR]; [IVDR Annex IX s. 2.4, 4.11][IVDR]; [MDCG 2020-3 rev.1, Chart C][MDCG 2020-3])

For high-risk AI that continues to learn after release, MDCG 2025-6 says pre-determined changes of the Annex IV kind should not be treated as a Section 4.10 change. It says this rule should be included in the device's change management procedure under the MDR or IVDR. ([MDCG 2025-6, Q29, Q30][MDCG 2025-6])

Our reading is that one model update raises three separate questions: whether it is a significant design change under Article 111(2), whether it is a substantial modification, and whether it is a device change under the route in the table. For a device still certified under the directives, the device question is whether the change is significant in design or intended purpose. Such a change would end the transition under Article 120(3c)(b).

## 9. How are incidents reported, and who enforces?

Under the AI Act a serious incident is an incident or malfunction leading to one of four outcomes. They are death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law protecting fundamental rights, and serious harm to property or the environment. ([AI Act Art. 3(49)][AI Act])

Providers report a serious incident to the market surveillance authority where it occurred, not later than 15 days after awareness. The limit is shorter for a widespread infringement, a critical infrastructure disruption or a death. For high-risk AI systems that are devices or their safety components, the AI Act reporting duty covers only incidents that infringe Union law protecting fundamental rights, and those reports go to the authority each Member State chooses. ([AI Act Art. 73(1) to (4), 73(10)][AI Act])

For such devices, incidents involving death or serious harm to health are reported through device vigilance under the MDR or IVDR. The limit is 15 days after awareness, 10 days for a death or unanticipated serious deterioration, and 2 days for a serious public health threat. Reports go through the electronic system once its vigilance module applies, and until then the directives' arrangements continue. The vigilance system is not among the four systems the Commission confirmed as functional in November 2025. ([MDR Art. 87(1), (3) to (5), 123(3)(d)][MDR]; [IVDR Art. 82(1), (3) to (5), 113(3)(f)][IVDR]; [Decision (EU) 2025/2371, Art. 1][Decision 2025/2371])

The Commission's draft Article 73 guidance also reads Article 73(10) as limiting AI Act reporting for devices to the fundamental rights outcome. Its guidelines page lists the reporting template as published, while the consultation page offers only the draft, so whether a final template exists is unresolved. ([Article 73 consultation page][Art 73 page]; [Draft Article 73 guidance, para. 40][Art 73 draft]; [AI Act guidelines programme page][Guidelines programme])

The AI Act also requires a post-market monitoring system, proportionate to the risks, that collects and analyses performance data over the lifetime. It rests on a plan in the Annex IV documentation, and Commission guidance with a template is due by 2 September 2027. Device manufacturers already keep a surveillance system in their quality system. ([AI Act Art. 72(1) to (3)][AI Act]; [MDR Art. 83(1)][MDR]; [IVDR Art. 78(1)][IVDR])

Our reading is that the AI Act's incident reporting and post-market monitoring duties apply to a device from 2 August 2028. Articles 72 and 73 sit in Chapter IX and concern high-risk systems, and an Annex I device's AI system becomes high-risk through Article 6(1), in Chapter III, which applies to Annex I devices from that date. ([AI Act, chapter headings][AI Act])

For AI systems related to Section A products, the market surveillance authority is the one designated under those acts. A Member State may designate another. Where the sectoral law has procedures giving equivalent protection, those procedures apply in place of Articles 79 to 83. Member States set the penalty rules, taking account of the interests of smaller companies. ([AI Act Art. 74(3), (4), 99(1)][AI Act])

| Breach | Fine of up to |
|---|---|
| Article 5 prohibitions | EUR 35 000 000 or 7 per cent of worldwide annual turnover, whichever is higher |
| Article 16 provider obligations, and the Article 50 transparency duties, listed at point (g) | EUR 15 000 000 or 3 per cent, whichever is higher |
| Misleading, incorrect or incomplete replies to notified bodies or authorities | EUR 7 500 000 or 1 per cent |

([AI Act Art. 99(3) to (5)][AI Act])

For SMEs and start-ups, each fine is capped at the lower of the two figures. For SMCs the lower figure applies to the fines in the second and third rows, set by paragraphs 4 and 5. ([AI Act Art. 99(6), (6a)][AI Act])

Our reading is that the Article 16 fine can be imposed only once the Chapter III obligations apply, which for a device is in 2028, while the other fines already apply to breaches of the provisions now in force.

## 10. Which cybersecurity rules apply to the device?

The MDR and IVDR set the device's own requirements in Annex I:

| Requirement | MDR Annex I | IVDR Annex I |
|---|---|---|
| Devices incorporating software, and software that is a device, ensure repeatability, reliability and performance | s. 17.1 | s. 16.1 |
| Software is developed to the state of the art, on the principles of development life cycle, risk management including information security, verification and validation | s. 17.2 | s. 16.2 |
| Mobile software takes account of the platform and conditions of use | s. 17.3 | s. 16.3 |
| Manufacturers set minimum requirements for hardware, information technology (IT) networks and IT security, including against unauthorised access | s. 17.4 | s. 16.4 |
| The instructions for use repeat those minimum requirements | s. 23.4(ab) | s. 20.4.1(ah) |

([MDR Annex I s. 17, 23.4(ab)][MDR]; [IVDR Annex I s. 16, 20.4.1(ah)][IVDR])

The MDR adds a rule for active devices and devices connected to them. They are designed to protect, as far as possible, against unauthorised access that could hamper the device from functioning as intended. ([MDR Annex I s. 18.8][MDR])

MDCG 2019-16 rev.1, the MDCG's non-binding cybersecurity guidance of July 2020, says cybersecurity incidents are reported through device vigilance. MDCG 2025-6 places cybersecurity in the risk and quality management systems, subject to conformity assessment. ([MDCG 2019-16 rev.1, p. 1, s. 1.2, 5.2][MDCG 2019-16]; [MDCG 2025-6, Q22][MDCG 2025-6])

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets horizontal cybersecurity requirements for products with digital elements. It does not apply to those to which the MDR or IVDR applies, and MDCG 2025-6 says the same. ([CRA, title; Art. 2(2)][CRA]; [MDCG 2025-6, Q22][MDCG 2025-6])

A high-risk AI system within the CRA that meets its Article 12(1) conditions is deemed to meet the AI Act's cybersecurity requirement. Our reading is that a device cannot use that route, because the CRA does not apply to it. ([AI Act Art. 42(3)][AI Act]; [CRA Art. 12(1)][CRA])

A high-risk AI system in a device has to resist attempts by unauthorised third parties to alter its use, outputs or performance by exploiting vulnerabilities. Measures include, where appropriate, controls against data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws. ([AI Act Art. 15(5)][AI Act])

IEC 81001-5-1:2021 sets life cycle security requirements for health software, and ISO/TS 24971-2:2026, a technical specification (TS), applies ISO 14971 to machine learning devices. The IEC and ISO catalogue pages show their status. ([IEC 81001-5-1 page][IEC 81001-5-1]; [ISO/TS 24971-2 page][ISO 24971-2])

## 11. Does NIS 2 reach the company?

NIS 2, Directive (EU) 2022/2555, applies to companies. Its Annex II lists manufacturers of medical devices and IVDs. The exception is manufacturers of devices on the list of critical devices for a public health emergency, which Annex I, point 5, lists instead among the sectors of high criticality. ([NIS 2 Annexes I and II][NIS 2])

NIS 2 applies to listed entities that are medium-sized or larger under Recommendation 2003/361/EC and active in the Union. A small enterprise has fewer than 50 staff and annual turnover or balance sheet total of no more than EUR 10 million. ([NIS 2 Art. 2(1)][NIS 2]; [Recommendation 2003/361/EC, Annex, Art. 2][Rec 2003/361])

A partner enterprise holding 25 per cent or more of the company, or in which the company holds 25 per cent or more, adds its figures in proportion. A linked enterprise, such as a parent with a majority of the voting rights, adds all of its figures. Some investors, such as venture capital companies, can hold 25 per cent or more without becoming partner enterprises, provided they are not linked. ([Recommendation 2003/361/EC, Annex, Art. 3 and 6][Rec 2003/361])

Our reading is that a company is medium-sized or larger if, with its partner and linked enterprises counted in this way, it has 50 or more staff, or both its annual turnover and its balance sheet total exceed EUR 10 million. NIS 2 recital 16 lets Member States take account of how independent a company's network and information systems and services are from those of its partner and linked enterprises, and so assess it on its own figures. ([NIS 2 Art. 2(1), recital 16][NIS 2])

Article 2(2) also applies NIS 2 to listed entities of any size in named cases, such as an entity whose disruption could significantly affect public health. ([NIS 2 Art. 2(2)][NIS 2])

Entities in scope take appropriate and proportionate measures to manage risks to their network and information systems. They notify significant incidents to their computer security incident response team (CSIRT) or competent authority. An early warning is due within 24 hours and a notification within 72 hours. ([NIS 2 Art. 21(1), 23][NIS 2])

NIS 2 works through national law, which Member States had to apply from 18 October 2024. An entity in its scope falls under the jurisdiction of the Member State where it is established. Article 26(1) makes exceptions to this rule for listed telecoms, digital and public administration entities, and our reading is that none of them applies to a device manufacturer. Each Member State publishes its own transposing measures. ([NIS 2 Art. 26(1), 41(1)][NIS 2])

**Figure 10.3. Which instrument sets cybersecurity duties for the device, its AI system and the company.**

![Figure 10.3](figures/figure-10-3-which-law-answers-cybersecurity.svg)



## 12. How the answer is reached

Each answer feeds the next:

1. **How the product produces its output**, compared with the seven elements of the definition, shows whether each function is an AI system, basic data processing, or a borderline case. ([C(2025) 5053 final, paras. 9, 46, 61 and 62][Definition guidelines])
2. **The MDR or IVDR class** decides whether a notified body takes part, and the AI Act does not change it. ([MDCG 2025-6, Q4][MDCG 2025-6])
3. **Article 6(1)** then decides whether each AI system is high-risk, with Article 6(1a) to (1c) applied. ([AI Act Art. 6(1) to (1c)][AI Act])
4. **Annex III** is read against the intended purpose. A device that is high-risk under both Annex I and Annex III keeps the MDR or IVDR procedure, while Article 49 registration, the Article 6(3) exception and the profiling rule apply because of Annex III. ([AI Act Art. 6(3), (4), 43(3), 49; Annex III][AI Act])
5. **The duties that do not depend on the class** follow: Article 5, Article 50(1) for each interface, and AI literacy. ([AI Act Art. 4(1), 50(1)][AI Act]; [MDCG 2025-6, Q4][MDCG 2025-6])
6. **Each duty takes its date** from Article 113, with Article 111(2) for systems already on the market. ([AI Act Art. 111(2), 113][AI Act])
7. **The AI evidence joins the device file** in one set of technical documentation, using the choices the Act gives for integrating AI processes into the device systems. Company size can simplify the Annex IV form and the quality system, though never below the rigour that compliance needs. ([AI Act Art. 11, 17(2)][AI Act])
8. **The notified body's route** to assessing the AI requirements depends on its notification and its AI Act designation. ([AI Act Art. 43(3)][AI Act])
9. **Changes** to the model are either foreseen at the initial assessment and pre-determined under Annex IV point 2(f), or raise the three questions set out in section 8. ([AI Act Art. 3(23), 43(4); Annex IV][AI Act])
10. **Incidents** take two branches: device vigilance for serious incidents, and the AI Act authority for fundamental rights. ([MDR Art. 87][MDR]; [AI Act Art. 73(10)][AI Act])
11. **Cybersecurity** comes from MDR or IVDR Annex I and, for high-risk AI, Article 15. The CRA does not apply, and whether NIS 2 applies depends on company size or on an Article 2(2) case. ([MDR Annex I s. 17][MDR]; [CRA Art. 2(2)][CRA]; [NIS 2 Art. 2(1), (2), 26(1)][NIS 2])

## 13. The four running cases

### The triage tool: AI-enabled software from a German company

**Intended purpose (illustrative).** Triage nurses in adult urgent care centres use the software to suggest how soon each patient should be seen, for patients the nurse has already assessed as having no life-threatening condition. The nurse confirms or changes the suggestion. Class IIb is the planning assumption, with IIa and III arguable, and a notified body takes part at each. As a further assumption, the software is a model trained on past triage records. It infers a priority from the nurse's entries and is retrained quarterly.

| Question | Answer | Basis |
|---|---|---|
| AI system? | Yes, on our reading: it infers from its input how to generate a recommendation | [AI Act Art. 3(1)][AI Act] |
| High-risk under Article 6(1)? | Yes, on our reading: the software is itself the device, assessed by a notified body on health and safety risks | [MDR Art. 2(1)][MDR]; [MDCG 2025-6, Q2, Table 1][MDCG 2025-6]; [AI Act Art. 6(1), (1c)][AI Act] |
| Annex III | Open: whether point 5(d) reaches a triage system as such, and whether urgent care triage is emergency healthcare triage; if it applies, the MDR procedure stays and Article 49(1) registration is added. A model that sets a priority for each patient also raises the question whether it profiles natural persons, and a system that profiles cannot use the Article 6(3) exception | [AI Act Annex III, point 5(d); Art. 6(3), 43(3), 49(1)][AI Act] |
| Duties whatever the class | AI literacy and Article 5 apply now, and Article 5(1)(f) does not reach a tool that infers no emotions; for Article 50(1), which applies from 2 August 2026 on our reading, it is open whether a suggestion shown in the nurse's workflow is direct interaction with a person, and whether the AI's role is obvious to a nurse | [AI Act Art. 4(1), 5(1)(f), 50(1), 113][AI Act] |
| Dates | Chapter III from 2 August 2028 through Annex I, or 2 December 2027 if point 5(d) applies; the company plans for the earlier date, with Article 49(1) registration before placing on the market | [AI Act Art. 113][AI Act] |
| File | One set of technical documentation, with AI risk and quality inside the MDR systems | [AI Act Art. 9(10), 11(2), 17(3), 43(3)][AI Act] |
| Cybersecurity | MDR Annex I s. 17.1, 17.2, 17.4 and 23.4(ab), with 17.3 on mobile platforms; Article 15(5) measures where appropriate, with no CRA route; NIS 2 by size or an Article 2(2) case | [MDR Annex I][MDR]; [AI Act Art. 15(5), 42(3)][AI Act]; [CRA Art. 2(2)][CRA]; [NIS 2 Art. 2(1), (2), 26(1); Annex II][NIS 2] |

In this illustration the interface labels the suggestion as generated by the model. The Commission's guidelines page lists its Article 50 guidelines as published. If a centre deploying the tool is a public authority, the 2 August 2030 deadline in Article 111(2) becomes a review date. ([AI Act guidelines programme page][Guidelines programme])

The training, validation and testing sets are past triage records, with origin, collection and design choices documented under Article 10. Our reading is that they are data concerning health. The General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, allows such data to be processed only under an Article 9(2) exception, which is a question for a data protection specialist. ([AI Act Art. 10(1), (2)][AI Act]; [GDPR Art. 4(15), 9][GDPR])

The nurse's confirmation step is the human oversight design, and the interface has to let the nurse oversee the output effectively. Centres that are deployers assign oversight to competent staff and follow the instructions for use. ([AI Act Art. 14(1), 26(1), (2)][AI Act])

Our reading is that whether quarterly retraining by the provider is a system that "continues to learn" under Article 43(4) is open. The quarterly retraining plan is a change foreseen under Article 3(23), described in the technical documentation under Annex IV point 2(f). The manufacturer asks the notified body which provision it will assess the plan under. Each retraining may also be a device change, under Annex IX Section 2.4 at class IIb or IIa and Section 4.10 at class III. ([AI Act Art. 3(23), 43(4)][AI Act]; [MDR Annex IX s. 2.4, 4.10][MDR])

An incident includes any malfunction or deterioration in performance, or inadequacy in the manufacturer's information. If a patient was given a lower priority based on the tool's output, and this may have contributed to a serious deterioration of the patient's health, the event can be a serious incident, reported once a causal relationship is established or reasonably possible. ([MDR Art. 2(64), 2(65), 87(1), (3)][MDR])

Our reading is that lower priorities for one group of patients could raise a fundamental rights question for AI Act incident reporting, once that reporting duty applies to the device. ([AI Act Art. 3(49), 73(10)][AI Act])

### The near-patient test: a cardiac troponin test from a Swiss company

The test measures cardiac troponin near the patient in hospital emergency departments, read on a point-of-care analyser the company supplies. The company has no Union entity and sells through distributors in Germany, the Netherlands, Belgium and Austria. Both of chapter 1's intended purposes are planned as IVDR class C, with a notified body. The test contains no AI system, so Article 6(1) does not arise.

As an illustrative assumption of this book, the test is a legacy device. Its Directive 98/79/EC declaration was drawn up before 26 May 2022 with no notified body. It may therefore stay on the market until 31 December 2028 if the Article 110 conditions are met. One condition is that its design and intended purpose do not change significantly. ([IVDR Art. 110(3), (3b), (3c)][IVDR])

Suppose, as a further illustrative assumption, that a later version of the analyser uses a trained model to interpret the signal. Software that drives a device or influences its use takes that device's class. On our reading the model would take class C, where the guidance's table shows the high-risk conditions met. A model confined to a non-sterile class A instrument would fall in a row showing them not met, so whether the model is high-risk depends on which product it sits in. While the test relies on Article 110, such a model is also, on our reading, a design change to weigh against the condition that its design and intended purpose do not change significantly. A high-risk provider outside the Union appoints an AI Act authorised representative. ([IVDR Annex VIII s. 1.4][IVDR]; [MDCG 2025-6, Table 1][MDCG 2025-6]; [AI Act Art. 22(1)][AI Act])

Any software in the test or its analyser meets IVDR Annex I Sections 16.1, 16.2 and 16.4, and 16.3 if it runs on a mobile platform. The instructions for use repeat the minimum IT security requirements. NIS 2 covers entities active in the Union, under the Member State where they are established. Our reading is that whether NIS 2 applies to a manufacturer with no Union establishment is a question for a specialist. ([IVDR Annex I][IVDR]; [NIS 2 Art. 2(1), 26(1)][NIS 2])

### The monitor: a wearable cardiac monitor from a US company

Chapter 1 classes the monitor's hardware as class IIa under Rule 10, on its reading. The companion application is class IIa if it only records for later review, and class IIb if it analyses the rhythm to guide a physician's diagnosis. The planning assumption is that it records only, so it has no AI system. As an illustrative assumption of this book, the application runs on the patient's phone, so MDR Annex I Section 17.3 applies with Sections 17.1, 17.2 and 17.4. The recorder is an active device, so Section 18.8 applies too. ([MDR Annex I s. 17, 18.8][MDR])

An algorithm that analyses the rhythm would move the application to class IIb, and guidance says added functionality may change qualification or class. On our reading, a trained model doing that analysis is the application itself or, under Article 6(1b), a safety component, since its failure could endanger health. A notified body assesses a class IIb device, so on the guidance's table the model would be high-risk. The company would then need an AI Act authorised representative, and would plan for the high-risk requirements to apply from 2 August 2028. Because it has no Union establishment, the open question about NIS 2 raised for the near-patient test applies to it too. ([MDCG 2019-11 rev.1, p. 24][MDCG 2019-11]; [MDCG 2025-6, Table 1][MDCG 2025-6]; [AI Act Art. 6(1b), 22(1), 113][AI Act])

### The implant: a spinal implant from a European company with a directive certificate

Chapter 1 classes the implant by component: the cage class III, screws and plates class IIb, hooks class IIb on MDCG 2021-24 rev.1's reading, and rods, wires and pins open. As an illustrative assumption of this book, it holds a Directive 93/42/EEC certificate and seeks its first MDR certificate under the Article 120 transition. Assumed to contain no software, it has no AI system. Our reading is that MDR Annex I Section 17 does not reach it, since that section covers devices incorporating electronic programmable systems or software. ([MDR Art. 120; Annex I s. 17.1][MDR])

| Case | AI system today | High-risk under Article 6(1) | Device cybersecurity |
|---|---|---|---|
| Triage tool | Yes, on our reading | Yes | MDR s. 17; AI Act Art. 15 |
| Near-patient test | No | Yes for an added model at the test's class C, and no in a non-sterile class A instrument, on the guidance's table | IVDR s. 16, for any software |
| Monitor | No | Yes if an added model analyses the rhythm, as the device or a safety component, on the guidance's table | MDR s. 17 and 18.8 |
| Implant | No, on the assumed absence of software | Does not arise | MDR s. 17 does not reach it, on our reading |




## 14. When specialist help is worth paying for

- **The AI system definition is borderline.** No automatic determination is possible, and the guidelines are not binding. ([C(2025) 5053 final, paras. 7 and 62][Definition guidelines])
- **The purpose touches Annex III**, such as triage, emergency calls or dispatch under point 5(d). ([AI Act Annex III; Art. 49][AI Act])
- **The model is retrained.** Whether planned retraining counts as continuing to learn under Article 43(4) is open. ([AI Act Art. 3(23), 43(4)][AI Act])
- **Training data includes health data**, which needs a GDPR Article 9(2) exception. ([GDPR Art. 4(15), 9][GDPR])
- **NIS 2 may reach the company**, or the company has no Union establishment. ([NIS 2 Art. 26(1), 41(1)][NIS 2])
- **COM(2025) 1023 advances, or an Article 2(13) delegated act is adopted.** Either could change the route or the requirements. ([Legislative Observatory, 2025/0404(COD)][OEIL 0404]; [AI Act Art. 2(13)][AI Act])

## Conclusion

How the product produces its output decides whether it contains an AI system, meaning software that infers from its input how to produce outputs such as predictions, recommendations, or decisions. Where that system is the device, or a safety component that protects health or safety or whose failure would endanger them, the device's class decides whether it is high-risk.

That MDR or IVDR class decides whether a notified body, the independent organisation that certifies the device, takes part, and its involvement meets the Article 6(1) condition of third-party assessment. The AI Act does not raise the class. Annex III, the Act's separate list of high-risk uses, is a second route with its own application date. Some duties apply whatever the class, such as the Article 5 prohibitions and the Article 50 duty to tell people they are dealing with an AI system. A high-risk system's evidence joins the device's technical documentation as one set, assessed inside the MDR or IVDR procedure.

Cybersecurity is governed separately: the device meets Annex I of the MDR or IVDR and, where its AI system is high-risk, Article 15 of the AI Act. NIS 2, the EU directive on network and information security, applies, if at all, to the company.

On our reading, the triage tool, AI-enabled software from a German company, contains an AI system and is high-risk under Article 6(1). While it remains open whether point 5(d) of Annex III, which mentions emergency healthcare patient triage, covers the tool, the company plans for the Annex III date of 2 December 2027. It also plans to register the tool in the EU database before placing it on the market.

The near-patient test, a cardiac troponin test from a Swiss company, and the wearable heart monitor from a US company contain no AI system today. A model added to the monitor to analyse the heart rhythm would make the application class IIb and, on our reading, high-risk. The US company would then need an AI Act authorised representative, a person in the Union mandated in writing to act for it.

A model added to the near-patient test would be high-risk if it sat in the class C test, and not if it were confined to a non-sterile class A instrument. The test is assumed to sell under the former directive's transition until 31 December 2028, one condition of which is no significant change to design or intended purpose. On our reading, such a model is a design change to weigh against that condition.

The spinal implant is assumed to contain no software, so it has no AI system and, on our reading, MDR Annex I Section 17, on devices with software or programmable electronics, does not reach it. The Cyber Resilience Act, the EU's general cybersecurity law for digital products, applies to none of the four.

Chapters 4, 5 and 7 cover the quality system, the standards and the technical documentation. Chapters 8, 9 and 11 cover the notified body, device registration and vigilance.

## Sources

The last column gives the latest date on which a statement was checked against the version shown.

| Source | Version used | Date of that version | Link | Checked |
|---|---|---|---|---|
| Regulation (EU) 2024/1689 (AI Act), consolidated text | CELEX 02024R1689-20260727, consolidation 001.001, last amendment M1, Regulation (EU) 2026/1744 | 27 July 2026 | [Publications Office][AI Act] | 30 September 2026 |
| Regulation (EU) 2026/1744 (Digital Omnibus on AI), as published | CELEX 32026R1744, OJ L, 2026/1744, 24 July 2026. Corrigendum of 29 September 2026 corrects the German text only | 8 July 2026 | [Publications Office][Omnibus] | 30 September 2026 |
| Corrigendum to Regulation (EU) 2026/1744 | OJ L 2026/90810, German text; no English expression held by the Publications Office on 30 September 2026 | 29 September 2026 | [Publications Office][Omnibus corrigendum] | 30 September 2026 |
| Regulation (EU) 2017/745 (MDR), consolidated text | CELEX 02017R0745-20260719, consolidation 007.001 | 19 July 2026 | [Publications Office][MDR] | 30 September 2026 |
| Regulation (EU) 2017/746 (IVDR), consolidated text | CELEX 02017R0746-20250110, consolidation 005.001 | 10 January 2025 | [Publications Office][IVDR] | 30 September 2026 |
| Regulation (EU) 2024/2847 (Cyber Resilience Act), as published | CELEX 32024R2847, OJ L, 2024/2847, 20 November 2024 | 23 October 2024 | [Publications Office][CRA] | 30 September 2026 |
| Commission Decision (EU) 2025/2371 on the functionality of certain systems of the European database on medical devices (EUDAMED) | OJ L, 2025/2371, 27 November 2025 | 26 November 2025 | [Publications Office][Decision 2025/2371] | 30 September 2026 |
| Regulation (EU) 2016/679 (GDPR), as published | CELEX 32016R0679, OJ L 119, 4 May 2016, with corrigendum R(02) of 2018 | 27 April 2016 | [Publications Office][GDPR] | 30 September 2026 |
| Commission Recommendation 2003/361/EC, definition of SMEs | CELEX 32003H0361, OJ L 124, 20 May 2003; not binding | 6 May 2003 | [Publications Office][Rec 2003/361] | 30 September 2026 |
| Directive (EU) 2022/2555 (NIS 2), as published | CELEX 32022L2555, OJ L 333, 27 December 2022 | 14 December 2022 | [Publications Office][NIS 2] | 30 September 2026 |
| Proposal COM(2025) 1023 final, targeted revision of the MDR and IVDR | COM(2025) 1023 final; a proposal, not law | 16 December 2025 | [European Commission][COM 1023] | 30 September 2026 |
| Legislative Observatory, procedure 2025/0404(COD) | Page as read | 29 September 2026 | [European Parliament][OEIL 0404] | 30 September 2026 |
| European Commission, AI Act overview page | Page as read | 29 September 2026 | [European Commission][AI overview] | 30 September 2026 |
| AI Act Service Desk, implementation timeline | Page as read | 29 September 2026 | [European Commission][Service Desk] | 30 September 2026 |
| MDCG 2025-6 / AIB 2025-1, interplay between the MDR, IVDR and AI Act | Original, no revision | June 2025 | [European Commission][MDCG 2025-6] | 30 September 2026 |
| MDCG 2019-16, cybersecurity for medical devices | Rev.1 | July 2020 | [European Commission][MDCG 2019-16] | 30 September 2026 |
| MDCG 2019-11, qualification and classification of software | Rev.1 | June 2025 | [European Commission][MDCG 2019-11] | 27 September 2026 |
| MDCG 2020-3, significant changes under MDR Article 120 | Rev.1 | May 2023 | [European Commission][MDCG 2020-3] | 30 September 2026 |
| MDCG endorsed documents page | Page as read | 29 September 2026 | [European Commission][MDCG list] | 30 September 2026 |
| Commission guidelines on the definition of an AI system | C(2025) 5053 final; MDCG 2025-6 cites the approval of the draft, C(2025) 924 final | 29 July 2025 | [European Commission][Definition guidelines] | 30 September 2026 |
| Draft Commission guidelines on the classification of high-risk AI systems, part 2 (Annex I), and their page | Draft for consultation | 19 May 2026; page updated 23 July 2026 | [Draft][Draft classification]; [page][Draft classification page] | 30 September 2026 |
| Commission page, guidelines for providers and deployers of high-risk AI systems | Page as read | 29 September 2026 | [European Commission][High-risk page] | 30 September 2026 |
| Commission page, supporting the implementation of the AI Act with guidelines | Last update 31 July 2026 | 31 July 2026 | [European Commission][Guidelines programme] | 30 September 2026 |
| Draft guidance on incident reporting under Article 73 AI Act, with its consultation page | Draft; consultation 26 September to 7 November 2025 | Page updated 4 November 2025 | [Draft][Art 73 draft]; [page][Art 73 page] | 30 September 2026 |
| CEN-CENELEC, EN 18286 news item | Posted 31 July 2026 | 31 July 2026 | [CEN-CENELEC][EN 18286] | 30 September 2026 |
| CEN-CENELEC JTC 21 post | Posted 9 July 2026 | 9 July 2026 | [CEN-CENELEC JTC 21][JTC 21 July] | 30 September 2026 |
| IEC 81001-5-1:2021, status page | Edition 1.0, corrected version 2025-12 | 16 December 2021 | [IEC][IEC 81001-5-1] | 30 September 2026 |
| ISO/TS 24971-2:2026, status page | Edition 1 | 2026 | [ISO][ISO 24971-2] | 30 September 2026 |

[AI Act]: http://publications.europa.eu/resource/cellar/b1730fb2-8f1c-11f1-9262-01aa75ed71a1.0001.02/DOC_1
[Omnibus]: http://publications.europa.eu/resource/cellar/b459c07f-86fb-11f1-bf5e-01aa75ed71a1.0006.01/DOC_1
[Omnibus corrigendum]: http://publications.europa.eu/resource/cellar/1d32c7c2-bb9e-11f1-81de-01aa75ed71a1.0001.01/DOC_1
[Decision 2025/2371]: http://publications.europa.eu/resource/cellar/52629153-cb32-11f0-8da2-01aa75ed71a1.0006.01/DOC_1
[GDPR]: http://publications.europa.eu/resource/cellar/3e485e15-11bd-11e6-ba9a-01aa75ed71a1.0006.01/DOC_1
[Rec 2003/361]: http://publications.europa.eu/resource/cellar/6ca8d655-126b-4a42-ada4-e9058fa45155.0004.02/DOC_1
[MDR]: http://publications.europa.eu/resource/cellar/e56fc708-95ab-11f1-9262-01aa75ed71a1.0004.03/DOC_1
[IVDR]: http://publications.europa.eu/resource/cellar/bb7d3f94-cd06-11ef-be2a-01aa75ed71a1.0007.03/DOC_1
[CRA]: http://publications.europa.eu/resource/cellar/21b7d4eb-a6e2-11ef-85f0-01aa75ed71a1.0006.01/DOC_1
[NIS 2]: http://publications.europa.eu/resource/cellar/9b84d482-85bd-11ed-9887-01aa75ed71a1.0006.01/DOC_1
[COM 1023]: https://health.ec.europa.eu/document/download/25e7ea7c-cab3-40cf-86d9-d11f5e7744d8_en?filename=md_com_2025-1023_act_en.pdf
[OEIL 0404]: https://oeil.secure.europarl.europa.eu/oeil/en/procedure-file?reference=2025/0404(COD)
[AI overview]: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
[Service Desk]: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
[MDCG 2025-6]: https://health.ec.europa.eu/document/download/b78a17d7-e3cd-4943-851d-e02a2f22bbb4_en?filename=mdcg_2025-6_en.pdf
[MDCG 2019-16]: https://health.ec.europa.eu/document/download/b23b362f-8a56-434c-922a-5b3ca4d0a7a1_en?filename=md_cybersecurity_en.pdf
[MDCG 2019-11]: https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf
[MDCG 2020-3]: https://health.ec.europa.eu/document/download/800e8e87-d4eb-4cc5-b5ad-07a9146d7c90_en?filename=mdcg_2020-3_en_1.pdf
[MDCG list]: https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en
[Definition guidelines]: https://ec.europa.eu/newsroom/dae/redirection/document/112455
[Draft classification]: https://ec.europa.eu/newsroom/dae/redirection/document/128560
[Draft classification page]: https://digital-strategy.ec.europa.eu/en/library/draft-commission-guidelines-classification-high-risk-ai-systems
[High-risk page]: https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems
[Guidelines programme]: https://digital-strategy.ec.europa.eu/en/news/supporting-implementation-ai-act-clear-guidelines
[Art 73 draft]: https://ec.europa.eu/newsroom/dae/redirection/document/119624
[Art 73 page]: https://digital-strategy.ec.europa.eu/en/consultations/ai-act-commission-issues-draft-guidance-and-reporting-template-serious-ai-incidents-and-seeks
[EN 18286]: https://www.cencenelec.eu/news-events/news/2026/en-in-the-spotlight/2026-07-30-ai-quality-management/
[JTC 21 July]: https://jtc21.eu/significant-milestone-for-european-ai-standardization/
[IEC 81001-5-1]: https://webstore.iec.ch/en/publication/63293
[ISO 24971-2]: https://www.iso.org/standard/87600.html