Provenance: Warum AI-Trust Nachweise statt Versprechen braucht

Die meisten Organisationen reden über KI-Compliance, als wäre sie ein Zustand: Man ist compliant oder man ist es nicht. Diese Sichtweise führt regelmäßig in die Irre. Eine Aufsichtsbehörde, ein Auditor oder ein Geschäftspartner fragt nie, ob Sie sich für compliant halten. Sie fragen, ob Sie es belegen können — lückenlos, reproduzierbar, ohne nachträgliche Konstruktion. Genau hier verschiebt sich der Fokus von Compliance als Behauptung zu Trust als Infrastruktur. Und im Zentrum dieser Infrastruktur steht ein Konzept, das in der KI-Governance bislang unterschätzt wird: Provenance.

Vom Versprechen zum Nachweis

Vertrauen entsteht nicht durch Zusicherung, sondern durch Überprüfbarkeit. Wer behauptet, ein KI-System sei sicher, fair und kontrolliert, trifft eine Aussage über die Gegenwart. Wer das belegen kann, trifft eine Aussage über die gesamte Historie des Systems: Welche Daten flossen ein, welche Version war wann produktiv, wer hat welche Entscheidung freigegeben, welche Tests liefen mit welchem Ergebnis. Provenance ist die durchgängige Herkunfts- und Veränderungskette eines KI-Systems — die Antwort auf die Frage "Woher kommt dieser Zustand, und wie ist er entstanden?".

Der Unterschied ist nicht akademisch. Behauptungen lassen sich im Nachhinein nicht prüfen; Nachweise schon. Eine Organisation, die ihre KI-Governance auf Versprechen aufbaut, steht im Ernstfall mit leeren Händen da — selbst wenn sie tatsächlich alles richtig gemacht hat. Denn ohne Evidenz ist "richtig gemacht" nicht von "behauptet" zu unterscheiden. Das ist der Kern der Buyer Promise hinter Evidence-based AI Trust: nachweisbar, audit-ready. Kein Garantieversprechen, sondern Belegbarkeit.

Was der EU AI Act tatsächlich verlangt

Der EU AI Act formalisiert genau diese Logik für Hochrisiko-KI-Systeme. Artikel 12 verpflichtet Anbieter dazu, dass Hochrisiko-Systeme technisch so ausgelegt sind, dass sie über ihre Lebensdauer Ereignisse automatisch protokollieren — Logging-Fähigkeiten sind keine Option, sondern Konstruktionsanforderung. Artikel 19 ergänzt die Pflicht, diese automatisch erzeugten Logs aufzubewahren, soweit sie unter der Kontrolle des Anbieters stehen. Und Artikel 11 in Verbindung mit Anhang IV verlangt eine technische Dokumentation, die vor Inbetriebnahme erstellt und laufend aktuell gehalten wird — nicht rekonstruiert, wenn die Behörde anklopft.

Liest man diese Artikel zusammen, ergeben sie kein Compliance-Häkchen, sondern eine Architektur-Anforderung: Das System muss seine eigene Geschichte erzeugen und vorhalten. Genau das ist Provenance in regulatorischer Sprache. Der Gesetzgeber hat verstanden, dass nachträgliche Erklärungen wertlos sind. Was zählt, ist die maschinell erzeugte, fortlaufende Spur — entstanden im Betrieb, nicht im Audit.

Mit dem Forcing Event der Enforcement am 02.12.2027 (Digital Omnibus) verschiebt sich diese Anforderung vom Papier in die Durchsetzung. Ab diesem Zeitpunkt ist die entscheidende Frage nicht mehr, ob eine Organisation eine Governance-Policy besitzt, sondern ob sie für jedes relevante System die zugehörige Evidenz abrufen kann.

Audit-Trail ist die Mechanik, Provenance ist das Prinzip

Es lohnt sich, zwei Begriffe zu trennen, die oft synonym verwendet werden. Ein Audit-Trail ist die konkrete, chronologische Protokollierung einzelner Ereignisse — wer hat wann was getan. Provenance ist das übergeordnete Prinzip: die vollständige, kausal nachvollziehbare Herkunft eines Zustands über alle Ebenen hinweg — Daten, Modell, Konfiguration, Entscheidung, Verantwortlichkeit. Der Audit-Trail liefert die Bausteine; Provenance setzt sie zu einer prüfbaren Erzählung zusammen.

