V5 Ultimate
Compliance · The complete guide

EU AI Act (medical devices)Regulation (EU) 2024/1689 — Artificial Intelligence Act, as applied to medical devices

TL;DR

Regulation (EU) 2024/1689 overlays AI-specific obligations on MDR and IVDR, classifying most AI medical devices and IVDs that require notified body involvement as high-risk and introducing new documentation, data governance, oversight, and monitoring duties on a staged timeline to full applicability.

Reviewed · By V5 Ultimate compliance team· 2,602 words · ~12 min read
AI · Explain it for MY operation

How does EU AI Act (medical devices) apply to your shop floor?

Pick your industry and scale — Ask V5 rewrites the definition in your context, gives a worked example, and shows what V5 does on day one.

Your scale

01What the EU AI Act means for medical devices and IVDs

Regulation (EU) 2024/1689, the AI Act, is a horizontal law that applies across sectors and adds AI-specific obligations to medical devices and in vitro diagnostics already regulated under MDR 2017/745 and IVDR 2017/746. It does not replace device law. Instead, it creates a second layer of requirements for AI systems that meet medical device or IVD definitions and are subject to third-party conformity assessment.

Under Article 6(1), any AI system that is itself a medical device or IVD, or a safety component of one, becomes a high-risk AI system when the underlying product requires a notified body. This automatic high-risk classification triggers obligations for risk management, data and data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity, post-market monitoring, and reporting.

Practically, manufacturers will extend their existing device processes to show how the model and its data lifecycle meet these new duties. The AI Act expects a documented, testable chain from intended purpose through data selection, training and validation, performance metrics, deployment controls, and in-field monitoring, including corrective actions.

Strategically, organizations should harmonize their device quality management system with AI Act expectations early. Aligning design controls, change control, and vigilance with AI-specific documentation reduces friction during combined assessments and helps avoid duplicated audits under different legal bases.

The legislative architecture encourages integrated conformity assessment, so most assessments for devices will run through the MDR/IVDR notified body with added AI checkpoints. This allows a single file, one audit path, and a consolidated certificate set, provided the technical documentation addresses the AI Act’s annexed content requirements and lifecycle controls.

Read the base device framework here: EU MDR.

02Scope, ‘high-risk’ under Article 6(1), and what is in

The AI Act covers AI systems placed on the EU market or put into service, including machine learning components embedded in medical devices and IVDs. Article 6(1) classifies as high-risk any AI system that is a product, or a safety component of a product, covered by the EU product safety legislation listed in Annex II, where the product requires third-party conformity assessment. MDR and IVDR are expressly listed, so their AI-enabled devices and IVDs ordinarily fall in scope when a notified body is required.

High-risk status is not tied to the device’s clinical performance claim alone, but to the legal pathway. If a device is self-certified and does not require a notified body, the AI system is generally not captured by Article 6(1). Conversely, a diagnostic classifier in an IVD that triggers NB involvement will be high-risk under the AI Act regardless of whether the model runs locally or in the cloud.

The definition of AI system is technology-neutral, capturing supervised, unsupervised, and reinforcement learning, and certain logic or statistical approaches that infer from inputs to generate outputs. Manufacturers should map each algorithmic component against intended purpose and safety function to determine whether it is a product, a safety component, or supportive tooling outside scope.

In borderline cases, scope often turns on whether the output is used for an intended medical purpose and whether failure would affect patient safety or compliance with essential requirements. Documentation should show a clear separation between development aids and deployed, user-facing functions, because only the latter are candidates for high-risk classification.

For scoping discipline, revisit your intended purpose statement, architecture decomposition, and evidence that each algorithmic element aligns with declared claims. This reduces later debates with assessors on what must be included in the AI technical file under the Act.

Helpful background on device pathways: Medical device classification.

03How AI Act compliance layers over MDR and IVDR

The AI Act does not replace MDR or IVDR essential requirements, clinical evidence, or performance evaluation. Instead, it adds AI-specific obligations that must be demonstrated within the device conformity assessment. For medical devices and IVDs, the practical expectation is a single assessment process in which the same notified body evaluates both device and AI Act evidence streams, avoiding duplicative audits.

From a quality perspective, manufacturers should extend their device QMS to include AI lifecycle controls rather than stand up a parallel AI governance system. Procedures for data governance, model development, verification and validation, human oversight, model release, monitoring, and decommissioning should be integrated into design controls, supplier management, vigilance, and change control.

