Audit-Log für KI-Agenten: Was der EU AI Act verlangt

18. September 2026 · 7 Min. Lesezeit

KI-Agenten beantworten in Entwicklungsteams längst nicht mehr nur Fragen. Sie legen Jira-Tickets an, kommentieren Pull Requests, fragen Tabellen in Databricks ab und schreiben Nachrichten in Slack. Jede dieser Aktionen ist ein Aufruf gegen ein echtes System, ausgeführt mit echten Zugangsdaten. Wenn etwas schiefgeht oder ein Prüfer oder Kunde wissen möchte, was ein Agent getan hat, braucht das Team ein Protokoll, das diese Frage genau beantwortet. In vielen Unternehmen gibt es dieses Protokoll nicht, oder es liegt ausschließlich beim KI-Anbieter.

Dieser Beitrag beschreibt, was ein Audit-Log für KI-Agenten enthalten sollte, warum der Ort des Protokolls genauso wichtig ist wie sein Inhalt und welchen Rahmen EU AI Act und DSGVO dafür setzen. Er gehört zu unserer Reihe über KI-Agenten in der Softwareentwicklung.

Warum das Thema gerade jetzt aufkommt

Hier treffen zwei Entwicklungen zusammen. Erstens greifen Agenten auf deutlich mehr Systeme zu als früher. Über das Model Context Protocol (MCP) kann ein Client wie Claude Code, Cursor oder VS Code direkt Tools in Jira, GitHub oder Confluence aufrufen. Zweitens verlangt die Regulierung zunehmend Nachweise. Der EU AI Act (Verordnung (EU) 2024/1689) enthält ausdrückliche Aufzeichnungspflichten, und die DSGVO fordert seit 2018 Rechenschaft für jede Verarbeitung personenbezogener Daten.

Der Zeitplan wird häufig falsch dargestellt, deshalb lohnt sich ein genauer Blick. Verbotene Praktiken gelten seit dem 2. Februar 2025, die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck seit dem 2. August 2025. Die Transparenzpflichten nach Artikel 50 gelten ab dem 2. August 2026. Die Pflichten für Hochrisiko-Systeme wurden durch den Digital Omnibus (Verordnung (EU) 2026/1744, in Kraft seit dem 27. Juli 2026) verschoben: Für eigenständige Hochrisiko-Systeme nach Anhang III gelten sie ab dem 2. Dezember 2027, für KI in regulierten Produkten nach Anhang I ab dem 2. August 2028.

Genauso wichtig ist eine ehrliche Einordnung. Die meisten Agenten, die Sprints planen, Code reviewen oder Dokumentation pflegen, sind keine Hochrisiko-Systeme im Sinne des AI Act. Die strengen Protokollierungspflichten nach Artikel 12 gelten für sie daher nicht unmittelbar. Die Frage wird dadurch jedoch nicht bedeutungslos. Sobald ein Agent personenbezogene Daten liest oder weitergibt, gilt die DSGVO, und der Verantwortliche muss nachweisen können, was passiert ist (Art. 5 Abs. 2 DSGVO). Hinzu kommt, dass Security-Teams und Kunden immer öfter genau die Frage stellen, die auch ein Prüfer stellen würde: Welcher Agent hat was getan, mit wessen Berechtigung, und war das erlaubt?

Was ein Audit-Log für KI-Agenten enthalten sollte

Ein brauchbares Audit-Log beantwortet für jeden einzelnen Aufruf fünf Fragen. Die folgenden Angaben sind ein sinnvolles Minimum.

Wer hat gehandelt? Die Identität hinter dem Aufruf: welcher Agent oder welche Person, mit welchem API-Key, in welchem Projekt oder Workspace. „Das war die KI“ ist keine Antwort, die ein Prüfer akzeptiert. Das Protokoll muss die verantwortliche Identität benennen.

Was wurde angefragt? Das Zielsystem, die Operation (zum Beispiel jira_create_issue oder github_merge_pr) und die Parameter, etwa der Projektschlüssel oder das Repository. Parameter können personenbezogene oder geheime Daten enthalten und sollten deshalb vor dem Schreiben geschwärzt werden. Das Protokoll darf nicht zur zweiten Kopie genau der Daten werden, die es eigentlich schützen soll.

