Gesundheitsdaten in der Schadenakte: Warum Dokumenten-KI für Versicherer on-premise laufen sollte

In fast jeder Personen- oder Krankenschadenakte liegen Dokumente, die datenschutzrechtlich einer eigenen Kategorie angehören: Arztrechnungen mit Diagnosen, Arbeitsunfähigkeitsbescheinigungen, Befundberichte, Reha-Berichte, medizinische Gutachten. Sobald eine Dokumenten-KI diese Unterlagen liest, verarbeitet sie nicht irgendwelche Belege, sondern Gesundheitsdaten — besondere Kategorien personenbezogener Daten im Sinne von Art. 9 DSGVO.

Das ändert die Anforderungen an die Verarbeitungsstrecke grundlegend. Dieser Beitrag ordnet die Themen fachlich ein: was in der Akte tatsächlich liegt, wo bei Cloud-KI-Diensten die Risiken sitzen, wie die Aufsicht auf den Bezug solcher Dienste blickt und was der Betrieb im eigenen Rechenzentrum konkret verändert. Er ersetzt keine rechtliche Prüfung im Einzelfall — die Bewertung gehört zu Ihrem Datenschutz- und Compliance-Bereich.

Was in der Schadenakte tatsächlich liegt

Die Diskussion über KI in der Schadenbearbeitung wird oft anhand der Werkstattrechnung geführt. Das unterschätzt den realen Aktenbestand. Typisch sind:

• Arztrechnungen mit Abrechnungsziffern, aus denen sich Behandlungen und Diagnosen ableiten lassen
• Arbeitsunfähigkeitsbescheinigungen und Krankenhausberichte
• Befund- und Entlassungsberichte, häufig mit ausführlichem medizinischem Freitext
• Medizinische Gutachten zu Kausalität, Invaliditätsgrad oder Berufsunfähigkeit
• Therapie- und Reha-Unterlagen, Heilmittelverordnungen, Rezepte
• Handschriftliche Notizen auf all dem — Vermerke, Rückfragen, Korrekturen

Ein Punkt wird dabei regelmäßig übersehen: Eine Dokumenten-KI verändert nicht nur, wer diese Unterlagen liest, sondern auch wie tief sie verarbeitet werden. Aus einem Papierstapel, der bisher gelesen und abgelegt wurde, entsteht ein maschinenlesbarer, durchsuchbarer, auswertbarer Datenbestand. Die Verarbeitungstiefe steigt — und mit ihr die Anforderungen an Zweckbindung, Zugriffskonzept und Löschung. Das ist kein Argument gegen Automatisierung. Es ist ein Argument dafür, die Verarbeitung dort zu halten, wo Sie sie steuern können.

Warum Cloud-KI-Dienste hier ein besonderes Risiko tragen

Die Frage ist selten, ob ein Anbieter seriös arbeitet. Die Frage ist, welche Risiken strukturell entstehen, sobald Gesundheitsdaten das eigene Netz verlassen.

Drittstaatentransfer und Zugriffsbefugnisse

Viele leistungsfähige KI-Dienste werden von Konzernen betrieben, die außerhalb der EU ansässig sind oder dort eine Muttergesellschaft haben. Ein Rechenzentrumsstandort in Europa beantwortet die Frage nach behördlichen Zugriffsbefugnissen nicht abschließend, solange der Betreiber einer ausländischen Rechtsordnung unterliegt. Für Datenkategorien nach Art. 9 DSGVO ist die Schwelle für ein tragfähiges Transferkonzept entsprechend hoch.

Telemetrie und Nebenverarbeitungen

Der eigentliche Verarbeitungszweck ist meist sauber geregelt. Die Nebenprozesse sind es seltener: Fehler- und Zugriffsprotokolle, Zwischenspeicher zur Beschleunigung wiederholter Anfragen, Prüfmechanismen gegen missbräuchliche Nutzung, Auswertungen zur Dienstqualität, Support-Zugriffe im Störungsfall. Jeder dieser Prozesse kann Dokumentinhalte oder Ausschnitte davon berühren. Für eine belastbare Bewertung müssen Sie diese Nebenverarbeitungen kennen — und sie müssen abschaltbar oder vertraglich ausgeschlossen sein, nicht nur in den Voreinstellungen deaktiviert.

