Audit-Logs für generative KI: Welche Nachweise der KI-Nutzung KI-Verordnung, ISO/IEC 42001 und Japans AI-Leitlinien verlangen und wie Sie sie aufbewahren

Generative KI intern nutzen, KI-Funktionen in das eigene Produkt einbauen, Aufgaben an KI-Agenten übergeben: Bei jeder dieser Nutzungsformen kommt bald der Moment, in dem Sie erklären müssen, wer die KI wofür nutzt und wie das gesteuert wird. Gegenüber sitzen mal Prüfer, mal der Sicherheitsfragebogen eines Kunden.

Mündliche Erklärungen oder Richtliniendokumente reichen dann nicht – gefragt ist, ob Sie es mit Aufzeichnungen belegen können. Dieser Artikel ordnet der Reihe nach, was Regulierung und Normen verlangen, welche Felder Sie erfassen sollten, wo Sie aufzeichnen und welche Bedingungen ein Nachweis erfüllen muss, damit Audit-Logs für generative KI als Nachweis tragen.

Was ist ein Audit-Log für generative KI?

Ein Audit-Log für generative KI hält für jede einzelne KI-Ausführung fest, wann, wer (bzw. welcher Agent), mit welchem Modell und mit welcher Entscheidung gearbeitet hat – in einer Form, die Dritte später überprüfen können.

Der Zweck unterscheidet sich von gewöhnlichen Betriebs- oder Anwendungslogs:

Der größte Unterschied: Die Leser sind Externe. Wenn Sie Außenstehenden nicht zeigen können, dass das Log nachträglich nicht verändert wurde, bleibt es als Nachweis schwach – egal wie detailliert es ist.

Warum der Nachweis der KI-Nutzung gerade jetzt gefragt ist

Im Wesentlichen aus drei Gründen:

• Sicherheitsprüfungen durch Kunden: Fragen zum Einsatzbereich generativer KI, zu eingegebenen Daten und zur Log-Aufbewahrung nehmen zu
• Audits nach SOC 2 Type II oder ISO/IEC 27001 (ISMS): Es muss gezeigt werden, dass Kontrollen über den gesamten Beobachtungszeitraum gewirkt haben – und auch die KI-Nutzung wird dabei hinterfragt
• Verbreitung von KI-Agenten: Immer öfter arbeitet nicht ein Mensch, sondern eine KI autonom; nötig sind Aufzeichnungen, die nachvollziehbar machen, welche KI was getan hat

Übersicht: Welche Aufzeichnungen Regulierung und Normen verlangen

Stand 31. Oktober 2026, geprüft anhand der Primärquellen.

Wichtig ist: Verschoben wurde in der KI-Verordnung der Geltungsbeginn, nicht die Log-Anforderung selbst. Zum Geltungsbeginn sollten bereits Logs über „mindestens 6 Monate“ vorliegen. Realistisch ist es daher, die Log-Infrastruktur jetzt aufzubauen und nicht erst kurz vor dem Stichtag.

Primärquellen: KI-Verordnung Artikel 12 · Artikel 19 · Artikel 26 · Artikel 113 (Geltungsbeginn) (AI Act Service Desk der Europäischen Kommission) / AI-Leitlinien für Unternehmen (japanisches Wirtschaftsministerium METI, Japanisch) / Inkrafttreten des KI-Förderungsgesetzes (Kabinettsbüro Japans, Japanisch)

Was aufgezeichnet werden sollte

Wenn Sie für jede KI-Ausführung die folgenden Felder erfassen, fällt die Erklärung leichter:

Sollten Prompt- und Ausgabetexte gespeichert werden?

In vielen Fällen genügen Fingerabdruck (Hash) und inhaltsfreie Metadaten, ohne den Volltext selbst aufzubewahren.

Volltexte enthalten leicht personenbezogene Kundendaten oder vertrauliche Informationen; je mehr Sie davon sammeln, desto größer ist der Schaden bei einem Datenabfluss. Mit gespeicherten Hashes können Sie im Ernstfall mit dem vorliegenden Text abgleichen und bestätigen, dass es genau diese Ein-/Ausgabe war.

