Adding autonomous AI features to a health product is an engineering decision that quickly becomes a regulatory one. Here’s where the line sits and how to build on the right side of it.

When a patient asks your app to reschedule a therapy session and the AI does it, that is a routine feature. When the AI adjusts a care plan based on mood data and sends a push notification to the patient’s psychiatrist, the conversation changes both with your users and with your notified body.

The shift from AI that suggests to AI that acts is what product teams in digital health are working through right now. The engineering lift is often small, but the regulatory implications are substantial.

Agentic AI in healthcare refers to software that doesn’t just analyze data or surface recommendations, it takes autonomous actions: scheduling appointments, sending clinical alerts, updating care records, or triggering follow-ups without waiting for a human to confirm each step. Unlike traditional clinical decision support, an agentic system closes the loop itself. That distinction is exactly what makes it harder to classify.

What MDR actually asks?

Under EU Medical Device Regulation (MDR 2017/745), the classification trigger isn’t „does this use AI.” It’s whether the software is intended by the manufacturer for a medical purpose. That phrase, intended purpose, does a lot of work.

If your AI feature provides information used to take decisions „with diagnosis or therapeutic purposes,” you’re already in scope under Annex VIII Rule 11, which puts you at Class IIa minimum and requires a Notified Body assessment. Self-certification is not an option at that point.

Autonomy makes this harder. A feature that surfaces a recommendation for a clinician to review sits in different territory than one that acts on that recommendation directly. The former can be designed out of SaMD scope by keeping a human in the loop. The latter an agent that books a follow-up, escalates a risk flag, or adjusts a care pathway is harder to argue away.

The FDA uses similar logic under its SaMD framework: the threshold is whether software „meaningfully influences diagnosis or treatment.” In the EU, the framing differs, but the practical result usually does not.

When autonomous action changes your risk class

Take a mental health app that shows users their mood trend and suggests they consider booking a session. That is decision support. The clinician sees it, the user decides. From a compliance standpoint, that position is relatively clean.

Now add an agentic feature: if the mood score drops below a threshold for three consecutive days, the AI automatically books a check-in with the assigned therapist and sends a summary to the clinical coordinator. The underlying model is the same; the regulatory implications are entirely different.

Under Rule 11, the relevant question becomes: what class of harm is possible when the system is wrong? If the automatic booking is unnecessary, a patient gets an unwanted appointment. If the AI misses a deterioration because the threshold was calibrated on the wrong population, someone doesn’t get a check-in they needed. That asymmetry is what pushes classification up.

Class IIb applies to software where incorrect decisions could cause serious deterioration in a person’s state of health. Class III, requiring the deepest conformity assessment, applies when incorrect decisions could cause death or irreversible harm. For mental health contexts, this classification conversation is not hypothetical.

This gap between commercial enthusiasm and clinical readiness shows up in the research too. A 2026 scoping review published in npj Digital Medicine examined seven studies on agentic AI systems in clinical settings and found that six remained at proof-of-concept stage, with only one randomized controlled trial involving real patients. The authors concluded that „robust clinical validation” is still largely absent from the field. Products shipping today are moving faster than the evidence base, which makes the regulatory framing even more important to get right from the start.

The AI Act sits on top, not instead

If you’ve been following the EU AI Act timeline, and if your product is in scope for MDR, you should be the interaction between the two regulations adds another layer worth understanding before you scope your next feature.

The AI Act classifies health AI systems as high-risk (Annex III, Section 5). High-risk AI systems must meet requirements around data governance, transparency, human oversight, and accuracy. For products already under MDR, the AI Act is designed to integrate into existing conformity assessment rather than run parallel to it. The operational interface between the two is still being worked out between the European Commission and the Medical Device Coordination Group.

We covered the AI Act’s implications for SaMD in more detail in this post. The deadline moved; the classification questions did not.

How to architect for agenthood without reclassifying your whole product?

The instinct when adding AI agents to a health product is to build the capability first and work out compliance later. We’ve seen this go wrong enough times to say plainly: the architecture decision and the regulatory question need to happen in the same meeting.

The single most effective thing you can do is keep a human in the loop longer than you think you need to. An AI that drafts a message and holds it for clinician approval before sending is categorically different from one that sends it directly. That approval step is a risk classification choice as much as a UX choice. For many teams, one extra confirmation keeps them out of Class IIb.

Scope the intended purpose precisely, and do it before you ship. MDR’s classification logic depends on what the manufacturer claims the software does, not just what it technically can do. If your agent handles administrative functions scheduling, reminders, documentation drafting and does not touch clinical decisions, that is a defensible position. If it starts adjusting medication recommendations or care plan parameters, the intended purpose has changed whether or not the underlying code has. Document that scope before launch, not during a notified body review.

Treat your agentic components as modular, with their own risk documentation, validation test sets, and change control procedures. This is not always the right call on engineering grounds, but it keeps the compliance surface area contained. If one autonomous module needs reclassification later, you are not rebuilding documentation for the entire product.

Finally, plan for drift detection from the start. Post-market surveillance for AI under MDR requires active monitoring bug reports alone are not enough. For agents that take actions based on model outputs, you need to know when the distribution of those outputs shifts relative to your validation data. Building that instrumentation before go-live is much cheaper than retrofitting it after.

One thing that catches teams off guard: continuously adaptive algorithms, models that update based on user interaction without a formal software release, do not have a clean CE marking pathway in the EU yet. Most products shipping today use locked algorithms or predefined change control envelopes for this reason. If your agentic feature learns from outcomes and adjusts over time, that is a harder conversation with a notified body than a locked model.

The conversation to have before you build

Agentic AI in healthcare is no longer speculative. Teams building for the German, Austrian, and Swiss markets are already shipping autonomous features appointment management, care coordination triggers, clinical documentation assistance. The question is whether the regulatory thinking is keeping pace with the engineering.

The mistake we see most often is not building something that turns out to be a medical device. It is building it, getting six months into user testing, and then discovering the classification implications at which point the architecture is already set, and reversing decisions is costly.

If your team is scoping agentic features for a health product and wants a second opinion on where the regulatory exposure sits before committing the architecture, let’s talk.

Monah M. et al., „The role of agentic artificial intelligence in healthcare: a scoping review,” npj Digital Medicine (2026) — nature.com/articles/s41746-026-02517-5