Recht & Compliance

Audit-Logs: Was sieben KI-Anbieter protokollieren

Sieben Plattformen, drei Fragen an das Protokoll: Wie lange, wie fälschungssicher, und wie kommt es ins SIEM?

Europäische KI

Sieben KI-Plattformen zeichnen auf, was in ihnen passiert, und keine zwei tun es gleich. Die Unterschiede liegen bei der Aufbewahrungsdauer, bei der Frage, ob ein Eintrag nachträglich verändert werden kann, und beim Weg des Protokolls in die Sicherheitssoftware des Unternehmens. oneAI hält das Provider Log fest 36 Monate vor und verkettet jeden Eintrag per Hash, Anthropic bestätigt für Claude Enterprise ein Exportfenster von 180 Tagen, und bei Dust und Lurus fehlt zu mindestens einem dieser Punkte jede veröffentlichte Angabe.

Was steht in einem KI-Audit-Log?

Ein Audit-Log ist die fortlaufende Aufzeichnung darüber, wer wann was in einem System getan hat, und die sieben verglichenen Anbieter füllen diese Aufzeichnung unterschiedlich. Am genauesten beschreibt Langdock den einzelnen Eintrag: Die Audit Logs API von Langdock liefert den Akteur, die Aktion, das betroffene Objekt, die IP-Adresse, den User-Agent und eine Momentaufnahme des Zustands vor und nach der Änderung.

Microsoft setzt tiefer an. Microsoft protokolliert jede einzelne Copilot-Interaktion als Datensatz vom Typ CopilotInteraction in Purview Audit, dem zentralen Protokolldienst von Microsoft 365. Anthropic protokolliert für Claude Enterprise dagegen Konto- und Sicherheitsereignisse, also Anmeldungen, die Verwaltung von Projekten und Arbeitsbereichen, Organisations- und SSO-Einstellungen sowie Datei-Uploads.

Dust vermerkt zusätzlich den Typ des Akteurs, nämlich user, api_key oder system. Damit lässt sich im Protokoll von Dust unterscheiden, ob ein Mensch oder ein KI-Agent gehandelt hat. Das Protokoll von Dust ist außerdem zeitlich geordnet, volltextdurchsuchbar und nach Zeiträumen filterbar.

Lurus beschreibt seine Audit-Logs nur allgemein als Unterstützung für interne Kontrollen, Governance und Prüfung. Welche Felder ein Eintrag bei Lurus enthält, steht auf der Sicherheitsseite von Lurus nicht.

Was unterscheidet die Audit-Logs der sieben Anbieter?

Die sieben Anbieter unterscheiden sich in Aufbewahrungsdauer, Unveränderbarkeit und Exportweg, und drei von ihnen lassen mindestens eine dieser Fragen unbeantwortet. Die folgende Übersicht fasst zusammen, was die Anbieter selbst veröffentlichen.

Tabelle: veröffentlichte Herstellerangaben zu Audit-Logs, live geprüft am 8. September 2026. Die Angaben in Zeile 1 haben den Stand 6. September 2026.
AnbieterAufbewahrungUnveränderbarkeitExport und SIEM
oneAIProvider Log 36 Monate fest, Deployer Log 14 Tage (Starter), 180 Tage (Team), 1 Jahr (Enterprise)Hash-verkettet, Datenbankregeln blockieren UPDATE und DELETE (Herstellerangabe)Export als CSV, JSON oder PDF
Anthropic (Claude Enterprise)180 Tage Exportfenster, für den Compliance-API-Feed keine Angabe veröffentlichtNicht als unveränderbar beworbenCSV-Export, Compliance API mit Elastic, Datadog, Cribl, Varonis
Microsoft 365 Copilot (Purview)180 Tage im Standard, 1 Jahr für E5 und Premium auf ausgewählten Diensten, bis 10 Jahre mit ZusatzpaketNicht als unveränderbar beworbenWeiterleitung an Microsoft Sentinel, Export über die Office-365-Management-Activity-API
DustKeine Angabe in der Entwicklerdokumentation"Tamper-evident" laut Dust, keine Details zur Hash-KetteLaufendes Streaming an Datadog, Splunk, AWS S3, GCP GCS oder einen eigenen HTTPS-Endpunkt, CSV-Export
Langdock90 Tage laut EntwicklerdokumentationNicht als unveränderbar beworbenAudit Logs API, kein SIEM-Streaming veröffentlicht
niologic (AllyAI)90 Tage onlineSHA-256-Hash-Kette und WORM-Speicher (Herstellerangabe)Export als CSV oder PDF
LurusNicht veröffentlichtNicht veröffentlichtNicht veröffentlicht

