Ohne Herkunft keine belastbare KI

Eine KI kann eine flüssige, detaillierte und dennoch unbrauchbare Antwort erzeugen. Wenn niemand weiß, worauf sie beruht, lässt sich weder ein Fehler korrigieren noch eine Entscheidung verteidigen. Dieses Problem wächst, sobald Systeme Informationen aus Dokumenten, Datenbanken, Suchindizes, APIs und Werkzeugaufrufen kombinieren.

Ohne Herkunft bleibt unklar, ob eine Aussage aus einer freigegebenen Richtlinie, einem alten Entwurf, einer automatisch erzeugten Zusammenfassung oder dem ungesicherten Ergebnis eines Werkzeugs stammt. Eine Quellenliste am Ende ist hilfreich, aber noch keine vollständige Provenienz.

Provenienz, Zitation, Lineage und Auditprotokoll

Vier verwandte Begriffe erfüllen unterschiedliche Aufgaben. Eine Zitation verweist auf eine Quelle, die eine Aussage stützen soll. Data Lineage beschreibt, wie Daten durch Systeme und Transformationen fließen. Provenienz erfasst die Herkunft und Entstehungsgeschichte eines Objekts einschließlich beteiligter Akteure und Verarbeitungsschritte. Ein Auditprotokoll zeichnet Ereignisse auf, damit spätere Kontrollen möglich werden.

Ein belastbares System verbindet diese Ebenen. Die Antwort zitiert verwendete Evidenz. Die Lineage zeigt, wie der relevante Datensatz oder Index entstand. Die Provenienz verbindet Quelle, Transformation und Verantwortlichkeit. Das Protokoll dokumentiert, wann welcher Prozess mit welchen Berechtigungen lief.

Ein einfaches Modell: Entität, Aktivität, Akteur

Das W3C-PROV-Modell beschreibt vereinfacht drei Kernbausteine:

1 · Entität: ein Dokument, Datensatz, Segment, Modellartefakt, Bericht oder eine konkrete Ausgabe in einem bestimmten Zustand.

2 · Aktivität: eine Extraktion, Bereinigung, Übersetzung, Zusammenfassung, Indexierung, Freigabe oder Modellinferenz.

3 · Akteur: eine Person, Organisation, Softwarekomponente oder verantwortliche Rolle, die an einer Aktivität beteiligt ist.

Die Beziehungen tragen die eigentliche Geschichte: Eine Ausgabe wurde durch eine Aktivität erzeugt; eine Aktivität verwendete Eingaben; eine neue Fassung wurde aus einer früheren abgeleitet; ein Akteur war verantwortlich oder beteiligt.

Für viele Projekte reicht eine kompakte Umsetzung. Jedes Objekt besitzt eine stabile Kennung, Quellverweis, Zeitpunkt, Version, Status und verantwortliche Rolle. Jede Transformation verweist auf Eingabe, Methode, Parameter, Werkzeugversion und Ausgabe. Freigaben werden als eigene Ereignisse festgehalten, statt still in einem Dateinamen zu verschwinden.

entity_id: policy-summary-v3
derived_from: policy-source-v7
activity: summarization
tool_version: summarizer-2.4
created_at: 2026-07-16T10:42:00Z
status: approved
approved_by_role: policy_owner
supersedes: policy-summary-v2

Das Original bleibt unverändert

Eine Provenienzkette braucht einen stabilen Anfang. Das ursprüngliche Dokument, Ereignis oder Messergebnis wird deshalb unverändert erhalten. Bereinigungen, Konvertierungen und Anreicherungen erzeugen neue, versionierte Objekte. So kann eine spätere Korrektur nachvollziehen, ob ein Fehler bereits in der Quelle lag oder erst durch Verarbeitung entstand.

Inhalts-Hashes können helfen zu erkennen, ob sich Bytes verändert haben. Sie sind jedoch kein Wahrheitsstempel. Ein Hash beweist nicht, dass eine Quelle richtig, rechtmäßig genutzt oder tatsächlich von der behaupteten Person erstellt wurde. Dafür braucht es zusätzliche Kontrollen wie vertrauenswürdige Identitäten, Signaturen, Zugriffsregeln und fachliche Freigabe.

Versionierung braucht fachliche Bedeutung

„final", „final_neu" und „wirklich_final" sind keine Statusmodelle. Eine Versionsnummer zeigt Reihenfolge, aber noch nicht Gültigkeit. Das System muss zusätzlich erfassen, was sich geändert hat, warum die Änderung erfolgte, wann sie gilt und welche frühere Fassung sie ersetzt.

Ein brauchbarer Lebenszyklus unterscheidet beispielsweise Entwurf, in Prüfung, freigegeben, ersetzt, zurückgezogen und archiviert. Diese Zustände müssen für maschinelles Retrieval filterbar sein. Sonst findet die semantische Suche möglicherweise den ähnlichsten, aber nicht den gültigen Text.

Ersetzungsbeziehungen sind besonders wichtig. Wird eine Quelle widerrufen, sollte ermittelbar sein, welche Segmente, Zusammenfassungen, Indizes und Antworten davon abhängen. Provenienz ermöglicht damit nicht nur Rückblick, sondern auch gezielte Korrektur und Impact-Analyse.

Die Herkunftskette endet nicht am Datenbestand

Bei einer KI-Ausgabe reicht es nicht, nur das Ursprungsdokument zu kennen. Auch der beobachtbare Weg zur Antwort muss reproduzierbar sein: Welche Anfrage und welcher freigegebene Prompt wurden verwendet? Welche Dokumente und Segmente wurden abgerufen? Welche Filter und Berechtigungen waren aktiv? Welche Versionen von Wissensbasis, Index, Modell und Werkzeugen liefen? Wo wurde menschlich bestätigt oder eingegriffen?