Technical documentation must now cover model provenance and performance as rigorously as hardware and software baselines. Expect assessors to triangulate intended purpose, risk controls, dataset representativeness, labeling practices, metrics for accuracy, robustness and cybersecurity, and the traceability of requirements through implementation and test.

Post-market, manufacturers must monitor AI performance and report serious incidents and malfunctions affecting compliance with the AI Act, in addition to MDR/IVDR vigilance. Aligning signals across both legal frameworks minimises duplicate reporting and allows efficient corrective actions.

An integrated approach makes surveillance audits smoother because the same objective evidence, such as logs and change records, supports both device law and AI Act obligations. It also positions teams to adopt harmonised standards once they are cited in the Official Journal.

Anchor these controls in your device QMS: QMS.

04Technical documentation, lifecycle risk management, and change control

High-risk AI systems must be supported by technical documentation that demonstrates compliance with AI Act requirements throughout the lifecycle. Beyond the general device file, the AI technical dossier should make model lineage, training and validation datasets, preprocessing, hyperparameters, performance metrics, robustness and cybersecurity measures, and human oversight design decisions explicit and testable.

Risk management remains foundational. Use a structured hazard analysis to connect data and model risks to device harms and risk controls. The AI Act expects risks to be reduced as far as possible without disproportionate trade-offs, with clear evidence that residual risks are acceptable in light of intended purpose, benefits, and user training.

Change control is critical for adaptive models and frequent updates. Manufacturers should define model release criteria, retraining triggers, data drift monitoring, rollback capability, and configuration management that preserves traceability between model versions and the performance evidence submitted for conformity assessment.

Where a predetermined change control plan is used to manage future algorithmic updates, keep the plan aligned with the AI Act’s expectations for risk analysis, validation, and post-deployment surveillance. The plan should be sufficiently specific to be auditable and bounded so that significant expansions of intended purpose do not slip through routine updates.

Finally, completeness matters. Assessors will expect requirements-to-tests traceability, dataset governance logs, and reproducible model builds. Documentation must be current at the time of the assessment and at each significant change, with defined owners and review cycles.

Deepen software lifecycle controls here: IEC 62304 medical device software readiness.

05Data governance, bias control, and post-market monitoring

The AI Act sets explicit expectations for data used to develop and test high-risk AI systems. Training, validation, and testing datasets must be relevant, representative, free of errors as far as possible, and complete in light of the intended purpose. Manufacturers should define and apply documented data management practices covering sourcing, consent and rights to use, curation, labeling, and quality checks on both inputs and annotations.

Bias risk must be analyzed and controlled proportional to the device risk and intended population. This includes demographic coverage in datasets, differential performance analyses, and mitigation strategies where clinically meaningful groups exhibit degraded sensitivity or specificity. Annotator training and inter-rater agreement records are especially important for imaging and pathology datasets.

In deployment, the manufacturer must implement post-market monitoring to verify that the AI system continues to meet AI Act obligations, including accuracy and robustness. Monitoring should combine automated telemetry and targeted field evaluations, and it must feed corrective and preventive action mechanisms when deviations are detected.

Serious incidents and malfunctions that affect compliance with the Act must be reported to competent authorities under the AI Act’s notification regime, in addition to MDR or IVDR vigilance. Harmonizing signal detection and reporting thresholds across frameworks avoids duplicative effort and reduces the risk of inconsistent submissions.

For IVDs, ensure that analytical and clinical performance data remain aligned with real-world specimen variability over time. Updates to sample preparation, instruments, or lab workflows can alter input distributions and require retraining or recalibration to avoid systematic drift.

For transition planning in diagnostics, see: EU IVDR readiness.

06Cybersecurity, transparency, and human oversight

High-risk AI systems must be resilient against reasonably foreseeable threats, including data poisoning, model inversion, and adversarial manipulation. Manufacturers should document controls across the stack: secure development and build pipelines, dependency governance, hardened runtime environments, input validation, and detection of anomalous model behavior.

Transparency obligations require clear instructions for use describing the AI system’s intended purpose, performance characteristics, limitations, known residual risks, and the role of human users. Logging must capture sufficiently detailed events to allow traceability and post-incident analysis without compromising patient confidentiality.

Human oversight is not a slogan, it is an engineered control. Define who the human-in-the-loop is, what authority they have to accept, override, or discard AI outputs, and what information and training they need to do so safely. Calibrate alerting and UI design to minimize automation bias and nuisance alarms while preserving sensitivity in safety-critical contexts.