Was wurde entschieden, und warum? Genau dieser Teil fehlt in den meisten Protokollen. Es reicht nicht, erfolgreiche Aufrufe festzuhalten. Ein vollständiges Audit-Log enthält auch abgelehnte Aufrufe samt Begründung (zum Beispiel „Operation in diesem Workspace nicht freigeschaltet“ oder „Repository nicht in der Allowlist“), Aufrufe, die auf eine manuelle Freigabe warten, Aufrufe, die an ein Rate Limit gestoßen sind, und Aufrufe, die mit einem Fehler geendet haben. Gerade die abgelehnten Aufrufe sind oft am aufschlussreichsten, weil sie zeigen, was ein Agent außerhalb seiner Befugnisse versucht hat.

Wann? Ein genauer Zeitstempel in einer einheitlichen Zeitzone, damit sich Einträge mit Ereignissen in anderen Systemen abgleichen lassen.

Ist der Eintrag unverändert? Ein Audit-Log ist nur dann ein Nachweis, wenn niemand es nachträglich unbemerkt ändern kann. Dafür braucht es einen technischen Schutz, nicht nur eine Richtlinie, die das Bearbeiten verbietet.

Ein guter Test: Nehmen Sie einen echten Vorfall und versuchen Sie, ihn ausschließlich anhand des Protokolls nachzuvollziehen. Wenn Sie dafür Screenshots, Chatverläufe oder das Gedächtnis von Kollegen brauchen, ist das Protokoll unvollständig.

Warum das Protokoll des Anbieters kein unabhängiger Nachweis ist

Mehrere KI-Anbieter bieten inzwischen eigene Audit-Logs für ihre Tools und Konnektoren an. Für den Betrieb dieser Tools sind sie nützlich, und es gibt keinen Grund, sie zu ignorieren. Als Nachweis haben sie jedoch eine strukturelle Schwäche: Die Partei, deren Handeln geprüft wird, führt auch das Protokoll.

Das ist aus drei Gründen relevant. Erstens die Unabhängigkeit: Ein Prüfer bewertet ein Protokoll, das der Betreiber des geprüften Systems selbst führt, anders als eines aus einer getrennten Kontrollinstanz. Das Prinzip kennt man aus der Buchhaltung, in der Buchführung und Prüfung bewusst getrennt sind. Zweitens die Abdeckung: Das Protokoll eines Anbieters erfasst nur dessen eigene Tools. Ein Team, das Claude Code für Code, Cursor in der IDE und einen internen Chatbot im Support einsetzt, hat drei Teilprotokolle in drei Formaten, und keines davon zeigt das Gesamtbild. Drittens die Kontrolle über Aufbewahrung und Zugriff: Aufbewahrungsdauer, Exportformat und Zugriffsrechte legt der Anbieter fest, nicht das Unternehmen, das für die Daten geradestehen muss.

Links: Jeder KI-Client schreibt in das Log seines Anbieters, mit dessen Format und Aufbewahrungsfrist. Rechts: Jeder Aufruf läuft über ein selbst gehostetes Gateway, das ein einziges Audit-Log führt und weiterleitet.

Eine unabhängige Kontrollinstanz vermeidet diese Probleme schon durch ihre Architektur. Laufen alle Aufrufe der Agenten über ein Gateway, das das Unternehmen selbst betreibt, ist das Protokoll anbieterübergreifend vollständig und gehört dem Unternehmen, das die Verantwortung trägt. Der Beitrag Was ist ein MCP Gateway? erklärt diese Architektur genauer.

Wie Vordix die Aktivität von Agenten protokolliert

Vordix ist ein selbst gehostetes Gateway zwischen KI-Agenten und Tools wie Jira, GitHub, Confluence, Slack und Databricks. Jede Anfrage läuft durch dieses Gateway und wird daher an einer Stelle protokolliert. Das Audit-Log orientiert sich an den oben genannten Fragen:

Jedes Ergebnis wird erfasst: erlaubt, abgelehnt mit Begründung, zur Freigabe angehalten, durch das Rate Limit gebremst und fehlgeschlagen. Jeder Eintrag enthält den Entscheidungspfad, also welche Regel zu welcher Entscheidung geführt hat.
Parameter werden vor dem Schreiben geschwärzt, damit personenbezogene Daten aus einer Anfrage nicht im Klartext im Protokoll landen.
Das Protokoll ist append-only und über eine HMAC-Hashkette verkettet. Keine Rolle, auch nicht der Administrator, kann Einträge bearbeiten, und die Integrität der Kette lässt sich jederzeit prüfen. Ein geänderter oder gelöschter Eintrag bricht die Kette.
Die Aufbewahrung beträgt mindestens 180 Tage, und ein Legal Hold kann Einträge darüber hinaus sichern.
Export und Weiterleitung: Einträge lassen sich als CSV oder JSON exportieren, als Live-Stream verfolgen oder über einen signierten Webhook an ein SIEM (Security Information and Event Management) übergeben.
Regulatorische Kennzeichnung: Audit-Einträge tragen Tags für die Artikel 10 und 12 des AI Act, und die Compliance-Seite der Dokumentation ordnet die Kontrollen den Artikeln 10, 12 und 14 des AI Act sowie ISO 27001 Anhang A zu.

