Wenn KI Differentialdiagnosen vorschlägt: Was die Architektur leisten muss

Eine Klinik-IT-Leitung eines kommunalen Hauses mit etwa 400 Betten liest im Frühjahr 2026 die Web-Proxy-Logs einer Routine-Auswertung. Drei Stations-Subnetze fallen auf: regelmäßige Aufrufe an chat.openai.com, claude.ai und gemini.google.com, häufig im Minuten-Takt nachmittags um die Visiten-Schluss-Zeit. Eine technische Stichprobe an einem Stations-Rechner zeigt, was die Logs nicht zeigen: eine Eingabe-Folge aus Symptomen, Laborwerten und Vorbefund-Fragmenten, eine ärztliche Anfrage nach möglichen Differentialdiagnosen. Die Anfrage ist nicht abwegig — sie ist klinisch fachlich sortiert. Sie ist nur in die falsche Architektur hineingestellt. Das Bedürfnis dahinter ist legitim; die Architektur, die ihm Raum gibt, ist es nicht. Wer als IT-Leitung oder ärztliche Leitung darauf reagieren will, hat zwei Wege vor sich: die Aufrufe blockieren — was die Anfrage in das Privathandy verlagert — oder eine architektonisch tragfähige Differentialdiagnose-Unterstützung im eigenen Haus bereitstellen. Die zweite Antwort ist die strukturell belastbare. Fünf Architektur-Anforderungen tragen sie.

Anforderung 1 — Kontrollierter Datenfluss

Die erste Anforderung beschreibt nicht die Modell-Qualität, sondern den Weg, den die ärztliche Eingabe nimmt. In den Reviews zur klinischen Entscheidungsunterstützung im New England Journal of Medicine AI (NEJM AI, 2024–2026) wird die Eingabe-Ausgabe-Kette eines klinischen KI-Werkzeugs als prüfbare Grenze beschrieben — nicht als blackbox-Fluss zu einem externen Modell-Anbieter. Kontrollierter Datenfluss heißt operativ: die ärztliche Eingabe verlässt den klinischen Datenraum nicht in Konsumenten-Endpunkte, mit denen die Klinik keinen Vertrag hat; die Verarbeitung läuft in einem benannten Verarbeitungs-Kontext, dessen Stellen — Modell-Anbieter, Cloud-Provider, Beobachtungs-Dienstleister — vollständig im Auftragsverarbeitungs-Vertrag (AVV) der Klinik geführt werden; und die Sitzung wird beendet, ohne dass die Eingabe in ein Trainings-Korpus eines Modell-Hosters eingeht. Diese drei Punkte sind keine Datenschutz-Forderungen aus politischer Vorsicht, sie sind die Vor-Strecke jeder klinisch sinnvollen Nachprüfbarkeit. Eine Differentialdiagnose, deren Eingabe man im Zweifelsfall nicht mehr findet, ist keine ärztliche Frage mehr — sie ist eine Spur in einem Logfile, das das Haus nicht besitzt.

Anforderung 2 — Datenminimierung in der Eingabe

Die zweite Anforderung ist die strukturelle Variante einer klinisch lange bekannten Disziplin. Wer einer ärztlichen Kollegin am Konsil-Telefon einen Fall vorträgt, nennt selten den Geburtsnamen — selten die exakte Adresse. Ein klinisch verlässliches Differentialdiagnose-Werkzeug führt diese Disziplin in die Eingabe-Schnittstelle hinein: identifizierende Merkmale werden vor der Modell-Anfrage entfernt oder pseudonymisiert, ohne dass die klinisch relevanten Größen — Alter in Spannen, Symptome, Verlaufs-Zeit, Vorbefunde in struktureller Form — verloren gehen. Die Verordnung (EU) 2024/1689 — der AI Act — nennt für KI-Systeme im Gesundheitsbereich (Anhang III Nr. 5) Anforderungen an Daten und Daten-Governance (Art. 10), Aufzeichnungs-Pflichten (Art. 12) und Transparenz (Art. 13). Datenminimierung ist die operative Übersetzung dieser Architektur-Anforderung in den Eingabe-Schritt. Sie ist nicht die rechtliche Auslegung der Verordnung — sie ist die strukturelle Voraussetzung dafür, dass die Frage nach der Differentialdiagnose im klinisch-fachlichen Register bleibt und nicht zu einer Personen-bezogenen Verarbeitung gerät, die später vor der Datenschutz-Aufsicht zu erklären ist.