Das verlangt nicht, jede interne Modellaktivierung oder verborgene Gedankenkette zu speichern. Relevant ist die betriebliche Verarbeitungskette: Eingaben, Konfiguration, abgerufene Evidenz, Werkzeugergebnisse, Entscheidungen, Ausgabe und Freigabe. Sie soll Fehler eingrenzbar machen, ohne unnötig sensible Inhalte zu protokollieren.

Bei agentischen Systemen wird dies noch wichtiger. Ein Agent kann suchen, Code ausführen, Dateien verändern oder externe Aktionen auslösen. Jeder Werkzeugaufruf benötigt daher Identität, Berechtigung, Eingabe, Ergebnis, Status und Korrelation zur übergeordneten Aufgabe. Ein späterer Beobachter muss erkennen können, welcher Schritt eine Änderung ausgelöst hat.

Provenienz muss selbst geschützt werden

Protokolle können personenbezogene Daten, vertrauliche Dokumentausschnitte, Zugangstoken oder interne Entscheidungsdetails enthalten. Vollständigkeit ist deshalb nicht gleichbedeutend mit grenzenloser Speicherung. Gute Provenienz folgt Datenminimierung, Zweckbindung, rollenbasiertem Zugriff, Aufbewahrungsfristen und manipulationsgeschützter Speicherung.

Geheimnisse gehören nicht in Klartextlogs. Wo möglich, werden Referenzen, stabile Kennungen und redigierte Parameter gespeichert. Zugriff auf Provenienzdaten wird selbst protokolliert. Auch eine perfekte Herkunftskette verliert ihren Wert, wenn sie nachträglich unbemerkt verändert werden kann.

Was Provenienz nicht beweist

Eine lückenlose Kette kann auch die Geschichte einer falschen Information korrekt dokumentieren. Provenienz beantwortet: Woher kam etwas, wie wurde es verändert und wer war beteiligt? Sie beantwortet nicht automatisch: Ist die Aussage wahr, war die Erhebung methodisch geeignet oder durfte die Information für diesen Zweck verwendet werden?

Deshalb bleiben Quellenkritik, Datenqualitätsprüfung, Rechtsgrundlage und fachliche Validierung eigenständige Kontrollen. Auch menschliche Freigabe ist kein unfehlbares Wahrheitssiegel; sie dokumentiert eine verantwortete Entscheidung zu einem bestimmten Zeitpunkt. Gute Systeme halten diese Grenzen sichtbar, statt aus vorhandenen Metadaten mehr Sicherheit abzuleiten, als tatsächlich belegt ist.

Provenienz kann zudem unterschiedlich granular sein. Für eine risikoarme interne Zusammenfassung genügt möglicherweise der Verweis auf Dokument- und Modellversion. Bei einer folgenreichen automatisierten Entscheidung können einzelne Merkmale, Regeln, Werkzeugaufrufe und Freigaben relevant werden. Die Granularität folgt dem Risiko und der nötigen Rekonstruierbarkeit.

Provenienz wird getestet

Ein Datenmodell allein garantiert keine Nachvollziehbarkeit. Tests prüfen, ob jede abgeleitete Entität eine erreichbare Quelle besitzt, ob Transformationen Werkzeug- und Parameterstände enthalten und ob freigegebene Objekte eine verantwortliche Rolle nennen. Negativtests simulieren fehlende Quellen, gebrochene Links, widerrufene Versionen und unzulässige Berechtigungen.

Für eine konkrete KI-Antwort sollte ein Rückwärtstest funktionieren: Ausgabe → Antwortlauf → verwendete Segmente → Indexversion → extrahiertes Dokument → unveränderte Originalquelle. Ein Vorwärtstest fragt umgekehrt: Welche abhängigen Objekte und Ausgaben sind betroffen, wenn eine Quelle zurückgezogen wird?

Provenienz ist damit kein dekorativer Quellenblock. Sie ist Betriebsinfrastruktur für Rückfragen, Reproduktion, Widerruf, Aktualisierung und Audit. Vor allem verhindert sie, dass sprachliche Sicherheit mit sachlicher Gültigkeit verwechselt wird.

Übungsblatt: Rekonstruiere eine Provenienzkette

Wähle eine veröffentlichte Zahl, Aussage oder KI-Antwort und dokumentiere ihren vollständigen Weg.

1. Quellobjekt bestimmen. Erfasse stabile Kennung, Ursprung, Ersteller, Zeitpunkt, Schutzklasse und unveränderte Originalfassung.

2. Transformationen modellieren. Dokumentiere mindestens zwei Aktivitäten mit Eingabe, Methode, Parameter- oder Werkzeugversion und Ausgabe.

3. Version und Status klären. Lege gültige Fassung, Freigabe, Gültigkeitszeitraum und ersetzte Version fest.

4. Antwortlauf rekonstruieren. Notiere verwendete Segmente, Filter, Index-, Modell- und Werkzeugversion sowie menschliche Eingriffe.

5. Zweite Fassung erzeugen. Ändere eine Aussage begründet und dokumentiere Ableitung und Ersetzungsbeziehung.

6. Impact prüfen. Ermittle, welche nachgelagerten Artefakte bei Widerruf der Quelle überprüft oder gesperrt werden müssen.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Provenienz belegt den dokumentierten Entstehungs- und Verarbeitungspfad. Sie beweist nicht automatisch Wahrheit, Rechtmäßigkeit oder fachliche Richtigkeit. Ein Hash kann Byte-Integrität unterstützen, bestätigt aber allein weder Autorenschaft noch sachliche Gültigkeit. Konkrete Aufzeichnungs- und Dokumentationspflichten hängen von Rolle, Systemklassifizierung und Einsatzkontext ab.