Vier Einträge in einer append-only Kette: Jeder speichert den vorherigen Hash und einen HMAC über sich selbst, sodass ein abgelehnter Aufruf samt Begründung genauso fest steht wie ein erlaubter. Die Kette lässt sich exportieren oder an ein SIEM senden.

Da Vordix auf der eigenen Infrastruktur des Unternehmens läuft, liegt das Protokoll dort, wo das Unternehmen es festlegt, und Vordix als Anbieter ist nicht in den Datenfluss eingebunden.

Für schreibende Operationen, die ein Vier-Augen-Prinzip brauchen, etwa das Mergen eines Pull Requests (siehe Berechtigungen für KI Code Review auf GitHub und Azure DevOps), kann ein Administrator eine Freigaberegel einrichten. Angehaltene Aufrufe erscheinen dann ebenfalls im Protokoll, zusammen mit der anschließenden Freigabe oder Ablehnung. Beim Datenzugriff zeigt dasselbe Protokoll, welche Tabellen und Spalten ein Agent gelesen hat, wie im Beitrag KI-Agenten und Datenzugriff in Databricks beschrieben.

Grenzen und Abwägungen

Ein Audit-Log ist ein notwendiger Teil von Governance, reicht allein aber nicht aus. Einige Einschränkungen sollten klar benannt werden.

Erstens dokumentiert ein Protokoll, es verhindert nichts. Seinen Wert entfaltet es erst zusammen mit der Durchsetzung: Eingeschränkte Berechtigungen, Allowlists und Freigaben legen fest, was ein Agent tun darf, und das Protokoll belegt, was er tatsächlich getan hat. Ein Protokoll ohne Durchsetzung dokumentiert vor allem den Schaden.

Zweitens kann ein Gateway nur erfassen, was durch das Gateway läuft. Besitzt ein Agent weiterhin ein direktes API-Token für GitHub, umgehen Aufrufe mit diesem Token das Gateway und fehlen im Protokoll. Direkte Zugangsdaten zu entfernen ist daher Teil der Einführung und kein optionaler Schritt.

Drittens ist Vordix nicht zertifiziert, und der Einsatz von Vordix macht ein Unternehmen nicht automatisch konform mit dem AI Act, der DSGVO oder ISO 27001. Die Kontrollen und die Zuordnung helfen dabei, Nachweise zu erbringen. Ob ein konkreter Anwendungsfall ein Hochrisiko-System ist und ob die Maßnahmen insgesamt ausreichen, bleibt eine Bewertung des Unternehmens und seiner Berater.

Schließlich ist das Schwärzen eine Abwägung. Je mehr Parameter vor dem Schreiben maskiert werden, desto weniger personenbezogene Daten enthält das Protokoll, desto schwieriger werden aber manche Analysen. Die richtige Balance hängt von den Daten ab, mit denen die Agenten arbeiten, und sollte gemeinsam mit dem Datenschutzbeauftragten festgelegt werden.

Fazit

Ein Audit-Log für KI-Agenten sollte festhalten, wer gehandelt hat, was angefragt wurde, was entschieden wurde und warum, und wann das geschah, und zwar für abgelehnte ebenso wie für erfolgreiche Aufrufe. Außerdem muss es gegen nachträgliche Änderungen geschützt sein. Für die meisten Agenten in der Softwareentwicklung gelten die Hochrisiko-Pflichten des AI Act nicht unmittelbar, doch die Rechenschaftspflicht der DSGVO und die Erwartungen von Kunden führen zur selben Anforderung. Wer dieses Protokoll in einer unabhängigen, selbst gehosteten Kontrollinstanz führt statt verteilt in den Tools der einzelnen Anbieter, erhält ein vollständiges Protokoll, das dem Unternehmen gehört, das dafür verantwortlich ist.

Die Vordix-Dokumentation beschreibt das Audit-Log im Detail, und in einer Demo lässt es sich mit echten Agenten-Aufrufen ansehen.