Regulatory literacy around AI tools has not kept pace with their adoption in primary care. General Practitioner practices across the EU are trialling and deploying AI-powered tools at speed — for documentation, triage support, clinical coding, and decision support — often without a clear understanding of whether those tools are regulated medical devices under EU Medical Device Regulation, and what that classification means for the practice itself. The consequences of getting this wrong are not theoretical: deploying an unclassified tool that should carry CE marking exposes a practice to liability, and the obligations that fall on the practice as an 'operator' are more substantial than most practice managers realise. This article explains the regulatory framework in plain terms and gives healthcare decision makers a practical basis for evaluating any AI tool before deployment.

The core distinction: medical device vs. productivity tool

The most important question to ask about any AI tool is whether it influences clinical decisions or patient outcomes, or whether it simply reduces administrative work. This distinction determines the entire compliance pathway.

Under EU Medical Device Regulation (MDR), software intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease is likely classified as a medical device. Software that only automates documentation, formats notes, generates patient letters, or assists with scheduling generally is not. The difference is not always obvious from a product's marketing materials, and that ambiguity is precisely where regulatory risk concentrates.

A concrete example: an ambient voice tool that transcribes a consultation and formats it into a structured clinical note, with the clinician reviewing and approving the output, is typically not a medical device. A tool that analyses that same consultation and suggests a differential diagnosis, recommends a referral, or flags a drug interaction is very likely subject to MDR obligations. The same underlying technology can sit on either side of this line depending on what it is designed and marketed to do.

How EU MDR defines a software medical device

EU MDR 2017/745, Article 2, defines a medical device to include software when that software is intended by the manufacturer for a medical purpose. The MDCG 2019-11 guidance on software qualification and classification — substantially revised in 2025 to explicitly address AI — provides the operative framework for determining whether a given piece of software qualifies as Medical Device Software (MDSW) or, more specifically, as Medical Device AI (MDAI).

The key criterion is 'intended purpose': what the software is designed, labelled, and marketed to do. A vendor cannot simply assert that their tool is not a medical device if the way it is promoted implies a clinical function. MDCG 2025-6, published in June 2025, confirmed that the intended purpose, including how a tool is described in promotional materials, is legally determinative, not just the underlying technical architecture.

The revised MDCG 2019-11 guidance also explicitly addresses AI-specific examples and considers interoperability with medical record systems under the European Health Data Space, which is directly relevant to GP practices integrating AI tools into existing clinical systems.

The three risk classes that determine what a GP practice must verify

EU MDR uses a tiered classification system under Annex VIII, Rule 11, which applies specifically to software. The risk class assigned to an AI tool determines the conformity assessment route the vendor must follow, and therefore what a GP practice needs to verify before deployment.

• Class I: Software that does not influence clinical decisions in a way that could harm the patient. These devices require a self-declaration of conformity by the manufacturer; no Notified Body is involved. Per MDCG 2025-6, Class I devices are not considered high-risk MDAI under the AI Act.

• Class IIa: Software intended to provide information used to make decisions with diagnosis or therapeutic purposes for serious conditions, or where errors could cause significant harm. Notified Body involvement is required for conformity assessment.

• Class IIb: Software intended to provide information used to make decisions with diagnosis or therapeutic purposes for life-threatening diseases or chronic conditions causing permanent impairment, or to monitor vital physiological parameters where variation could result in immediate danger.

• Class III: Software implicated in decisions that, if incorrect, could directly cause death or irreversible deterioration of health.

In a GP context, clinical decision support tools that generate differential diagnoses, risk stratification outputs, or referral recommendations are typically Class IIa or higher, requiring Notified Body involvement and CE marking. The 2025 revision of MDCG 2019-11 broadened the Rule 11 interpretation to consider the degree of software autonomy and its role in primary versus supportive diagnostics, meaning tools that were previously borderline may now fall into a higher class.

