Inhaltsfreie Audit-Logs: Wie wir nachweisen, was das Modell getan hat, ohne Prompts aufzubewahren

Jede administrative Aktion in der AI Suite erzeugt einen JSONL-Audit-Eintrag. Der Eintrag erfasst den Zeitstempel, die E-Mail-Adresse des Akteurs, das Aktionsverb, die betroffene Ressource, die X-App-Id des auslösenden Clients und einen stabilen Hash, mit dem ein Prüfer den Eintrag mit späteren Ereignissen korrelieren kann. Der Eintrag erfasst weder Eingabe noch Ausgabe des Modells. Keinen Prompt-Text, keinen Completion-Text, keinen Dokumentinhalt, keine extrahierten Entitäten. Diese Entscheidung – inhaltsfrei by design – ist es, was den Audit-Eintrag für Einkaufs- und Compliance-Prüfer nützlich macht, und es lohnt sich zu erläutern, warum.

Was in einem Audit-Eintrag steht – und was nicht

Ein repräsentativer Eintrag, leicht redigiert:

{"ts":"2026-06-05T09:14:22Z","actor":"[email protected]","action":"license.assign",
 "subject":"[email protected]","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Was er enthält: genügend Metadaten, um die Fragen zu Betreiberpflichten zu beantworten, die Auditoren stellen – wer hat was, wann, an welcher Ressource, von welchem Client aus getan. Was er nicht enthält: keinerlei Payload aus dem KI-Workflow. Wenn die Aktion ein Modell aufgerufen hätte (in diesem Beispiel nicht der Fall, aber sie könnte es), gäbe es einen Eintrag, der das Aufruf-Ereignis festhält, aber keinerlei Aufzeichnung des Prompts oder der Antwort in unserer Infrastruktur.

Diese Trennung ist bewusst. Der Audit-Eintrag ist der Nachweis, dass eine Aktion stattgefunden hat. Der Inhalt der Aktion – der an das Modell gesendete Prompt, die zurückgegebene Antwort – verbleibt auf der eigenen Hardware des Betreibers und unterliegt dessen eigener Aufbewahrungsrichtlinie. Wir sehen ihn nie.

Warum der Inhalt aus dem Eintrag herausbleibt

Zwei Gründe – einer regulatorisch, einer operativ.

Regulatorisch: Der EU AI Act verlangt von Betreibern hochriskanter KI, Logs „für einen angemessenen Zeitraum" aufzubewahren, den Systembetrieb zu überwachen und Compliance auf Anfrage nachzuweisen ^[1]. Die Pflicht liegt beim Betreiber, nachzuweisen, was passiert ist. Cloud-LLM-APIs beantworten dies, indem sie Prompt und Antwort auf der Infrastruktur des Anbieters speichern – was das Datenverarbeitungsproblem auf den Anbieter überträgt und einen zweiten Compliance-Perimeter schafft, den der Betreiber nicht kontrolliert. Inhaltsfreies lokales Audit beantwortet dieselbe regulatorische Frage ohne diese Übertragung: Der Betreiber behält den Inhalt, im eigenen Speicher des Betreibers, unter dessen eigenen Aufbewahrungsregeln.

Operativ: Jedes Byte gespeicherten Modellinhalts ist ein Byte, das verschlüsselt, zugriffskontrolliert, aufbewahrt, planmäßig gelöscht und im Rahmen von E-Discovery herausgegeben werden muss. Inhaltsfreie Einträge sind klein (wenige hundert Bytes), formfest, nur anhängbar und trivial in das bestehende SIEM des Betreibers serialisierbar. Sie sind die kleinste Beweis­einheit, die die Pflicht noch erfüllt.

Wie sich das in den großen Rahmenwerken niederschlägt

NIST AI RMF 1.0 nennt Auditierbarkeit als zentrale Dimension vertrauenswürdiger KI und fordert von Betreibern, „Aufzeichnungen über Systemaktionen zu führen, die ausreichen, um Entscheidungen zu rekonstruieren" ^[2]. „Ausreichend zur Rekonstruktion" ist die entscheidende Formulierung: Der Eintrag muss es einem Prüfer ermöglichen, das Geschehene wiederherzustellen. Ein inhaltsfreier Eintrag leistet das für administrative Aktionen (eine Lizenz wurde ausgestellt, eine Richtlinie geändert, ein Server in Betrieb genommen), ohne den Inhalt einer Inferenz aufzubewahren. Für die Inhaltsseite der Pflicht beantwortet der lokale Speicher des Betreibers die Frage.

Die KI-Cybersicherheitsleitlinien der ENISA fassen dies aus der Perspektive der Bedrohungsmodellierung ^[3]: Jeder auf der Infrastruktur eines Anbieters gespeicherte Prompt und jede dort gespeicherte Antwort erweitert die Angriffsfläche des Betreibers um die des Anbieters. Das Entfernen von Modellinhalten von der Anbieterseite engt diese Fläche auf das ein, was der Betreiber ohnehin kontrolliert.

Die Form, die wir ausliefern – die AI Admin Console-Oberfläche, das JSONL-Audit des aisuite-server-Daemons und der pro-Organisation konfigurierbare SIEM-Weiterleitungs-Hook – setzt dies direkt um. Jedes administrative Ereignis landet in einem für den Betreiber lesbaren Eintrag; weder Prompt- noch Antwortinhalt verlässt jemals den Perimeter des Betreibers.

Wie sich das in einer Einkaufsprüfung darstellt

Die Einkaufsfrage, an der Cloud-KI-Anbieter ins Stocken geraten, lautet: „Wo lebt der Inferenz-Inhalt, und kann unser Compliance-Team ihn auf Anforderung herausgeben?" Die Einkaufsfrage, die inhaltsfreies Audit beantwortet, ist dieselbe – mit zwei klaren Antworten: Der Inhalt lebt auf Ihrer Hardware, und Ihr Team gibt ihn heraus, weil es ihn ohnehin schon hat. Der Audit-Eintrag von unserer Seite weist nach, dass die Aktion stattgefunden hat; der Inhalt von Ihrer Seite weist nach, was die Aktion bewirkt hat.

Für die breitere Einkaufseinordnung – einschließlich der Frage, wie man den Lieferantenfragebogen mit diesen Eigenschaften anstelle anbieterseitiger Zertifizierungen anführt – siehe Warum On-Premises-KI-Bereitstellungen im Einkauf ins Stocken geraten und den Artikel zur EU-AI-Act-Compliance.

Was in der Verantwortung des Betreibers bleibt

Inhaltsfreies Audit ist eine strukturelle Eigenschaft der Bereitstellung, keine durchgehende Compliance-Lösung. Der Betreiber bleibt verantwortlich für:

• Die Definition, was „ausreichend zur Rekonstruktion" bedeutet, für die eigenen Workflows – Aufbewahrungsfristen, Maskierungsregeln, E-Discovery-Position.
• Den Betrieb des lokalen Inhaltsspeichers (was immer der Betreiber wählt – Dateisystem, Dokumenten-DB, verschlüsselter Blob-Store) und die Weiterleitung der Audit-Einträge von unserer Seite in das SIEM, in dem sie mit den eigenen Logs korreliert werden.
• Das Verfassen des Vermerks zu den Betreiberpflichten, der im Einkauf auf diese Architektur verweist.

Unsere Seite liefert die Architektur und das Audit-Eintrags-Format. Alles stromabwärts davon – einschließlich der Aufbewahrungsrichtlinie für den Inhalt – ist der Punkt, an dem das Compliance-Team des Betreibers seine eigenen Regeln anwendet.

Quellen

1. Europäische Kommission. „AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Abgerufen am 2026-06-03.
2. NIST. „AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Abgerufen am 2026-06-03.
3. ENISA. „Artificial Intelligence Cybersecurity." enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Abgerufen am 2026-06-03.

Verwandte Artikel

• AI Admin Console: Was jede der sechs Funktionen tatsächlich leistet
• Null Projektausfälle seit 2007 – die Engineering-Regeln dahinter
• EU AI Act 2026: Was On-Premises-Bereitstellung an der Compliance ändert
• Warum On-Premises-KI-Bereitstellungen im Einkauf ins Stocken geraten (und welche Einordnung das löst)
• Alle Artikel →