AI Act × MDR für Anbieter: SaMD, Hochrisiko-KI & Betreiberpflichten

Kurzantwort

Ein KI-Produkt für Arztpraxen fällt regelmäßig unter zwei Regelwerke zugleich. Die MDR entscheidet über Regel 11, ob die Software ein Medizinprodukt ist, und über Art. 6 Abs. 1 EU AI Act wird daraus, sobald eine Benannte Stelle nötig ist (in der Regel ab Klasse IIa), eine Hochrisiko-KI.

Die Zulassung erledigt die eine Hälfte. Die andere Hälfte sind die Betreiberpflichten, die beim ärztlichen Kunden landen, sobald er das Produkt einschaltet. Wer diese Betreiberseite im Produkt, in der Dokumentation und im Onboarding mitliefert, verkauft schneller. Wer sie offenlässt, macht das Produkt zum Compliance-Risiko im Vertrieb.

Sie haben Ihr Produkt auf Konformität gebracht. Die technische Dokumentation steht, das QM-System nach ISO 13485 läuft, die Benannte Stelle ist im Gespräch. Aus Ihrer Sicht ist die Compliance damit erledigt.

Aus Sicht des Arztes, der Ihr Produkt einschaltet, fängt sie genau dort an. Er wird mit dem ersten Klick zum Betreiber eines KI-Systems und schuldet ab diesem Moment einen eigenen Pflichtenkatalog, der bei ihm liegt, nicht bei Ihnen. Wer im Beschaffungsgespräch eine fertige Antwort auf seine Frage hat, verkürzt den Sales-Zyklus. Wer ihn mit der Frage allein lässt, produziert die Unsicherheit, die einen Kauf verzögert.

Wann Ihr Produkt zugleich Medizinprodukt und Hochrisiko-KI ist

Die beiden Regelwerke greifen ineinander. Die MDR klärt, ob Sie ein Medizinprodukt bauen, und der AI Act knüpft daran an. Der Weg dorthin läuft in drei Schritten.

MDR Rule 11

Liefert Ihre Software Informationen für diagnostische oder therapeutische Entscheidungen, ist sie SaMD und wird über Regel 11 klassifiziert.

Benannte Stelle

Für SaMD ist ab Klasse IIa eine Konformitätsbewertung durch eine Benannte Stelle erforderlich.

Art. 6 Abs. 1 AI Act

Genau diese Notified-Body-Pflicht macht Ihr Produkt zur Hochrisiko-KI. Die Einstufung hängt an der MDR-Klasse, nicht an einer eigenen AI-Act-Prüfung.

Der Grenzverlauf entscheidet über fast alles, was danach kommt.

Bleibt Klasse I

Reine Dokumentation und Transkription

Ein Ambient-Scribing-Tool, das ein Gespräch nur mitschreibt oder einen Text strukturiert, ohne medizinische Entscheidungen zu beeinflussen.

Ab Klasse IIa, Hochrisiko-KI

Entscheidungsrelevante Information

Sobald dasselbe Tool ICD-Codes vorschlägt, Kontraindikationen markiert oder Befunde priorisiert, wird es Medizinprodukt und über Art. 6 Abs. 1 AI Act zur Hochrisiko-KI.

Die Joint FAQ der Medical Device Coordination Group und des AI Board (MDCG 2025-6 / AIB 2025-1) empfiehlt, die AI-Act-Anforderungen in das bestehende QM-System und die technische Dokumentation zu integrieren statt parallel aufzubauen. Sie errichten kein zweites Compliance-Gebäude, sondern erweitern Ihr MDR-Fundament. Wie sich beide Regime im Detail verschränken, zeigt der Beitrag zur parallelen Konformitätsbewertung.

Die Betreiberpflichten Ihrer Kunden, und Ihr Hebel darauf

Der AI Act adressiert zwei Rollen getrennt. Sie sind Anbieter, Ihr ärztlicher Kunde ist Betreiber. Jede seiner Pflichten aus Art. 26 und Art. 4 lässt sich durch Produktgestaltung erleichtern oder erschweren. Was Sie ihm nicht mitliefern, baut er selbst nach, oder er kauft nicht.

Art. 26 Abs. 2

Menschliche Aufsicht

Ihr Produkt-HebelEine Freigabe-Logik, die der Arzt bewusst bestätigt, statt einer Schaltfläche, die sich wegklicken lässt.

Art. 26 Abs. 1

Bestimmungsgemäße Nutzung

Ihr Produkt-HebelEine Gebrauchsanweisung, aus der der Betreiber seine Pflichten direkt ableiten kann.

Art. 26 Abs. 6

Protokollierung

Ihr Produkt-HebelEin Audit-fähiger Export der automatisch erzeugten Logs.

Art. 26 Abs. 5

Überwachung und Meldung

