Azure-OpenAI-Protokollierung nach EU AI Act

Europäische Unternehmen steuern auf ein Datum zu, das viele Vorstände noch als abstrakt behandeln. Ab dem 2. August 2026 müssen Hochrisiko-KI-Systeme nach Anhang III des EU AI Act eine konkrete Reihe von Pflichten erfüllen — Konformitätsbewertung, Registrierung, technische Dokumentation, menschliche Aufsicht und Beobachtung nach dem Inverkehrbringen. In dieser Liste versteckt sich eine Anforderung, die still darüber entscheidet, ob der Rest überhaupt nachweisbar ist: die automatische Protokollierung. Wenn Sie Azure OpenAI in einem System einsetzen, das Beschäftigung, Kreditvergabe, kritische Infrastruktur oder andere Anhang-III-Bereiche berührt, ist Ihr Audit-Log das Rückgrat Ihrer Compliance. Machen Sie es falsch, wird die Konformitätsbewertung zum Ratespiel; machen Sie es richtig, fallen die meisten anderen Pflichten als Nebenprodukt guter Ingenieursarbeit ab.

TL;DR / Die wichtigsten Erkenntnisse

Artikel 12 des EU AI Act verlangt eine automatische Ereignisprotokollierung über die gesamte Lebensdauer von Hochrisiko-Systemen — für Azure-OpenAI-Betreiber ist das eine Architekturanforderung, kein Häkchen.
Die Hochrisiko-Pflichten nach Anhang III gelten ab dem 2. August 2026; Ihr Protokollierungsdesign muss davor stehen und getestet sein, nicht danach.
Azure liefert die Roh-Telemetrie (Diagnoseeinstellungen, Log Analytics, Content-Filter-Annotationen, Purview), aber die semantische Entscheidungsspur, die einen Modellaufruf mit einer Geschäftsentscheidung und einer prüfenden Person verbindet, bauen Sie selbst.
Das rechtlich relevante Log ist eine nachverfolgbare Entscheidungsspur, nicht hochvolumige Token-Telemetrie — trennen Sie beides, um Kosten und Aufbewahrung zu steuern.
ISO/IEC 42001 liefert das Managementsystem-Gerüst, das die AI-Act-Protokollierung auditierbar macht; bilden Sie einen Nachweissatz auf beides ab.

Warum Protokollierung die tragende Pflicht ist

Der Großteil der Debatte um den AI Act dreht sich um Bußgelder — bis zu 35 Mio. EUR oder 7 % des weltweiten Umsatzes bei verbotenen Praktiken, bis zu 15 Mio. EUR oder 3 % bei Hochrisiko-Verstößen. Diese Zahlen erzeugen Aufmerksamkeit. Doch der Mechanismus, der Sie ihnen tatsächlich aussetzt, ist die Nachverfolgbarkeit. Eine Marktüberwachungsbehörde bestraft Sie nicht dafür, dass ein Modell falsch lag; sie wird tätig, wenn Sie nicht belegen können, dass Sie das System wie dokumentiert betrieben haben — mit menschlicher Aufsicht und angemessenen Risikomanagementmaßnahmen.

Artikel 12 ist eindeutig: Hochrisiko-KI-Systeme müssen die automatische Aufzeichnung von Ereignissen (Logs) über ihre gesamte Lebensdauer technisch ermöglichen, in einem dem Verwendungszweck angemessenen Umfang. Die Erwägungsgründe verknüpfen dies direkt mit Nachverfolgbarkeit und Beobachtung nach dem Inverkehrbringen. Mit anderen Worten: Das Log ist der Nachweis, dass alles andere in Ihrer Konformitätsakte stimmt. Wir haben Governance-Ebenen für Azure-OpenAI-Deployments geliefert, bei denen der Kunde exzellente Richtlinien auf dem Papier hatte und dennoch nicht belegen konnte, welche Modellversion sechs Wochen zuvor eine konkrete, später bestrittene Ausgabe erzeugt hatte oder ob ein Mensch sie geprüft hatte. Diese Lücke ist der mit Abstand häufigste Befund, den wir antreffen.

Wenn Sie noch nicht geklärt haben, ob Ihr System in den Anwendungsbereich fällt, beginnen Sie mit der Einstufung — unser Leitfaden zur Hochrisiko-Einstufung nach Anhang III führt durch die Entscheidungslogik. Die Protokollierungslast skaliert direkt mit dieser Antwort.

Was das Log tatsächlich enthalten muss

