> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withdovetail.com/llms.txt
> Use this file to discover all available pages before exploring further.
# EU AI Act for Medical Devices: A Practical Compliance Guide
> Learn how the EU AI Act applies to medical devices, what MDR processes already cover, and which AI-specific controls manufacturers still need.
**TL;DR**
If an AI system is a medical device or safety component covered by the MDR or IVDR **and** the product requires third-party conformity assessment, the AI system will generally be high-risk under the EU AI Act.
Your existing quality system gives you a strong starting point. It does not close every gap. You will still need AI-specific classification, data governance, logging, human oversight, transparency, performance monitoring, and documentation.
Under the AI Act currently in force, high-risk rules for AI embedded in regulated products apply from **2 August 2027**. An approved amendment would move this date to **2 August 2028**, but it had not yet entered into force as of 14 July 2026.
## Introduction
If you are developing an AI-enabled medical device, you do not need to build a second compliance system from scratch. Your MDR or IVDR quality system already covers much of the underlying work: risk management, technical documentation, verification and validation, conformity assessment, and post-market surveillance.
But MDR or IVDR conformity does not automatically demonstrate conformity with the EU AI Act. The AI Act adds a separate classification test and requirements that existing medical-device frameworks only cover in part. The biggest gaps usually concern training and validation data, bias, fundamental rights, model behaviour, logging, human oversight, and performance over time.
This guide shows you how to identify the requirements that apply, reuse evidence you already have, and focus your gap assessment on the AI-specific work that remains.
**Source and scope.** This guide translates the [official text of Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) into a practical overview for medical-device teams. Its legal-status information was checked on 14 July 2026. It is general information, not a substitute for a case-specific regulatory or legal assessment.
## How the EU AI Act risk framework works
The AI Act follows a risk-based approach. The more an AI system can affect health, safety, or fundamental rights, the more control and evidence the Act requires.
The commonly used labels "unacceptable," "high," "limited," and "minimal" risk are useful shorthand, but they can hide important details. A system outside the high-risk category may still be subject to AI literacy, prohibited-practice, or transparency rules. General-purpose AI models follow a separate obligation path.
| Category | What it means | Example relevant to a medical-device company |
| :----------------------------------- | :------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------------------- |
| **Prohibited practices** | Certain uses of AI are banned. | AI that manipulates people or exploits vulnerabilities in a way that causes or is likely to cause significant harm. |
| **High-risk AI systems** | The full set of high-risk requirements applies. | An AI-based diagnostic device that requires third-party conformity assessment. |
| **Systems with transparency duties** | Users must receive specific disclosures in situations covered by Article 50. | A support chatbot that interacts directly with users or synthetic content that must be marked as AI-generated. |
| **Other AI systems** | The high-risk chapter may not apply, but horizontal obligations can still apply. | An internal tool that does not make or materially influence safety-critical decisions. |
| **General-purpose AI models** | Model providers have separate obligations, with additional rules for models posing systemic risk. | A foundation model integrated into a medical-device workflow. The model provider and downstream manufacturer may have different duties. |
## Current EU AI Act timeline
The AI Act entered into force on 1 August 2024 and applies in phases.
Definitions, AI literacy duties, and prohibited AI practices began to apply.
Governance provisions and obligations for providers of general-purpose AI models began to apply.
Most remaining provisions apply under the law currently in force, including the high-risk rules for systems listed in Annex III and the Article 50 transparency requirements.
The high-risk rules for AI systems covered by Article 6(1) apply under the law currently in force. This includes qualifying AI systems embedded in products regulated under the MDR or IVDR.
**Pending timeline change—status on 14 July 2026.** The Council gave final approval to an amendment that would move the Annex III high-risk date to **2 December 2027** and the Article 6(1) product-embedded high-risk date to **2 August 2028**. As of 14 July 2026, the amendment was awaiting publication in the Official Journal and had not entered into force. Until it does, the dates above remain legally binding. See the [Council announcement](https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/pdf/), the [Council-approved text (PE-CONS 30/1/26 REV 1)](https://data.consilium.europa.eu/doc/document/PE-30-2026-REV-1/en/pdf), and the [draft Commission guidelines for high-risk AI systems](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems). The draft guidelines are non-binding; their consultation remains open until 23 July 2026 and final adoption is pending. Check the latest Official Journal version before making a deadline-dependent decision.
## First identify your role
Your obligations depend on what you do in the AI value chain, not only on the technology you use.
You develop an AI system or have one developed, and you place it on the market or put it into service under your name or trademark. A medical-device manufacturer will often be the provider of AI embedded in its device.
You use an AI system under your authority in a professional context. A hospital using an AI-enabled device may be a deployer.
You are located or established in the EU and place on the market an AI system that bears the name or trademark of an entity established outside the EU.
You make an AI system available in the EU supply chain without being the provider or importer.
One organisation can hold more than one role. Your role can also change if you rebrand a system, make a substantial modification, or change its intended purpose. Record the role assessment for every AI system in your inventory.
## When is an AI medical device high-risk?
For regulated products, [Article 6(1)](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6) uses a two-part test. An AI system is high-risk when **both** conditions are true:
1. The AI system is itself a product, or a safety component of a product, covered by legislation listed in Annex I of the AI Act. The MDR and IVDR are included.
2. The product requires a third-party conformity assessment before it can be placed on the market or put into service.
In plain language: if the AI is the medical device or is intended to be a safety component of it, and a Notified Body must assess the product, you should expect the AI system to be high-risk.
Not every piece of software used by a medical-device company is automatically a high-risk medical-device AI system. An internal writing assistant, customer-support chatbot, or administrative tool needs its own assessment. It may fall under transparency or other rules without meeting the Article 6(1) high-risk test.
Use this decision path for each system:
Compare the system with the AI Act definition. Do not classify a product from its marketing label alone.
State what the system does, who uses it, whose decisions it affects, and whether it performs a medical-device or safety function.
Determine whether the system is a product or safety component under the MDR or IVDR and whether third-party conformity assessment is required.
If Article 6(1) does not apply, check Annex III high-risk use cases, prohibited practices, Article 50 transparency duties, and any general-purpose AI obligations.
Keep the decision, supporting evidence, reviewer, and review date under change control. Reassess it when the intended purpose, model, product, or regulatory guidance changes.
## What high-risk AI compliance requires
High-risk AI compliance is not one document. It is a controlled evidence system that covers the full lifecycle.
| Area | What you need to demonstrate | What your existing medical-device system can contribute |
| :------------------------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Quality management and accountability** | Defined responsibilities, controlled processes, supplier oversight, competence, and evidence that requirements are consistently met. | Your MDR/IVDR and ISO 13485 quality system provides the structure. Add AI-specific roles, review gates, supplier controls, and literacy requirements. |
| **Risk management** | Continuous identification, evaluation, control, testing, and monitoring of risks to health, safety, and fundamental rights. | [ISO 14971 risk management](/regulatory-requirements/risk-management) is a strong foundation. Extend it to dataset bias, model behaviour, foreseeable misuse, automation effects, and affected groups. |
| **Data governance** | Relevant and sufficiently representative training, validation, and test data with documented provenance, preparation, assumptions, limitations, and bias controls. | Clinical and design-control processes provide useful evidence, but most teams need additional dataset governance and traceability. |
| **Technical documentation and records** | Intended purpose, architecture, development methods, data, performance metrics, risk controls, validation, model versions, and automatically generated logs. | Your [technical file](/regulatory-requirements/technical-file) and software lifecycle records cover part of this. Add AI-specific design decisions, datasets, model behaviour, and logging. |
| **Transparency and information** | Clear information about capabilities, limitations, expected accuracy, input requirements, foreseeable misuse, and human oversight. | Labelling, instructions for use, and usability engineering provide the delivery mechanisms. Review whether the content meets AI-specific information duties. |
| **Human oversight** | People can understand relevant outputs, detect anomalies, intervene, and disregard, reverse, or stop the system where appropriate. | Clinical workflow and usability controls help, but oversight must be designed into the system and validated rather than assumed. |
| **Accuracy, robustness, and cybersecurity** | Defined and tested performance that remains appropriate over time, including resilience to faults, model drift, misuse, and adversarial manipulation. | Verification, validation, software lifecycle, and cybersecurity controls provide the base. Add AI-specific failure modes and monitoring thresholds. |
| **Post-market monitoring and incidents** | Active monitoring of behaviour and outcomes, corrective action, and reporting of serious incidents where required. | Your [post-market surveillance system](/regulatory-requirements/post-market-surveillance) already provides the feedback loop. Extend it to model drift, data shifts, unexpected outputs, and AI-specific incident criteria. |
### Human oversight must be designed, not assumed
Putting a clinician in the workflow does not automatically meet the human-oversight requirement. The interface, instructions, training, and operating controls must allow that person to:
* understand what the output means and where its limits are;
* recognise anomalies or over-reliance;
* intervene before harm occurs;
* disregard, override, or reverse an output when appropriate; and
* stop the system or move to a safe state when necessary.
Test these controls in realistic use conditions. A policy that says "a human reviews the result" is not enough if the design makes meaningful review impractical.
### Data governance goes beyond data quality
Good model performance on one validation dataset is not the same as controlled data governance. For datasets covered by Article 10, document:
* where training, validation, and test data came from;
* why the data is relevant to the intended purpose and target population;
* how you identified and addressed missing, imbalanced, or biased data;
* which preprocessing, annotation, and exclusion rules you applied;
* which limitations remain and how you control them; and
* how you will detect material changes in real-world input data.
As a validation best practice—not an express checklist item in the AI Act—also document how you separated datasets and controlled leakage risk.
The practical goal is traceability. A reviewer should be able to follow the path from intended purpose to dataset choices, performance claims, identified risks, controls, validation evidence, and post-market monitoring.
## How existing frameworks help—and where they stop
Standards can reduce duplicated work. Under the law currently in force, none of them replaces the legal classification, role assessment, or conformity obligations in the AI Act.
The approved but not-yet-in-force amendment would add a targeted mechanism to reduce overlap. Through delegated acts, the Commission could limit specific requirements in Articles 9–15 and obligations in Articles 17–25 where Annex I sectoral legislation, including the MDR or IVDR, provides equivalent or higher protection. This would not create automatic equivalence: it would apply only after the amendment enters into force and the Commission adopts the relevant delegated act.
| Standard or framework | Strongest contribution | What it does not replace |
| :-------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- |
| **EU MDR / IVDR** | Quality management, product risk, technical documentation, clinical or performance evaluation, conformity assessment, and post-market surveillance. | AI Act classification, fundamental-rights analysis, AI-specific data governance, transparency, and model-behaviour controls. |
| **ISO 14971** | Lifecycle medical-device risk management. | Dataset governance, bias assessment, AI transparency, and the AI Act's legal classification test. |
| **ISO/IEC 42001** | AI management-system governance, accountability, objectives, controls, and continual improvement. | Product classification, prohibited-practice screening, conformity assessment, and other binding legal duties. |
| **ISO/IEC 23894** | A structured method for identifying and managing AI-specific risks. | A complete quality system, technical documentation, registration, or conformity assessment. |
| **ISO/IEC 27001 and 27701** | Information security and privacy management. | AI performance, human oversight, transparency, bias, and high-risk system classification. |
| **NIST AI RMF** | Voluntary practices for governing and measuring trustworthy AI risk across the lifecycle. | EU legal obligations, CE marking, registration, incident reporting, or conformity assessment. |
The cleanest approach is to map AI Act requirements into your existing quality system. Reuse procedures and records where they genuinely satisfy both frameworks. Add AI-specific evidence where they do not.
## A practical EU AI Act compliance plan
Include AI you develop, buy, embed, rebrand, or use internally. Record the owner, intended purpose, users, model or supplier, affected product, data, market, and lifecycle status.
Decide whether you are the provider, deployer, importer, distributor, or a combination. Document dependencies on model providers and other suppliers.
Apply the Article 6 tests, screen prohibited practices, check Article 50 transparency duties, and record the rationale. Do not use a single classification for an entire product portfolio.
Link each applicable AI Act requirement to an existing procedure, record, control, or owner. Mark partial coverage honestly.
Prioritise dataset governance, bias and affected-group analysis, model documentation, logging, human oversight, AI-specific cybersecurity, and model-change control.
Set performance metrics, acceptance criteria, subgroup analyses, drift thresholds, oversight tests, and logging requirements before verification and validation begins.
Align AI evidence with your MDR or IVDR technical documentation and Notified Body plan. Confirm responsibilities and evidence expectations early rather than adding an AI file at the end.
Connect model, data, supplier, intended-purpose, and software changes to regulatory reassessment. Feed post-market signals back into risk management, validation, and corrective action.
## Conclusion
The product-embedded high-risk date under the law currently in force is 2 August 2027. An approved amendment is expected to move it to 2 August 2028, but you should not plan against the later date until the amendment enters into force.
The shortest path is to use the quality system you already have. Start with your MDR or IVDR evidence, map it to the AI Act, and isolate the gaps. Then build AI-specific data, oversight, logging, performance, and monitoring controls into the same lifecycle rather than creating a parallel compliance programme.
If you want a second set of eyes on the classification or gap assessment, [ask Dovetail to review the regulatory pathway with your team](https://www.withdovetail.com/).
## Main takeaways
Your obligations depend on the system's intended purpose, your role, and the Article 6 classification test. Record the rationale before planning controls.
Reuse your QMS, risk, technical documentation, validation, and post-market processes. Add the AI-specific evidence they do not cover.
Dataset provenance, representativeness, bias, model versions, logging, drift, human oversight, and real-world performance need explicit controls and evidence.
As of 14 July 2026, the binding product-embedded date remains 2 August 2027. The approved amendment would move it to 2 August 2028 after publication and entry into force. Keep integrating the requirements into development and conformity planning now.
## Official sources
* [Regulation (EU) 2024/1689 — Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
* [Current Article 113 application dates](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113)
* [Council-approved Digital Omnibus text (PE-CONS 30/1/26 REV 1)](https://data.consilium.europa.eu/doc/document/PE-30-2026-REV-1/en/pdf)
* [Draft European Commission guidelines for providers and deployers of high-risk AI systems](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems)
* [Council final approval of the revised AI Act implementation rules, 29 June 2026](https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/pdf/)
* [MDCG 2025-6 FAQ on the interplay between MDR, IVDR, and the AI Act](https://health.ec.europa.eu/latest-updates/mdcg-2025-6-faq-interplay-between-medical-devices-regulation-vitro-diagnostic-medical-devices-2025-06-19_en)
## Frequently asked questions
No. First confirm that the software meets the AI Act definition of an AI system. Then assess its intended purpose, role in the product, conformity pathway, and other possible obligation categories. Software is not high-risk under the AI Act simply because a medical-device company uses it.
Not automatically. Under Article 6(1), the AI must be a regulated product or safety component and the product must require third-party conformity assessment. Systems that do not meet both conditions still need screening for Annex III, prohibited practices, transparency duties, and other applicable rules.
No automatic equivalence applies under the law currently in force. MDR or IVDR conformity gives you substantial reusable evidence, but the AI Act adds its own classification, data governance, transparency, human-oversight, logging, and lifecycle-performance requirements. The approved but not-yet-in-force amendment would let the Commission limit selected AI Act requirements through delegated acts where sectoral law provides equivalent or higher protection. Perform a documented gap assessment unless and until a relevant delegated act applies.
Under the law currently in force, the Article 6(1) high-risk rules for qualifying AI embedded in regulated products apply from 2 August 2027. An approved amendment would move this date to 2 August 2028, but as of 14 July 2026 it had not entered into force. Other AI Act obligations already apply or begin earlier, so do not postpone your inventory, literacy, prohibited-practice screening, or transparency work.
The AI Act does not make ISO/IEC 42001 certification a universal requirement. The standard can provide a useful governance structure, but certification does not replace the legal requirements or prove that a specific product conforms.
Separate the model provider's obligations from your own. As the manufacturer placing the AI-enabled device on the market, you may still be the provider of the downstream AI system. Define the information, change notifications, performance evidence, security controls, and access rights you need from the supplier.
Start with an inventory and classification record. Without those, you cannot reliably determine which controls, evidence, suppliers, deadlines, or owners matter.