Anforderung 3 — Quellen-Transparenz in der Ausgabe

Ein Differentialdiagnose-Vorschlag ohne benannte Quelle ist ein Modell-Stilmittel, keine klinische Aussage. Die systematischen Reviews zur Retrieval-Augmented-Generation-Architektur (RAG) in npj Digital Medicine beschreiben den Unterschied technisch: ein Sprachmodell allein generiert eine plausibel klingende Antwort; eine RAG-Architektur ergänzt die Ausgabe um benannte Quellen aus einem definierten Korpus — Leitlinien, klinische Datenbanken, eigene Klinik-Standards. Die Quellen-Bindung ist nicht ein Schmuck-Element, sie ist die Vorbedingung der klinischen Nachprüfbarkeit. Ein Beitrag in Nature Medicine (2024) ordnet die Größenordnung: generative Modelle erreichen in strukturierten Vignetten-Benchmarks diagnostische Genauigkeiten zwischen etwa sechzig und siebzig Prozent — Vignetten-Studien, kein klinischer Alltag. Die Lücke zur ärztlichen Praxis bleibt erheblich, weil reale Befunde unstrukturierter, lückenhafter und kontextbedürftiger vorliegen. Genau deshalb hängt die klinische Verwendbarkeit eines Vorschlags nicht an der Modell-Genauigkeit allein, sondern an der Frage, ob die ärztliche Person hinter dem Vorschlag jede einzelne Aussage zu ihrer Quelle zurückführen kann.

Anforderung 4 — Provenienz-Nachverfolgung pro Aussage

Quellen-Transparenz im Ausgabe-Block ist die eine Hälfte; Provenienz-Nachverfolgung pro einzelner Aussage ist die andere. Eine klinische Antwort, die fünf Differentialdiagnosen vorschlägt und am Schluss eine Liste mit drei Leitlinien-Anhängen führt, leistet die Quellen-Transparenz formal — sie löst aber die strukturelle Aufgabe nicht. Provenienz-Nachverfolgung heißt operativ: jede einzelne Aussage trägt im System einen Verweis auf den Beleg-Abschnitt, aus dem sie stammt; die ärztliche Person sieht im Ausgabe-Block nicht eine flache Liste am Schluss, sondern eine pro Satz auflösbare Quelle. Diese Architektur-Eigenschaft beantwortet die Klasse von Fehlern, die in der Modell-Praxis als Halluzination bekannt ist, strukturell — nicht durch ein größeres Modell, sondern durch eine Architektur, die kein Aussage-Stück ausgibt, das nicht zur Beleg-Stelle zurückführbar ist. Eine Aussage ohne Belegs-Verweis wird im klinisch tragfähigen Werkzeug entweder als Modell-eigene Vermutung markiert oder gar nicht ausgespielt. Dieselbe Disziplin verändert die ärztliche Lese-Praxis: die Frage am Ende eines Differentialdiagnose-Vorschlags ist nicht „klingt das plausibel“, sondern „auf welchen Beleg stützt sich genau dieser Punkt“.

Anforderung 5 — Audit-Trail über die Nutzung