A peer-reviewed case study of the Aireen diabetic retinopathy screening AI, which achieved MDR 2017/745 compliance and CE marking before market entry in 2023, illustrates the depth of clinical validation required: a multi-site clinical trial involving over a thousand patients, with physicians involved at every stage from intended use definition through risk analysis and software validation. This is the standard a GP practice should expect a regulated AI medical device to have met.

What CE marking means for an AI tool, and what it doesn't

CE marking under EU MDR signals that a vendor has completed a conformity assessment appropriate to the device's assigned risk class. For Class IIa and above, this means a Notified Body has reviewed the technical file and clinical evidence. It is a meaningful threshold, but it is not a blanket assurance of clinical validity across every use case or care setting.

The scope of a CE mark matters. A tool may be CE-marked for use as a diagnostic aid in secondary care dermatology but not validated for use in a GP setting. A practice deploying that tool outside its certified intended purpose is not protected by the CE mark and may itself be operating outside the regulatory framework.

Decision makers should look beyond the presence of CE marking to understand its scope: which patient population, which clinical context, and which specific functions are covered. This information should be available in the vendor's Declaration of Conformity and, at a summary level, in the Instructions for Use.

The regulatory obligations that fall on the GP practice, not just the vendor

A widespread misconception among GP practices is that regulatory responsibility for an AI tool rests entirely with the software vendor. Under EU MDR, this is not the case. The practice, as the 'operator' deploying the tool, carries its own obligations, and under the AI Act's terminology, the MDR 'user' maps directly to the AI Act 'deployer', a role with explicit compliance duties.

Operator obligations under EU MDR include:

• Deployment-readiness review: Confirming the tool is used only within its certified intended purpose and in the clinical context for which it was validated.

• Record-keeping: Maintaining a register of which regulated AI tools are deployed, including their classification and CE status.

• Staff training: Ensuring clinicians and administrative staff understand the tool's intended use, its limitations, and when not to rely on its outputs.

• Incident reporting: Reporting serious incidents, including near-misses that could have caused patient harm, to the relevant national competent authority.

• Post-market vigilance: Monitoring for safety signals and updating deployment practices if the vendor issues safety notices or updates the tool's intended purpose.

These are not discretionary. A GP practice that deploys a regulated AI tool without meeting these obligations is non-compliant regardless of the vendor's own certification status.

Documentation a GP practice needs before deploying any AI tool

Before signing a contract or beginning a pilot deployment, GP practices should request and retain the following documentation from any AI vendor:

• Declaration of Conformity (for regulated medical devices) or a written, reasoned classification rationale explaining why the tool is not a medical device.

• CE certificate including its scope, the issuing Notified Body (for Class IIa and above), and expiry date.

• Intended purpose statement: The vendor's formal description of what the tool is designed to do, for which patients, and in which clinical context.

• Clinical evidence summary: A summary of the clinical data supporting the tool's performance claims, including the population and setting in which they were established.

• Data Processing Agreement: Required under General Data Protection Regulation (GDPR); should specify where patient data is processed and stored, and the legal basis for processing.

• Post-market surveillance commitments: How the vendor monitors real-world performance and communicates updates or safety signals to operators.

These documents exist because the vendor is required to produce them. A vendor unable or unwilling to provide them is itself a compliance signal.

High-risk scenarios: AI tools that are likely regulated medical devices in primary care

The following categories of AI tools are most likely to carry MDR obligations in a GP context, and warrant the highest level of scrutiny before deployment:

• Clinical decision support generating differential diagnoses: Any tool that analyses patient data and produces a ranked list of possible diagnoses is almost certainly MDSW, likely Class IIa or higher.

• Risk stratification tools: Tools that assign patients a risk score for a specific condition (for example, cardiovascular risk or cancer risk) and use that score to recommend clinical action.

• Automated triage systems: AI that determines urgency or directs patients to a care pathway based on symptom input, without mandatory clinician review at the point of decision.

