AI Symptom Checker Medical Device Classification Under the EU AI Act

Classification starts with intended purpose

The Commission's AI Act FAQ states that risk classification is based on the intended purpose of the AI system, in line with existing EU product safety legislation. It depends on the function performed and on the specific purpose and modalities of use. The technology is not the test. The same conversational front end can sit on either side of the boundary depending on what it is for and how it is used.

The Commission's position on self-help chatbots shows the reasoning. Chatbots that fulfil the definition of a medical device are subject to the requirements and controls of the Medical Device Regulation. A chatbot marketed as addressing specific mental health conditions or guiding users through therapeutic interventions would likely fall within the MDR, as software intended for the treatment or alleviation of disease under Article 2(1). That guidance addresses mental health chatbots, not symptom checkers specifically. Applying it to a symptom checker is an analogy that legal and regulatory counsel need to confirm.

The practical lesson is that marketing and positioning count as evidence of purpose. The claims made in labelling, product pages and user-facing copy belong in the classification record alongside the technical description. A symptom checker described as helping users understand possible conditions reads differently from one described as general health information, even when the model is identical.

Annex I device pathway versus Article 50 chatbot

The two outcomes carry different obligations and different operational demands. The table summarizes what the Commission's materials support. Dates are as of November 2026 and may change if the Digital Omnibus on AI is formally adopted.

• Trigger: Device pathway: the software meets the medical device definition under the MDR. Chatbot pathway: it does not meet that definition and other self-help chatbots mostly fall outside the listed Annex III use cases.
• Primary obligations: Device pathway: MDR requirements and controls, with AI Act high-risk requirements alongside. Chatbot pathway: Article 50 disclosure obligations, which the Commission says may at least partly mitigate risks to informed decision-making.
• High-risk requirements: Device pathway: a documented risk management system, human oversight by design, records and technical documentation. Chatbot pathway: these are not the core framework.
• Timing: Device pathway: the Commission FAQ says rules on AI embedded in medical devices apply from 2 August 2028. The Digital Omnibus on AI, proposed on 19 November 2025 with a provisional agreement on 7 May 2026, concerns high-risk timing, and its formal adoption should be checked.
• Runtime emphasis: Device pathway: behavior stays within the declared intended purpose, with oversight and approval paths. Chatbot pathway: behavior stays informational, with no drift into diagnostic or triage output.
• Determination owner: Both pathways: legal and regulatory functions decide classification. Engineering and tooling implement and evidence it.

How runtime behavior moves a system across the boundary

A declared classification is a statement about intended purpose. Production behavior is a separate fact. A system declared informational can begin to behave like a device if its outputs change. Three kinds of output deserve particular attention: diagnostic statements that name or rank likely conditions, triage recommendations that tell a user how urgently to seek care, and treatment suggestions. General information about symptoms or conditions is a different category.

Drift can come from several directions: a model update, a prompt change, new retrieval content, or a marketing claim that outgrows the documented purpose. Under the Commission's reasoning, a change in purpose or claims could move a system across the MDR boundary. That makes ownership important. Someone should be accountable for approving changes to intended purpose, marketing claims and model behavior, and each change should trigger a review of the classification record.

The point for compliance leaders is that documentation reviewed after the fact only describes what was intended. If an informational system produced a triage recommendation last Tuesday, a policy document does not show whether that happened or what was done about it. Enforcement at the point of each interaction, with a record of the outcome, closes that gap.

Where Trussed fits, and where it does not

Trussed enforces policy in the execution path on individual interactions. For a symptom checker declared informational, that means diagnostic-style outputs can be blocked or redacted at runtime, not reviewed after the fact. For a system on the device pathway, outputs can be allowed within the declared purpose, with escalation for human approval. Each enforcement decision generates audit-ready evidence, mapped to the EU AI Act among other frameworks, and the evidence is retained under configurable retention and data residency settings in a self-managed deployment in the customer cloud.

Trussed does not decide whether software is a medical device, whether a system is high-risk, or whether a conformity assessment or CE marking is required. Those are legal and regulatory determinations for the regulated enterprise and its advisers. Enforcement makes a declared classification operational and provable. It does not replace the decision behind it.