Provenienz by construction: KI-Analysen, die Ihre Auditoren nachvollziehen können

Es gibt in jedem KI-Piloten eines Finanzinstituts den Moment, in dem jemand die Frage stellt, die über das Projekt entscheidet: "Und wenn die Aufsicht fragt, woher diese Zahl kam?" Die meisten Piloten enden dort - nicht weil die Antworten falsch waren, sondern weil niemand beweisen konnte, dass sie richtig waren. "Das Modell hat es gesagt" ist keine Antwort, die eine Compliance-Verantwortliche unterschreiben kann, und jeder im Raum weiß das.

Die übliche Reaktion ist ein angebautes Erklärungs-Feature: das Modell seine Begründung beschreiben lassen, die Beschreibung speichern, das Ganze Audit-Trail nennen. Wir halten diesen Ansatz für auf eine Weise defekt, die sich nicht polieren lässt - und dieser Artikel beschreibt die Alternative, die wir stattdessen gebaut haben: Provenienz als Konstruktionsbedingung. In DataQube kann der Agent keinen Claim erzeugen, ohne dass die Evidenzkette existiert, weil das Zusammensetzen der Kette der Weg ist, auf dem Claims entstehen. Der Audit-Trail dokumentiert nicht die Analyse. Er ist die Analyse.

Was ein KI-Audit-Trail tatsächlich enthalten muss

Beginnen Sie bei dem, was ein Reviewer braucht, denn das definiert die Datenstruktur. Wenn ein Aufsichtsteam, die interne Revision oder die Modellrisiko-Funktion eine KI-erzeugte Zahl prüft, stellt sie fünf Fragen in vorhersehbarer Reihenfolge: Was durfte der Agent anfassen, welches Vorwissen hat er angewandt, was hat er tatsächlich ausgeführt, wie wurde aus den Ergebnissen die Zahl berechnet, und was wurde geprüft, bevor irgendjemand sie weitergegeben hat.

Jede dieser Fragen entspricht einer Stufe dessen, was wir die Evidenzkette nennen - und jede Antwort des Agenten trägt alle fünf:

• Scope - der Workspace, die geltenden Berechtigungen und das Governance-Gate, das die Session vor dem ersten Aufruf passiert hat.
• Abgerufenes Wissen - welche validierten Definitionen und Konventionen angewandt wurden, und wann jede zuletzt bestätigt wurde.
• Auditierte Aufrufe - jede Query, jeder Dateizugriff, jeder Lauf, jeweils mit Audit-Event-Referenz.
• Rechenweg - wie aus abgerufenen Zeilen die Zahl auf dem Bildschirm wurde.
• Prüfungen - was gegen eine unabhängige Quelle abgestimmt wurde, bevor die Antwort erschien.

Nichts davon ist Prosa. Jede Stufe ist strukturierte Daten, erzeugt in dem Moment, in dem die Arbeit passiert, mit Identifikatoren, die sich im Audit-Log auflösen. Diese Unterscheidung - strukturierte Events zur Ausführungszeit statt Erzählung im Nachhinein - macht den Rest dieses Artikels erst möglich.

Anatomie einer auditierbaren Antwort

Hier ist ein Beispiel der Form, aus unserem stehenden Demonstrationsszenario: Das Group-Risk-Team einer Bank fragt vor einer Antwort an die Aufsicht nach der Konzentration im Gewerbeimmobilien-Portfolio. Ein Befund - "Büro-CRE liegt bei 92% seines internen Sublimits" - zusammengesetzt aus vier verschiedenen Systemen, jeder Aufruf mit seiner Audit-Referenz:

Lauf wiederholen

Auf Basis realer Kundengespräche — alle Daten fiktiv.