• Prescription or referral recommendation tools: Any tool that suggests a specific medication, dose, or referral destination based on patient data.

• Diagnostic image analysis: Tools that analyse retinal images, skin photographs, electrocardiograms, or other diagnostic outputs to identify pathology.

Diagnostic software, clinical decision support tools, and AI-enabled medical devices are largely classified as high-risk under both MDR and the AI Act, triggering mandatory conformity assessment, data quality requirements, and human oversight obligations.

Lower-risk scenarios: AI tools that typically fall outside MDR scope

The following categories of AI tools generally do not constitute medical devices under EU MDR, because they do not perform a medical function. They support administrative or documentation workflows, with the clinician retaining full clinical authority:

• Ambient voice technology for clinical documentation: Tools that transcribe a consultation and format the output as a structured clinical note, where the clinician reviews, edits, and approves the content before it enters the record.

• AI-assisted patient letters: Tools that draft letters based on clinician-provided information, without generating clinical recommendations.

• Administrative summarisation: Tools that condense referral letters, discharge summaries, or prior correspondence to reduce reading time.

• Clinical coding suggestion tools: Tools that propose SNOMED or ICD codes based on note content, where the clinician makes the final coding decision.

Even for tools in these categories, vendors should provide a written classification rationale, a documented explanation of why the tool does not meet the definition of MDSW. The absence of such documentation is not reassurance; it is a gap.

There is also a practical limitation worth noting in the current regulatory landscape. The high cost of MDR certification and the shortage of Notified Bodies in the EU has led some software manufacturers to remove clinical functionalities from their tools specifically to avoid medical device classification. GP practices should be alert to tools that appear to have clinical utility but are marketed with conspicuous disclaimers about not being intended for clinical decision-making. This may reflect regulatory positioning rather than genuine product design.

How to evaluate a vendor's regulatory claims before signing a contract

Vendor regulatory claims vary considerably in quality and accuracy. The following questions help procurement leads and practice managers conduct meaningful due diligence:

On classification:

• Is this tool classified as a medical device under EU MDR? If not, can you provide a written classification rationale?

• If it is a medical device, what is its risk class, and which Notified Body issued the CE certificate?

On evidence:

• What clinical evidence supports the tool's performance claims? In which patient population and care setting was that evidence generated?

• Has the tool been validated specifically for use in primary care or GP settings?

On intended purpose:

• What is the formal intended purpose statement? Does our planned use case fall within that scope?

On regulatory status:

• Is the CE certificate current? What is its expiry date?

• Are you registered with the relevant national competent authority?

On the AI Act:

• Is this tool considered high-risk under the EU AI Act? If so, what conformity assessment has been completed?

The phrase 'we are working toward CE marking' is not equivalent to holding it. A tool without CE marking that should be a regulated medical device cannot be legally deployed in the EU, regardless of how promising its capabilities appear. MDCG 2025-6 confirmed that manufacturers of MDAI must meet obligations under both MDR and the AI Act via integrated quality management and risk management frameworks. 'In progress' is not a compliant state.

National competent authorities and where to escalate uncertainty

Each EU member state has a national competent authority responsible for MDR oversight and enforcement. These include BfArM in Germany, ANSM in France, HPRA in Ireland, and equivalent bodies in other member states. National competent authorities maintain registers of authorised medical devices and can provide guidance on classification questions.

GP practices facing genuine uncertainty about whether a specific tool requires MDR compliance, particularly in borderline cases where a vendor's classification rationale is ambiguous, can approach their national competent authority for guidance rather than making a unilateral deployment decision. This is preferable to proceeding on the basis of an incomplete or self-serving vendor declaration.

The consequences of deploying an unclassified tool that should be regulated include potential enforcement action by the national competent authority, liability in the event of patient harm, and, under the AI Act's extended obligations, deployer-level penalties that fall on the practice itself, not only the vendor.

