EU AI Act for healthcare and medical devices

Does the EU AI Act for healthcare and medical devices apply to us?

AI in medical and in vitro diagnostic devices is high-risk through Annex I, with an application date of 2 August 2028, and AI used for emergency healthcare patient triage or for deciding public benefit eligibility falls under Annex III, with an application date of 2 December 2027. If you build, sell or run AI in health, the first question is which of these two routes your system takes. The answer is not decided by the sector alone. It turns on whether the AI is a safety component of a product, or is itself a product, covered by Annex I legislation that requires third-party conformity assessment under that legislation. Under Article 6(1), that test applies to the device or product, not to the software in isolation.

Next, establish your role. A device manufacturer that puts AI into its product is normally the provider and carries the provider duties under the Act. A hospital or clinic that uses a certified AI tool in its own operations is usually a deployer, and must follow the provider's instructions for use and keep the logs and oversight the Act requires. Many health organizations are both, for example when they build an in-house tool for their own staff. Confirm your role for each system separately. Also confirm whether you are a public authority or act on its behalf, because that status brings the Annex III benefit eligibility and emergency dispatch rules into play, including for triage tools used by public health services.

How medical and IVD AI moves through the sectoral conformity route

Medical devices and in vitro diagnostic devices sit in Annex I Section A, so the AI Act does not run as a separate approval for their AI software. Under Article 6(1), an AI system that is a safety component of such a product, or is itself the product, is high-risk when the product must undergo third-party conformity assessment under the sectoral law. For these systems, Article 43(3) folds the AI Act requirements and the Article 17 quality management system into the conformity assessment already required under the device regulations. The manufacturer does not run a second, parallel AI Act route. Article 11(2) then requires a single set of technical documentation that combines the AI Act information with the device information, so the device file becomes the place where AI evidence lives.

Roles matter here. The notified body designated under device law is the party that examines the file and issues the device certificates. The organization owns the quality management system, the technical documentation and the post-market processes, and it must be able to show how they operate day to day. A partner can help build the QMS, map AI-specific evidence into the file and prepare the audit trail, but no implementation partner issues the certificate. Your first decision is therefore who in the organization owns the single file, and whether the QMS already covers model versioning, data governance, logging and monitoring of the AI component or needs extending to them.

Timing has shifted. As amended by Regulation (EU) 2026/1744, the high-risk rules for Annex I product systems apply from 2 August 2028, replacing the earlier 2 August 2027 date. The harmonised standard EN 18286:2026, which covers quality management, was cited in the Official Journal on 14 October 2026. Ask your notified body which version of the requirements it will assess against and how it will examine AI-specific evidence such as training data governance, performance metrics and drift monitoring. Get that answer in writing before you fix your development plan, because the file structure and the assessment questions will determine how much evidence you need to produce in the device cycle.

What makes the health AI workload larger or smaller

Six factors decide how much work an AI Act program creates for a health AI system. Most of them are set early, by product design, the device classification and the organization's role, so they are worth settling before any evidence is collected. Read them together, because a single device can move along several at once.

Number of AI functions per device

A device with one diagnostic model and a single intended purpose has one system to document, test and monitor. A device that bundles triage scoring, image enhancement and a dosing recommendation may contain several AI functions, each with its own data, risk profile and performance metrics. Map every AI function to its intended purpose before estimating effort, and ask your notified body or assessor how they plan to treat multiple functions within one technical file.

Safety component or non-safety feature

The AI Act treats an AI system as high-risk under Article 6(1) when it is a safety component of a covered product, or is itself that product, and third-party conformity assessment applies. An AI feature that only supports administrative workflows, such as scheduling or transcription, may fall outside that route. Document the reasoning for each function, because the boundary between safety and non-safety features is where classification disputes usually arise.

Provider or deployer role

A manufacturer that places an AI-enabled device on the market carries the provider obligations, including the quality management system, technical documentation and post-market monitoring. A hospital that configures or uses a third-party system carries deployer duties, such as human oversight, input data control and log retention. The same organization can hold both roles if it builds models in-house and sells them. Confirm your role for each system before scoping, because the evidence set differs sharply.

Existing MDR or IVDR technical file