Es hält sich hartnäckig der Irrglaube, "wir schicken alles nach Log Analytics" erfülle den AI Act. Das tut es nicht. Operative Telemetrie — Latenz, Token-Zahlen, Fehlerraten — ist nützlich für den Betrieb, für eine Behörde aber weitgehend irrelevant. Den AI Act interessiert, ob Sie eine konkrete Nutzung des Systems nachträglich rekonstruieren können.

Der minimale, semantisch relevante Datensatz für eine Hochrisiko-Azure-OpenAI-Interaktion sieht so aus:

Feld	Warum es zählt	Quelle
Korrelations-/Entscheidungs-ID	Verknüpft den Modellaufruf mit einer Geschäftstransaktion	Ihre Orchestrierungsebene
Zeitstempel und Nutzungszeitraum	Nach Art. 12 für Nachverfolgbarkeit erforderlich	Anwendung + Azure Monitor
Prompt-/Eingabereferenz	Rekonstruiert, was das System gefragt wurde	Anwendung (Hash oder Referenz, nicht stets Roh-PII)
Modell und Version	Reproduzierbarkeit und Verantwortlichkeit der Ausgabe	Azure-OpenAI-Deployment-Metadaten
Zurückgegebene Ausgabe	Die tatsächliche Entscheidung oder Generierung	Anwendung
Content-Filter-/Sicherheitsverdikt	Nachweis wirksamer Risikomanagementmaßnahmen	Azure-OpenAI-Content-Filter-Annotationen
Prüfende Person / Übersteuerung	Belegt die menschliche Aufsicht	Anwendungs-Workflow
Aufbewahrungsklasse	Steuert Lebenszyklus und Legal Hold	Protokollierungsrichtlinie

Beachten Sie, wie wenig davon die Plattform kostenlos liefert. Azure liefert zuverlässig die Modell-Deployment-Metadaten, die Content-Filter-Annotationen und die Diagnose auf Anfrageebene. Die Korrelations-ID, die Verbindung zu einer Geschäftsentscheidung und die Aufsichtshandlung erzeugt Ihr Code. Genau diesen Teil unterschätzen Teams systematisch — und deshalb ist "Diagnoseeinstellungen aktivieren" notwendig, aber bei Weitem nicht hinreichend.

Eine zweite Feinheit: Prompts enthalten häufig personenbezogene Daten, womit Ihr Audit-Log selbst eine Verarbeitungstätigkeit nach DSGVO ist. Sie erfüllen den AI Act nicht, indem Sie Roh-Prompts ewig horten. Das reife Muster ist, eine Referenz oder einen Hash der Eingabe zu protokollieren, ergänzt um eine kontrollierte, zugriffsbeschränkte Kopie der rechtlich erforderlichen Felder — mit kategoriespezifischer Aufbewahrung und Datenminimierung.

Eine Referenzarchitektur auf Azure

Die Architektur, die wir ausrollen, trennt bewusst drei Belange: Plattform-Telemetrie, Entscheidungsspur und Governance.

1. Plattform-Telemetrie (Azure-nativ)

Aktivieren Sie Diagnoseeinstellungen auf jeder Azure-OpenAI-Ressource und leiten Sie Logs und Metriken in einen dedizierten Log-Analytics-Workspace. Das erfasst Anfragemetadaten, Throttling und die Content-Filter-Annotationen, die belegen, dass Ihre Sicherheitskontrollen aktiv waren. Diese Ebene ist günstig zu aktivieren und gilt als Pflichtprogramm.

2. Die Entscheidungsspur (bauen Sie selbst)

Ihr Orchestrierungscode — ob ein eigener Dienst, ein KI-Gateway oder ein Framework wie Semantic Kernel — erzeugt pro Hochrisiko-Interaktion ein strukturiertes, ausschließlich anfügbares Log-Ereignis mit den Feldern aus der obigen Tabelle. Leiten Sie es in einen unveränderbaren Speicher (Log Analytics mit Unveränderbarkeit oder ein Append-only-Blob/-Table mit WORM, wo die Aufbewahrung streng ist). Die Entscheidungsspur ist volumenärmer als die Telemetrie und trägt das rechtliche Gewicht — sie rechtfertigt stärkere Garantien.

3. Governance und Review (Purview + Monitoring)

Nutzen Sie Microsoft Purview für Datenklassifizierung, Lineage und Zugriffs-Governance über die Log-Speicher und bauen Sie Azure-Monitor-Dashboards und -Alarme für Drift, auffällige Filterereignisse und Aufsichtslücken. Entscheidend: Die Logs müssen in eine echte Schleife zur Beobachtung nach dem Inverkehrbringen münden — einen dokumentierten Prozess, in dem jemand sie prüft. Ein Archiv, das niemand liest, ist keine Beobachtung.