Gehen Sie die Kette hinter diesem Befund entlang, und Sie finden keine Erzählung, nur Aufzeichnungen. Die Exposure-Seite kam aus einer Read-only-Query gegen das Warehouse - 18.204 Zeilen, 213 Millisekunden, Audit-Event evt-4c19d2. Das Aggregatlimit von 12,5% wurde weder erinnert noch angenommen: Es wurde aus §3.2 des vom Board genehmigten Policy-Dokuments gelesen, und das Zitat verweist auf Abschnitt und zitierte Passage, nicht nur auf einen Dateinamen. Die Monatszahlen wurden nicht neu hergeleitet - der Agent rief den stehenden Workflow cre-monthly-exposure auf, Lauf #38, Parameter fixiert; deshalb ist die Zahl in diesem Ad-hoc-Gespräch identisch mit der Zahl im verteilten Monatspack. Und bevor der Befund ausgesprochen wurde, wurden die Segment-Exposures mit dem Hauptbuch auf ±0,1% abgestimmt.

Vier Systeme, vier Audit-Referenzen, eine Korrelations-ID, die den ganzen Lauf verbindet. Ein Reviewer muss dem Satz nicht vertrauen; er kann jeden Verweis darin öffnen.

Claims tragen Belege, keine Fußnoten

Die tragende Designentscheidung liegt eine Ebene unter der Oberfläche: Ein Claim ist in DataQube eine Datenstruktur, deren Felder seine Evidenz sind. Hier ist derselbe Büro-CRE-Befund, aufgeklappt - das ist das Panel, das sich öffnet, wenn jemand am Befund oben auf "Wie wurde das hergeleitet?" klickt, genau wie es im Produkt erscheint:

Auf Basis realer Kundengespräche — alle Daten fiktiv.

Die Reihenfolge der Schritte ist der Punkt. Der Agent schreibt nicht erst den Claim und hängt dann Material an - er kann es nicht. Das Claim-Objekt wird aus den Belegen zusammengesetzt: Das Query-Ergebnis liefert das Exposure, der Dokumentzugriff das Limit, der Workflow-Lauf die Parität mit dem stehenden Pack, die Prüfung die Abstimmung. Entfernen Sie einen Beleg, und es gibt keinen Claim mehr auszusprechen. Wir nennen das Provenienz by construction - in bewusstem Kontrast zur Provenienz als Dekoration: dieselbe Struktur, nachträglich erzeugt, indem man ein Modell fragt, worauf es sich vermutlich gestützt hat.

Die praktische Konsequenz zeigt sich in den Fehlerfällen. Wenn eine Quelle nicht verfügbar ist - das Policy-Dokument wurde verschoben, das Warehouse hatte einen Timeout -, produziert ein dekorierendes System eine selbstbewusste Antwort mit dünnerer Erklärung. Ein konstruierendes System produziert keine Zahl - und sagt warum. Für ein reguliertes Team ist das zweite Verhalten der ganze Sinn der Sache.

Die Ablehnung gehört zum Protokoll

Ein Audit-Trail, der nur Erfolge aufzeichnet, ist ein Marketingdokument. Echte Prüfungen verbringen die meiste Zeit mit dem Negativraum: Wer hat versucht, worauf zuzugreifen, und wurde abgelehnt; welche Limits haben gegriffen; was hat das System verweigert.

Jede Autorisierungsentscheidung in DataQube landet im selben unveränderlichen Log wie der Datenzugriff, den sie regelt - einschließlich, gerade, der Ablehnungen. Versucht die Session einer Analystin, eine Quelle außerhalb ihrer Berechtigung zu erreichen, wird die Ablehnung mit der Regel aufgezeichnet, die gegriffen hat. Erforderte eine sensible Aktion die Freigabe einer Person, zeigt das Protokoll, wer gefragt wurde, was genau freigegeben wurde und wann. Der Permission-Prompt und die menschliche Antwort sind Events mit demselben Rang wie eine Query.