The AI Act's phased implementation timeline is also relevant to planning. Full high-risk obligations apply from August 2026, with an extended transition to August 2027 for AI systems already regulated as medical devices under MDR or IVDR. This August 2027 deadline applies specifically to AI systems already on the market under those regulations; newly deployed high-risk AI systems not previously regulated under MDR or IVDR face the August 2026 obligations. Practices deploying new tools now should assume full obligations are imminent.

Building a simple AI governance framework for your GP practice

GP practices do not need a dedicated regulatory team to manage AI tool compliance, but they do need a repeatable process. A lightweight governance framework covers four areas:

Classification review before deployment

For every AI tool under consideration, document whether it is a medical device, its risk class, the status of its CE marking, and the scope of that marking. Complete this review before any pilot begins, not after.

Approval and record-keeping

Maintain a register of all AI tools in use, including their regulatory status, the date of deployment, and the name of the person responsible for monitoring compliance. Update this register when tools are updated or their intended purpose changes.

Staff training

Ensure that all staff using an AI tool understand its intended purpose, its limitations, and the boundaries of appropriate reliance. For regulated medical devices, training requirements may be specified in the Instructions for Use.

Incident logging and periodic reassessment

Establish a process for logging incidents, including near-misses, where an AI tool's output may have contributed to a patient safety concern. Review the register of deployed tools at least annually, and reassess classification whenever a vendor updates the tool's functionality or marketing materials, since intended purpose, including how a tool is marketed, is legally determinative under EU MDR.

This framework does not need to be complex. It needs to be documented, consistently applied, and updated as the regulatory environment and the tools themselves change.

Frequently asked questions

▶ How do I know if an AI tool used in my GP practice is a regulated medical device under EU MDR?

The key question is whether the tool influences clinical decisions or patient outcomes. Under EU Medical Device Regulation 2017/745, software intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease is likely classified as a medical device. A tool that only transcribes consultations, drafts patient letters, or formats clinical notes generally is not. The same underlying technology can sit on either side of this line depending on what it's designed and marketed to do, so the vendor's intended purpose statement is the starting point for any classification review.

▶ What are the MDR risk classes for AI software, and which applies to clinical decision support tools?

EU MDR uses a tiered classification system under Annex VIII, Rule 11, specifically for software. Class I covers software that doesn't influence clinical decisions in a way that could harm the patient, and requires only a manufacturer's self-declaration. Class IIa covers software that informs decisions for serious conditions, and requires Notified Body involvement. Class IIb applies to software used in decisions about life-threatening or chronically impairing conditions. Class III covers software implicated in decisions that, if incorrect, could directly cause death or irreversible harm. In a GP context, clinical decision support tools that generate differential diagnoses, risk stratification outputs, or referral recommendations are typically Class IIa or higher.

▶ What does CE marking on an AI medical tool actually confirm, and what doesn't it cover?

CE marking signals that a vendor has completed a conformity assessment appropriate to the device's assigned risk class. For Class IIa and above, a Notified Body has reviewed the technical file and clinical evidence. It's a meaningful threshold, but it's not a blanket assurance of clinical validity across every use case or care setting. A tool may be CE-marked for use in secondary care dermatology but not validated for a GP setting. Deploying that tool outside its certified intended purpose means the practice isn't protected by the CE mark. The scope of the mark, covering which patient population, which clinical context, and which specific functions, should be confirmed in the vendor's Declaration of Conformity and Instructions for Use.

▶ What compliance obligations fall on a GP practice when deploying a regulated AI tool?

Regulatory responsibility doesn't rest solely with the software vendor. Under EU MDR, the practice as the 'operator' carries its own obligations. These include confirming the tool is used only within its certified intended purpose, maintaining a register of deployed regulated AI tools and their classification status, ensuring all staff understand the tool's intended use and limitations, reporting serious incidents including near-misses to the relevant national competent authority, and monitoring for safety signals from the vendor. These obligations apply regardless of the vendor's own certification status, and a practice that doesn't meet them is non-compliant.