Architektur im Überblick

Loading diagram...

Aufbewahrung: behalten, was das Recht verlangt — nicht alles für immer

Der AI Act verlangt eine Aufbewahrung der Logs für einen dem Verwendungszweck angemessenen Zeitraum, mindestens jedoch sechs Monate, sofern kein anderes Unions- oder nationales Recht eine längere Frist vorschreibt. Für die meisten Unternehmen ist die bindende Schranke gar nicht der AI Act, sondern das Sektorrecht. Eine Bank mit einem Anhang-III-System lebt zugleich unter DORA; ein Gesundheitsdienstleister unter sektoralen Aufbewahrungsregeln. Diese übersteigen sechs Monate meist deutlich.

Die ingenieurtechnische Konsequenz ist, die Aufbewahrung je Log-Kategorie zu definieren, nicht global:

Entscheidungsspur — Aufbewahrung über die längste anwendbare gesetzliche Frist, unveränderbar, zugriffskontrolliert.
Content-Filter-/Sicherheitsereignisse — gemeinsam mit der Entscheidungsspur aufbewahren; sie sind Teil des Nachweises der Risikomanagementmaßnahmen.
Operative Telemetrie — kurze Aufbewahrung (oft 30–90 Tage), denn sie dient dem Engineering, nicht der Revision.
Personenbezogene Daten in Eingaben — aggressiv minimieren; wo machbar referenzieren statt roh speichern.

Diese Klassen zu vermengen ist der Weg, auf dem Organisationen jahrelang für Terabytes nutzloser Telemetrie zahlen und das Audit dennoch nicht bestehen — weil das eine Feld, das zählte, die prüfende Person, nie erfasst wurde.

Eine pragmatische Bereitschafts-Checkliste

Für Teams mit einem Hochrisiko-Azure-OpenAI-System, das vor August 2026 produktiv ist oder geplant wird, arbeiten Sie diese Abfolge ab:

Einstufen des Systems gegen Anhang III und Dokumentation der Begründung.
Entscheidungsdatensatz definieren — das Schema vor jedem Zeilen Logging-Code.
Azure-Diagnoseeinstellungen aktivieren und prüfen, dass Content-Filter-Annotationen fließen.
Orchestrierungsebene instrumentieren mit einer stabilen Korrelations-ID, die Modellaufruf, Geschäftstransaktion und menschliche Aufsicht verknüpft.
Kategoriespezifische Aufbewahrung und Unveränderbarkeit anwenden; Purview-Governance verdrahten.
Dashboards und einen dokumentierten Review-Prozess aufsetzen, damit Logs in die Beobachtung nach dem Inverkehrbringen einfließen.
Nachweise auf ISO/IEC-42001-Controls abbilden, sodass ein Datensatz Behörde und Zertifizierungsauditor bedient.

Das greift in den breiteren Zeitplan unserer Bereitschafts-Checkliste für August 2026 ein, und das Log selbst wird zu einer zentralen Eingabe Ihrer Konformitätsbewertung.

ISO/IEC 42001 als Bindegewebe

Der AI Act sagt Ihnen, was zu belegen ist; ISO/IEC 42001 hilft Ihnen, das Belegen zu betreiben. Als anerkannte Norm für KI-Managementsysteme liefert sie Rollen, Risikobehandlungsprozesse, Überwachungsanforderungen und Nachweisführung. Wenn wir Governance für Azure OpenAI bauen, bilden wir die AI-Act-Protokollierungspflichten direkt auf 42001-Controls ab, sodass dieselbe strukturierte Entscheidungsspur sowohl die Marktüberwachungsbehörde nach dem AI Act als auch einen Zertifizierungsauditor nach der Norm bedient. Der Nutzen ist real: Sie bauen die Protokollierung einmal und amortisieren sie über regulatorische, Zertifizierungs- und interne Prüfanforderungen hinweg, statt die Nachweise dreimal zu erstellen.

Fazit

Audit-Logging ist nicht der glamouröse Teil der EU-AI-Act-Bereitschaft, aber der Teil, der entscheidet, ob alles andere einer Prüfung standhält. Azure liefert ein starkes Fundament; die Entscheidungsspur, die ein Hochrisiko-System wirklich nachverfolgbar macht, ist Ingenieursarbeit in Ihrer Verantwortung. Da die Frist im August 2026 näher ist, als die meisten Programme annehmen, ist der Zeitpunkt, diese Protokollierungsebene zu entwerfen — und zu testen — jetzt.