Where a technical file already exists under Regulation (EU) 2017/745 or 2017/746, the AI Act requirements are assessed as part of the sectoral conformity assessment rather than as a separate exercise. Article 11(2) requires a single set of technical documentation for these products. The main effort is extending the existing file with AI-specific content, such as data governance, performance under the intended population and logging. Check whether your current file covers the AI function at its current version.

Sites and data sources

Each hospital, laboratory or data source that feeds training, validation or live operation adds documentation, data lineage and comparability checks. A model trained on data from one scanner vendor or one patient population may behave differently elsewhere. Count sites and data pipelines early, record how data is collected and labeled at each, and confirm with your assessor how multi-site performance evidence will be presented.

Public benefit or emergency use

A system that also sits in Annex III point 5 becomes high-risk on that basis as well. Emergency healthcare patient triage and AI used by or for public authorities to assess eligibility for healthcare benefits or services are both listed. Such uses can add a second set of obligations, including a fundamental rights impact assessment where public bodies are the deployers. Identify early whether any deployment is run by a public authority, because it changes which duties apply and who must perform them.

Emergency triage and public benefit eligibility under Annex III

Annex III point 5(d) covers AI used to evaluate and classify emergency calls, to dispatch or prioritize emergency first response services (including police, firefighters and medical aid), and emergency healthcare patient triage systems. If your system ranks patients or calls by urgency in an emergency setting, it is likely to be high-risk under this point, subject to the Article 6(3) exemption analysis.

Risk management and data governance: Maintain a documented risk management process across the system lifecycle and document how training, validation and test data were selected and checked for bias.
Technical documentation and logs: Prepare the documentation described in Annex IV and keep automatically generated logs that allow the outputs to be traced.
Human oversight and deployer information: Design the system so clinicians or dispatchers can understand, override and stop it, and give deployers the instructions for use.
Quality management and registration: Operate a quality management system under Article 17 and register the system in the EU database before placing it on the market.
Post-market monitoring and incidents: Monitor performance after release and report serious incidents under Article 73.

Confirm with your clinical safety team and legal counsel whether a triage tool is an Annex III system, a medical device under Annex I, or both, because the answer changes the route and the date.

How an AI Act health conformity file moves from scope to notified body review

This sequence takes a health AI function from classification under Article 6 to a complete conformity file that a notified body or assessor can review, with each step producing a defined document or check. It shows where the organization decides, where the implementation partner prepares evidence, and where the independent body judges.

Confirm classification under Article 6
The manufacturer or provider decides whether the AI function is a safety component of a product, or is itself a product, covered by an Annex I law, and whether that product needs third-party conformity assessment under that law. For medical and in vitro diagnostic devices, this step is led by the manufacturer's regulatory and quality team with legal review. The output is a written classification memo that names each AI function, the Annex I legislation it falls under, and the reasoning. Check the draft Commission guidelines on classification before you close this step, and ask your notified body to confirm its reading in writing.
Map each AI function to the device or service
Build an inventory that links every AI component to the device, software function or clinical workflow it supports, including training data sources, inputs, outputs, and any human oversight step. Engineering, clinical and regulatory staff review the map together, because a function that looks like administration can still influence a diagnosis or treatment decision. The output is a function-to-device traceability register with a version and an owner for each entry. Confirm that the register covers every model version that will be placed on the market, not only the current release.
Build the single technical file
Under Article 11(2), a single set of technical documentation combines the AI Act information with the sectoral device documentation, so the notified body reviews one file rather than two. The provider's engineering and regulatory teams compile the Annex IV content, including system design, development process, data governance, performance metrics and intended purpose, and cross-reference the sectoral technical documentation. The output is a versioned technical file with an index that maps each Annex IV element to its location. Ask the notified body how it expects the combined file to be structured before drafting begins.
Run the quality management system and risk management
The provider operates a quality management system covering the AI Act requirements, which the conformity assessment checks as part of the sectoral route under Article 43(3) and Article 17. The quality and regulatory team defines procedures for design control, data management, risk management, change control, and post-market activity, then runs them against the AI function. The output is a set of records showing the procedures were followed, including risk files, design reviews, verification and validation results, and change approvals. The first harmonised standard on quality management, EN 18286:2026, was cited in the Official Journal on 14 October 2026, so confirm with the notified body which standards it will use as the reference.
Prepare evidence for the sectoral conformity assessment
The provider assembles the evidence package the sectoral conformity assessment will examine, including clinical or performance evaluation results, validation datasets and their provenance, bias and robustness testing, cybersecurity documentation, and instructions for use that describe human oversight. An implementation partner can prepare the test records and the evidence index, while the manufacturer keeps ownership of every claim. The output is an evidence index that links each requirement to a document, a test result and a named owner. Verify that the test records are reproducible, because reviewers will ask how each figure was produced.
Engage the notified body or assessor
The provider submits an application to the notified body designated for the relevant device legislation, usually under Regulations (EU) 2017/745 or 2017/746, and agrees the scope of the assessment in writing. The regulatory lead and the notified body agree the document set, sampling approach and interview plan. The output is a signed assessment agreement and a document request list. Ask the notified body for its timeline and fee structure in writing, since these vary by body and by device class, and do not plan around any duration from a third party.
Respond to findings and resolve nonconformities
The notified body reviews the file and issues findings that the provider must answer with corrective evidence, updated documents or changes to the product. Engineering, clinical and quality staff each own their response items, and the regulatory lead tracks every finding to closure. The output is a findings log showing each item, the corrective action, the evidence supplied and the notified body's acceptance. Keep the log under document control, since the assessor may re-check closed items during later reviews.
Maintain post-market monitoring and incident reporting
After the conformity assessment, the provider runs post-market monitoring, collects performance and field data, and handles serious incidents under the reporting rules. For medical devices under Regulations (EU) 2017/745 and 2017/746, Article 73(9) and (10) limit AI Act notification to infringements of fundamental rights obligations, so device incident reporting continues under sectoral law. The output is a monitoring plan, a periodic review record and an incident log that feeds back into the technical file. Confirm with your notified body and competent authority which reporting route applies to each event.

