Ihre IT hat gestern ein Update installiert. Heute sind Sie Betreiber eines Hochrisiko-KI-Systems.

Donnerstagmorgen. Ihr IT-Dienstleister hat nachts routinemäßig Updates eingespielt. Alles läuft. Keine Störung. Kein Ticket im System.

Was Sie nicht wissen: Mit diesem Update hat sich die rechtliche Einordnung Ihrer Praxissoftware fundamental geändert.

Gestern war Ihr Terminverwaltungssystem ein Kalendertool. Heute analysiert eine KI im Hintergrund Patienteneingaben, priorisiert automatisch Notfälle und schlägt basierend auf Symptombeschreibungen den passenden Facharzt vor.

Ihr Datenschutzkonzept beschreibt noch die alte Version. Ihre Auftragsverarbeitungsverträge decken die neuen Datenflüsse nicht ab. Ihre Ärzte wissen nicht, dass sie jetzt KI-generierte Entscheidungsvorschläge nutzen.

Sie haften trotzdem.

Das Problem: Wer kontrolliert die Updates?

Die zentrale Frage lautet: Wer bei Ihnen prüft, ob ein Software-Update die rechtliche Einordnung Ihres Systems verändert?

Wenn die Antwort "Niemand, das macht der Anbieter" lautet, haben wir ein Problem.

Der Software-Hersteller liefert Technik. Er trägt die Produkthaftung für sein Tool. Aber Sie entscheiden, dieses Tool in der Patientenversorgung einzusetzen. Sie sind der Betreiber. Und als Betreiber tragen Sie die Verantwortung dafür, dass der Einsatz rechtssicher erfolgt.

Der Hersteller kennt Ihre Prozesse nicht. Er weiß nicht, wie Ihre Ärzte die Software nutzen. Er kann nicht beurteilen, ob sein neues Feature in Ihrem spezifischen Kontext ein Compliance-Risiko erzeugt.

Das können nur Sie.

Drei konkrete Probleme

1) Das DSFA-Dilemma

Eine Datenschutz-Folgenabschätzung bildet die tatsächliche Datenverarbeitung ab. Wenn Ihre Software nach einem Update plötzlich Gesundheitsdaten an einen Sub-Prozessor zur KI-Analyse sendet oder automatisierte Priorisierungen vornimmt, beschreibt Ihre DSFA von 2023 nicht mehr die Realität.

Das ist kein Papierkram-Problem. Das ist ein Haftungsrisiko.

Wenn Ihr Landesdatenschutzbeauftragter prüft — und die prüfen inzwischen gezielt Healthcare-KI —, kann er feststellen: "Ihre dokumentierte Datenverarbeitung stimmt nicht mit der tatsächlichen überein."

Die Folge sind aufsichtsrechtliche Maßnahmen, die Ihren Betrieb empfindlich stören können. Bußgelder sind dabei oft noch das kleinere Übel im Vergleich zum Reputationsschaden.

Was ich in der Praxis sehe: Viele Betreiber gehen davon aus, dass der Software-Anbieter die DSFA aktualisiert. Das ist ein Missverständnis. Der Anbieter kann eine Muster-DSFA liefern. Aber die konkrete Folgenabschätzung für Ihren Betrieb müssen Sie durchführen.

2) Heterogene IT-Landschaften (bei lokalen Installationen)

Das größte Risiko in MVZs mit lokalen Servern oder zeitversetzten Rollouts: nicht synchronisierte IT-Systeme.

Standort A nutzt Software X in Version 3.2. Standort B hat Version 3.5, weil deren IT-Dienstleister schneller updated. Standort C läuft noch auf 3.1, weil ein kritisches Modul inkompatibel ist.

Jede Version hat andere Features. Unterschiedliche Datenflüsse. Unterschiedliche Risikoprofile. Ihre Compliance-Dokumentation geht aber von "der Software" aus.

Im Schadensfall müssen Sie beweisen können: "Wir wussten, welche Systeme wo liefen. Wir haben die Risiken bewertet." Wenn Sie das nicht können, deutet die fehlende Dokumentation darauf hin, dass Sie die Kontrolle nicht hatten.

(Hinweis: Bei reinen Cloud-Lösungen (SaaS) haben alle Nutzer meist die gleiche Version. Das Problem verschiebt sich dort auf die Frage: Wer prüft die Release Notes, bevor das Update automatisch ausgerollt wird?)

3) Die schleichende Mutation der Zweckbestimmung

Der EU AI Act unterscheidet KI-Systeme nach ihrer Zweckbestimmung. Ein reines Dokumentationswerkzeug unterliegt anderen Anforderungen als ein System, das klinische Entscheidungen beeinflusst.

Die Grenze ist messerscharf: Sobald Software nicht mehr nur dokumentiert, sondern Entscheidungen vorbereitet, ändert sich die Risikoklasse.

Ein Beispiel: Ihr Terminverwaltungssystem hat bisher Anrufe entgegengenommen und Termine nach Verfügbarkeit vergeben. Nach dem Update analysiert es Freitext-Eingaben ("starke Brustschmerzen seit heute Morgen"), erkennt potenzielle Notfälle und priorisiert diese automatisch.

