Die automatische Protokollierung gehört zu den unscheinbaren, aber harten technischen Pflichten des EU AI Act. Art. 12 verlangt, dass Hochrisiko-KI-Systeme so konzipiert sind, dass sie während ihres gesamten Lebenszyklus Ereignisse automatisch aufzeichnen — sogenannte Logs. Anders als die Risikoklassifizierung oder die Grundrechte-Folgenabschätzung lässt sich diese Pflicht nicht durch ein Dokument erfüllen; sie muss in der Architektur des Systems verankert sein. Wer das übersieht, steht im Audit mit einem ansonsten konformen System da, das den einen Nachweis nicht erbringen kann, der über Nachvollziehbarkeit entscheidet.
Was Art. 12 konkret verlangt
Der Kern ist die Rückverfolgbarkeit. Die Protokollierung muss eine Aufzeichnung von Ereignissen ermöglichen, die für die Erkennung von Situationen relevant sind, in denen das System ein Risiko im Sinne von Art. 79 darstellen oder zu einer wesentlichen Änderung führen kann. Sie muss zudem die Überwachung des Betriebs nach dem Inverkehrbringen erleichtern und die menschliche Aufsicht unterstützen. Für bestimmte Hochrisiko-Systeme — namentlich biometrische Fernidentifizierung — nennt der AI Act ausdrücklich Mindestinhalte: Zeitraum jeder Nutzung, die Referenzdatenbank, gegen die abgeglichen wurde, die Eingabedaten, die zu einem Treffer führten, und die Identität der Personen, die das Ergebnis überprüft haben.
Daraus ergibt sich ein Grundsatz, der über die Pflichtfälle hinaus gilt: Loggen Sie genug, um im Nachhinein rekonstruieren zu können, was das System wann auf welcher Grundlage getan hat und wer es überwacht hat. Ein Log, das nur «Anfrage verarbeitet» festhält, erfüllt den Zweck nicht.
Was in ein prüffestes Log gehört
In der Praxis bewährt sich pro relevantem Ereignis ein Datensatz mit: einem Zeitstempel; einer eindeutigen Vorgangs-ID; der Version des eingesetzten Modells und der Anwendung; einer Referenz auf die Eingabedaten (nicht zwingend die Daten selbst); dem Ergebnis bzw. der Klassifizierung; einer etwaigen menschlichen Überprüfung oder Korrektur mit Identität des Prüfers; und sicherheitsrelevanten Ereignissen wie Fehlern oder Anomalien. Wichtig ist die Unveränderlichkeit: Logs, die sich nachträglich ändern lassen, sind als Nachweis wertlos. Schreiben Sie sie in einen append-only-Speicher oder sichern Sie ihre Integrität kryptografisch.
Die Aufbewahrungsfrage
Der AI Act verlangt, dass Anbieter die automatisch erzeugten Logs aufbewahren, soweit diese unter ihrer Kontrolle stehen — für einen Zeitraum, der dem Zweck des Systems angemessen ist und mindestens sechs Monate beträgt, sofern nicht spezifischeres Unionsrecht oder nationales Recht etwas anderes vorschreibt. Für Betreiber gelten parallele Aufbewahrungspflichten für die Logs, die in ihrem Verantwortungsbereich anfallen. Sechs Monate sind dabei die Untergrenze, nicht der Standard: In regulierten Branchen oder bei langlebigen Entscheidungen kann eine deutlich längere Frist angemessen sein.
Der Konflikt mit dem Datenschutz
Hier entsteht die heikelste Spannung. Umfassendes Logging und Datenminimierung nach der DSGVO ziehen in entgegengesetzte Richtungen. Die Lösung liegt nicht im Verzicht auf eines von beiden, sondern in der bewussten Gestaltung: Loggen Sie Referenzen und Metadaten statt vollständiger personenbezogener Inhalte, pseudonymisieren Sie wo möglich, trennen Sie die Logs technisch und rechtlich von den Produktivdaten und definieren Sie für die Logs eine eigene Aufbewahrungs- und Löschlogik, die sowohl die AI-Act-Mindestfrist als auch die DSGVO-Grenzen respektiert. Dokumentieren Sie diese Abwägung — sie ist genau der Punkt, an dem eine Aufsichtsbehörde nachfragen wird.
Logging als Betriebsvorteil
Über die Pflicht hinaus ist gutes Logging ein Betriebsvorteil. Dieselben Aufzeichnungen, die der AI Act verlangt, sind die Grundlage für Observability, Fehleranalyse und Modell-Monitoring. Wer das Logging einmal sauber aufsetzt, erfüllt nicht nur eine regulatorische Anforderung, sondern gewinnt die Datenbasis, um Drift zu erkennen, Vorfälle zu untersuchen und die Qualität des Systems über die Zeit zu belegen. Behandeln Sie die Art-12-Pflicht deshalb nicht als isolierte Compliance-Aufgabe, sondern als Anlass, Ihre Beobachtbarkeit insgesamt zu professionalisieren.
Was zu tun ist
Beginnen Sie mit einer Inventur: Welche Hochrisiko-Systeme betreiben oder liefern wir, und was zeichnen sie heute auf? In den meisten Fällen existiert irgendein Logging, aber selten in einer Form, die unveränderlich, vollständig und mit definierter Aufbewahrung ausgestattet ist. Schliessen Sie die Lücke zwischen dem, was technisch anfällt, und dem, was Art. 12 verlangt. Definieren Sie das Log-Schema, den Speicherort mit Integritätsschutz, die Aufbewahrungsfrist und die Löschlogik in Abstimmung mit dem Datenschutz. Verankern Sie das Ergebnis in Ihrer technischen Dokumentation nach Anhang IV. Wenn Sie unsicher sind, wo die angemessene Aufbewahrungsfrist für Ihren konkreten Anwendungsfall liegt, ist das genau die Stelle, an der eine fachliche Zweitmeinung den Unterschied zwischen Über- und Unterdokumentation macht.
Die richtige Granularität
Eine praktische Kunst liegt in der Granularität. Zu wenig Logging verfehlt den Zweck der Rückverfolgbarkeit; zu viel erzeugt Datenberge, die niemand auswertet, hohe Kosten und neue Datenschutzrisiken. Die Faustregel: Loggen Sie auf der Ebene, auf der eine Entscheidung oder ein risikorelevantes Ereignis stattfindet — nicht jeden technischen Zwischenschritt, aber jeden Punkt, an dem das System eine Bewertung trifft, eine Schwelle überschreitet oder von einem Menschen überprüft wird. Definieren Sie diese Ereignistypen einmal bewusst, statt reflexhaft alles oder nichts zu protokollieren.
Verankern Sie das Logging-Konzept schliesslich in Ihrer Governance, nicht nur im Code. Wer ein KI-Risikoinventar führt, ergänzt für jedes Hochrisiko-System einen Verweis auf dessen Logging: Welche Ereignisse, welcher Speicherort, welche Aufbewahrungsfrist, welche Löschlogik. So entsteht der lückenlose Nachweis, den ein Audit verlangt — von der Systemübersicht über das Risikomanagement bis zum konkreten, unveränderlichen Protokoll, das im Ernstfall belegt, was das System getan hat.