Incident reporting under device law and the AI Act

For a medical device that contains AI, the first rule to map is that the device reporting channel remains the main route for device incidents. Article 73 of the AI Act requires providers of high-risk AI systems to report serious incidents to market surveillance authorities, but for providers under equivalent Union reporting regimes, and for medical devices under Regulations (EU) 2017/745 and 2017/746, the AI Act notification is limited to infringements of fundamental rights obligations, as set out in Article 73(9) and (10). In practice, a patient harm or device malfunction is still reported through the existing medical device vigilance process, and the AI Act adds a separate notification only where a fundamental rights breach is involved. Confirm with your notified body and competent authority how they expect the two channels to be coordinated for your device class.

The incident response plan should therefore show both routes as separate branches with named owners. The quality or regulatory affairs lead should decide, within the device vigilance timelines, whether an event is a reportable device incident, and the AI compliance owner should decide whether it also engages a fundamental rights obligation. Engineering needs to be able to pull the logs, model version, training data reference and performance records that either report will need, so the plan should name the systems that hold them and the person who can export them. Ask your vendor which of these artifacts they retain and for how long, because a provider that cannot reconstruct a model version will struggle with either route.

The Commission's draft guidance and reporting template on serious AI incidents, published on 26 September 2025 for consultation, is a draft to track, not a final rule. Its definitions and reporting format may change before adoption, so build the plan so that fields can be updated without redesigning the process. Review the Commission's consultation page on serious AI incidents at each planning review, and record which version of the guidance your plan follows. Any outside consultant or implementation partner can prepare the runbooks and evidence, but the reports themselves are issued by the organization to the relevant authority.

Who is paid for what in AI Act health compliance

This table compares the main cost components of AI Act compliance for healthcare and medical device AI, showing who is paid, whether the cost is one-time or recurring, and what drives it up. No supplied source gives fees or durations, so use it to frame quote requests rather than to estimate budgets. Ask each payee for a written quote that follows from a written scope.

