Audit-Vorbereitung Reha: Welche Spuren KI hinterlässt

Die Audit-Saison einer Reha-Klinik beginnt selten mit einer Ankündigung, die alle vier Audit-Klassen bündelt. Im Frühjahr kommt die Peer-Review-Stichprobe der Deutschen Rentenversicherung (DRV) — eine Auswahl von Entlassungsberichten geht zur strukturierten Bewertung an peer-Reha-Mediziner:innen. Im akut-nahen Bereich prüft der Medizinische Dienst (MD, ehemals Medizinischer Dienst der Krankenversicherung MDK; seit dem MDK-Reformgesetz 2020 unabhängige Körperschaft) die Strukturqualität nach eigener Logik. Die zuständige Datenschutz-Aufsicht kann in jedem Monat eine Anfrage einreichen — Verarbeitungsverzeichnis, Auftragsverarbeitungs-Verträge, Speicher-Orte. Daneben läuft, wenn das Haus zertifiziert ist, der drei-Jahres-Zyklus des Audits nach der Norm für ein Information Security Management System (ISMS), ISO/IEC 27001. Sobald in einem Bericht eine vom KI-System generierte oder strukturell vorbereitete Aussage steht, kommt eine neue Klasse von Fragen hinzu — Fragen, die das Peer-Review im Berichts-Sinn nicht primär stellt, die die Strukturprüfung im akut-nahen Bereich nicht primär stellt, die aber an jeder dieser Audit-Klassen am Rand auftauchen werden.

Die methodische KI-Audit-Literatur konvergiert seit Ende der 2010er Jahre auf eine Architektur mit vier Spuren-Klassen. Mitchell et al. (2019) formulieren die Modell-Karte (Model Card) als strukturierte Pro-Modell-Dokumentation: bestimmungsgemäßer Einsatz, Anwendungs-Grenzen, Trainings-Daten-Charakterisierung, Evaluations-Ergebnisse. Sie ist die Grundlage einer auditierbaren Modell-Provenienz. Gebru et al. (2021) ergänzen das Gegenstück auf der Daten-Seite — Datensatz-Karten (Datasheets) — und beantworten die Trainings-Daten-Herkunfts-Frage mit eigener Struktur. Raji et al. (2020) ordnen die Spuren-Kette in einen internen KI-Audit-Rahmen ein, der Modell-Karte, Datensatz-Karte, Risiko-Analyse, Test-Berichte, Freigabe-Spuren und Monitoring-Spuren als aufeinander aufbauende Artefakte beschreibt. Die drei Texte sind Vorschläge aus dem akademischen ML-Diskurs, keine verbindlichen Standards; ihre Übertragung in die deutsche Klinik-Audit-Praxis erfolgt durch operationelle Adaption. Die Klasse der Forderung ist über die drei Texte und über die Folge-Literatur konvergent.

Drei Audit-Klassen, drei Frage-Logiken

Die DRV-Peer-Review-Verfahrensbeschreibung bewertet eine Stichprobe der Entlassungsberichte einer Reha-Einrichtung anhand strukturierter Bewertungsmerkmale. Bewertet wird die schriftliche Bericht-Qualität — Vollständigkeit, Plausibilität der Indikationsstellung, Begründungs-Tiefe der sozialmedizinischen Beurteilung, Operationalisierung der Reha-Ziele, Verlaufs-Lücken — durch peer-Reha-Mediziner:innen auf einer mehrstufigen Skala. Das Verfahren bewertet das Berichts-Ergebnis, nicht den Berichts-Entstehungsweg. Wie Auditor:innen mit erkennbar KI-vorbereiteten Bericht-Anteilen umgehen, ist in der Verfahrensbeschreibung 2026 nicht primär ausgeformt; die Wahrnehmung in der Praxis variiert. Bei sichtbaren Synthese-Mustern in einem Bericht — etwa zwei Vorbefunde in einer dritten Aussage zusammengeführt — kann ein Hinweis auf die Quellenzuordnung der einzelnen Bericht-Aussagen folgen. Die DRV empfiehlt Qualitäts-Merkmale, sie verbindet sie nicht im Sinne einer einzeln abrechenbaren Vorgabe.

Die Strukturprüfung des Medizinischen Dienstes im akut-nahen Bereich folgt einer eigenen Logik. Sie adressiert organisatorische, personelle und apparative Strukturqualität nach Standards des MD Bund. Sie ist nicht identisch mit der Begutachtung im Einzelfall, in der die Indikation einer Versorgungs-Leistung pro Versicherter oder Versicherter durch den MD geprüft wird; Strukturprüfung adressiert die Einrichtung, Begutachtung adressiert den Einzelfall. Beide Prüf-Sprachen treffen auf eine Reha-Klinik mit akut-nahen Anteilen unterschiedlich; in beiden ist die KI-Generierungs-Spur derzeit nicht primär adressierter Prüf-Gegenstand. Die Erfahrung der vergangenen Jahre zeigt aber, dass an Stellen, an denen ein Bericht oder eine Akte sichtbare Strukturen vorgefertigter Textbausteine zeigt, eine Frage nach Herkunft und Freigabe folgt — unabhängig davon, ob das Verfahren KI-Vorbereitung oder Vorlagen-Arbeit nennt.