Wie lange bleiben die Protokolle verfügbar?

Zwischen 90 Tagen und mehreren Jahren, abhängig von Anbieter und Tarif. Anthropic bestätigt für Claude Enterprise ein Exportfenster von 180 Tagen, der CSV-Export reicht also 180 Tage zurück. Für den Aktivitäts-Feed der Compliance API veröffentlicht Anthropic keine Aufbewahrungsdauer, und die Angaben Dritter widersprechen sich: eine nennt sechs Jahre, eine andere legt 180 Tage nahe. Bestätigt ist nur das Exportfenster.

Microsoft Purview bewahrt Audit-Datensätze im Standardumfang heute 180 Tage auf. Diese Frist wurde von zuvor 90 Tagen angehoben, und zwar für Datensätze, die am oder nach dem 17. Oktober 2023 entstanden sind. Kunden mit E5 oder Audit Premium erhalten für Exchange-, SharePoint-, OneDrive- und Entra-Datensätze standardmäßig ein Jahr, das sich mit einem Zusatzpaket auf bis zu zehn Jahre verlängern lässt.

Langdocks Entwicklerdokumentation nennt am 8. September 2026 eine Aufbewahrung von 90 Tagen. Eine zweite Langdock-Quelle, die diese Frist bestätigt, gibt es bisher nicht, die Angabe steht also auf einem Bein. niologic hält die AllyAI-Protokolle 90 Tage online.

Dust nennt in der Entwicklerdokumentation und im zugehörigen Changelog keine Aufbewahrungsdauer. Lurus veröffentlicht ebenfalls keine. Für beide gilt: Wer wissen will, wie weit ein Protokoll zurückreicht, muss danach fragen, statt es nachzulesen.

Was heißt "unveränderbar" bei einem Audit-Log?

Unveränderbar heißt, dass ein einmal geschriebener Eintrag nicht nachträglich verändert oder gelöscht werden kann, ohne dass es auffällt. Zwei technische Mittel dafür tauchen in diesem Vergleich auf. Bei einer Hash-Kette trägt jeder Eintrag eine Prüfsumme des vorherigen Eintrags, eine nachträgliche Änderung zerreißt die Kette also sichtbar. Bei WORM-Speicher, kurz für write once, read many, lässt schon die Speicherebene kein Überschreiben zu.

niologic setzt beides für AllyAI ein: eine SHA-256-Hash-Kette über alle Aktionen und WORM-Speicher. Dust nennt sein Protokoll "tamper-evident", also so gebaut, dass eine Manipulation erkennbar wird, veröffentlicht dazu aber keine Details zur Hash-Kette. Anthropic, Microsoft und Langdock bewerben ihre Protokolle nicht als unveränderbar oder hash-verkettet, und Lurus veröffentlicht zu diesem Punkt gar nichts.

Alle Zusicherungen dieser Art sind Herstellerangaben. Keiner der sieben Anbieter veröffentlicht eine Prüfung durch einen unabhängigen Dritten, die die Unveränderbarkeit des Protokolls bestätigt. Für eine Innenrevision ist das ein wichtiger Unterschied: Eine Hash-Kette ist technisch nachvollziehbar beschrieben, ein Testat über ihre Wirksamkeit liegt bei keinem der sieben Anbieter vor. Wer ein solches Testat braucht, sollte es vertraglich einfordern, statt es aus der Produktbeschreibung herauszulesen.

Wie kommen die Protokolle in die Sicherheitssoftware des Unternehmens?

Auf sehr unterschiedlichen Wegen, und bei der Anbindungsbreite führen hier die großen US-Anbieter. Ein SIEM, kurz für Security Information and Event Management, ist die zentrale Software, in der ein Sicherheitsteam die Protokolle aller Systeme zusammenführt, durchsucht und für Alarme auswertet. Ein Audit-Log, das dort nicht ankommt, wird selten gelesen.

