← Tous les articles

Cet article n’est pas encore disponible dans votre langue ; nous affichons donc l’original en anglais.

What the EU AI Act adds to your device's instructions for use

Article 13 of the EU AI Act sets its own list of IFU contents for high-risk AI. For an MDR or IVDR device it lands on top of Annex I, from 2 August 2028.

AI Act · MDR · eIFU Regulation

The EU AI Act has been amended once already. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026. It moved the application date for AI systems embedded in regulated products to 2 August 2028. The consolidated text is now stable enough to plan against. This post takes one requirement from it, the instructions for use, and sets it beside the requirement you already meet under Annex I of the MDR or IVDR.

The wider question is how the AI Act’s quality system, risk management and post-market duties fold into an ISO 13485 system. MDCG 2025-6, the joint guidance of the AI Board and the MDCG, covers that. The guidance was written in June 2025 and still carries the pre-Omnibus dates, so read its timing answers against the new text. The instructions for use are a narrower topic. Both regulations require an IFU, and for an AI-enabled device it will be one document that has to satisfy both.

Which devices this concerns

An AI system is high-risk under Article 6(1) of the AI Act when two conditions are met. It must be a safety component of a product, or a product in itself, covered by the legislation listed in Annex I. That product must also undergo a third-party conformity assessment. The MDR and the IVDR are points 11 and 12 of Annex I. The second condition is therefore notified body involvement. MDCG 2025-6 sets it out in a table it labels non-exhaustive, reproduced here with the device classes it names.

MDR or IVDR classificationNotified body involvedSecond condition met
MDR Class I, non-sterile, non-measuring, non-reusable surgicalNoNo
MDR Class I sterile, measuring or reusable surgicalYesYes
MDR Class IIa, IIb and IIIYesYes
MDR Annex XVI products, except non-invasive Class IYesYes
IVDR Class A, non-sterileNoNo
IVDR Class A sterileYesYes
IVDR Class B, C and DYesYes
In-house devices under Article 5(5) MDR or IVDRNoNo

The first condition still has to be met as well: the AI must be a safety component of the device, or be the device itself.

The Omnibus narrowed that first condition. AI used solely for non-safety aspects of user assistance, performance optimisation, service efficiency, automation, convenience or quality control does not count as a safety component (Article 6(1a) of the AI Act). The carve-out falls away where a failure of that AI would endanger health and safety (Article 6(1b) of the AI Act). High-risk status under the AI Act does not change the device’s MDR or IVDR class. The dependency runs in one direction only: the device classification decides whether the AI system is high-risk, and nothing in the AI Act moves a device to a higher class.

Two definitions of the same document

Both regulations define instructions for use, and both aim them at the person who operates the device. The AI Act’s definition is “the information provided by the provider to inform the deployer of, in particular, an AI system’s intended purpose and proper use” (Article 3(15) of the AI Act). Where the AI system is itself the device, the manufacturer is the provider under the ordinary definition. Where it is a safety component sold under the device manufacturer’s name or trade mark, that manufacturer is treated as the provider (Article 25(3) of the AI Act). The deployer is the hospital, laboratory or practice that uses the device under its own authority. In device terms, the deployer is your professional user.

That matters because the AI Act gives the deployer duties of its own, and those duties refer to the instructions. Deployers must use the system in accordance with the instructions for use (Article 26(1) of the AI Act). They must also monitor its operation on the basis of those instructions (Article 26(5) of the AI Act). Where use in accordance with the instructions may present a risk, they must inform the provider and the market surveillance authority. Whether a hospital has complied with Article 26 will therefore be judged against what your IFU says.

This is new. The MDR is addressed to manufacturers, authorised representatives, importers and distributors, and it asks almost nothing of the hospital that uses the device. Health institutions must store the UDI of class III implantable devices (Article 27(9)) and may make in-house devices under conditions (Article 5(5)). On the instructions for use the MDR says nothing to the user. It contains no duty to use a device in accordance with its IFU and no duty to monitor it. Even incident reporting by healthcare professionals is something Member States are asked to encourage, not something the regulation requires of them (Article 87(10)). Under the MDR the IFU defines the conditions under which you stand behind the device; use outside them shifts responsibility, but the user’s compliance is not measured by EU law. From 2 August 2028 the AI Act measures it, for the AI part of the device, against the document you wrote. MDCG 2025-6 describes what that asks of the content: the instructions should put the deployer in a position to choose the system correctly, to know the intended and precluded uses, and to use it as appropriate.

The AI Act binds the user to the instructions for use, which the MDR never did.

What Article 13 adds to Annex I

Article 13(3) of the AI Act lists the minimum content of the instructions for use of a high-risk AI system. Set against Section 23.4 of Annex I to the MDR, two of its items are already there in full, four are there in a weaker form, and six are new. The IVDR list in Annex I, Section 20.4, is built the same way, so the comparison holds for IVDs.