Ihr Produkt-HebelKlare Kanäle, über die der Kunde Auffälligkeiten an Sie zurückspielt.

Art. 4

KI-Kompetenz

Ihr Produkt-HebelEin produktspezifisches Schulungsmodul samt Teilnahmenachweis, ablegbar im QM.

Art. 35 DSGVO

Datenschutz-Folgenabschätzung

Ihr Produkt-HebelVorbereitete Bausteine zur Verarbeitungsbeschreibung, die der Kunde übernimmt.

Art. 26 Abs. 2 bildet dabei den ungebrochenen Hochrisiko-Kern. Art. 4 ist eine Bemühungs- und Dokumentationspflicht, kein Erfolgsversprechen und keine Sanktionsdrohung. Wer seinem Produkt ein fertiges Schulungsmodul beilegt, nimmt dem Kunden eine eigene Pflicht ab und macht das Onboarding zum Verkaufsargument.

Der Anbieter-Kipp nach Art. 25

Art. 25 AI Act beschreibt die Schwelle, an der ein Betreiber selbst zum Anbieter wird und in Ihre Pflichtenwelt rutscht. Drei Auslöser tragen sie.

Eigener Name oder Marke

Der Kunde bringt das System unter eigenem Namen in Verkehr.

Wesentliche Zweckänderung

Er setzt es für einen Zweck ein, den die Zweckbestimmung nicht vorsieht.

Wesentliche Änderung

Er verändert das System wesentlich, etwa durch Fine-Tuning mit eigenen Patientendaten.

Für Sie ist das ein doppeltes Argument. Es warnt den Kunden davor, an Ihrem System eigenmächtig zu schrauben, und es schützt Ihr Produkt, weil eine klar dokumentierte Zweckbestimmung den Kunden im Betreiber-Rahmen hält. Für PVS-Anbieter ist die Schwelle besonders relevant, denn KI-Funktionen kommen als buchbare Add-ons, nicht als stilles Update. Die Betreiberstellung beginnt mit der bewussten Buchung und Aktivierung, und genau dieser Moment ist der richtige, um dem Kunden die Betreiber-Information an die Hand zu geben.

Welche Fristen nach dem Digital Omnibus gelten

Die ursprünglich kursierende Frist August 2026 für die Hochrisiko-Betreiberpflichten ist nach dem Digital Omnibus überholt.

Februar 2025

Art. 4 KI-Kompetenz gilt, als Bemühungs- und Dokumentationspflicht (Audit-Trail-Logik).

Dezember 2027

Eckdatum für den Hochrisiko-Kern der Betreiberpflichten nach den angepassten Übergangsregeln.

August 2028

Vollständige Anwendung der Hochrisiko-Pflichten.

Der zeitliche Druck auf die schweren Hochrisiko-Pflichten hat sich entspannt, die Sales-relevante Erwartung der Kunden an Art.-4-Material und Betreiber-Unterlagen besteht aber jetzt. Wer wartet, verschenkt den Vorsprung an die Anbieter, die ihre Betreiber-Readiness schon heute mitliefern.

Schweigepflicht und Serverstandort als Verkaufsargument

Der Arzt unterliegt der Schweigepflicht und verarbeitet besonders geschützte Gesundheitsdaten. Drei Punkte aus Ihrem Produkt entscheiden mit darüber, ob er überhaupt unterschreiben darf.

EU-Serverstandort und AVV

Ein EU-Standort, ein sauberer AV-Vertrag und eine Einbindung als zur Verschwiegenheit verpflichtete Stelle räumen dem Kunden Hindernisse aus dem Weg, die er sonst selbst klären müsste (§ 203 StGB).

Kein Training mit Kundendaten

Die Zusicherung, dass Sie die Daten Ihrer Kunden nicht zum Training Ihrer Modelle verwenden, steht in fast jeder Engine-Antwort und in jedem ernsthaften Beschaffungsgespräch.

DSFA-Bausteine

Vorbereitete Bausteine für die Datenschutz-Folgenabschätzung, die der Betreiber bei Gesundheitsdaten regelmäßig durchführen muss (Art. 9 DSGVO).

Für besonders sensible Umgebungen wird der Souveränitätsgrad selbst zum Argument. Ein On-Premise- oder Sovereign-AI-Betrieb, bei dem Daten die kontrollierte Umgebung nicht verlassen, löst die Schweigepflicht-Frage an der Wurzel und öffnet Kunden, die eine Cloud-Lösung gar nicht erst prüfen dürfen.

Wo die Zulassungsberatung aufhört und ich anfange

Die Zulassungsseite

ISO 13485, technische Dokumentation nach Anhang IV, Vorbereitung auf die Benannte Stelle und die CE-Kennzeichnung. Das Feld der etablierten Zulassungs- und Zertifizierungsberatung. Damit konkurriere ich nicht.