Auch die OWASP-Leitlinien zur Abwehr von Prompt Injection bei LLMs verlangen seit der Überarbeitung vom 4. Oktober 2026, in Logs „sicherheitsrelevante Metadaten und Entscheidungen“ festzuhalten und Zugangsdaten sowie unnötige sensible Informationen auszuschließen (OWASP Cheat Sheet).

Wo aufgezeichnet wird

Je nach Ort der Aufzeichnung ändern sich, was erfasst werden kann und wie vertrauenswürdig das Ergebnis ist.

Code und Proxy sollten nicht alternativ, sondern kombiniert eingesetzt werden. Der Proxy erfasst lückenlos, dass ein Aufruf stattfand; den Entscheidungsgrund zeichnet die Code-Schicht auf, die die Entscheidung getroffen hat.

Ebenso wichtig: Ein Log, das Sie selbst schreiben und selbst verwahren, genießt bei Externen für sich allein wenig Vertrauen. Es braucht einen Mechanismus, der zeigt, dass es nachträglich nicht umgeschrieben wurde. Dazu der nächste Abschnitt.

Bedingungen für einen im Audit tragfähigen Nachweis

Damit ein Log als Nachweis taugt, braucht es diese fünf Eigenschaften:

1. Nachweisbar unverändert: Verkettet man den Fingerabdruck (Hash) jedes Eintrags mit dem vorherigen, passen nach der Änderung eines einzelnen Eintrags alle folgenden Verkettungen nicht mehr – Manipulation wird erkennbar
2. Durch Dritte selbst überprüfbar: Die Aufzeichnung lässt sich lokal verifizieren, ohne dem Unternehmen oder Dienst vertrauen zu müssen, das sie erstellt hat
3. Aufbewahrungsdauer erfüllt: Die „mindestens 6 Monate“ der KI-Verordnung und der Beobachtungszeitraum des Audits (meist 6 bis 12 Monate) werden abgedeckt
4. Urheber erkennbar: Bei geteilten Konten oder Schlüsseln lässt sich nicht erklären, wer etwas genutzt hat. Personen und Agenten werden getrennt erfasst
5. Fehlende Felder erkennbar: Wer offenlegt, welche Felder nicht aufgezeichnet werden, kann den Umfang ehrlich erklären. Eine Aufzeichnung, bei der unklar ist, was fehlt, kostet eher Vertrauen

Besondere Fragen bei KI-Agenten

KI-Agenten rufen anstelle von Menschen selbstständig Tools auf und treiben Aufgaben voran. Daraus ergeben sich andere Fragen als bei generativer KI, die von Menschen genutzt wird.

• Jeden Agenten identifizieren: Erfassen Sie getrennt, welcher Agent was getan hat. Laufen alle über einen einzigen API-Schlüssel, ist keine Unterscheidung möglich
• Tool-Aufrufe festhalten: Ob nur Text erzeugt oder ein externes System bedient wurde, macht beim Risiko einen grundlegenden Unterschied
• Festhalten, ob ein Mensch geprüft hat: Ob vor einer wichtigen Aktion ein Mensch bestätigt hat, ist direkt relevant für die Frage der Verantwortung
• Coding-Agenten einbeziehen: Auch die Coding-Agenten, die Engineers täglich nutzen, sind auf Netzwerkebene KI-Aufrufe. Sie werden leicht übersehen, gehören aber in den Aufzeichnungsumfang

Was SPHIOR leistet

Die KI-Governance von SPHIOR ist darauf ausgelegt, Aufzeichnungen zu erzeugen, die die oben genannten Bedingungen erfüllen.

Arten der Aufzeichnung (4 Wege)

Unterstützte KI und Tools

Ist der Ziel-Endpunkt ein bekannter Anbieter, zeichnet der Proxy dessen Namen auf; andernfalls (etwa bei selbst gehosteten Modellen oder über ein internes Gateway) den Hostnamen des Endpunkts unverändert. Wohin gesendet wurde, wird nie durch eigenmächtige Vermutungen ergänzt. Die Einrichtung ist in der Dokumentation beschrieben.

Umgang mit den Aufzeichnungen