Was sich technisch wie ein nützliches Feature anfühlt, ist juristisch eine Änderung der Zweckbestimmung. Aus Admin-Software wird ein Medizinprodukt.

Das Problem: Viele Software-Anbieter kommunizieren das nicht. Nicht aus Böswilligkeit — sondern weil sie selbst oft nicht wissen, wie ihr Feature rechtlich einzuordnen ist.

Was jetzt zu tun ist

Hier sind drei Schritte für ein pragmatisches Change-Management:

1) Release-Review vor Rollout

Bevor ein Major-Update eingespielt wird, prüft jemand — intern oder extern —, ob sich etwas Wesentliches ändert:

• Ändert sich die Zweckbestimmung?
• Neue Datenflüsse?
• Neue Automatismen?

Das muss keine vierstündige Analyse sein. In den meisten Fällen reicht ein strukturiertes 30-Minuten-Review der Release Notes.

Wichtig: Fragen Sie Ihren Anbieter proaktiv nach den Release Notes, wenn diese nicht automatisch kommen.

2) DSFA-Update-Trigger

Wenn eine der Fragen oben mit "Ja" beantwortet wird, löst das eine DSFA-Aktualisierung aus. Das ist deutlich weniger Aufwand als ein Bußgeldverfahren, in dem Sie nicht nachweisen können, dass Sie die Datenverarbeitung unter Kontrolle hatten.

3) Dokumentierte Freigabe pro Standort

Wer hat wann welches Update für welche Standorte freigegeben? Das muss nachvollziehbar sein. Eine einfache Tabelle reicht: Datum, Standort, Software-Version, freigebende Person, Bemerkungen.

Das eigentliche Problem

Das Grundproblem ist nicht technisch. Es ist organisatorisch.

IT-Sicherheit ist nicht dasselbe wie Compliance. Ihr IT-Dienstleister kann nicht beurteilen, ob ein Software-Update Ihre Datenschutzkonzepte obsolet macht oder Ihre Haftungsrisiken verändert.

Die Frage ist: Wessen Job ist es dann?

In vielen Organisationen lautet die ehrliche Antwort: "Niemandes." Es gibt eine Lücke zwischen IT-Betrieb und rechtlicher Verantwortung. Und diese Lücke wird größer, je komplexer Ihre IT-Landschaft wird.

Was das für Sie bedeutet

Wenn Sie eine heterogene IT-Landschaft über mehrere Standorte betreiben und sich gerade fragen, ob Ihre Compliance mit Ihren Updates Schritt hält — Sie sind nicht allein.

Sie brauchen einen Prozess. Einen schlanken, pragmatischen Governance-Mechanismus, der Software-Changes nicht blockiert, sondern rechtssicher macht.

Genau dafür gibt es Legal Engineering.

Wenn Sie wissen wollen, wie das konkret bei Ihnen aussehen könnte — lassen Sie uns reden. Bevor Ihr Datenschutzbeauftragter es tut.

Häufig gestellte Fragen (FAQ)

Kann ein Software-Update die Risikoklasse meiner Praxissoftware ändern?

Ja. Wenn ein Update KI-Funktionen hinzufügt, die klinische Entscheidungen beeinflussen (z. B. automatische Symptom-Priorisierung), ändert sich die Zweckbestimmung. Aus einem Kalendertool kann ein Medizinprodukt werden, das unter die Hochrisiko-Kategorie des EU AI Act fällt.

Warum muss ich als Betreiber Software-Updates selbst prüfen?

Der Hersteller liefert Technik, kennt aber Ihre Prozesse nicht. Er kann nicht beurteilen, ob ein neues Feature in Ihrem spezifischen Kontext ein Compliance-Risiko erzeugt. Als Betreiber tragen Sie die Verantwortung für den rechtssicheren Einsatz.

Wie prüfe ich, ob ein Software-Update compliance-relevant ist?

Führen Sie vor jedem Major-Update ein strukturiertes 30-Minuten-Review der Release Notes durch. Drei Kernfragen: Ändert sich die Zweckbestimmung? Gibt es neue Datenflüsse? Gibt es neue Automatismen? Bei „Ja": DSFA-Aktualisierung auslösen.

Was passiert, wenn meine DSFA nicht zur aktuellen Software-Version passt?

Das ist ein Haftungsrisiko. Wenn der Landesdatenschutzbeauftragte feststellt, dass Ihre dokumentierte Datenverarbeitung nicht mit der tatsächlichen übereinstimmt, drohen aufsichtsrechtliche Maßnahmen und Bußgelder. Die DSFA muss immer die aktuelle Realität abbilden.

Wie dokumentiere ich Software-Versionen bei mehreren MVZ-Standorten?

Führen Sie eine einfache Freigabetabelle pro Standort: Datum, Standort, Software-Version, freigebende Person, Bemerkungen. Im Schadensfall müssen Sie beweisen können, dass Sie wussten, welche Systeme wo liefen und die Risiken bewertet haben.