Anthropic bietet mit der Compliance API einen programmatischen Aktivitäts-Feed und nennt dafür Integrationen mit Elastic, Datadog, Cribl und Varonis, begrenzt auf 600 Anfragen pro Minute je übergeordneter Organisation. Das ist die breiteste Liste namentlich genannter SIEM-Anbindungen im Vergleich.

Dust streamt Audit-Logs im Enterprise-Tarif fortlaufend an Datadog, Splunk, AWS S3, GCP GCS oder einen eigenen HTTPS-Endpunkt. Bei sofort einsatzbereitem Dauerstreaming führt Dust. Microsoft wiederum lässt Copilot-Audit-Daten nativ an Microsoft Sentinel weiterleiten oder über die Office-365-Management-Activity-API an ein SIEM eines Drittanbieters übergeben. Wer die Sicherheitstelemetrie von Microsoft 365 ohnehin in Sentinel sammelt, bekommt die Copilot-Daten direkt daneben.

Langdock bietet nur den Abruf über die Audit Logs API und veröffentlicht kein SIEM-Streaming. niologic exportiert AllyAI-Protokolle als CSV oder PDF. Für oneAI ist keine Liste benannter SIEM-Connectoren veröffentlicht, der Weg nach draußen führt über den gefilterten Export als CSV, JSON oder PDF. Auf dieser Dimension liegen Anthropic, Dust und Microsoft vorn.

Warum trennen manche Anbieter zwei Protokolle?

Weil eine Aufsichtsbehörde und ein Sicherheitsteam Verschiedenes aus demselben Geschehen lesen wollen. Die Behörde will sehen, dass ein System über alle Kunden hinweg überwacht wird, und braucht dafür keine Klarnamen. Das Sicherheitsteam eines einzelnen Unternehmens braucht umgekehrt jedes Detail zum eigenen Mandanten und darf die Daten anderer Kunden nicht sehen.

Diese Trennung setzt oneAI in zwei getrennten Protokollen um. Das Provider Log ist anonymisiert, es führt gehashte Mandanten-IDs statt Klarnamen, wird fest 36 Monate aufbewahrt und steht laut Herstellerbeschreibung Aufsichtsbehörden für die Marktbeobachtung nach dem EU AI Act zur Verfügung, der KI-Verordnung der EU. Das Deployer Log gehört einem einzelnen Mandanten, ist vollständig detailliert, wird je nach Tarif 14 Tage (Starter), 180 Tage (Team) oder ein Jahr (Enterprise) aufbewahrt und lässt sich als CSV, JSON oder PDF exportieren. Beide Protokolle sind nach Herstellerangabe hash-verkettet, und Datenbankregeln blockieren UPDATE und DELETE, also das nachträgliche Ändern und das Löschen eines Eintrags.

Das Deployer Log kennzeichnet jeden Eintrag nach Herkunft, etwa als Guardrail-Treffer, Chat-Aktivität oder Einstellungsänderung. Auch Änderungen an Compliance-Schaltern, Modellkatalog und Rechtevergabe landen darin, sodass die Frage "wer hat das abgeschaltet, und wann" beantwortbar bleibt. Führt die KI selbst eine Aktion aus, hält der Eintrag fest, warum sie erlaubt war: durch menschliche Bestätigung, durch eine Richtlinie oder durch eine Freigabe des Eigentümers.

Wer die Trennung nach Leserkreis braucht, bekommt in derselben Plattform einen Klassifikator dazu, der jede Interaktion auf der Risikoleiter des EU AI Act einstuft und dazu eine kurze Begründung mit Konfidenzwert, die erkannten Kategorien sensibler Daten und einen empfohlenen Verarbeitungsort notiert. Dieser Klassifikator wird als kostenpflichtiges Add-on verkauft und ist nicht Teil des Basispreises. Die Plattform und ihre Protokollinfrastruktur laufen in der EU-Cloud der Hetzner Online GmbH in Nürnberg und Falkenstein oder vollständig auf eigenen Servern.

Quellen