Wenn Sie Azure OpenAI für einen Hochrisiko-Anwendungsfall aufbauen oder härten und eine Protokollierungs- und Governance-Architektur wollen, die ein Audit übersteht, hat unser Team für KI- und Datenplattform-Engineering genau das für europäische Unternehmen geliefert. Wir prüfen Ihr aktuelles Design gerne.

FAQ

Verlangt der EU AI Act tatsächlich eine Protokollierung für Azure-OpenAI-Systeme?

Der AI Act nennt Azure OpenAI nicht namentlich, verlangt aber nach Artikel 12 die automatische Aufzeichnung von Ereignissen (Logs) über die gesamte Lebensdauer von Hochrisiko-KI-Systemen, ergänzt um Nachverfolgbarkeit und Beobachtung nach dem Inverkehrbringen. Ist Ihre Anwendung als Hochrisiko nach Anhang III eingestuft, fallen die zugrunde liegenden Azure-OpenAI-Aufrufe unter diese Pflicht. Anbieter von GPAI-Modellen treffen ebenfalls Transparenz- und Dokumentationspflichten, doch die operative Protokollierungslast liegt primär bei Ihnen als Betreiber.

Was muss ein AI-Act-Audit-Log konkret enthalten?

Mindestens muss rekonstruierbar sein, was das System getan hat und warum: der Zeitraum jeder Nutzung, die Eingabereferenz oder der Prompt, das aufgerufene Modell samt Version, die zurückgegebene Ausgabe, die prüfende oder übersteuernde Person sowie alle Sicherheits- oder Content-Filter-Ereignisse. Maßstab ist, dass eine zuständige Behörde oder Ihre eigene Revision eine konkrete Entscheidung nachträglich nachvollziehen kann. Personenbezogene Daten in Prompts unterliegen der DSGVO, weshalb Logs Aufbewahrungsgrenzen und Zugriffskontrollen brauchen.

Ab wann gelten diese Protokollierungspflichten?

Die Hochrisiko-Pflichten nach Anhang III, einschließlich der Protokollierungs- und Aufzeichnungspflichten aus Artikel 12, gelten ab dem 2. August 2026. GPAI-Pflichten gelten bereits seit dem 2. August 2025, und GPAI-Modelle, die vor diesem Datum in Verkehr gebracht wurden, müssen bis zum 2. August 2027 konform sein. Betreiben Sie eine Hochrisiko-Azure-OpenAI-Anwendung, sollten Sie August 2026 als harte Frist für Ihre Protokollierungsarchitektur behandeln.

Decken Azure-native Dienste die Anforderung ab oder brauche ich Drittanbieter-Tooling?

Azure liefert den Großteil des Rohmaterials: Diagnoseeinstellungen, Azure Monitor, Log Analytics, Content-Filter-Annotationen und Microsoft Purview für Data Governance. Was Azure nicht out of the box liefert, ist das anwendungsbezogene semantische Log, das eine Geschäftsentscheidung mit einer konkreten Modellinteraktion und einer prüfenden Person verknüpft. Diese Ebene bauen Sie selbst, üblicherweise als strukturierte Protokollierung aus Ihrem Orchestrierungscode in Log Analytics oder einen unveränderbaren Speicher.

Wie lange müssen wir AI-Act-Logs aufbewahren?

Der AI Act verlangt eine Aufbewahrung für einen dem Verwendungszweck angemessenen Zeitraum, mindestens jedoch sechs Monate, sofern kein anderes Recht etwas anderes vorschreibt. In regulierten Sektoren wie dem Finanzwesen unter DORA oder dem Gesundheitswesen dominieren meist längere sektorale Aufbewahrungsfristen. Wir empfehlen, die Aufbewahrung je Log-Kategorie zu definieren und hochvolumige Telemetrie von der rechtlich erforderlichen Entscheidungsspur zu trennen.

Wie hängt ISO/IEC 42001 mit der AI-Act-Protokollierung zusammen?

ISO/IEC 42001 ist die Norm für KI-Managementsysteme. Sie ersetzt den AI Act nicht, liefert aber das Governance-Gerüst — Rollen, Risikomanagementmaßnahmen, Überwachung und Nachweise —, das die Protokollierung nach Artikel 12 belastbar macht. Wir bilden die AI-Act-Protokollierungsanforderungen in der Regel auf ISO/IEC-42001-Controls ab, sodass ein einziger Nachweissatz sowohl die Behörde als auch den Zertifizierungsauditor bedient.