Your approach should show proportionality. Higher-stakes clinical decisions warrant tighter oversight thresholds, dual confirmation on high-consequence outputs, and more frequent quality assurance checks. Lower-risk support tools can rely on sampled reviews and trend monitoring, provided documented criteria justify the difference.

Cybersecurity, transparency, and oversight evidence must be coherent across the technical file, clinical evaluation, and user training packages. Regulators will look for alignment between documented risks, UI design, and how end users are instructed to mitigate limitations.

Build defensible verification depth with proportionate controls: Risk-based validation.

07Transition timeline through August 2026 and beyond

The AI Act entered into force in 2024 with staged applicability. Prohibited AI practices apply first, followed by general-purpose AI obligations, then broader governance measures, and finally the full suite for high-risk systems. Medical devices and IVDs affected by Article 6(1) should plan deliverables around these milestones, recognizing that several obligations bite before the complete high-risk regime matures.

By mid-2025, foundational elements such as codes of practice and sandbox structures begin to appear. Through 2026, authorities and notified bodies build capacity, and manufacturers should use this period to close documentation gaps, operationalize monitoring, and test evidence packages with assessors. Device-specific high-risk obligations will ultimately apply in full thereafter, with conformity assessment pathways stabilized as harmonised standards are published.

Teams should avoid waiting for every harmonised standard to land. The better approach is to adopt state-of-the-art controls now, document rationale against current ISO and IEC references, and be prepared to map to harmonised clauses when they are cited. Early engagement with your NB on AI file structure and sampling depth can prevent surprises late in the transition.

The table below highlights key dates for planning purposes. Align internal readiness reviews and supplier contracts to these checkpoints, ensuring contracts and service levels allow for increased logging, data retention, and security controls required under the AI Act.

MilestoneWhat changesTarget date
Entry into forceAI Act published and enters into forceAugust 2024
Prohibitions applyBanned AI practices become unlawfulFebruary 2025
GPAI duties beginGeneral-purpose AI obligations start to applyAugust 2025
Operational build-outAuthorities, standards bodies, and NBs scale capacity; manufacturers finalize AI filesThrough August 2026
Full high-risk device regimeComprehensive high-risk obligations for Annex II product laws fully applicablePost-2026 (staged into 2027)

Remember that adjacent EU programs also mature in this window. For example, EUDAMED moves toward mandatory use by 2026, which can affect your surveillance and vigilance interfaces as you integrate AI Act-monitoring into device post-market systems.

Track this related device milestone: MDR EUDAMED mandatory 2026.

08Harmonised standards, common specifications, and the role of notified bodies

Harmonised standards for the AI Act are still being developed. Until they are cited in the Official Journal, conformity can be demonstrated using state-of-the-art international standards and guidance as justified by your risk profile. Expect eventual harmonisation to reference AI governance, data quality, robustness, transparency, and cybersecurity controls, along with mapping to device software and risk management standards.

Manufacturers should preemptively align their QMS with anticipated AI Act themes by reinforcing supplier qualification for data and models, tightening software configuration management, and updating internal competence matrices. Keeping procedures modular will ease future clause mapping once harmonised texts are published.

Notified bodies designated under MDR or IVDR are expected to seek AI Act designation where they service AI-enabled portfolios. Practically, this means your existing NB will extend its scope and integrate AI checkpoints into regular assessments, including document reviews, process audits, sampling strategy for datasets and model evidence, and on-site verification of logging and monitoring capabilities.

NBs will likely emphasize clarity of intended purpose, data governance records, and the coherence of claims across labeling, promotional materials, and technical documentation. They will pay special attention to update mechanisms and how performance commitments are maintained across versions, particularly where field updates can materially alter performance.

A candid pre-assessment dialogue on AI file structure, sampling, and post-market analytics often pays dividends. Agreeing on evidence expectations early reduces iteration cycles and helps avoid late-stage nonconformities tied to documentation completeness or traceability gaps.

09Common pitfalls, neighboring frameworks, and practical steps to take now

A frequent misstep is treating the AI Act as an isolated checklist. Success depends on integrating AI lifecycle controls into device QMS processes and ensuring that claims, instructions, and evidence are synchronized across MDR or IVDR files and AI documentation. Regulators will test the consistency of intended purpose statements and the substantiation of performance claims throughout the product lifecycle.

Another recurring problem is under-specifying human oversight. If the oversight role, authority, and user interface signals are unclear, assessors will doubt the effectiveness of the control. Similarly, vague change control for models invites findings, because it obscures the link between fielded versions and the evidence base reviewed during conformity assessment.