Die Datenschutz-Aufsicht — auf Bundes-Ebene der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI), in der klinischen Aufsicht überwiegend die Landesdatenschutz-Beauftragten — prüft in einer Reha-Klinik klassischerweise das Verarbeitungsverzeichnis, die Auftragsverarbeitungs-Verträge mit IT-Anbietern, die Speicher-Orte personenbezogener Daten, die Lösch-Konzepte und die technischen und organisatorischen Maßnahmen. Bei einer KI-gestützten Doku-Anwendung kommen Fragen zur Trainings-Daten-Herkunft, zur Auftragsverarbeitungs-Beziehung gegenüber Modell-Anbietern, zur Speicherung der Modell-Eingaben und -Ausgaben und zur Lösch-Mechanik hinzu. Die Aufsichts-Praxis ist heterogen zwischen den Bundesländern; die genaue Frage-Schwerpunkt-Setzung variiert. Das Klassen-Bild bleibt stabil: drei Audit-Sprachen, drei Bewertungs-Anker, eine gemeinsame Frage nach den Spuren, die das KI-System hinterlässt.

Erste Spur: Modell-Provenienz

Die erste Spuren-Klasse ist die Modell-Provenienz: Welches Modell hat die Aussage erzeugt, in welcher Version, mit welchen Anwendungs-Grenzen? Die Modell-Karte in der Form von Mitchell et al. liefert die Antwort: Modell-Identifier, Versions-Stand, bestimmungsgemäßer Einsatz (Bericht-Vorbereitung in der Reha-Aufnahme, in der Verlaufs-Doku, in der Entlass-Synthese), Anwendungs-Grenzen (etwa: nicht für Indikations-Entscheidungen ohne ärztliche Prüfung, nicht für sozialmedizinische Beurteilung autonom). Die Modell-Karte gehört nicht in den Bericht selbst — sie liegt im Audit-Ordner der ärztlichen Leitung und der IT-Leitung und wird auf Nachfrage vorgelegt. Sie ist eine Pro-Version-Aussage, keine einmalige; bei Modell-Wechseln und Versions-Aktualisierungen entsteht ein neuer Eintrag mit Datum, Begründung und Verantwortlichkeit. Die Datensatz-Karte in der Form von Gebru et al. ergänzt die Trainings-Daten-Herkunft auf Anbieter-Seite — der Klinik-Anteil ist meist die Frage nach der Modell-Wahl und der vertraglichen Auftragsverarbeitungs-Lage, nicht die nach den Trainings-Daten selbst.

Zweite Spur: Eingabe-Ausgabe-Bezug pro Aussage

Die zweite Spuren-Klasse ist der Eingabe-Ausgabe-Bezug auf Aussage-Ebene: Welche Eingabe (Vorbefund, Anamnese, ärztliche Eintragung) hat zu welcher generierten Aussage geführt? Die Frage ist nicht „welche Datei wurde eingelesen“ — sie ist „welche konkrete Aussage in der generierten Synthese geht auf welche konkrete Quell-Eintragung zurück“. Die Granularität entscheidet die Antwort. Eine Architektur, die nur Datei-Ebenen-Bezüge speichert, beantwortet im Audit-Fall die schwächere der beiden Fragen; eine Architektur, die jede Aussage einzeln auf eine Quell-Stelle zurückführt, beantwortet die stärkere. Das ist die operative Antwort auf eine Klasse von Synthese-Mustern, in denen zwei einzeln richtige Eingaben zu einer dritten Aussage führen, die in keiner der beiden Eingaben als solche steht — die Logik ist im Beitrag „Provenienz-Nachverfolgung: Warum jede klinische Aussage eine Quelle braucht“ ausführlicher dargestellt. Im Audit-Fall heißt das: Die Stichprobe öffnet einen Bericht, klickt auf eine Bericht-Aussage, sieht die zugrunde liegende Eingabe und sieht die Modell-Version, die die Synthese erzeugt hat. Drei Klicks, drei sichtbare Spuren.

Dritte Spur: Freigabe als sichtbares Ereignis