Modelltraining durch den Anbieter

Ob Kundendaten in die Weiterentwicklung von Modellen einfließen, ist eine der zentralen Fragen — und eine, die sich mit Vertragsversionen ändern kann. Eine Zusicherung, die als abwählbare Option ausgestaltet ist, hat eine andere Qualität als ein vertraglicher Ausschluss. Bei Gesundheitsdaten kommt hinzu, dass sich einmal eingeflossene Information aus einem trainierten Modell praktisch nicht mehr entfernen lässt: Ein Löschersuchen wäre technisch nicht sauber erfüllbar.

Unterauftragnehmerketten

Anbieter von KI-Diensten setzen häufig selbst auf Infrastruktur- und Modellanbieter auf. Für Sie ist relevant, wie tief diese Kette reicht, wer welche Rolle einnimmt und wie Sie über Änderungen informiert werden. Je länger die Kette, desto schwieriger werden Informations- und Prüfungsrechte tatsächlich durchsetzbar — und desto aufwendiger die eigene Dokumentation.

Der aufsichtsrechtliche Rahmen — qualitativ betrachtet

Für Versicherungsunternehmen ist der Bezug von IT-Dienstleistungen kein rein technischer Vorgang. Die aufsichtsrechtlichen Erwartungen an IT und an die Steuerung von Auslagerungen und sonstigem Fremdbezug — geprägt durch die VAIT und, mit Blick auf digitale operationale Resilienz, durch DORA — führen zu einem wiederkehrenden Fragenkatalog. Ohne in die Einzelnormen zu gehen, laufen die Prüfungen typischerweise auf diese Punkte hinaus:

• Einordnung: Handelt es sich um eine Auslagerung, um sonstigen Fremdbezug — und ist der Bezug für kritische oder wichtige Funktionen relevant?
• Risikoanalyse vor Vertragsschluss und regelmäßige Neubewertung im laufenden Betrieb
• Informations-, Zugangs- und Prüfungsrechte — für Sie selbst, für Ihre Interne Revision und für die Aufsicht
• Weiterverlagerung: Transparenz über Unterauftragnehmer und Zustimmungs- beziehungsweise Informationsvorbehalte
• Ausstiegsstrategie: Was passiert bei Kündigung, Insolvenz oder Produktabkündigung — und wie lange dauert die Rückabwicklung realistisch?
• Konzentrationsrisiko: Hängen mehrere kritische Prozesse am selben Anbieter oder an derselben zugrunde liegenden Infrastruktur?
• Registerführung und Dokumentation der vertraglichen Vereinbarungen

Der Punkt ist nicht, dass externe Dienste unzulässig wären — sie sind es nicht. Der Punkt ist der Aufwand: Jede dieser Fragen muss beantwortet, dokumentiert und gepflegt werden. Bei einer Verarbeitung im eigenen Rechenzentrum entfallen viele davon nicht vollständig, aber sie verlagern sich in Bereiche, die Sie ohnehin steuern und für die es bereits etablierte Prozesse gibt.

Was On-Premise konkret ändert

“On-Premise” ist kein Compliance-Siegel. Es ist eine Architekturentscheidung mit konkreten, benennbaren Folgen.

Der Datenfluss endet im eigenen Rechenzentrum

Das ist der wesentliche Unterschied. Dokument, Zwischenergebnis und extrahierte Felder verlassen Ihr Netz nicht. Eine Reihe von Fragen, die bei einem externen Dienst aufwendig zu klären sind, beantwortet sich damit anders:

Frage	Externer KI-Dienst	Betrieb im eigenen Rechenzentrum
Wo werden die Dokumente verarbeitet?	Beim Anbieter, ggf. über weitere Unterauftragnehmer	Auf Ihren Systemen, in Ihrem Netzsegment
Wer kann im Störungsfall Inhalte sehen?	Betriebs- und Supportprozesse des Anbieters	Ausschließlich Ihre Administratoren, nach Ihrem Rollenkonzept
Was passiert mit Protokollen und Zwischenständen?	Anbieterseitig geregelt, für Sie schwer prüfbar	Von Ihnen konfiguriert und mitgelöscht
Fließen Inhalte in Modelltraining ein?	Vertraglich zu klären und laufend nachzuhalten	Technisch ausgeschlossen, wenn kein Rückkanal existiert
Wie ändert sich das Modell?	Aktualisierung durch den Anbieter, teils ohne Ankündigung	Versionierter Modellstand, Wechsel ist Ihre Entscheidung
Was gilt bei Vertragsende?	Migration, Löschnachweise, Übergangsfristen	Daten liegen ohnehin bei Ihnen; kein Datenrücktransport nötig

AVV und TOMs werden schlanker

Wenn keine personenbezogenen Daten an den Softwareanbieter fließen, verschiebt sich die Rolle: Der Anbieter liefert Software und Unterstützung, nicht die Verarbeitung. Auftragsverarbeitung entsteht dann allenfalls punktuell — etwa bei einem Fernwartungszugriff, der bewusst geregelt, protokolliert und auf den Einzelfall begrenzt werden kann. Die technischen und organisatorischen Maßnahmen sind in weiten Teilen die Ihres eigenen Rechenzentrums, das bereits geprüft und dokumentiert ist. Das reduziert nicht die Sorgfaltspflicht, aber die Zahl der Stellen, an denen Sie sich auf Zusicherungen Dritter verlassen müssen.

Modell-Offenlegung wird möglich

Bei einem lokal betriebenen Modell ist beschreibbar, welcher Modellstand im Einsatz ist, wann er gewechselt wurde und welche Ergebnisse er zu welchem Zeitpunkt erzeugt hat. Das ist für zwei Situationen entscheidend: für die Reproduzierbarkeit eines Vorgangs Jahre später und für Auskunftsverlangen betroffener Personen zur Frage, wie ein Ergebnis zustande kam. Bei einem Dienst, der im Hintergrund still aktualisiert wird, ist beides nicht sauber beantwortbar.

Konfidenzwerte und offene Formate machen die Verarbeitung prüfbar

Prüfbarkeit hängt nicht nur am Betriebsort. Wenn jedes extrahierte Feld einen Konfidenzwert und eine Fundstelle im Originaldokument mitbringt und die Ergebnisse in offenen Formaten — JSON, CSV, XML — vorliegen, kann Ihre Interne Revision die Verarbeitung ohne Anbieterwerkzeug nachvollziehen. Zusammen mit dem lokalen Betrieb ergibt das eine Strecke, die von der Dokumenteneingabe bis zum Feld im Schadensystem erklärbar bleibt.

Was On-Premise nicht ersetzt

Der Vollständigkeit halber, weil ein realistisches Bild belastbarer ist als ein werbliches: Der eigene Betrieb verlagert Verantwortung, er beseitigt sie nicht. In Ihrer Hand bleiben Patch- und Schwachstellenmanagement, ein sauberes Berechtigungs- und Rollenkonzept, Netzsegmentierung, Protokollierung und deren Auswertung, Backup- und Wiederanlaufkonzepte, Kapazitätsplanung sowie ein Löschkonzept, das auch Zwischenergebnisse und Verarbeitungsprotokolle erfasst. Wer diese Punkte nicht abdeckt, hat mit einem lokalen System nichts gewonnen — nur die Zuständigkeit verschoben.

Der pragmatische Einstieg: Pilot mit anonymisierten Testbeständen

Der übliche Fehler ist, die Entscheidung an einer Anbieterpräsentation festzumachen. Belastbar wird sie erst an Ihrem eigenen Material. Ein tragfähiger Pilot folgt typischerweise diesen Schritten:

1. Bestand auswählen: eine überschaubare, aber repräsentative Menge realer Vorgänge — einschließlich der schlechten Scans, der Handschrift und der Anlagen-Konvolute. Ein Pilot nur mit sauberen Dokumenten misst nichts.
2. Anonymisieren oder pseudonymisieren: Bei medizinischem Freitext ist echte Anonymisierung anspruchsvoll, weil sich Personen über Kontextangaben rekonstruieren lassen. Realistisch ist häufig eine Kombination aus Pseudonymisierung, reduziertem Bestand und einem abgeschotteten Testsegment — abgestimmt mit dem Datenschutzbeauftragten.
3. Gold-Standard erstellen: Die korrekten Feldwerte für den Testbestand einmal manuell festhalten. Ohne diese Referenz ist jede Genauigkeitsaussage — die des Anbieters wie Ihre eigene — nicht überprüfbar.
4. Konfidenzschwellen kalibrieren: je Feld ermitteln, ab welchem Wert automatische Übernahme vertretbar ist und wie hoch die verbleibende Ausnahmequote ausfällt. Das ist die eigentliche fachliche Arbeit im Pilot.
5. Datenschutz und Mitbestimmung früh beteiligen: Datenschutzbeauftragter, Informationssicherheit, Compliance und — wo einschlägig — der Betriebsrat. Eine Datenschutz-Folgenabschätzung ist bei Art.-9-Daten regelmäßig ein Thema; sie lässt sich mit Pilotergebnissen deutlich besser führen als ohne.
6. Ergebnisse dokumentieren: Feldgenauigkeit auf Ihrem Bestand, Ausnahmequote, Betriebsaufwand, Ressourcenbedarf. Diese Dokumentation ist später die Grundlage sowohl für die Investitionsentscheidung als auch für die aufsichtsrechtliche Nachweisführung.

Am Ende eines solchen Piloten steht keine Anbieteraussage, sondern eine eigene Messung an eigenen Dokumenten — und damit eine Entscheidungsgrundlage, die auch einer Prüfung standhält.

German-OCR im eigenen Rechenzentrum

German-OCR ist für diesen Betriebsmodus ausgelegt: ein eigenes lokales Modell, das on-premise in Ihrer Infrastruktur läuft, ohne Rückkanal zum Hersteller. Es verarbeitet gedruckte Vorlagen ebenso wie Handschrift und fotografierte Belege, liefert pro extrahiertem Feld einen Konfidenzwert samt Fundstelle und exportiert in offenen Formaten in Ihre Bestands-, Schaden- und Archivsysteme. Der Modellstand ist versioniert und wird nicht im Hintergrund ausgetauscht. Entwicklung und Betrieb finden in Deutschland statt.

Damit endet der Datenfluss dort, wo er nach Art. 9 DSGVO am besten aufgehoben ist: in Ihrem eigenen Haus.

Fazit

Gesundheitsdaten in der Schadenakte sind kein Sonderfall, sondern Regelbestand — und sie unterliegen einem strengeren Maßstab als der Rest der Akte. Wer die Dokumentenverarbeitung automatisiert, erhöht die Verarbeitungstiefe und sollte deshalb genau prüfen, wo diese Verarbeitung stattfindet, wer sie einsehen kann und ob sie Jahre später noch erklärbar ist. Der Betrieb im eigenen Rechenzentrum beantwortet mehrere dieser Fragen strukturell statt vertraglich: Der Datenfluss endet im eigenen Haus, das Modell bleibt offenlegbar und versioniert, und die Ergebnisse sind über Konfidenzwerte und offene Formate prüfbar. Der Weg dorthin führt nicht über eine Produktentscheidung, sondern über einen sauber aufgesetzten Pilot mit Ihrem eigenen Bestand.

On-Premise-Einsatz im eigenen Haus besprechen — Kontakt auf german-ocr.de