Cost component	Who is paid	One-time or recurring	What drives it
Notified body or assessor fees for the sectoral conformity assessment	The notified body or conformity assessment body under the sectoral legislation (Regulations (EU) 2017/745 and 2017/746 for medical and IVD devices)	Mostly one-time per assessment, with recurring surveillance and re-assessment after significant changes	Device class, number of AI functions in scope, completeness of the technical file, and how many review rounds occur
Internal QMS and technical file staff	Your own regulatory affairs, quality, clinical and engineering staff, or contractors you hire	Recurring, because the quality management system and technical documentation must be kept current	Number of AI-enabled products, release frequency, and how much documentation already exists under device law
Implementation partner preparing systems and evidence	An implementation partner such as DeployOpen, under a fixed-scope written agreement	One-time for the initial build, with optional recurring retainers for upgrades and evidence upkeep	Number of systems in scope, state of logging and access controls, and whether hosting is self-managed in your own infrastructure
Tooling for logging, risk and documentation	Software vendors, open-source project maintainers (through support contracts), or your own infrastructure team	Licences or hosting recur. Initial configuration is one-time	Log retention needs, number of users, self-hosted versus managed deployment, and integration with device quality systems
Post-market monitoring and incident handling	Your internal pharmacovigilance, vigilance and quality teams, plus any outsourced monitoring service	Recurring for as long as the device is on the market	Volume of field data, incident frequency, and the reporting duties under device law and Article 73 of the AI Act
Legal review of classification	External counsel or regulatory consultants, billed by scope or hours	One-time for the initial classification, with repeat review when intended purpose or the Annex changes	Number of AI functions, whether a function is a safety component or a stand-alone product, and reliance on draft Commission guidance

Who owns the file, who prepares it, and who issues the certificate

Your organization remains the legal manufacturer or provider. For an AI system that is a safety component of a medical or in vitro diagnostic device, you hold the obligations under the AI Act and the sectoral device legislation, and you alone make the decisions that those obligations depend on. No partner or assessor can take these over.

Quality management system: You define, run and own the QMS that covers the AI Act requirements and the sectoral device requirements, including roles, approvals and management review.
Risk management and clinical decisions: You decide intended purpose, acceptable residual risk, clinical performance claims and the evidence base for them.
Technical and design decisions: You choose the model, data sources, human oversight design and the criteria for putting the system on the market or withdrawing it.
The declaration: You sign the EU declaration of conformity and keep the single technical documentation set current after every substantial change.
Incident reporting: You decide and file reports under device law and, where applicable, the AI Act.

Before engaging anyone, confirm internally which named person signs each of these decisions.

What must be in place before the notified body reviews the file

A notified body or other conformity assessment body will not start from a blank page. The items below are the records that must exist, be consistent with each other and be traceable before the review begins. Check each one against the device file, not against a slide deck describing intent.

Classification memo for each AI function

Each AI function in a device or service needs a written memo that explains whether it is a safety component of an Annex I product, whether it is itself a product covered by Annex I legislation, and whether it falls under Annex III, such as emergency healthcare patient triage or benefit eligibility. The memo should cite the Article 6 route used and state why any Article 6(3) exemption does or does not apply. Check that the memo names the sectoral legislation and that the conclusion matches the intended use in the labeling.

AI inventory linked to devices and services

The inventory lists every model, algorithm and AI-enabled function, its version, its training and deployment sites, and the device or clinical service it belongs to. Each entry should point to the classification memo, the sectoral conformity route and the owner accountable for updates. Check that the inventory matches the device master file and that no function in production is missing from it, including vendor-supplied components whose behavior you can change through configuration.

Risk management and QMS records

The quality management system must cover the AI-specific risk process, including hazard identification, risk estimation, risk controls and residual risk review, and it must connect to the existing medical device risk file. Keep dated records of design reviews, change control decisions and corrective actions. Check that each identified AI risk maps to a control and a verification result, and that the QMS procedures are the ones actually followed in the records you show an assessor.

Data governance and training data documentation

Document where training, validation and test data came from, how it was labeled, how representative it is of the intended patient population, and how known gaps and biases were handled. Keep the data lineage traceable from source to the model version shipped. Check that test datasets were kept separate from training data, that data access logs exist for clinical records, and that personal data handling is consistent with the GDPR records held by the organization.

Logging and human oversight evidence

Logs must show which model version produced each output, the inputs needed to reconstruct it, and when clinicians overrode or accepted a recommendation. Human oversight must be designed into the workflow and proven with records, such as training completion for operators and tests of override functions. Check that logs are retained for the period your device file states, that they are tamper-evident, and that a clinician can explain how the oversight step works in practice.

Post-market monitoring plan

