KI in der Arztpraxis: Vollständig vermarktet. Halb erklärt.
Daniel Kleiboldt — Legal Engineer
Auf einen Blick
- 01Der Arzt wird Betreiber kraft Gesetzes — nicht kraft Zustimmung oder Vertrag
- 02Art. 4 AI Act (KI-Literacy-Pflicht) gilt seit Februar 2025 — für jede Praxis, die KI einsetzt
- 03Die meisten Anbieter kommunizieren Betreiberpflichten nicht — das ist strukturell, nicht fahrlässig
- 04Wer nicht weiß, was er schuldet, kann es nicht dokumentieren — und nicht verteidigen
- 05Legal Engineering ist die Antwort auf die Lücke zwischen Anbieter-Marketing und Betreiber-Realität
Der Markt für Praxisverwaltungssoftware macht gerade vieles richtig. CGM, medatixx, tomedo, Doctolib, sie alle investieren erkennbar in Lösungen, die dem chronisch überlasteten Praxisalltag echte Entlastung versprechen: KI-gestützte Telefonassistenten, Ambient-Scribing, intelligente Kodiervorschläge für die Quartalsabrechnung. Das Marketing ist präzise, die Versprechen sind konkret. Und das kommt an, bei Ärzten, die im Schnitt 2,5 Stunden täglich mit Dokumentation verbringen, die nichts mit Patientenversorgung zu tun hat.
Das ist keine Zukunftsmusik mehr. Das ist der aktuelle Markt.
Das Problem beginnt genau dort, wo das Marketing aufhört.
// Der Arzt wird Betreiber. Kraft Gesetzes. Nicht kraft Zustimmung.Was der EU AI Act aus dem Arzt macht — und warum nicht jede KI gleich ist
Jeder Arzt, der ein KI-System professionell einsetzt, wird zum Betreiber (Deployer) im Sinne des AI Act. Das gilt unabhängig davon, ob die Software nur transkribiert oder eigenständig Diagnosen vorschlägt. Was sich unterscheidet, ist die Tiefe der Pflichten. Und das hängt davon ab, ob das System als Hochrisiko-KI eingestuft wird.
Hier wird es für den Healthcare-Bereich komplex, denn zwei Regulierungswelten treffen aufeinander: die Medizinprodukteverordnung (MDR) und der AI Act.
Die entscheidende Norm ist Art. 6 Abs. 1 AI Act: Ein KI-System gilt als Hochrisiko-KI, wenn es ein Produkt ist oder als Sicherheitsbauteil eines Produkts fungiert, das unter Harmonisierungsrechtsvorschriften der EU fällt und für das eine Konformitätsbewertung durch eine Benannte Stelle erforderlich ist. Anhang I des AI Act listet die MDR explizit als eine dieser Harmonisierungsrechtsvorschriften auf.
Die praktische Konsequenz: Fällt eine KI-Software unter MDR-Risikoklasse IIa oder höher, wird sie automatisch zur Hochrisiko-KI im Sinne des AI Act. Die Einstufung als Medizinprodukt ist dabei der Dreh- und Angelpunkt.
Wann wird eine KI-Software zum Medizinprodukt?
MDR Rule 11 (Anhang VIII, Kapitel III) ist hier die zentrale Klassifizierungsregel: Software, die dazu bestimmt ist, Informationen zu liefern, die für diagnostische oder therapeutische Entscheidungen herangezogen werden, ist mindestens Klasse IIa.
Das klingt abstrakt. Konkret bedeutet es: Eine KI, die eigenständig ICD-10-Codes vorschlägt — also nicht nur dokumentiert, was der Arzt gesagt hat, sondern aus dem Gesprächskontext Diagnosevorschläge ableitet — liefert Information für diagnostische Entscheidungen. Sie fällt unter Rule 11, wird mindestens Klasse IIa, erfordert eine Konformitätsbewertung durch eine Benannte Stelle, und wird damit automatisch zur Hochrisiko-KI nach Art. 6 Abs. 1 AI Act.
Die regulatorische Kette ist: ICD-10-Vorschlag → Medizinprodukt (MDR Rule 11, Klasse IIa) → Benannte Stelle erforderlich → Hochrisiko-KI (Art. 6 Abs. 1 + Anhang I AI Act).
Die wichtige Unterscheidung: Transkription versus Diagnosevorschlag
Nicht jede KI in der Praxissoftware löst diese Kette aus. Und genau hier liegt eine Differenzierung, die in der aktuellen Debatte zu selten gemacht wird:
Ein reines Ambient-Scribing-System — eines, das das Arzt-Patienten-Gespräch transkribiert, strukturiert und die vom Arzt explizit formulierte Diagnose als Freitext extrahiert — dokumentiert. Es trifft keine diagnostische Aussage. Die Einstufung als Medizinprodukt ist hier nicht automatisch gegeben, die Abgrenzung im Einzelfall aber anspruchsvoll.
Ein System, das aus dem Gesprächskontext eigenständig ICD-10-Codes ableitet und dem Arzt zur Bestätigung vorschlägt, geht einen Schritt weiter. Es liefert diagnostische Information. Es fällt unter Rule 11. Es wird zum Medizinprodukt. Und damit zur Hochrisiko-KI.
Das ist keine akademische Feinheit. Das ist der Unterschied zwischen einem Pflichtenprogramm, das sich auf Art. 4 (KI-Kompetenz) und die DSGVO beschränkt — und dem vollständigen Betreiber-Pflichtenkatalog nach Art. 26 AI Act.
Wo stehen die Anbieter heute?
Ein Blick auf die aktuellen Produktportfolios zeigt, dass die Grenze zwischen Dokumentation und Diagnoseunterstützung bereits überschritten wird — und zwar nicht überall gleich:
Doctolib integriert in seinen Sprechstundenassistenten eine ICD-10-Vorschlagsfunktion, die bei Nutzung der Doctolib-eigenen Praxissoftware aktiv ist. Die KI analysiert das Arzt-Patienten-Gespräch und schlägt passende ICD-10-Codes vor, die per Ein-Klick-Validierung übernommen werden können. Das ist keine Transkription mehr, das ist ein diagnostischer Vorschlag.
tomedo Praxissoftware AG bietet mit tomedo.Intelligence einen Sprechstundenassistenten, der ebenfalls ICD-Diagnosen vorschlägt. Im Nutzerforum wird aktiv über die Verbesserung dieser Funktion diskutiert — aktuell müssen vorgeschlagene ICDs noch per Copy-Paste übernommen werden, die Community wünscht sich klickbare Übernahme.
CompuGroup Medical SE & Co. KGaA positioniert seinen DokuAssistenten primär als Ambient-Scribing-Lösung: Transkription und Strukturierung des Arzt-Patienten-Gesprächs, keine eigenständigen ICD-Vorschläge im deutschen Praxissegment. In Österreich existiert allerdings ein separater Codierservice, der Freitext-Diagnosen über SNOMED-CT auf ICD-10 mappt — eine Funktion, die angesichts der strategischen Ausrichtung von CGM absehbar auch in der deutschen Praxissoftware landen wird.
medatixx steht mit x.scribe (Ambient Scribing, in Kooperation mit Corti) und dem medatixx-Copiloten am Beginn der KI-Integration. Beide Lösungen fokussieren auf Transkription und Dokumentationsunterstützung — eine eigenständige ICD-Vorschlagsfunktion ist derzeit nicht dokumentiert.
Das Bild ist also heterogener, als es auf den ersten Blick scheint. Aber die Richtung ist eindeutig: Der Markt bewegt sich von der reinen Dokumentation zur diagnostischen Unterstützung. Und damit in den Regulierungsbereich der Hochrisiko-KI.
Drei Stufen der Pflichten — und die Compliance-Lücke zieht sich durch alle
Aus dem Zusammenspiel von AI Act, MDR und DSGVO ergeben sich für den Arzt als Betreiber drei Pflichtenebenen, gestaffelt nach Funktionsumfang der eingesetzten KI:
Stufe 1 — Gilt für jede KI in der Praxis (auch reine Dokumentation)
- →KI-Kompetenz (Art. 4 AI Act): Betreiber sind verpflichtet, nach besten Kräften ein ausreichendes Maß an KI-Kompetenz beim eingesetzten Personal sicherzustellen. In der Compliance-Praxis läuft das auf eine regelmäßige, dokumentierte Schulung des Praxisteams hinaus — auch wenn der Gesetzestext bewusst Spielraum bei der konkreten Umsetzung lässt. Diese Pflicht gilt seit Februar 2025, ohne Übergangsfrist.
- →DSGVO-Pflichten: Der Einsatz von KI, die Gesundheitsdaten verarbeitet — und Ambient-Scribing tut genau das —, dürfte regelmäßig die Schwelle für eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO überschreiten, allein aufgrund der besonderen Datenkategorien (Art. 9 DSGVO) und der systematischen Verarbeitung. Hinzu kommen die Informationspflichten nach Art. 13 und 14 DSGVO gegenüber Patienten.
- →Transparenz gegenüber Patienten: Die Aufklärungspflicht ergibt sich aus dem Zusammenspiel von Behandlungsvertrag (§ 630e BGB) und DSGVO. Wer KI-gestützte Verfahren in der Patientenversorgung einsetzt, muss darüber informieren.
Diese Baseline gilt heute, für jedes KI-Tool. Bei jedem Anbieter. Und kein Anbieter, den ich kenne, liefert hierfür strukturierte Unterstützung.
Stufe 2 — Gilt zusätzlich für Hochrisiko-KI (ICD-Vorschläge, Diagnoseunterstützung)
Sobald eine KI eigenständig diagnostische Vorschläge generiert und damit unter MDR Rule 11 als Medizinprodukt eingestuft wird, greift der vollständige Betreiber-Pflichtenkatalog nach Art. 26 AI Act. Für KI-Systeme, die über die MDR als Hochrisiko eingestuft werden, gilt dieser Katalog ab dem 2. August 2027 vollumfänglich — mit der verlängerten Übergangsfrist für Anhang-I-Produkte.
- →Menschliche Aufsicht (Art. 26 Abs. 2): KI-generierte Entscheidungen müssen durch kompetentes Personal aktiv überprüft werden. Automation Bias — das unreflektierte Übernehmen maschineller Ausgaben — ist nicht nur ein medizinisches Qualitätsproblem, es ist ein Haftungsrisiko. Ein ICD-10-Vorschlag, der ungeprüft in die Akte übernommen wird, ist ein dokumentiertes Risiko.
- →Protokollaufbewahrung (Art. 26 Abs. 6): Automatisch erzeugte System-Logs sind für mindestens sechs Monate aufzubewahren, sofern diese der Kontrolle des Betreibers unterliegen.
- →Datenschutz-Folgenabschätzung (Art. 26 Abs. 9 i.V.m. Art. 35 DSGVO): Der Einsatz von Hochrisiko-KI, die Gesundheitsdaten verarbeitet, löst die DSFA-Pflicht nach Art. 35 DSGVO praktisch zwingend aus. Art. 26 Abs. 9 AI Act verweist explizit darauf, dass der Betreiber die vom Hersteller bereitgestellten Informationen für diese Pflicht heranzuziehen hat.
Das ist zwingendes Europarecht. Es kann nicht per AGB abbedungen werden — weder vom Arzt noch vom Softwareanbieter.
Stufe 3 — Die Grauzone, die juristisch noch nicht ausjudiziert ist
Zwischen reiner Transkription und aktivem Diagnosevorschlag liegt ein Bereich, der regulatorisch noch nicht vollständig geklärt ist: Ambient-Scribing-Systeme, die Freitext-Diagnosen aus dem Gespräch extrahieren — nicht als ICD-Code, aber als strukturierte diagnostische Aussage. Ob diese Extraktion bereits als "Information für diagnostische Entscheidungen" im Sinne von Rule 11 gilt, hängt vom Einzelfall ab: Wie viel Eigenleistung bringt das System ein? Reformuliert es nur, was der Arzt gesagt hat — oder interpretiert es?
Diese Grauzone wird kleiner werden. Die MDCG-Guidance 2019-11 Rev. 1 (Juni 2025) hat den Begriff "Medical Device AI" erstmals eingeführt und die Abgrenzungskriterien geschärft. Der Trend geht eindeutig in Richtung einer breiten Auslegung.
Das Muster, das sich beobachten lässt
Wer sich jetzt die Vertriebsmaterialien, Produktseiten und AGB der großen PVS-Anbieter ansieht, stellt etwas Interessantes fest.
Auf der Marketingseite: Die Sprache ist ausgefeilt. KI als Effizienzgewinn, als Entlastung, als Innovation. Konkrete Zeitersparnisse werden kommuniziert, Testimonials zitiert, Integrationen betont.
Auf der Vertragsseite: Die Formulierungen sind präzise. KI als "Unterstützungswerkzeug". "Letztentscheidung liegt beim Anwender." Haftungsausschlüsse, die den Betreiberstatus des Arztes klar benennen und die daraus resultierenden Pflichten konsequent beim Arzt belassen.
Beides ist für sich genommen verständlich. Das Marketing muss verkaufen. Die AGB müssen das Unternehmen schützen. Das ist keine Neuigkeit und kein Vorwurf.
Was fehlt, ist die Brücke.
Zwischen dem Versprechen im Pitch Deck und der Rechtswirklichkeit klafft eine Lücke, die derzeit niemand schließt. Kein Anbieter, den ich kenne, liefert mit seinem KI-Tool ein Betreiber-Onboarding mit, das diesen Namen verdient: kein DSFA-Template für das spezifische System, keine AI-Literacy-Schulungsunterlage für das Praxisteam, keine Checkliste zur Human-Oversight-Implementierung, keinen Leitfaden zur Logging-Konfiguration. Und bei den Anbietern, deren Systeme bereits ICD-10-Codes vorschlagen — also in den Bereich der Hochrisiko-KI hineinreichen —, kein Hinweis darauf, dass sich der regulatorische Rahmen mit dieser Funktion fundamental verschiebt.
Der Arzt bekommt ein Produkt. Und eine FAQ. Das ist nicht dasselbe.
Warum das rational ist — und trotzdem nicht mehr ausreicht
Um fair zu sein: Die Strategie der Anbieter ist nachvollziehbar. In regulierten Märkten ist es Standard, die Compliance-Verantwortung vertraglich beim Anwender zu verorten. Das ist nicht nur legal, sondern aus Unternehmensperspektive vernünftig. Schließlich kennt der Anbieter weder die konkreten Prozesse noch die spezifische IT-Landschaft jeder einzelnen Praxis.
Außerdem haben die Hersteller durch das Opt-in-Modell — KI-Funktionen als kostenpflichtige Add-ons — das Problem der ungewollten Betreiberstellung durch automatische Updates weitgehend entschärft. Auch das ist eine bewusste, rechtlich saubere Entscheidung.
Die Frage ist nicht, ob diese Strategie zulässig ist. Sie ist es.
Die Frage ist, ob sie zukunftsfähig ist.
// Die AGB sind wasserdicht. Die Frage ist, ob das reicht.Wenn die ersten Enforcement-Fälle kommen — und sie werden kommen, spätestens wenn Aufsichtsbehörden beginnen, Healthcare-KI gezielt zu prüfen —, wird eine Frage laut werden: Wurde der Arzt ausreichend über seine Betreiberpflichten informiert? Hat der Anbieter alles Zumutbare getan, um den sicheren und rechtskonformen Einsatz seines Produkts zu ermöglichen?
Im Schadensfall landet die primäre Haftung beim Arzt — das ist die aktuelle Rechtslage. Aber der Reputationsschaden landet beim Anbieter. Der Nachrichtenwert von "Praxissoftware-KI führt zu Haftungsfall" ist erheblich. Die Frage "Hat der Hersteller den Arzt über seine Pflichten informiert?" wird gestellt werden.
Und für Anbieter, deren Systeme ICD-10-Codes vorschlagen, kommt eine weitere Dimension hinzu: Ist das System als Medizinprodukt zugelassen? Liegt eine Konformitätsbewertung durch eine Benannte Stelle vor? Wenn nicht, steht nicht nur der Betreiber im Feuer — sondern auch der Anbieter als Inverkehrbringer.
Was "Compliance-out-of-the-box" bedeuten könnte
Der Anbieter, der diese Lücke als erster schließt, hat einen echten Differenzierungsvorteil — nicht nur regulatorisch, sondern im Markt.
Konkret gedacht: Was wäre, wenn PVS-Anbieter mit ihrem KI-Modul ein strukturiertes Betreiber-Onboarding mitliefern würden? Ein System, das beim ersten Aktivieren automatisch den Konfigurationsstand für die Logging-Pflicht dokumentiert, eine DSFA-Vorlage generiert, eine kurze AI-Literacy-Einheit für das Praxisteam bereitstellt?
Das ist kein regulatorischer Luxus. Das ist ein Verkaufsargument.
"Unsere KI ist nicht nur effizient — sie ist von Anfang an rechtskonform einsetzbar." In einem Markt, in dem niedergelassene Ärzte zunehmend über regulatorischen Mehraufwand klagen, wäre das eine Botschaft, die zieht.
Und für die Anbieter selbst: Ein dokumentiertes Betreiber-Onboarding stärkt im Haftungsfall die eigene Position erheblich. Wer nachweisen kann, dass er den Arzt strukturiert über seine Pflichten informiert hat, steht im Regress-Verfahren deutlich besser da.
Dabei muss "Compliance-out-of-the-box" nicht zwingend bedeuten, alle Antworten in die Software zu bauen. Ein Teil der Lösung ist strukturell ein menschlicher Layer: Ärzte, die ihre Betreiberpflichten kennen, weil jemand sie verständlich erklärt hat.
Anbieter, die diesen Schritt aktiv mitgestalten, bringen sich in eine Position, die kein AGB-Werk erreicht: Sie werden zum Partner in der Compliance, nicht zum Haftungsabschieber.
Was das für die rechtliche Praxis bedeutet
Für Juristen, die Arztpraxen, MVZs oder Krankenhäuser beraten: Die KI-Compliance-Frage wird in den nächsten 18 Monaten ein Standardthema. Die Betreiberpflichten nach Art. 26 AI Act, die Schnittstelle zur MDR, die Frage der Medizinprodukte-Einstufung bei KI-gestützter Kodierung, die DSFA-Pflicht bei KI-gestützter Dokumentation — das sind Themen, die in den meisten Praxen noch nicht auf dem Schirm sind.
Für Compliance-Verantwortliche in PVS-Unternehmen: Die Frage ist nicht, ob die Anbieter ihre Hausaufgaben gemacht haben — die AGB sind wasserdicht. Die Frage ist, ob das reicht. Oder ob ein proaktiver, partnerschaftlicher Ansatz bei der Betreiber-Aufklärung langfristig der bessere Weg ist. Und für Unternehmen, deren Systeme bereits ICD-10-Codes vorschlagen: Die Frage der MDR-Konformität wird sich nicht vermeiden lassen.
Die regulatorische Realität ist: Der Markt ist reif. Die Produkte sind beeindruckend. Die Compliance-Kommunikation — da ist noch Luft nach oben.
Was das für Ihre Praxis bedeutet
Wenn Sie diese Zeilen als niedergelassener Arzt lesen und KI-gestützte Software einsetzen — ob für Dokumentation, Telefonie oder Diagnoseunterstützung: Sie sind bereits Betreiber im Sinne des AI Act. Das folgt nicht aus Ihrer Absicht, sondern aus der Funktion des Systems.
Die Pflicht zur KI-Kompetenz für Ihr Praxisteam gilt seit Februar 2025. Die DSGVO-Pflichten — insbesondere die Frage der Datenschutz-Folgenabschätzung — laufen unabhängig vom AI Act. Und wenn Ihre Software eigenständig ICD-10-Codes vorschlägt, bewegen Sie sich im Bereich der Hochrisiko-KI mit einem deutlich erweiterten Pflichtenkatalog ab August 2027.
Drei Fragen, die Sie sich jetzt stellen sollten:
- 1Weiß mein Praxisteam, wie das KI-System kontrolliert werden soll?
- 2Habe ich geprüft, ob eine Datenschutz-Folgenabschätzung erforderlich ist?
- 3Schlägt mein System eigenständig Diagnosen oder ICD-Codes vor — und wenn ja, weiß ich, was das regulatorisch bedeutet?
Wenn Sie mindestens eine dieser Fragen mit Nein beantworten: Das ist normal — und es ist lösbar. Aber die Zeit, es zu ignorieren, läuft ab.
Daniel Kleiboldt ist Legal Engineer mit Spezialisierung auf Healthcare-KI-Compliance. Er entwickelt akkreditierte Fortbildungsformate für Ärzte und MVZ-Betreiber und referiert zu den Implikationen des AI Act für das Gesundheitswesen — an der Schnittstelle von Recht, Technologie und Praxisalltag.
Systematisch vorbereitet. In 90 Minuten.
Der KI-Compliance-Kurs für Ärzte und Praxisteams
Betreiberpflichten, KI-Literacy-Nachweis und 3 CME-Punkte — mit Fallbeispielen, Checklisten und konkretem Fahrplan für die Praxis.
Weiterlesen