Die Audit-Spur eines Agenten: Was die ärztliche Direktion sehen können muss

Am Montagmorgen liegt der Wochenend-Bericht der agentischen Aufnahme-Plattform auf dem Bildschirm der ärztlichen Direktion. Vierzehn Anfragen wurden über das Wochenende automatisch geprüft, sieben Patienten-Profile gebaut, drei Nachversorger angefragt, eine Anfrage abgelehnt. Die Konsole zeigt einen Status pro Operation — „erledigt“, „abgelehnt“, „in Klärung“. Was die Konsole nicht zeigt, ist die Frage, die am Donnerstag im Aufsichtsrat tatsächlich beantwortet werden muss: warum genau wurde Anfrage Nummer elf abgelehnt, und mit welcher Begründung lässt sich diese Ablehnung gegenüber einer dritten Partei vertreten. Die ärztliche Direktion trägt die klinische und regulatorische Verantwortung für jede dieser vierzehn Operationen, ohne sie selbst ausgeführt zu haben. Sie braucht — pro Operation, nicht pro Plattform — eine prüfbare Spur. Diese Spur ist nicht ein Compliance-Anhang, der nach der Operation produziert wird; sie ist das Artefakt, das die Verantwortbarkeit überhaupt erst konstituiert.

Künstliche Intelligenz (KI) verschiebt die Frage der Audit-Tauglichkeit, sie hebt sie nicht auf. Eine Plattform, die nur antwortet, lässt die ausführende Entscheidung beim Menschen — die Audit-Spur entsteht in der ärztlichen Akte des Hauses, nicht in der Plattform. Eine Plattform, die handelt, bewegt die Entscheidung in das Software-System hinein. Damit wandert auch der Ort der Audit-Spur. Sie muss in der Plattform selbst entstehen, pro Operation, in einer Form, die sich später unabhängig rekonstruieren lässt — ohne dass die Direktion auf die Bereitschaft des Anbieters angewiesen ist, einen Sonder-Export zu fahren.

Was die Regelwerke übereinstimmend verlangen

Vier Regelwerke beschreiben die Audit-Tauglichkeit agentischer KI-Architekturen aus unterschiedlichen Perspektiven; sie konvergieren auf einer überraschend ähnlichen Anforderungs-Liste. Die Europäische Verordnung über Künstliche Intelligenz (EU AI Act, Verordnung (EU) 2024/1689) fordert in Artikel 12 die automatische Aufzeichnung der Ereignisse, in Artikel 14 die menschliche Aufsicht, in Artikel 15 die Genauigkeit, Robustheit und Cybersicherheit über den Lebenszyklus, in Artikel 16 die Nachverfolgbarkeit der Funktionsweise — für Klinik-Anwendungen, die unter Anhang III als Hochrisiko-System klassifiziert werden, gelten diese Pflichten in der breiten Anwendung ab dem 2. August 2026. Der Management-System-Standard ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system, erstausgegeben Dezember 2023 von der International Organization for Standardization (ISO) und der International Electrotechnical Commission (IEC) — beschreibt Risiko-Bewertung, Aufzeichnungen, Versionierung und Audit als Pflicht-Klauseln eines KI-Management-Systems. Das NIST AI Risk Management Framework (NIST AI 100-1, Januar 2023), herausgegeben vom National Institute of Standards and Technology, ergänzt um das Generative AI Profile (NIST AI 600-1, Juli 2024) — strukturiert das Risikomanagement in vier Funktionen — Govern, Map, Measure, Manage —; Measure verlangt eine Mess- und Aufzeichnungs-Disziplin pro Schritt, Manage verlangt einen Eskalations- und Korrektur-Pfad als operative Pflicht. Und die U.S. Food and Drug Administration (FDA) Good Machine Learning Practice (GMLP) Guiding Principles, gemeinsam herausgegeben mit Health Canada und der britischen Medicines and Healthcare products Regulatory Agency (MHRA) im Oktober 2021, ergänzt durch die FDA-Final-Guidance zum Predetermined Change Control Plan (Dezember 2024), beschreiben Versionierung und Change-Tracking als Mindeststandard für Software as a Medical Device (SaMD). Die vier Regelwerke konvergieren auf einer Anforderungs-Liste, die sich operativ in fünf Audit-Komponenten pro Operation übersetzen lässt.

Fünf Komponenten, die pro Operation persistent geführt werden müssen

Erstens: ein Hash der Eingangsdaten in dem Zustand, in dem der Agent sie las. Eine Aufnahmeanfrage trägt einen Patienten-Status, einen Vorbefund-Stand, eine Pflegegrad-Information — und sie verändert sich, sobald die einweisende Praxis nachliefert. Wenn der Agent am Sonntag um 14:32 Uhr eine Anfrage prüft, muss die spätere Audit-Spur den Datenstand zu diesem Zeitpunkt eindeutig identifizieren, nicht den Stand vom Montagmorgen. Ein kryptographischer Hash der gelesenen Felder leistet das, ohne den Datenstand selbst zu duplizieren. Ohne diesen Hash wandert die Frage „auf welcher Datenbasis hat der Agent entschieden“ in den Bereich der nachträglichen Plausibilisierung — und die ist keine Audit-Spur.