Die fünfte Anforderung trägt nicht die Eingabe und nicht die Ausgabe, sondern die spätere Rekonstruierbarkeit der Nutzung. Ein Audit-Trail für ein Differentialdiagnose-Werkzeug hält fest, welche ärztliche Person zu welchem Zeitpunkt welche Anfrage gestellt hat, welcher Modell-Stand geantwortet hat, welche Quellen die Antwort getragen haben und welche Freigabe in der Akte hinterlegt wurde. Vier Einträge pro Nutzungs-Vorgang reichen für die Rekonstruktion strukturell aus — Anfrage, Modell-Stand, Quellen-Liste, Freigabe-Entscheidung. Ein fünfter Eintrag — die anonymisierte Spur, dass die ärztliche Person den Vorschlag bewusst nicht übernommen hat — schließt die Linie für die Lese im Folge-Jahr. Der Stanford-HAI-AI-Index 2024 ordnet die Studien-Lage international ein: weniger als fünfzehn Prozent klinischer KI-Studien sind randomisiert, ein deutlicher Anteil bleibt retrospektiv. Diese Lage wird die hauseigene Aufsicht nicht in absehbarer Zeit ändern. Was sie hingegen ändert, ist die Rolle des hauseigenen Audit-Trails: wo die publizierte Studien-Lage dünn bleibt, trägt die eigene Mess-Disziplin die Lücke. Ein Audit-Trail, der über zwölf Monate die Nutzung führt, beantwortet eine Aufsichts-Frage im Frühjahr 2027 strukturell — nicht aus dem Gedächtnis, nicht aus einer nachgeholten Auswertung, sondern aus einer Aufzeichnung, die als Bestandteil der Architektur entstanden ist. Ohne diesen Trail ist die spätere Rechenschaft eine Behauptung; mit ihm ist sie eine Wiedergabe.

Was die fünf Anforderungen in der Beschaffungs-Lese verändern

Die fünf Anforderungen sind keine Bedenken-Liste vor der Beschaffung. Sie sind die Beschaffungs-Lese-Vorlage. Vor dem nächsten Pitch zu einem Werkzeug, das im Klinik-Alltag Differentialdiagnosen vorschlagen soll, werden im eigenen Haus fünf Fragen schriftlich geführt: in welchem benannten Verarbeitungs-Kontext läuft die Eingabe; welche Datenminimierung greift vor der Modell-Anfrage; welche Quellen bindet die Ausgabe und in welcher Form; welche Provenienz pro Aussage liefert die Architektur; und welcher Audit-Trail trägt die spätere Rekonstruktion. Die fünf Antworten lassen sich aus dem Architektur-Dokument des Anbieters ablesen — sie lassen sich nicht aus einer Demo ableiten, in der ein Anwendungs-Fall durchgespielt wird. Wer die fünf Linien als Eingangs-Filter führt, liest den Pitch in der Folge anders: nicht als Antwort auf das eigene Bedürfnis nach Differentialdiagnose-Unterstützung, sondern als Hinweis darauf, ob das Werkzeug die ärztliche Frage in einer Architektur beantwortet, die im eigenen Haus auch im zweiten Jahr noch trägt. Die hauseigene Ordnung dieser fünf Fragen kostet wenig — ein Anforderungs-Blatt, eine technische Sitzung mit der IT-Leitung, eine Abstimmung mit der Datenschutz-Beauftragten. Sie ist gleichwohl der Schritt, den die meisten Häuser im Frühjahr 2026 vor sich herschieben und in der Folge nachholen, wenn die erste Aufsichts-Anfrage eintrifft.

Eine letzte Beobachtung am Rand. Die ärztlichen Anfragen in den Proxy-Logs des kommunalen Hauses, mit denen dieser Beitrag begonnen hat, gehen nicht weg, weil eine technische Sperre die Endpunkte blockiert. Sie verlagern sich — auf das Privathandy, in die Mittagspause, in den Schichtwechsel. Eine architektonisch tragfähige Differentialdiagnose-Unterstützung ist die strukturelle Antwort auf eine Frage, die in der Klinik bereits gestellt wird; sie unterscheidet sich von der heutigen Praxis nicht in der Frage, sondern in der Stelle, an der sie beantwortet wird. Die ärztliche Frage ist legitim. Die Architektur, in die sie hineingestellt wird, entscheidet darüber, ob sie eine klinische Frage bleibt oder zu einem Datenschutz-Vorfall wird. Die fünf Anforderungen halten die Frage in der klinischen Spalte — die Modell-Demo zeigt davon nichts, weil sie strukturell nicht die Stelle ist, an der diese Linien sichtbar werden.