The plan describes how the organization will collect performance data, complaints and field incidents after the device is placed on the market, and how it will detect drift in model behavior. It should set out who reviews signals, how updates are validated before release, and when a serious incident is reported under device law. Note that for medical devices, notification under the AI Act is limited to fundamental rights infringements (Article 73(9) and (10)). Check that the plan links to the existing vigilance process rather than running in parallel.

Questions health organizations ask about the EU AI Act

Does the AI Act apply to a hospital using a third-party diagnostic tool?

Often yes, but the hospital's role decides which duties it carries. Article 2 applies the Act to deployers established in the EU, so a hospital that uses the tool under its own authority is a deployer. Whether the tool is high-risk depends on the product. If it is a medical or in vitro diagnostic device covered by Annex I that needs third-party conformity assessment under device law, Article 6(1) applies and the high-risk rules take effect on 2 August 2028. The hospital takes on provider duties only if it places the tool on the market under its own name or changes it substantially, a point to confirm with counsel. Before go-live, ask the vendor in writing for the intended purpose, the device classification and its AI Act position. Hospitals usually keep the operational duties, such as human oversight, logs and following the provider's instructions for use.

Is a clinical decision support tool high-risk under the AI Act?

It is high-risk only when a specific route in Article 6 or Annex III applies, and the route depends on how the tool is regulated. Under Article 6, an AI system is high-risk when it is a safety component of a product, or is itself a product, covered by Annex I legislation that requires third-party conformity assessment. Medical devices and in vitro diagnostic devices sit in Annex I Section A, so software that qualifies as a device under Regulations (EU) 2017/745 and 2017/746 usually follows this route. Separately, Annex III point 5(d) covers emergency healthcare patient triage, and Annex III point 5(a) covers public authority decisions on eligibility for essential healthcare services. A tool that only supports clinician judgment outside those categories may fall outside high-risk status, but that conclusion needs a documented analysis against the Article 6 wording and the Commission's draft classification guidelines of 19 May 2026.

What is the single technical file for an AI medical device?

It is one set of technical documentation that covers both the AI Act requirements and the sectoral device information, so assessors review one dossier instead of two. Article 11(2) requires this single set for systems related to Annex I Section A products. Annex IV sets out the content the AI Act expects, including the system description, the design and development process, data governance, monitoring and the quality management system evidence. Under Article 43(3), the AI Act requirements and the Article 17 quality management system are assessed as part of the sectoral conformity assessment. In practice, the manufacturer keeps the file current across the product lifecycle, links each AI requirement to a section of the device file and makes sure the notified body can trace evidence to each claim. Many teams build it from existing device documentation, and the gaps are often in data governance, logging and post-market monitoring evidence.

Does the 2028 date change existing medical device certificates?

The 2028 date changes when the AI Act's high-risk rules apply to AI in these products. It does not, by itself, change the validity of certificates issued under device law. As amended in 2026, Article 113 applies the high-risk rules to Article 6(1) and Annex I systems from 2 August 2028, instead of 2 August 2027. A device certificate already issued under Regulations (EU) 2017/745 or 2017/746 remains governed by its own terms and renewal cycle. However, a change to the AI function, its intended purpose or its training approach may require a new conformity assessment, and the notified body decides that. Manufacturers should map each AI feature to its certificate, record which changes need notified body review and ask each notified body how the AI Act assessment will be added at the next change or renewal. Request that position in writing.

Who pays the notified body for AI Act conformity assessment in healthcare?

The manufacturer or provider pays the notified body under its own contract, and the hospital deployer usually does not. The notified body sets its fee from the written scope, so the amount depends on the device class, the number of AI functions in scope, the volume of documentation to review and whether the manufacturer already holds certificates from the same body. Costs fall into one-time items, such as the initial assessment, and recurring items, such as surveillance activities, certificate maintenance and reassessment after significant changes. No fee figure is supplied here, so ask each notified body for a written quote that separates the AI Act assessment from the device assessment, lists the review steps and states what triggers re-review. Also ask how the single technical file will be reviewed. Good internal preparation can reduce rework during review, but it does not replace the notified body's fee.

Can our team prepare the AI Act evidence ourselves?