• Inhalte werden nicht gesendet: Standardmäßig werden Prompt- und Ausgabetexte nicht übertragen; aufgezeichnet werden nur Fingerabdruck (Hash) und Metadaten
• Aufbewahrung mit Manipulationserkennung: Jeder Eintrag wird normalisiert und gehasht, mit dem vorherigen verkettet und gebündelt extern mit einem Zeitstempel fixiert
• Durch Dritte überprüfbar: Mit dem veröffentlichten Verifizierungswerkzeug lässt sich lokal prüfen, ohne SPHIOR vertrauen zu müssen
• Entscheidungen bleiben in Ihrem System: Über Erlauben oder Ablehnen entscheiden Ihre eigenen Leitplanken; SPHIOR zeichnet das Ergebnis auf
• Nicht aufgezeichnete Felder werden offengelegt: Beim Proxy etwa werden Kosten nur erfasst, wenn Sie Preise hinterlegen (tatsächliche Preise variieren durch Rabatte und Verträge, daher wird nicht geschätzt). Außerdem sind die Entscheidungen Ihrer Leitplanken für den Proxy nicht sichtbar; sie sollten aus der Code-Schicht aufgezeichnet werden

Was Sie Prüfern zeigen können

• Liste der Ausführungen (filterbar nach Agent, Modell, Entscheidung und Zeitraum)
• Anzahl je Agent × Modell und Verteilung der Entscheidungen (erlaubt, abgelehnt usw.)
• Verifizierungsinformationen je Eintrag
• Verifizierungspaket für einen gewählten Zeitraum (maximal 1.000 Einträge pro Export; bei mehr Einträgen den Zeitraum aufteilen)

Preise

Eine Abrechnung pro Eintrag gibt es bewusst nicht: Sie würde Weglassen belohnen und damit dem Ziel lückenloser Aufzeichnung widersprechen. Bezahlte Pläne stoppen die Aufzeichnung auch bei Überschreiten des Limits nicht, und der kostenlose Plan wird nie ungefragt kostenpflichtig. Details finden Sie unter Preise.

Häufige Fragen

Reicht es, Logs 6 Monate aufzubewahren?

Artikel 19 und Artikel 26 der KI-Verordnung schreiben „mindestens 6 Monate“ vor. Je nach Zweck kann ein längerer Zeitraum verlangt werden, und bei Audits wie SOC 2 Type II muss der Beobachtungszeitraum (meist 6 bis 12 Monate) abgedeckt sein. Wenn andere Gesetze abweichende Vorgaben machen, gelten auch diese.

Kann man ohne gespeicherte Prompt-Texte im Ernstfall überhaupt untersuchen?

Mit gespeicherten Fingerabdrücken (Hashes) können Sie mit noch vorhandenen Texten oder den Logs des Anbieters abgleichen und bestätigen, ob es diese Ein-/Ausgabe war. Je mehr Volltext Sie sammeln, desto größer ist der Schaden bei einem Datenabfluss. Ob Volltexte aufbewahrt werden, sollten Sie daher realistisch durch Abwägen von Untersuchungsbedarf und Abflussrisiko entscheiden.

Ersetzt das eine Zertifizierung nach ISO/IEC 42001?

Nein. Eine Zertifizierung erhält man nach der Prüfung durch eine Zertifizierungsstelle. Das Audit-Log ist eines der Materialien, die Sie für diese Prüfung und für Erklärungen nach innen und außen nutzen.

Taugen selbst erstellte Logs nicht?

Doch. Wenn Sie sie Externen vorlegen, müssen Sie aber erklären können, dass sie nachträglich nicht umgeschrieben wurden. Wenn Sie das etwa mit einer Hash-Kette oder externer Zeitstempelung belegbar machen, wird die Erklärung kürzer.

Zusammenfassung

• Audit-Logs für generative KI dienen der Erklärung gegenüber Externen. Wichtiger als Detailtiefe ist, dass sie nicht umgeschrieben sind und der Urheber erkennbar ist
• Die KI-Verordnung hat den Geltungsbeginn verschoben, doch die automatische Log-Aufzeichnung und die Aufbewahrung von mindestens 6 Monaten bleiben Anforderung
• Grundsätzlich keinen Volltext speichern, sondern Fingerabdruck und Metadaten. Nicht aufgezeichnete Felder offenlegen
• Proxy und Code-Schicht kombinieren und KI-Agenten sowie Coding-Agenten in den Aufzeichnungsumfang einbeziehen

Verwandt: Change Management in GitHub als Nachweis für ISO/IEC 27001 und SOC 2 vorlegen