▶ Which AI tools used in primary care are most likely to require MDR certification?

The categories that warrant the highest level of scrutiny before deployment include: clinical decision support tools that generate differential diagnoses, risk stratification tools that assign patients a condition-specific risk score and recommend clinical action, automated triage systems that direct patients to a care pathway without mandatory clinician review, prescription or referral recommendation tools, and diagnostic image analysis tools that identify pathology in retinal images, skin photographs, or electrocardiograms. These are largely classified as high-risk under both EU MDR and the EU Artificial Intelligence Act, triggering mandatory conformity assessment, data quality requirements, and human oversight obligations.

▶ Which AI tools in GP practices typically fall outside the scope of EU MDR?

Tools that support administrative or documentation workflows, with the clinician retaining full clinical authority, generally don't constitute medical devices. These include ambient voice technology that transcribes a consultation and formats a structured clinical note for clinician review and approval, AI-assisted patient letter drafting based on clinician-provided information, administrative summarisation of referral letters or discharge summaries, and clinical coding suggestion tools where the clinician makes the final coding decision. Even for these tools, vendors should provide a written classification rationale explaining why the tool doesn't meet the definition of Medical Device Software. The absence of that documentation is itself a compliance signal.

▶ What documents should a GP practice request from an AI vendor before deployment?

Before signing a contract or beginning a pilot, practices should request and retain: a Declaration of Conformity for regulated medical devices, or a written classification rationale explaining why the tool isn't a medical device; the CE certificate including its scope, the issuing Notified Body for Class IIa and above, and expiry date; the vendor's formal intended purpose statement; a clinical evidence summary covering the population and setting in which performance was established; a Data Processing Agreement specifying where patient data is processed and stored and the legal basis under General Data Protection Regulation; and the vendor's post-market surveillance commitments. A vendor unable or unwilling to provide these documents is itself a compliance signal.

▶ What questions should a GP practice ask a vendor to evaluate their regulatory claims?

On classification, ask whether the tool is classified as a medical device under EU MDR, and if not, request a written classification rationale. If it is a medical device, confirm the risk class and the Notified Body that issued the CE certificate. On evidence, ask what clinical data supports the tool's performance claims, in which patient population and care setting that evidence was generated, and whether the tool has been validated specifically for primary care or GP settings. On regulatory status, confirm the CE certificate is current and ask whether the vendor is registered with the relevant national competent authority. On the EU Artificial Intelligence Act, ask whether the tool is considered high-risk and what conformity assessment has been completed. The phrase 'we are working toward CE marking' is not equivalent to holding it.

▶ What is the EU AI Act timeline that GP practices need to plan for?

Full high-risk obligations under the EU Artificial Intelligence Act apply from August 2026. An extended transition to August 2027 applies specifically to AI systems already on the market and regulated as medical devices under EU MDR or the In Vitro Diagnostic Regulation. Newly deployed high-risk AI systems not previously regulated under those frameworks face the August 2026 obligations. Practices deploying new tools now should assume full obligations are imminent and plan accordingly.

▶ What should a GP practice do if it's uncertain whether a specific AI tool requires MDR compliance?

Practices facing genuine uncertainty, particularly where a vendor's classification rationale is ambiguous, can approach their national competent authority for guidance rather than making a unilateral deployment decision. Each EU member state has a national competent authority responsible for MDR oversight: BfArM in Germany, ANSM in France, HPRA in Ireland, and equivalent bodies elsewhere. These authorities maintain registers of authorised medical devices and can advise on classification questions. Proceeding on the basis of an incomplete or self-serving vendor declaration carries real risk: deploying an unclassified tool that should be regulated can result in enforcement action, liability in the event of patient harm, and deployer-level penalties under the AI Act that fall on the practice itself.