Mein Feld, die Kundenseite

Ich übersetze zwischen dem, was Sie bauen, und dem, was der Betreiber von Ihnen verlangt, damit er rechtssicher arbeitet. Als Legal Engineer, der die Betreiber-Realität in Produkt, Dokumentation und Vertrieb zurückspielt.

Das ist regulatorisch-technische Beratung an der Schnittstelle von Recht, Technik und Praxis. Ich bin kein zugelassener Rechtsanwalt und erbringe keine anwaltliche Rechtsberatung im Einzelfall im Sinne des Rechtsdienstleistungsgesetzes.

Was ein Betreiber-Ready-Audit konkret prüft

Ein Betreiber-Ready-Audit nimmt Ihr Produkt aus der Kundenperspektive auseinander und beantwortet eine Leitfrage. Macht Ihr Produkt seine Betreiber compliant, oder lädt es ihnen Arbeit auf, die sie im Beschaffungsgespräch gegen Sie verwenden?

Leitet der Betreiber aus Ihrer Gebrauchsanweisung seine Art.-26-Pflichten ab?

Trägt Ihr Interface die menschliche Aufsicht oder verleitet es zur Routineklick-Bestätigung?

Liefern Sie ein produktspezifisches Art.-4-Schulungsmodul samt Nachweis mit?

Halten Zweckbestimmung und Konfigurationsgrenzen den Kunden sicher im Betreiber-Status?

Geben Ihre Unterlagen dem Kunden AV-Vertrag, DSFA-Bausteine und Trainingsdaten-Zusicherung fertig in die Hand?

Konkret werden

Sie bauen ein KI-Produkt für Arztpraxen oder MVZ?

Im kostenlosen Erstgespräch von 30 Minuten klären wir, wo Ihr Produkt seine Betreiber heute schon compliant macht und wo es ihnen Arbeit aufbürdet, die den Verkauf bremst.

Erstgespräch buchen Angebote für Anbieter

Häufige Fragen

Fällt unser KI-Produkt unter MDR und AI Act gleichzeitig?

Wenn Ihre Software ein Medizinprodukt nach MDR ist und für die Konformitätsbewertung eine Benannte Stelle braucht (in der Regel ab Klasse IIa), gilt sie nach Art. 6 Abs. 1 AI Act zugleich als Hochrisiko-KI. Beide Regelwerke greifen dann parallel, der AI Act ergänzt die MDR um KI-spezifische Anforderungen, ohne sie zu ersetzen.

Ab welcher MDR-Klasse wird unsere SaMD zur Hochrisiko-KI?

Maßgeblich ist nicht die Klasse als Zahl, sondern die Frage, ob eine Benannte Stelle eingebunden werden muss. Das ist bei SaMD über MDR Rule 11 regelmäßig ab Klasse IIa der Fall, und genau daran knüpft die Hochrisiko-Einstufung des AI Act an.

Was müssen wir unseren ärztlichen Kunden über ihre Betreiberpflichten mitgeben?

Eine verständliche Gebrauchsanweisung zur bestimmungsgemäßen Verwendung, eine Interface-Logik, die die menschliche Aufsicht trägt, einen Art.-4-Schulungsnachweis zu Ihrem Produkt sowie die Datenschutz-Unterlagen (AV-Vertrag, DSFA-Bausteine, Trainingsdaten-Zusicherung). Damit erfüllt der Kunde seine Pflichten aus Art. 26 und Art. 4 weitgehend mit Ihrem Produkt.

Wann wird unser Kunde durch die Nutzung selbst zum Anbieter?

Nach Art. 25 AI Act, wenn er das System unter eigenem Namen vertreibt, seine Zweckbestimmung wesentlich ändert oder es wesentlich verändert, etwa durch Fine-Tuning mit eigenen Patientendaten. Klare Zweckbestimmung und definierte Konfigurationsgrenzen halten ihn im Betreiber-Status.

Gilt die August-2026-Frist noch?

Nein. Nach dem Digital Omnibus sind die Hochrisiko-Betreiberpflichten gestaffelt mit Eckdaten Dezember 2027 und August 2028 neu terminiert. Die Art.-4-Pflicht zur KI-Kompetenz gilt seit Februar 2025 unverändert.

Beraten Sie zur CE-Zulassung und technischen Dokumentation?

Das ist das Feld der spezialisierten Zulassungsberatung. Mein Ausgangspunkt ist die Kundenseite Ihres Produkts, also die Betreiberpflichten, die Ihre ärztlichen Kunden treffen, und wie Sie diese in Produkt, Dokumentation und Vertrieb beantworten.

AI Act und MDR an der Schnittstelle: was Anbieter für ihre Kunden mitdenken müssen

Auf einen Blick