Article 13(3) of the AI Act requiresAnnex I, Section 23.4 of the MDR already requiresWhat the AI Act adds
Provider identity and contact details, and the authorised representative where there is one (point (a))The same particulars, carried over from the label (23.4(a))Nothing; the item is already covered
Intended purpose (point (b)(i))Intended purpose with indications, contra-indications, patient target groups and intended users (23.4(b))Nothing; the item is already covered
The level of accuracy, including its metrics, robustness and cybersecurity, against which the system was tested and validated, and the circumstances that may affect that level (point (b)(ii))Performance characteristics, and the degree of accuracy claimed for a measuring function (23.4(e), 23.4(h))The accuracy, robustness and cybersecurity figures the system was validated against, and the circumstances under which those figures no longer hold
Known or foreseeable circumstances, including reasonably foreseeable misuse, that may lead to risks to health, safety or fundamental rights (point (b)(iii))Residual risks, contra-indications and side-effects; warnings, precautions and limitations of use (23.4(g), 23.4(s))Risks to fundamental rights, alongside health and safety; foreseeable misuse named as a category of its own
Where applicable, the technical capabilities that help explain the output (point (b)(iv))No equivalentThe whole item: a description of any feature that shows the user why the system produced a given output
When appropriate, performance on specific persons or groups (point (b)(v))The patient target groups the device is intended for, as part of the intended purpose (23.4(b))A performance figure for each group, rather than only the name of the group
When appropriate, specifications for the input data, or information on the training, validation and testing data sets (point (b)(vi))IT and network requirements to run software; devices used in combination (23.4(ab), 23.4(q))What input data the system needs, and what it was trained, validated and tested on
Where applicable, information to enable the deployer to interpret the output and use it appropriately (point (b)(vii))No stated equivalentThe whole item: guidance on reading the output and acting on it, which a software IFU may already partly contain
The changes to the system and its performance pre-determined at the initial conformity assessment (point (c))No equivalentThe whole item: the list of changes you pre-specified in the change plan, so the user knows what may change without a new assessment
The human oversight measures under Article 14, including technical measures that help interpret outputs (point (d))Special training or particular qualifications the user needs (23.4(j))The measures that let a person supervise and override the system, beyond stating what training the user needs
Computational and hardware resources, expected lifetime, and maintenance including software updates and their frequency (point (e))Hardware and IT requirements; preventive and regular maintenance (23.4(ab), 23.4(k))How long the AI system is expected to remain fit for use, and how often it will be updated
Where relevant, how the deployer collects, stores and interprets the logs generated under Article 12 (point (f))No equivalentThe whole item: how the user retrieves and reads the event logs, which requires the logging capability to be designed into the product first

Three rows deserve a note. On performance for specific groups, Annex I asks you to name the patient groups the device is intended for. The AI Act asks, when appropriate, how well the system performs for each of them, for example sensitivity and specificity stated separately for patients over 75 or for a skin type the training data covered thinly. This follows from the data governance duty in Article 10 of the AI Act, which requires the training, validation and testing data to be representative of the intended population. MDCG 2025-6 lists age, gender, sex, race, ethnicity, geographical location, medical condition, intended use environment and measurement inputs as characteristics the training, validation and testing data should represent. The pre-determined changes row connects to the change plan in Annex IV, point 2(f), of the AI Act. Changes you describe in that plan at the initial conformity assessment must also be listed in the IFU. MDCG 2025-6 says a change executed under that plan is not a substantial modification. In its view such a change should not be treated as a change to the certified device under Annex IX, Section 4.10, of the MDR or Section 4.11 of the IVDR. The human oversight row is where MDCG 2025-6 reads the Annex I training requirement alongside the AI Act’s training and AI literacy expectations.

MDCG 2025-6 treats these transparency requirements as essential requirements. They are handled inside the manufacturer’s risk and quality management systems and verified through the conformity assessment. Under Article 43(3) of the AI Act that verification is done by your MDR or IVDR notified body as part of the device procedure. The condition is that the body has been assessed against the AI Act’s own notified body requirements. Bodies notified under the MDR or IVDR must apply for that designation by 28 January 2028. The guidance also notes, on the MDR and IVDR side, that how the AI contributes to the device’s performance must be reflected in the instructions for use or the user interface. Article 13 itself requires the listed content in the instructions that accompany the system. Interface elements can support those instructions without replacing them. Record which screen elements support which instruction, because the notified body will want to see that link.

One IFU, not two

Nothing in either regulation asks for a separate AI Act document. A provider that already draws up technical documentation under Annex I legislation must produce a single set containing both (Article 11(2) of the AI Act). The AI Act also gives such a provider the choice of integrating its testing, reporting, information and documentation duties into the procedures already established under that legislation (Article 8(2) of the AI Act). MDCG 2025-6 strongly encourages manufacturers to use that flexibility. For the IFU this means one document. The Article 13(3) items are added to the Section 23.4 template where they are missing and expanded where Annex I already has a heading.

One point from the guidance needs stating plainly. Integrating the two sets of requirements into one document and one set of procedures saves you from maintaining two. It does not reduce what the document has to contain. Every item required by the AI Act and every item required by Annex I still has to be present and correct, and the notified body will check for both.

The format question

