Erklärbarkeit ohne Replay ist Theater
Die Erklärung, die zu spät kam
Die unbequeme Erklärung kommt meist erst, nachdem die Entscheidung bereits Folgen hatte. Ein Kunde wurde abgelehnt. Eine Patientin wurde weitergeleitet. Eine Studentin wurde markiert. Eine Lieferung wurde verzögert. Ein Bürger wurde vertröstet. Das KI-System hat die Antwort vor Tagen oder Wochen erzeugt, alle waren beschäftigt, die Warteschlange ist weitergezogen, und jetzt will jemand wissen, warum diese Antwort zustande kam. In diesem Moment zeigt sich, ob die Organisation über Erklärbarkeit verfügt oder nur über eine Abteilung für Erklärungen.
Die erste Version wirkt oft plausibel. Ein Dashboard zeigt Konfidenzwerte. Eine Modellkarte besagt, dass das System getestet wurde. Ein generierter Absatz erklärt, dass mehrere Faktoren zum Ergebnis beigetragen haben. Eine Prüferin erinnert sich, dass die Belege damals stimmig aussahen. Ein Log-Export enthält viele Zeilen und wirkt dadurch seriös. Menschen versammeln sich um die Artefakte und beginnen zu erzählen. Sie mögen ehrlich sein. Sie mögen kompetent sein. Sie mögen sogar recht haben. Doch wenn sich der Pfad nicht nachvollziehen lässt, ist die Erklärung eine Inszenierung mit Requisiten.
Replay verändert den Maßstab. Es stellt die Frage, ob die Organisation den Entscheidungspfad aus den tatsächlichen Bestandteilen rekonstruieren kann: Anfrage, Identität, Datenzustand, Abrufergebnisse, Prompt oder Anweisung, Modellversion, Einstellungen, Tool-Aufrufe, Policy-Prüfungen, menschliche Handlungen, Zeitablauf und Ausgabe. Nicht einen ähnlichen Pfad. Nicht einen plausiblen Pfad. Sondern den Pfad, der die Antwort erzeugt hat, oder einen kontrollierten Bericht darüber, warum eine exakte Rekonstruktion unmöglich ist und welcher Teil nicht wiederhergestellt werden kann. Das ist weniger glamourös als ein Erklärungs-Panel. Es ist auch viel schwerer zu fälschen.
Erklärbarkeit ohne Replay ist Theater, weil sie Menschen dazu einlädt, eine Geschichte zu bewundern, statt ein System zu prüfen. Theater ist nicht nutzlos. Gutes Theater kann lehren, trösten, warnen und gelegentlich einen Gemeindesaal am Leben halten. Es sollte nicht darüber entscheiden, ob eine automatisierte Entscheidung rechtmäßig, fair, verhältnismäßig oder korrekt war. Dafür braucht das Publikum die Maschinerie hinter der Bühne.
Warum eine flüssige Begründung nicht ausreicht
Große Sprachmodelle sind sehr gut darin, Begründungen zu erzeugen. Das ist Teil ihres Nutzens und Teil des Problems. Eine Begründung kann klar, plausibel, höflich und losgelöst von dem tatsächlichen Pfad sein, der die Antwort erzeugt hat. Das System kann eine Klassifikation erklären, indem es Faktoren nennt, die plausibel klingen, während der tatsächliche Einfluss von einer veralteten Quelle, einem Prompt-Zweig, einer versteckten Standardeinstellung oder einem Tool-Ergebnis stammte, das im Text nie auftaucht. Der Text kann hilfreich sein. Er ist nicht automatisch ein Beleg.
Das ist kein besonderer moralischer Defekt von KI. Auch Menschen erklären sich im Nachhinein mit großer Kreativität und selektivem Gedächtnis. Der Unterschied liegt im Umfang und in der Beschaffenheit. KI-Systeme können Tausende von Entscheidungen erzeugen, jede mit einer ordentlichen Erklärung, während der operative Pfad vom Verschieben von Daten, Versionen, Caches, Richtlinien und Diensten abhängt. Die Erklärungsebene kann ruhig bleiben, während der zugrunde liegende Prozess sich wie eine Besteckschublade bei einem Erdbeben verhält.
Eine nützliche Erklärung muss zwei Fragen beantworten. Welche Gründe kann eine Person verstehen. Welche Belege zeigen, dass diese Gründe mit dem tatsächlich Geschehenen zusammenhängen. Die erste Frage betrifft die Kommunikation. Die zweite betrifft die Wiedergabe. Wenn die Organisation nur die erste beantworten kann, hat sie möglicherweise eine gute Benutzererfahrung, aber eine schwache Rechenschaftsfläche. Das ist gefährlich, weil die Erklärung gerade dann überzeugender werden kann, wenn sie bescheidener werden sollte.
Es gibt Situationen, in denen eine einfache Erklärung ausreicht. Wenn ein risikoarmer Assistent eine Rechtschreibkorrektur vorschlägt, braucht niemand eine forensische Rekonstruktion der Vokalökonomie. Aber wenn eine Ausgabe Rechte, Geld, Zugang, Sicherheit, professionelles Urteilsvermögen oder öffentliches Vertrauen betrifft, braucht die Organisation mehr als einen flüssigen Grund. Sie braucht einen Weg zurück durch das System. Eine Person sollte fragen können: Zeig mir, was das System gesehen hat, was es tun durfte, welche Version lief, welche Regel angewendet wurde, wer sich darauf verlassen hat und wie ich es anfechten kann.
Wiedergabe ist nicht nur Determinismus
Wenn Menschen von Wiedergabe hören, denken sie oft an das Drücken eines Knopfs und das Erhalten exakt derselben Token-Sequenz. Manchmal ist das möglich. Manchmal nicht. Modelle können stochastisch sein. Externe Dienste können sich ändern. Retrieval-Indizes können aktualisiert werden. Zeitkritische Daten können ablaufen. Ein Tool kann von einem Rate-Limit, einem Marktpreis, einem Kalenderzustand oder einer menschlichen Eingabe abhängen. Exakte bitweise Wiederholung ist nützlich, wenn sie verfügbar ist, aber Wiedergabe ist eine breitere Disziplin als deterministische Nostalgie.
Wiedergabe bedeutet, dass das System den Entscheidungspfad auf dem Niveau rekonstruieren kann, das für die Frage erforderlich ist. Für eine faktische Antwort kann das die Quellen, Rangfolgen, Ausschnitte, den Prompt, die Modellversion und die Ausgabe bedeuten. Für eine Tool-Aktion kann das die Berechtigung, Parameter, Richtlinienprüfungen, den Genehmigungsstatus, das Ausführungsergebnis und den nachgelagerten Datensatz bedeuten. Für eine menschlich unterstützte Entscheidung kann das die Modellempfehlung, das Belegpaket, die Aktion der prüfenden Person, die Abweichung und das endgültige Ergebnis bedeuten. Das Ziel ist, die Vergangenheit überprüfbar zu machen, nicht so zu tun, als wäre die Vergangenheit eine Laborprobe unter Glas gewesen.
Diese Unterscheidung ist wichtig, weil exakte Wiedergabe zu einer Ausrede werden kann, nichts zu tun. Ein Team sagt, das Modell sei nichtdeterministisch, daher sei Wiedergabe unmöglich, daher würden Erklärungen bei Bedarf erzeugt. Das ist, als würde man sagen, Wetter könne nicht zurückgespult werden, daher habe es keinen Sinn, einen Flugschreiber zu behalten. Wir können vielleicht nicht jedes Turbulenzmolekül reproduzieren. Wir können trotzdem Höhe, Kurs, Steuerung, Warnungen und Entscheidungen aufzeichnen. KI-Systeme verdienen dieselbe Bescheidenheit und dieselbe Disziplin.
Wiedergabe braucht auch einen Umfang. Alles für immer aufzuzeichnen ist nicht verantwortungsvoll. Es schafft Datenschutzrisiken, Kosten und Governance-Nebel. Ein Wiedergabe-Design sollte die Mindestbelege erfassen, die zur Rekonstruktion folgenreicher Pfade nötig sind, wobei Aufbewahrung und Zugriff am Risiko ausgerichtet sind. Die Wahl ist nicht zwischen totalem Gedächtnis und theatralischer Amnesie. Ernsthafte Systeme leben in der Mitte, wo Belege zweckmäßig, begrenzt und stark genug sind, um spätere Fragen zu beantworten.
Wo Wiedergabe scheitert
Replay bricht meist an Grenzen. Der Modellaufruf ist leicht zu merken, weil alle darauf starren. Im umgebenden Kontext entkommen die Fakten. Die Benutzerrolle hat sich geändert. Das Quelldokument wurde überschrieben. Der Retrieval-Index wurde ohne Snapshot neu aufgebaut. Die Prompt-Vorlage wurde direkt bearbeitet. Die Policy-Engine verwendete die aktuelle Regel, als nach dem letzten Monat gefragt wurde. Das Tool gab einen Wert von heute zurück. Der menschliche Prüfer sah einen Bildschirm, den es nicht mehr gibt. Die Systemuhr war in einem Dienst falsch und in einem anderen richtig, ein kleines Geschenk verteilter Systeme an zukünftige Besprechungen.
Kontextverfall ist besonders häufig in Retrieval-Systemen. Eine generierte Antwort zitiert eine Policy-Seite. Sechs Monate später hat sich die Seite geändert. Das Zitat löst weiterhin auf, aber es sagt nicht mehr, was es sagte. Die Erklärung sagt, das System habe sich auf die Policy gestützt, was im unnützlichsten Sinne wahr ist. Ohne Content-Hash, Version, Snapshot oder Archivreferenz kann die Organisation nicht zeigen, welche Policy die Antwort geprägt hat. Sie kann nur die aktuelle Seite zeigen und hoffen, dass die Geschichte kooperativ wirkt.
Die Tool-Nutzung erzeugt einen weiteren Bruch. Ein Modell kann beschließen, ein Tool aufzurufen, aber die Erklärung bewahrt möglicherweise nicht die Parameter, die Berechtigungsprüfung, die Antwort, den Wiederholungspfad oder den Nebeneffekt. Die Ausgabe sieht dann wie eine Antwort aus, während die wichtige Handlung woanders stattfand. Wenn das Tool einen Datensatz geändert, eine Nachricht gesendet, ein Risiko bewertet oder einen Workflow ausgelöst hat, muss Replay dieser Grenze folgen. Sonst beschreibt die Erklärung den sprechenden Teil und übersieht die Hand, die den Hebel bewegt hat.
Menschliche Prüfung kann Replay ebenfalls brechen. Ein Prüfer kann Beweise sehen, ein Urteil fällen und nur einen Endstatus hinterlassen. Später sagt die Organisation, dass ein Mensch beteiligt war. Das ist wahr und dünn. Welche Beweise sah der Prüfer. Haben sie die Ausgabe geändert. Haben sie eine Empfehlung angenommen oder eine unabhängige Entscheidung getroffen. Hatten sie Zeit. Haben sie Zweifel festgehalten. Zeigte die Oberfläche Konfidenz auf eine Weise, die sie beeinflusste. Wenn der menschliche Zustand nicht aufgezeichnet wird, wird die menschliche Prüfung zu einem Vorhang. Er wirkt beruhigend auf das Publikum. Dahinter kann niemand den Stuhl finden.
Erklärung sollte eine Sicht auf Beweise sein
Das bessere Muster ist, Erklärung als eine Sicht auf Replay-Beweise zu behandeln. Das Beweispaket ist der zugrunde liegende Datensatz. Die Erklärung ist eine für Menschen gestaltete Darstellung ausgewählter Teile dieses Datensatzes. Ein Bürger sieht möglicherweise eine kurze Darstellung von Quellkategorien, Regelbasis, automatisierter Unterstützung, menschlicher Prüfung und Berufungsweg. Ein Operator sieht möglicherweise Quellausschnitte, Konfidenz, Policy-Prüfungen und Tool-Ergebnisse. Ein Prüfer sieht möglicherweise Hashes, Versionen, Zeitstempel, Genehmigungsereignisse und Aufbewahrungshaltung. Verschiedene Sichten, gleiche Beweisbasis.
So wird verhindert, dass Erklärungen zu erfundener Prosa werden. Das System soll ein Modell nicht bitten, eine frühere Entscheidung aus dem Gedächtnis oder aus einer Zusammenfassung seiner selbst zu erklären. Es soll die Erklärung aus aufgezeichneten Belegen erstellen oder zusammenstellen. Fehlen Belege, soll die Erklärung das sagen. Fehlende Belege sind keine Unannehmlichkeit der Benutzeroberfläche. Sie sind eine Tatsache über die Rechenschaftspflicht der Entscheidung. Sie unter einem glatteren Absatz zu verbergen, ist der Punkt, an dem Theater teuer wird.
Beleggestützte Erklärungen verbessern auch die Barrierefreiheit. Menschen, die von Entscheidungen betroffen sind, brauchen keine Rohdatenprotokolle. Sie brauchen verständliche Gründe, Wege zur Korrektur und genug Details, um Einspruch zu erheben. Entwickler und Prüfer brauchen tiefere Ebenen. Die Trennung von Belegen und Ansichten ermöglicht es dem System, beiden zu dienen, ohne Transparenz mit dem Abladen technischen Materials auf Menschen zu verwechseln, bis sie aufgeben. Eine tausendzeilige Ablaufverfolgung kann so undurchsichtig sein wie eine Blackbox, wenn sie dem falschen Publikum vorgelegt wird.
Die Ansicht darf auch nicht übertreiben. Eine Modellerklärung sollte nicht so tun, als enthülle sie innere psychologische Motive. Eine Bewertungserklärung sollte Korrelation nicht in moralisches Urteil übersetzen. Eine Abruferklärung sollte nicht andeuten, dass nicht zitierte Quellen irrelevant waren, wenn sie nie abgerufen wurden. Gute Erklärung verwendet trockene Sprache: Diese Anfrage verwendete diese Quellenversionen, unter diesen Regeln, mit dieser Modelleinstellung, erzeugte diese Ausgabe, geprüft von dieser Rolle, führte zu dieser Aktion. Trockene Sprache wird unterschätzt. Sie bietet weniger Platz, um Unsinn zu verstecken.
Replay schließt den Lernkreislauf
Replay dient nicht nur Prüfungen und Beschwerden. Es ist die Art, wie Systeme lernen, ohne sich selbst zu belügen. Wenn eine schlechte Ausgabe auftaucht, ermöglicht Replay dem Team, den Weg zu untersuchen. Fehlte die Quelle. War die Quelle vorhanden, aber zu niedrig eingestuft. Unterdrückte der Prompt Unsicherheit. Ignorierte das Modell eine Regel. Gab ein Werkzeug den falschen Zustand zurück. Genehmigte ein menschlicher Prüfer, weil das Belegpaket schlecht gestaltet war. Erzwang ein Richtlinienkonflikt einen fragilen Weg. Jede Antwort weist auf eine andere Reparatur hin.
Ohne Replay wird Verbesserung zum Aberglauben. Das Team ändert den Prompt, weil Prompts sichtbar sind. Es tauscht das Modell, weil Modelle aufregend sind. Es fügt eine Warnung hinzu, weil Warnungen billig sind. Das eigentliche Problem könnte ein veralteter Index, eine unversionierte Regel, ein stiller Berechtigungsfehler oder eine Prüferoberfläche gewesen sein, die Meinungsverschiedenheiten versteckte. Aberglaube kann Bewegung erzeugen. Er erzeugt selten Kontrolle. Die Organisation fühlt sich beschäftigt und bleibt verwirrt, ein beliebtes, aber ermüdendes Betriebsmodell.
Ein Replay-Kreislauf kann die Auswertung speisen. Fehlgeschlagene Fälle werden zu Testfällen mit erhaltenem Kontext. Menschliche Korrekturen werden zu beschrifteten Beispielen. Berufungsergebnisse werden zu Governance-Signalen. Fehler bei der Quellenaktualität werden zu Datenqualitätsmetriken. Werkzeugfehler werden zu Vertragstests. Das System erhält ein Gedächtnis seiner Fehler, das reicher ist als ein Haufen Beschwerden. Dieses Gedächtnis ermöglicht es Teams, Änderungen vorzunehmen und dann den neuen Weg mit dem alten zu vergleichen.
Replay schützt auch vor Verbesserungstheater. Eine neue Version kann schönere Erklärungen erzeugen, während sie schlechtere Entscheidungen trifft. Eine andere kann die Genauigkeit verbessern, aber das Ablehnungsverhalten schwächen. Eine dritte kann die Latenz reduzieren, indem sie Quellenbelege weglässt. Wenn die Organisation Fälle aufzeichnet und wiedergibt, kann sie Kompromisse sehen. Wenn sie nur polierte Erklärungen stichprobenartig prüft, wird sie versucht sein, der Version mit den besten Manieren zu glauben.
Der Datenschutzeinwand ist real
Replay kann falsch designt werden. Die faule Version zeichnet alles auf: vollständige Prompts, vollständige Dokumente, personenbezogene Daten, Tool-Ausgaben, interne Notizen, Kommentare von Prüfenden und vielleicht noch die Farbe des Stuhls, falls ein Sensor in der Nähe war. Dann nennt die Organisation das Prüfbarkeit und schafft ein zweites Risikoareal. Das ist nicht ausgereift. Das ist Horten mit Compliance-Abzeichen.
Ein verantwortungsvolles Replay-Design beginnt mit dem Zweck. Welche Entscheidungen Replay benötigen. Welche Beweise notwendig sind. Welche Teile über stabile Kennungen referenziert statt kopiert werden können. Welche Werte gehasht werden sollten. Welche Inhalte geschwärzt werden müssen. Welche Rollen auf tiefere Ebenen zugreifen können. Welche Aufbewahrungsfrist zum rechtlichen und menschlichen Wert des Prozesses passt. Welche Beweise niemals erfasst werden sollten, weil das Risiko den Nutzen überwiegt. Diese Fragen sind keine Hindernisse für Erklärbarkeit. Sie sind Teil davon.
Datenschutzfreundliches Replay bedeutet oft Schichtung. Die öffentliche Erklärung kann Kategorien und Gründe enthalten. Die interne Prüfung kann Quellkennungen und Ausschnitte enthalten. Die Prüfebene kann Hashes, Zeitstempel und Signaturen enthalten. Die Vorfallsebene kann unter strenger Kontrolle vorübergehend breiteren Zugriff erfordern. Die Ebenen sollten verbunden sein, aber sie sollten nicht zu einem einzigen Riesenarchiv kollabieren, das für alle zugänglich ist, die wissen, wo der Export-Button lebt. Export-Buttons sind keine Governance. Sie sind Türen, und Türen brauchen Schlösser.
Es gibt auch einen Fairnessgrund, Replay sorgfältig zu gestalten. Wenn nur einige Fälle detaillierte Aufzeichnungen erhalten, weil sie hohes Risiko oder hohen Wert haben, sollte die Organisation das wissen und begründen. Wenn Fälle mit geringem Risiko unterdokumentiert sind, haben Menschen möglicherweise weniger Möglichkeiten, Fehler in diesen Abläufen anzufechten. Wenn Fälle mit hohem Risiko überdokumentiert sind, könnten sensible Gruppen stärkerer Überwachung ausgesetzt sein. Replay ist kein neutrales Gedächtnis. Es ist eine Designentscheidung darüber, wessen Vergangenheit von wem eingesehen werden kann.
Replay verändert, wie Teams Prompts schreiben
Sobald Replay wichtig wird, hören Prompts auf, privates Insiderwissen zu sein. Ein Prompt wird Teil des Entscheidungspfads. Er braucht Versionierung, Eigentümerschaft, Tests und eine Beziehung zur Richtlinie. Das bedeutet nicht, dass jede Formulierungsänderung eine Zeremonie mit Keksen braucht. Es bedeutet aber, dass ein folgenreicher Prompt nicht ohne Hinterlassung eines Protokolls an Ort und Stelle bearbeitet werden sollte. Wenn sich der Prompt zwischen einer Entscheidung und einem Einspruch geändert hat, muss die Organisation wissen, welcher gegolten hat.
Replay macht Prompts auch an den richtigen Stellen kleiner. Teams stopfen oft Policy, Formatierung, Ablehnungsregeln, Datenanweisungen, Ton, Tool-Nutzung, Beispiele und operative Einschränkungen in einen einzigen langen Prompt. Dann verlangen sie von ihm, Governance, Schnittstelle und Gedächtnis zugleich zu sein. Ein replayfähiges System kann einen Teil dieser Struktur in explizite Kontrollen verlagern: Policy-Gates, Quellenfilter, Schema-Validatoren, Tool-Berechtigungen und Zustandsübergänge. Der Prompt kann sich auf Spracharbeit konzentrieren, statt so zu tun, als wäre er die Verfassung.
Das verbessert Erklärungen, weil das System auf konkrete Kontrollen verweisen kann. Die Antwort wurde abgelehnt, weil das Policy-Gate medizinischen Rat außerhalb der Rolle blockiert hat, nicht weil das Modell ein vages Gefühl hatte. Die Quelle wurde ausgeschlossen, weil der Datenvertrag sie als zweckfremd markiert hat, nicht weil der Prompt zur Vorsicht beim Datenschutz mahnte. Das Tool wurde nicht ausgeführt, weil die Aktion ohne Genehmigung irreversibel war, nicht weil ein Satz in einem Prompt auf Umsicht hoffte. Hoffnung ist eine wunderbare menschliche Eigenschaft. Sie ist keine Kontrollebene.
Prompts sind weiterhin wichtig. Sie prägen Framing, Unsicherheit, Ton und Denkverhalten. Replay verhindert nur, dass sie der einzige Ort sind, an dem Verantwortung versteckt wird. Das ist gesünder für alle, auch für die Person, die den Prompt sechs Monate später pflegen soll, wenn er zu einem zarten Fossil vergangener Besprechungen geworden ist.
Die Kosten nützlicher Erklärungen
Nützliche Erklärungen haben ihren Preis. Das Erfassen von Belegen kostet Speicher und Entwicklungszeit. Das Versionieren von Quellen kostet Disziplin. Das Aufbewahren von Snapshots kostet Geld. Das Erstellen rollenspezifischer Ansichten kostet Produktdesign. Datenschutzprüfung kostet Aufmerksamkeit. Replay-Tests kosten Laufzeit. Für Menschen lesbare Begründungscodes kosten Facharbeit. Diese Kosten sind real. So zu tun, als wären sie es nicht, führt dazu, dass Organisationen entweder überdimensionierte Archive oder charmant nutzlose Erklärungen haben.
Die richtige Frage ist, welches Maß an Replay die Entscheidung verdient. Ein beiläufiger Schreibassistent braucht möglicherweise leichte Spuren und kurze Aufbewahrungsfristen. Eine klinische Triage-Hilfe braucht stärkere Belege, Quellen-Snapshots, Prüfprotokolle und Unterstützung für Einspruch. Eine Entscheidung über öffentliche Leistungen braucht fallbezogene Belege und rechtliche Versionierung. Ein Betrugsermittlungssystem braucht eine sorgfältige Balance zwischen Erklärbarkeit, Sicherheit und Anfechtbarkeit. Eine einzige Replay-Haltung für jedes System ist so unsinnig wie eine Schuhgröße für jedes Treffen.
Abwägungen sollten explizit sein. Mehr Details verbessern die Prüfung, können aber das Datenschutzrisiko erhöhen. Starke Snapshots verbessern Replay, kosten aber Geld. Schnellere Systeme erfassen möglicherweise weniger. Reichhaltigere Erklärungen können sensible Logik offenlegen. Menschliche Notizen können Urteile klären, erzeugen aber auch Aufzeichnungen, die Governance benötigen. Das sind Designentscheidungen, keine Ausreden. Ernsthafte Teams benennen sie vor dem Einsatz. Weniger ernsthafte Teams entdecken sie bei Beschwerden und nennen es dann Lessons Learned, ein traditioneller Ausdruck, der so viel bedeutet wie: nächstes Mal vielleicht.
Die besten Replay-Systeme sind bescheiden und zuverlässig. Sie erfassen die Belege, die für die Fragen nötig sind, die die Organisation wahrscheinlich und verpflichtet ist zu beantworten. Sie vermeiden es, alles aufzuzeichnen. Sie erzeugen Erklärungen aus Belegen, nicht aus Stimmungen. Sie räumen Unsicherheit ein. Sie machen fehlende Belege sichtbar. Sie ermöglichen Teams, sich zu verbessern. Das ist nicht spektakulär. Gute Governance ist das selten. Ihre höchste Leistung ist oft, dass eine schwierige Frage beantwortet werden kann, ohne dass alle theatralisch werden.
Die Lektion
Erklärbarkeit ohne Replay ist Theater, weil sie eine überzeugende Darstellung mit einer überprüfbaren verwechselt. Eine generierte Begründung, ein Dashboard, eine Modellkarte und ein selbstbewusster Prüfer können alle helfen. Keines davon reicht aus, wenn eine folgenreiche Entscheidung rekonstruiert werden muss. Das System braucht den Pfad: Kontext, Quellen, Anweisungen, Modellzustand, Richtlinienprüfungen, Tool-Aktionen, menschliches Urteil, Ausgabe und Wirkung.
Replay erfordert keine perfekte Determiniertheit. Es erfordert disziplinierte Erinnerung. Es erfordert stabile Referenzen, Versionen, bei Bedarf Snapshots, rollenspezifische Ansichten, Datenschutzgrenzen und Aufzeichnungen, die angeben, wann Belege fehlen. Es behandelt Erklärung als eine Sicht auf Belege und nicht als eine im Nachhinein erfundene Geschichte. Es gibt Betroffenen etwas, das sie anfechten können, Betreibern etwas, das sie reparieren können, und Prüfern etwas Besseres als eine geführte Tour durch Hoffnung.
Die Zukunft der erklärbaren KI wird nicht allein durch schönere Erklärungstexte gewonnen. Sie wird von Systemen gewonnen, die durch ihre eigene Arbeit zurückgehen können. Wenn der Pfad wiedergegeben werden kann, kann eine Erklärung getestet werden. Wenn der Pfad nicht wiedergegeben werden kann, mag die Erklärung immer noch eloquent sein. Sie mag sogar wahr sein. Aber in ernsthaften Kontexten ist Eloquenz ein schlechter Ersatz für die Maschinerie, die ihre Arbeit zeigen kann.