Manufacturers should also avoid assuming that clinical performance alone will satisfy AI Act obligations. Dataset provenance, representativeness, and annotation quality carry equal weight. Weak telemetry and logging will undermine both cybersecurity and post-market monitoring expectations, especially where incident reconstruction is necessary.

Finally, watch the edges. Borderline tools that influence clinical workflows can creep into scope as safety components. Keep architecture contracts up to date, and document why internal development aids are out of scope to avoid scope creep during audits.

  • Map every AI function to intended purpose and safety role, then document the scope and rationale.
  • Harden change control for models with release gates, rollback plans, and drift monitoring.
  • Elevate dataset governance with sourcing, consent, labeling SOPs, and bias analyses tied to risk.
  • Define human oversight roles, escalation paths, and UI signals that enable effective intervention.
  • Rehearse incident logging and reporting workflows that align AI Act and MDR/IVDR vigilance.

Keep an eye on UK innovations such as the MHRA AI Airlock, which offers an early path to pressure-test evidence packages in a supervised environment. Even if you do not enter the sandbox, its expectations foreshadow review practices that EU notified bodies may emulate.

For a structured risk lens applicable across AI and device contexts, see: ICH Q9 quality risk management readiness.

10How V5 Ultimate supports AI Act implementation for devices and IVDs

V5 Ultimate helps manufacturers integrate AI Act expectations into existing device quality systems without creating parallel processes. Teams can capture intended purpose, architecture, dataset lineage, model training records, verification and validation evidence, and human oversight design controls in one environment that links directly to change control and post-market monitoring.

Built-in workflows align with MDR and IVDR design controls while adding AI-specific checkpoints for data governance, bias analysis, robustness testing, cybersecurity hardening, and logging sufficiency. Versioned model releases maintain traceability from requirements to deployed binaries and telemetry, with drift alerts escalating to CAPA when performance moves outside pre-set bands.

During assessment, V5 compiles AI Act technical documentation and device files into auditor-friendly views. Evidence can be shared securely with your notified body, including dataset samples, validation summaries, and monitoring dashboards that demonstrate ongoing conformity in the field.

After launch, V5 links post-market signals to model versions, enabling rapid investigation, rollback, and reporting under both the AI Act and MDR/IVDR vigilance. Standard analytics and export templates streamline recurring reviews and management reporting across your portfolio.

Explore how we operationalize these controls: V5 AI and Audit readiness.

Frequently asked questions

Q.When is an AI medical device automatically high-risk under the EU AI Act?+

Under Article 6(1), an AI system that is a medical device or IVD, or a safety component of one, is high-risk when the product requires notified body conformity assessment under MDR or IVDR. Self-certified devices without NB involvement are generally not captured.

Q.Does the AI Act replace MDR or IVDR obligations?+

No. The AI Act adds AI-specific obligations on top of MDR and IVDR. Clinical evaluation, performance evaluation, and essential requirements still apply, and you must show AI Act compliance within the same conformity assessment.

Q.What new documentation does the AI Act require for devices?+

Manufacturers need AI-focused technical documentation covering data governance, training and testing datasets, model design, performance metrics, robustness and cybersecurity, human oversight design, logging, and post-market monitoring, all traceable to the intended purpose.

Q.How should we manage algorithm updates after launch?+

Define release gates, retraining triggers, and rollback paths, and monitor drift continuously. Use a predetermined change control plan where appropriate, and ensure updates remain within the validated intended purpose and documented risk controls.

Q.Will our existing ISO 13485 QMS be sufficient?+

It provides a strong base but typically needs extensions for data governance, AI model lifecycle controls, cybersecurity, and logging. Keep procedures modular so you can map to harmonised AI Act standards when they are published.

Q.Who will assess AI Act compliance for devices?+

Your MDR or IVDR notified body is expected to integrate AI checkpoints into device conformity assessment once designated under the AI Act. Engage early to agree on evidence structure and sampling depth.

Q.What is the practical timeline through 2026?+

Prohibitions bite first, followed by general-purpose AI obligations in 2025. Through 2026, authorities and notified bodies scale assessments while manufacturers finalize AI files. Full high-risk device obligations stabilize thereafter with standards roll-out.

Primary sources

Further reading

See EU AI Act (medical devices) working on a real shop floor

V5 Ultimate ships with the EU AI Act (medical devices) controls already wired in — audit trail, e-signatures, validation evidence. Free trial, no credit card, onboard in days, not months.