Die dritte Spuren-Klasse ist die Freigabe. Eine generierte Aussage wird in der Reha-Doku nicht ohne ärztliche oder therapeutische Prüfung in den Bericht übernommen; die Freigabe ist die Stelle, an der die fachliche Verantwortung sichtbar wird. Im Audit-Fall ist die Frage: Welcher Log-Eintrag dokumentiert die Freigabe — mit Zeitstempel, freigebender Person, Verfahrens-Stand der Aussage zum Freigabe-Zeitpunkt? Die Freigabe ist kein impliziter Schritt im Hintergrund. Sie ist ein eigener Eintrag, der zeigt, dass eine ärztliche oder therapeutische Fachperson das System-Ergebnis gelesen, geprüft und übernommen oder verworfen hat. Bei einer ablehnenden Freigabe entsteht ein eigener Eintrag mit Begründung. Die DRV-Peer-Review fragt diese Spur nicht direkt im Bewertungs-Bogen ab; sie wird sie aber bei einer Rück-Frage zu einer auffälligen Bericht-Stelle zugrunde legen. Die Datenschutz-Aufsicht fragt sie über die technischen und organisatorischen Maßnahmen ab. Die ISMS-Auditierung im Rahmen ISO/IEC 27001 fragt sie als Bestandteil der Logging- und Zugangs-Kontrollen ab.

Vierte Spur: Anpassungs-Spur nach der Freigabe

Die vierte Spuren-Klasse ist die Anpassungs-Spur. Eine vom System vorbereitete Aussage wird in der Praxis selten unverändert übernommen — sie wird gekürzt, präzisiert, im Reha-Ziel ergänzt, im Verlaufs-Bezug umformuliert. Die Anpassungs-Spur dokumentiert, welche Stellen der freigegebenen Aussage gegenüber der System-Vorlage angepasst wurden. Sie macht im Audit-Fall sichtbar, an welchen Stellen die fachliche Beurteilung gegenüber der System-Synthese eigene Akzente gesetzt hat. Sie ist auch das Gegenstück zur ärztlichen Verantwortung: Eine ärztliche Fachperson übernimmt eine Aussage entweder im Wortlaut oder in einer angepassten Form; in beiden Fällen ist die Aussage anschließend ihre. Die Anpassungs-Spur trennt diese beiden Fälle für die spätere Lese sichtbar. Im IT-Grundschutz-Rahmen des Bundesamts für Sicherheit in der Informationstechnik (BSI) gehört Logging mit Anpassungs-Tiefe zu den etablierten Bausteinen; die KI-spezifische Erweiterung ist 2026 noch im Aufbau, die methodische Grundlage steht.

Eine Architektur, die alle vier Spuren bereitstellt

Aus der Lese der vier Spuren-Klassen folgen vier Architektur-Anforderungen an eine KI-Doku-Anwendung in der Reha-Klinik. Erstens: Die Modell-Karte liegt pro Modell-Version mit Datum, bestimmungsgemäßem Einsatz und Anwendungs-Grenzen schriftlich vor und wird bei Modell-Wechsel fortgeschrieben. Zweitens: Jede generierte Aussage führt auf eine konkrete Quell-Eintragung zurück — die Auflösung ist Aussage-granular, nicht Datei-granular. Drittens: Die Freigabe ist ein eigener Log-Eintrag mit Zeitstempel, fachlich-verantwortlicher Person und Verfahrens-Stand der Aussage. Viertens: Die Anpassungs-Spur dokumentiert, welche Teile der Aussage gegenüber der System-Vorlage geändert wurden. Diese vier Anforderungen liegen unterhalb der Audit-Klassen-Sprache; sie werden in DRV-Peer-Review-Rück-Fragen, in MD-Struktur-Nachfragen und in Datenschutz-Audit-Fragen jeweils anders verlangt — die Substanz bleibt dieselbe. Die Norm ISO/IEC 27001:2022 adressiert die Logging- und Zugangs-Kontroll-Schicht im ISMS-Geltungsbereich; die Norm ISO/IEC 42001:2023 ergänzt einen KI-Management-Rahmen mit Modell-Lebenszyklus, KI-Risiko und KI-Audit. Beide ersetzen sich nicht; die Architektur-Forderung an die vier Spuren steht unterhalb beider Normen.

Spuren entstehen genau dann, wenn die Architektur sie beschreibbar führt — sonst nicht. Die vier Klassen sind in der akademischen KI-Audit-Literatur seit gut einem halben Jahrzehnt konvergent dokumentiert; die deutschen Audit-Sprachen fragen sie jeweils anders ab, das Gefragte bleibt strukturell gleich. Die Audit-Vorbereitung verschiebt sich damit von der Frage „Wie reagieren wir auf die nächste Anfrage“ zur Frage „Welche Spuren liegen heute in welcher Auflösung vor“. Die zweite Frage ist die einzige, die sich vor dem Audit-Termin beantworten lässt.