Für die Praxis bedeutet das: Es genügt nicht, irgendwo Logs zu haben. Entscheidend ist, ob aus den verstreuten Spuren eine geschlossene Kette wird, die eine externe Partei ohne Insiderwissen nachvollziehen kann. Drei Eigenschaften machen den Unterschied zwischen Datenmüll und belastbarer Evidenz:

• Integrität — die Spur ist gegen nachträgliche Veränderung geschützt, sonst beweist sie nichts.
• Vollständigkeit — relevante Ereignisse fehlen nicht, sonst entstehen Lücken, die im Audit als Versäumnis gelten.
• Zuordenbarkeit — jeder Eintrag ist eindeutig einem System, einer Version und einer verantwortlichen Stelle zugeordnet.

Fehlt eine dieser Eigenschaften, kippt die Evidenz von einem Asset zu einer Belastung: Eine unvollständige oder manipulierbare Spur ist im Zweifel schlechter als keine, weil sie aktiv Fragen aufwirft.

Warum das ein Infrastruktur-Thema ist

Der entscheidende Denkfehler vieler Programme ist, Trust als Dokumentations-Aufgabe zu behandeln — etwas, das ein Team am Ende eines Projekts erledigt. Doch Evidenz, die am Ende erzeugt wird, ist per Definition keine Provenance, sondern Rekonstruktion. Belastbare Nachweise entstehen nur, wenn das System sie im Betrieb, automatisch und kontinuierlich produziert. Das ist eine Eigenschaft der Infrastruktur, nicht der Schlussdokumentation.

Genau deshalb ist Trust-Infrastructure die richtige Kategorie und nicht Compliance-Software. Compliance ist das Ergebnis, das sich einstellt, wenn die darunterliegende Evidenz-Schicht stimmt. Wer die Infrastruktur baut — automatisches Logging, versionierte Modell- und Datenstände, unveränderliche Audit-Trails, klare Verantwortungszuordnung —, bekommt Compliance als Nebenprodukt. Wer umgekehrt nur auf Compliance zielt, produziert Papier, das im Ernstfall nicht trägt.

Diese Verschiebung passt auch zu reifen Governance-Modellen. Ein AIMS nach ISO/IEC 42001 in Verbindung mit der Reifegradlogik von CMMI v3 misst nicht, ob Policies existieren, sondern ob Prozesse wiederholbar, gemessen und nachweisbar gelebt werden. Reife bedeutet hier: Die Evidenz fällt strukturell an, nicht heroisch am Projektende. Ein System, das seine eigene Nachweiskette erzeugt, ist per Konstruktion auditfähig — über alle relevanten Rechtsräume hinweg, ob DE, EU27-Rest, UK oder CH.

Die praktische Konsequenz

Für die Vorbereitung auf die Enforcement ergibt sich daraus eine konkrete Prioritätenfolge. Bevor eine Organisation über Policies und Schulungen nachdenkt, sollte sie eine schlichte Frage beantworten können: Für jedes produktive KI-System — können wir heute, ohne Vorlauf, die vollständige, integre und zuordenbare Evidenzkette vorlegen? Lautet die Antwort nein, ist das die eigentliche Baustelle. Alles andere ist Aufbau auf Sand.

Evidence-based AI Trust kehrt damit die übliche Reihenfolge um. Nicht "erst compliant werden, dann dokumentieren", sondern "erst die Nachweis-Infrastruktur bauen, dann ist Compliance belegbar". Das ist kein Mehraufwand, sondern eine Investition, die sich bei jeder Prüfung, jedem Audit und jeder Partner-Due-Diligence auszahlt — und die im Streitfall den Unterschied macht zwischen einer Behauptung und einem Beweis.

Wer den Aufbau dieser Evidenz-Schicht systematisch angehen will, findet im Konzept der AEGIRA Trust-Platform einen strukturierten Rahmen dafür: aegira.ai.