Deshalb ist "explizite Ablehnung gewinnt immer" eine Architekturaussage und keine Richtlinienpräferenz: Eine Ablehnung, um die ein Agent herumargumentieren kann, ist kein Beleg für Kontrolle - und Belege für Kontrolle sind das, was ein Auditor tatsächlich sammeln will.

Was ein Reviewer ohne Systemzugriff nachvollziehen kann

Die Kette wäre von begrenztem Nutzen, wenn ihre Prüfung einen DataQube-Login und einen wohlwollenden Admin erforderte. Sie lässt sich exportieren.

Der exportierte Trace eines Threads enthält die fünf Stufen für jeden Claim, die vollständige Audit-Event-Liste mit Zeitstempeln und Zeilenzahlen, die Dokumentzitate mit ihren Passagen und die Workflow-Referenzen mit fixierten Parametern. Ein Reviewer, der allein mit dem Export arbeitet, kann drei Dinge tun, die zählen: prüfen, dass jede Zahl eine lückenlose Kette hat; die zitierten Queries über den eigenen Zugang gegen die Quellsysteme erneut ausführen und Zeilenzahlen wie Ergebnisse vergleichen; und bestätigen, dass Policy-Zahlen auf die maßgeblichen Dokumente zurückgehen statt auf das Gedächtnis des Modells. Logzeilen enthalten nie Credentials, personenbezogene Daten oder rohe Ergebnismengen - der Trail ist Evidenz, keine zweite Kopie Ihrer Daten -, sodass der Export einen Prüfprozess durchlaufen kann wie jedes andere Audit-Artefakt.

Anders gesagt: Wer die Prüfung unterschreibt, muss nicht unserer Software vertrauen. Er muss dem eigenen Warehouse, dem eigenen Dokumentenspeicher und der Arithmetik vertrauen.

Warum nachträgliche Erklärbarkeit im Audit scheitert

Es lohnt sich, die verworfene Alternative präzise zu benennen, denn sie ist der Branchenstandard. "Explainable AI" bedeutet in den meisten aktuellen Produkten: das Modell nach der Antwort bitten, eine Darstellung seiner Begründung zu produzieren. Die Darstellung ist flüssig, plausibel und strukturell nicht verifizierbar - sie ist ein zweiter Modell-Output über den ersten, mit demselben epistemischen Status und ohne unabhängige Prüfung. Weichen Erklärung und tatsächliche Berechnung voneinander ab, entdeckt das nichts. Ein Auditor kann eine treue Erklärung nicht von einer konfabulierten unterscheiden - was für Auditzwecke bedeutet, dass die Erklärung gar keine Information trägt.

Der konstruktive Ansatz gibt dafür etwas Reales auf: Der Agent antwortet langsamer als ein System, das sich die Buchführung spart, und er verweigert in Situationen, in denen ein Chat-Produkt improvisieren würde. Wir halten beide Kosten für das Produkt, das wie beabsichtigt funktioniert. Eine Antwort ohne ihre Kette ist keine günstigere Antwort - in einem regulierten Umfeld ist sie eine Verbindlichkeit mit guter Grammatik.

Die Frage an jeden Anbieter

Wenn Sie KI-Analysewerkzeuge für ein reguliertes Umfeld evaluieren, gibt es einen Ein-Fragen-Test, der die beiden Architekturen trennt: Nehmen Sie eine beliebige Zahl aus dem Output und verlangen Sie die Query, die sie erzeugt hat, das Dokument hinter jeder Policy-Zahl und das Protokoll dessen, was das System unterwegs verweigert hat. Ein System mit Provenienz by construction antwortet mit Verweisen. Ein dekorierendes System antwortet mit Prosa.

Unsere Antwort auf diesen Test steht auf der Security-Seite, einschließlich der vollständig gerenderten Evidenzkette - und wenn Sie den Test gegen Ihre eigenen Daten laufen lassen wollen, buchen Sie eine Demo und bringen Sie Ihre härteste Zahl mit.