Medical devices and in vitro diagnostic medical devices are governed by Regulation (EU) 2017/745 and Regulation (EU) 2017/746, both listed in Annex I Section A. An AI system that is itself such a device, or is intended to be used as a safety component of such a device, can be high risk under Article 6(1) where third party conformity assessment is required under the device legislation. The AI requirements are then assessed through the device conformity procedure. This guide gives only an outline of the interplay. Whether software is a medical device, and which device classification applies, must be confirmed under the device regulations themselves.
What device legislation is in Annex I?
Regulation (EU) 2017/745 on medical devices and Regulation (EU) 2017/746 on in vitro diagnostic medical devices are the sector instruments listed in Annex I Section A for these products. Each Regulation sets its own scope, definitions, classification rules, conformity assessment procedures, clinical evaluation or performance evaluation requirements, post market surveillance duties and vigilance duties. The medical device Regulation covers devices intended for medical purposes, including diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, and certain products without a medical purpose that are listed in its annexes. The in vitro diagnostic Regulation covers reagents, instruments and systems intended for the in vitro examination of specimens from the human body. The AI Act does not change those scope and classification rules. A software product must first be examined under the device Regulations to decide whether it is a device at all, and if so, which class applies. Only after that sector examination can the AI Act product route be applied on a sound basis.
When is AI software a medical device?
Software can be a medical device in its own right, a component of a device, or an accessory, depending on its intended purpose and its function. The intended purpose is stated by the manufacturer in the instructions for use, labelling and promotional material, and it is examined against the medical purpose definitions in the device Regulations. Software that analyses medical images to support a diagnosis, software that monitors physiological data to detect deterioration, and software that controls a therapeutic device are examples of functions that commonly raise the device question. Software that only stores records, displays data without a medical interpretation, or supports general administration may not be a device, but the boundary is fact sensitive and the device guidance on software qualification must be checked. A manufacturer should record the intended purpose, the medical claims made, the user, the clinical context and the reasons for the device conclusion, including any guidance relied on. A claim that software is not a device because it is only decision support should be tested against the device definitions and guidance, not assumed. The device conclusion should be confirmed with a competent authority or legal adviser and, where relevant, with a notified body.
For the broader regulatory framework, see products, machinery and vehicles overview.
How does Article 6(1) apply to devices?
Where software is a medical device or an in vitro diagnostic device, or is a safety component of such a device, Article 6(1) asks whether third party conformity assessment is required under the device Regulation. Many device classes require notified body involvement, while some lower class devices can follow a self assessment route under the device Regulations, subject to specific conditions. The Article 6(1) answer therefore follows the device classification and the conformity procedure that the device Regulation prescribes for that class. Where third party assessment is required, the system is high risk under Article 6(1) and the AI requirements in Chapter III, Section 2 are assessed through the device conformity procedure under Article 43(3). The device file must then address both the device requirements and the AI requirements in a coherent way, with clinical or performance evidence, data governance, human oversight, accuracy, robustness and cybersecurity addressed to the extent the combined procedure requires. Where third party assessment is not required, the Article 6(1) route does not lead to high risk classification on that ground, but other AI Act provisions and the device duties themselves still apply.
What other device duties run alongside the AI Act?
Device manufacturers must meet duties that go beyond the AI Act chapter on high risk systems, including general safety and performance requirements, risk management under the device Regulations, clinical evaluation or performance evaluation, post market surveillance, vigilance reporting for serious incidents and field safety corrective actions, and the duties of the person responsible for regulatory compliance. Data protection law, professional and clinical governance, and national health law also apply to the use of AI in healthcare settings. The AI Act post market monitoring and serious incident provisions in Articles 72 and 73 must be read alongside the device vigilance system, and the file should show how the two systems interact without duplication or gaps. A change to an AI model, to training data or to the intended purpose can trigger a new device conformity assessment, a new clinical or performance evaluation, or both, and the change control record should address each trigger. Healthcare deployers, such as hospitals, have separate duties in relation to use, oversight and incident reporting, and the boundary between manufacturer and deployer duties should be recorded in the supply and use agreements.
What should a device team record for an AI function?
A device team should record the intended purpose, the device qualification reasoning, the classification, the conformity procedure, the clinical or performance evaluation plan and results, the data used for development and validation, the performance measures and their limitations, the human oversight design, the cybersecurity measures, the post market surveillance plan and the change control process. For AI functions, the record should also describe the training and validation data, the population represented, known limitations and failure modes, the monitoring of performance drift, and the arrangements for updates. The record should distinguish between performance in a validation study and performance in routine clinical use, and should state the conditions under which the function should not be used. Where a function is intended for use by lay persons, patients or carers, the instructions and warnings need separate attention. The record should be written so that a notified body, a competent authority or a clinician reviewer can follow the reasoning without needing to interview the development team. Gaps, uncertainties and open questions should be visible in the record, with owners and dates for resolution.
Continue with Annex I Section A and Section B.
What does this outline not decide?
This outline does not decide whether any named software product is a medical device or an in vitro diagnostic device, does not assign a device class, and does not describe the clinical evaluation, performance evaluation or conformity procedures in full. It does not address reimbursement, professional liability, or the clinical governance of a particular healthcare service. The device Regulations, the sector guidance on software qualification and classification, and the current notified body position must be checked for each product. A manufacturer or healthcare deployer with a specific AI device should confirm the position with a competent authority, a notified body where relevant, and a legal adviser, and should not treat this general outline as a determination for that device.
Frequently asked questions
Is all health related AI software a medical device?
No. Whether software is a medical device depends on its intended purpose and function under Regulation (EU) 2017/745 or Regulation (EU) 2017/746. General wellness, record keeping and administrative software may fall outside the device definitions, while software with a diagnostic or therapeutic purpose may fall inside them. The qualification reasoning must be recorded and confirmed under the device Regulations.
Does the AI Act add a second CE mark for devices?
No separate AI Act CE mark is described in this guide. For Section A devices, the AI requirements are assessed through the device conformity procedure, and the CE marking follows that combined procedure. The declaration of conformity and the device file must show how the AI requirements were addressed. The exact declaration wording and procedure must be checked in the current device and AI Act texts.
What happens when a device AI model is updated?
An update can trigger device change control, a new clinical or performance evaluation, a new conformity assessment and an AI Act reassessment, depending on the nature of the change. The change record should address each trigger separately, with the notified body involved where the device procedure requires it. An update should not be released on the basis of a general statement that the model improved.
Can this guide be used for a clinical deployment decision?
No. A clinical deployment decision needs the device file, the clinical or performance evidence, the local clinical governance review, data protection assessment and confirmation from the relevant authorities and advisers. This guide explains the interplay in outline only and does not make a clinical or legal determination.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