Yes, most of the preparation can be done in-house, and the organization keeps ownership of its controls either way. The manufacturer or hospital owns its controls, an implementation partner prepares systems, documentation and evidence, and only an independent notified body or auditor issues certificates or reports. Teams with device quality management experience usually start with the single technical file, the logging and traceability design, the human oversight procedures and the post-market monitoring plan, because these produce the evidence assessors test. The work becomes heavy for teams without AI engineering or regulatory writing capacity, and it recurs when models or data change. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure and prepares evidence for assessment, but it does not issue audit reports or certificates. Scope, deliverables and timelines are agreed in writing before work starts.

When must we report AI incidents for a medical device?

For medical devices under Regulations (EU) 2017/745 and 2017/746, the AI Act notification duty is limited to infringements of fundamental rights obligations, as set out in Article 73(9) and (10). The incident reporting that device law already requires remains the main route, and the AI Act adds a narrower duty for fundamental rights breaches. Article 73 sets the general serious incident rules for high-risk systems. The Commission's draft guidance and reporting template on serious AI incidents, published on 26 September 2025, shows the expected content. Hospitals acting as deployers should agree with the manufacturer how they will pass on suspected incidents, who triages them and how logs are kept. Confirm with your notified body and competent authority which reporting channel applies to each product before go-live.

How to choose a partner for the health AI file

Start by separating three roles that buyers often blur together. A notified body is an independent conformity assessment body designated under the sectoral device law, and it is the party that assesses and certifies the device. A regulatory consultant advises on how the AI Act and device rules apply to your product and reviews your documents. An implementation partner builds or hardens the systems that produce the evidence, such as logging, version control, data pipelines and test environments. Before you sign anything, confirm the notified body's designation for the specific device law that covers your product, whether that is the medical device or in vitro diagnostic regulation, and check the designation scope in the official register rather than relying on the body's own marketing. Then ask whether it will assess AI-specific evidence, such as training data governance, performance metrics, drift monitoring and human oversight, or whether that work will fall outside its assessment.

Request scope and deliverables in writing from every party before work starts. For an implementation partner, the written scope should list the systems covered, the evidence each deliverable produces, the single technical file sections the partner will prepare, who signs off on each section, and what the organization still has to decide. Ask for the list of items the partner will not touch, such as clinical evaluation, risk management decisions and the declaration of conformity, because those remain with the manufacturer. Ask which open-source components the partner will deploy in your environment and who will maintain them after handover. Vendors and consultants should be able to describe this without referring to outcomes they cannot control.

Check that the partner does not claim to issue certificates, reports or attestations. Only a notified body or another independent certification body can certify a device conformity assessment, and only an accredited or independent auditor can issue audit reports. A partner that promises a certificate, a CE marking or a "compliant" status on its own authority is describing a role it does not hold. Ask for the partner's written statement of its role in the file, and make sure your contract assigns ownership of the technical file to your organization. Plan for the notified body's own timeline and fees, which you should obtain directly from the body, since they are not set by the partner.

How DeployOpen works on this

DeployOpen helps health organizations and medical device manufacturers prepare AI systems and the evidence that supports EU AI Act assessments, inside their own infrastructure. We plan and implement the technical side, while the organization keeps ownership of its controls and independent assessors issue any conformity outcome.

How we scope

Map which AI systems fall under Article 6(1) with Annex I medical or in vitro diagnostic legislation, and which fall under Annex III health uses.
Agree in writing which systems, environments, logs and documents the engagement covers before work starts.
Confirm with your notified body or sectoral assessor which technical documentation and quality management evidence they expect.

How we build

Deploy and harden self-hosted open-source platforms for model registries, logging, monitoring and access control in your own cloud or data center.
Structure one technical file that combines AI Act documentation with the sectoral device information, so evidence is not duplicated.
Run security testing on AI systems and their APIs, and document the findings and remediation alongside the technical file.

How we hand over

Deliver configured systems, runbooks and evidence packs mapped to the documentation items your assessor will request.
Document incident detection and escalation paths so reporting under device law and the AI Act can be followed.
Provide training for the staff who will operate, monitor and update the systems after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Retainers can cover updates to the technical file when a system changes, and periodic re-testing of AI components.
Ask any partner to confirm in writing which responsibilities stay with your organization and which are performed by an independent assessor.