Zweitens: die Version der Entscheidungslogik in der Form, in der sie zum Zeitpunkt der Operation aktiv war. Eine agentische Plattform trägt eine Entscheidungslogik in mehreren Schichten — Prompts, Regelsätze, Tool-Definitionen, Schwellenwerte für die Eskalation. Diese Schichten ändern sich häufiger, als die Konsole nahelegt: ein Prompt wird angepasst, ein Schwellenwert verschoben, eine Tool-Beschreibung präzisiert. Wenn die Direktion eine Operation rekonstruieren will, braucht sie die Konfiguration, die in dieser Sekunde lief — nicht die heutige. Versionierung dieser Schichten ist die zweite Komponente; sie deckt sich mit der Versionierungs-Disziplin, die FDA GMLP für SaMD beschreibt.

Drittens: die Modellversion mit Datum. Ein Sprachmodell ist nicht ein statisches Werkzeug, sondern ein versioniertes Artefakt, das sich zwischen den Vertragsperioden — und manchmal innerhalb einer einzigen Vertragsperiode — verändert. Editorial- und Review-Beiträge in NEJM AI 2024–2026 und Original-Beiträge in npj Digital Medicine 2024–2026 zeigen strukturell, dass die Stabilität klinisch verwertbarer Aussagen agentischer Architekturen — gestützt auf Large Language Models (LLM) — strukturell von der Provenienz pro Schritt abhängt; die Modellversion ist Teil dieser Provenienz. Diese Befunde stammen aus internationalen Settings und sind nicht 1:1 auf eine deutsche Klinik übertragbar; die strukturelle Aussage „Provenienz pro Schritt prägt Audit-Tauglichkeit“ trägt jedoch über die Settings hinweg, weil sie an der Engineering-Mechanik hängt. In einer Audit-Spur reicht es nicht, ein Sprachmodell der Klasse anzugeben — die genaue Version mit Datum gehört in jede Operations-Zeile.

Viertens: das Ergebnis mit Provenienz pro Aussage. Eine Begründung „Anfrage abgelehnt wegen unzureichender Vorbefund-Lage“ ist als Status-Feld zu wenig. Die Audit-Spur muss zeigen, welche Quell-Felder zur Begründung herangezogen wurden, in welcher Reihenfolge der Agent sie kombiniert hat, an welcher Stelle eine Aggregation entstanden ist. Die in der Forschung zu agentischen Systemen wiederholt beschriebene Klasse der Aggregations-Halluzination — eine Drittaussage, die in keiner der Quell-Aussagen stand — wird genau dort sichtbar oder unsichtbar, wo Provenienz pro Aussage geführt wird oder nicht. Provenienz heisst hier: jede klinische Aussage des Agenten ist mit Quelle, Lese-Datum und Begründungs-Pfad zurückführbar — nicht in einem Sonder-Export, sondern als Standard-Ausgabe der Operation. In diesem Punkt knüpft der Mindeststandard an den Aiomics-Anker „Das Fax als Angriffsvektor“ an: Eingangs-Pfade, die nicht kontrolliert sind, reissen Lücken in die Audit-Spur, die spätere Provenienz nicht mehr schliessen kann.

Fünftens: der Eskalations-Pfad. Eine agentische Plattform hat Schwellenwerte, an denen sie aufhört zu handeln und an die ärztliche Direktion zurückgibt — eine ungeklärte Pflegegrad-Frage, eine widersprüchliche Vorbefund-Lage, eine Anfrage, deren Profilbau nur mit aggregierten Aussagen möglich wäre. Diese Schwellen sind keine Marketing-Funktion; sie sind versions-feste Konfiguration. Die Audit-Spur muss dokumentieren, warum eine Operation nicht eskaliert wurde — also welche Bedingung greifend hätte sein müssen, aber nicht griff, oder welcher Schwellenwert greifend war und unter dem Eingangsdaten-Stand keine Eskalation auslöste. Der Eskalations-Pfad ist die Komponente, in der die menschliche Aufsicht aus Artikel 14 EU AI Act und die Manage-Funktion des NIST AI Risk Management Framework operativ zusammenfallen.

Was die Direktion in der Pitch-Diskussion sehen können muss

Im Beschaffungs-Gespräch vor einer agentischen Plattform reicht das Marketing-Wort „Audit-Trail“ nicht. Die Direktion kann an einer einzigen, beliebigen Beispiel-Operation prüfen, ob die fünf Komponenten persistent geführt werden — und in welcher Form. Erstens: lassen Sie sich für eine konkrete Anfrage den Eingangsdaten-Hash zeigen, mit Zeitstempel und Quell-Feld-Liste. Zweitens: lassen Sie sich die Konfiguration der Entscheidungslogik aus der Sekunde der Ausführung zeigen — Prompt, Regelsatz, Tool-Definitionen, Schwellenwerte. Drittens: lassen Sie sich die Modellversion mit Datum zeigen. Viertens: lassen Sie sich für eine Aussage des Agenten die Provenienz zur Quelle nachweisen — mit Lese-Datum und Begründungs-Pfad. Fünftens: lassen Sie sich den Eskalations-Pfad zeigen, mit den Bedingungen, unter denen er greift, und einer Beispiel-Operation, in der er gegriffen hat. Eine Plattform, die diese fünf Punkte substantiell beantwortet, beschreibt sich auf der Architektur-Schicht. Eine, die ausweicht — auf Dashboards, Status-Felder, generische Zusicherungen — beschreibt sich auf dem Marketing-Header.

Die Audit-Spur ist in dieser Form keine Last, die sich der Plattform zusätzlich aufbürden lässt. Sie ist die Architektur, die die agentische Plattform überhaupt erst klinisch verantwortbar macht. Eine Plattform, die nach Audit gefragt wird und Status-Felder zeigt, beantwortet die Frage nicht. Die ärztliche Direktion sieht die Verantwortung nur, wenn sie die Operation rekonstruieren kann.