Article 13(2) of the AI Act requires the instructions for use “in an appropriate digital format or otherwise”. The AI Act does not itself constrain the medium. For a device, the medium is governed by Annex I, which allows a non-paper IFU only to the extent and under the conditions of the eIFU implementing rules (Annex I, Section 23.1(f)). Today that means Regulation (EU) 2021/2226 as amended in 2025. The AI Act does not displace it. A device whose instructions are intended for lay persons still needs paper for those instructions. A professional-use device may go electronic only after the risk assessment and under the conditions of Article 5 of that regulation. Software may carry its own instructions, within those same conditions (Article 3(3)). For IVDs there is no implementing regulation; the IVDR allows non-paper instructions for professional-use devices directly, near-patient testing excepted.

The AI Act does affect one practical aspect of the IFU: how often it will need revising. Declared accuracy metrics, performance on specific groups, the list of pre-determined changes and the update cadence all describe the current version of the model. When the model changes, those statements may stop being true. The trigger for a revision is a change in what the instructions declare, not the retraining as such. A retraining that stays within a performance envelope the IFU already states, and that the change plan pre-specified, does not need a new IFU. One that moves the declared accuracy, the input specifications or the known limitations does. A model change outside the change plan is a substantial modification, with a conformity assessment of its own. How you write the change plan therefore decides how often the IFU has to be revised. When a revision is needed, the eIFU regulation already sets out how users are told. It requires a system to indicate clearly when the instructions have been revised, and to inform each user where the revision was necessary for safety (Article 5(8)). It also requires every issued electronic version, with its publication date, to remain available on the website, or on request for obsolete versions (Article 5(13)).

The change plan, not the retraining schedule, decides how often the instructions for use have to be revised.

For a professional-use device that qualifies, an electronic IFU is therefore a reasonable choice for an IFU that will be revised more often. A manufacturer already providing one has a revision notice and a version history in place because Article 5 requires them. A manufacturer providing paper will need to set up a procedure for issuing revisions and telling users about them. Ydntfy’s hosting supports the website-side conditions of Article 5, including the revision notice and the availability of every version. The larger piece of work is deciding what the IFU must now say and validating it with users, and that work is the same whichever format you use.

Timing

  • 2 August 2028. Chapter III, Sections 1 to 3, of the AI Act, which include Article 13, apply to high-risk AI systems classified under Article 6(1) and Annex I from this date, with the exception of Article 6(5) (Article 113, point (c) of the AI Act, as amended by Regulation (EU) 2026/1744). Stand-alone Annex III systems apply from 2 December 2027.
  • Devices already on the market. For a high-risk AI system placed on the market or put into service before that date, the AI Act applies only if the system undergoes a significant change in its design from that date onwards (Article 111(2) of the AI Act). Systems intended for use by public authorities must comply by 2 August 2030 in any case, which will matter for devices used in public hospitals. The Omnibus rewrote this paragraph. The original text named 2 August 2026 as the date from which a significant change would bring a system into scope, a year before the high-risk rules applied to devices at all. MDCG 2025-6 dealt with that mismatch in its Question 31 by assuming the later date was meant. The amended text now says so: the date that counts is the date from which Chapter III applies to the device.
  • Per unit, not per type. MDCG 2025-6 applies the Blue Guide’s rule that placing on the market refers to each individual product. A unit placed on the market after 2 August 2028 falls under the AI Act even if the same device type was on the market for years before that date.
  • Standards and guidelines. When MDCG 2025-6 was published, CEN-CENELEC JTC 21 was still developing the harmonised standards on data and bias, and the Commission’s horizontal guidelines on Article 10 were still to come. The IFU content in Article 13(3) does not depend on either, so it can be drafted now.

What to do with this before 2028

Three steps fit inside an ordinary design change or the next scheduled IFU review.

  • Map the two lists. Put the six points of Article 13(3), twelve items once the sub-points of point (b) are counted, beside Section 23.4 of Annex I, or Section 20.4 of the IVDR, in the IFU template. Mark each as present, present but to be expanded, or new. The table above is a starting point; the mapping for your device may differ.
  • Decide what the interface carries. The instructions have to contain the listed content. Interpretation aids and oversight controls may also be shown on screen, at the point where the user needs them. Record which screen elements support which instruction, because the notified body assesses the instructions and the interface together.
  • Write the IFU revision into the change plan. If you intend to use a pre-determined change plan under Annex IV, point 2(f), each pre-specified change should state the performance range the IFU already declares, which IFU sections must be revised if a change takes the system outside that range, and how users will be told. Without that, a change may be permitted under the plan while the users are left with an IFU that no longer describes their device.

Sources

Primary sources. Every claim in this post is traceable to one of these, and the sub-provision detail sits here rather than in the body.

Show 6 sources

About this post

Ydntfy runs electronic instructions for use for medical device and IVD manufacturers, built to the conditions in Articles 4 to 7 of Regulation (EU) 2021/2226 for devices under the MDR and to Annex I, Section 20.1(f) of the IVDR for in vitro diagnostics. You can see how it works at ydntfy.com.

Originally published at https://ydntfy.com/en/blog/ai-act-instructions-for-use-medical-devices/ on 27 August 2026. You are welcome to quote or reuse this, with a link back.