Artikel 12 des EU AI Act verlangt, dass Hochrisiko-KI-Systeme die automatische Aufzeichnung von Ereignissen während der gesamten Lebensdauer des Systems unterstützen. Die Protokolle müssen das System in einem dem bestimmungsgemäßen Zweck angemessenen Maß nachvollziehbar machen sowie Risikoerkennung, Überwachung nach dem Inverkehrbringen und Betreiberüberwachung unterstützen. Artikel 19 verpflichtet Anbieter anschließend, automatisch erzeugte Protokolle unter ihrer Kontrolle aufzubewahren. Bei einem KI-Agenten verbindet eine belastbare Umsetzung den Lauf, den Agenten und das Release, Policy-Entscheidungen, Werkzeugaufrufe, menschliche Entscheidungen, Ergebnisse und Integritätsnachweise. Dieser Leitfaden trennt den Gesetzestext von der technischen Spezifikation, mit der überprüfbare Aufzeichnungen erzeugt werden. Er dient der praktischen Orientierung und stellt keine Rechtsberatung dar.
Was Artikel 12 und Artikel 19 verlangen
Artikel 12 steht in Kapitel III Abschnitt 2 mit den Anforderungen an Hochrisiko-KI-Systeme. Sein Geltungsbereich hängt von der Klassifizierung und dem bestimmungsgemäßen Zweck des Systems ab. Ein Kundenservice-Agent oder interner Assistent fällt nicht allein deshalb unter Artikel 12, weil er ein KI-Modell verwendet oder Werkzeuge aufrufen kann. Beginnen Sie mit der Übersicht zu den Anforderungen des EU AI Act und dokumentieren Sie die Klassifizierungsentscheidung.
Die Verordnung (EU) 2026/1744 hat die Anwendungstermine dieser Hochrisiko-Bestimmungen geändert. Kapitel III Abschnitte 1 bis 3 gelten ab dem 2. Dezember 2027 für Systeme, die nach Artikel 6 Absatz 2 und Anhang III klassifiziert sind, und ab dem 2. August 2028 für Produktsysteme, die nach Artikel 6 Absatz 1 und Anhang I klassifiziert sind. Die späteren Termine schaffen Umsetzungszeit. Das Kontrolldesign aus Artikel 12 und Artikel 19 bleibt bestehen.
| Quelle | Anforderung der Verordnung | Operative Spezifikation | Nachweistest |
|---|---|---|---|
| Artikel 12 Absatz 1 | Das Hochrisiko-KI-System unterstützt technisch die automatische Aufzeichnung von Ereignissen während seiner gesamten Lebensdauer. | Erzeugen Sie auf dem Ausführungspfad für jeden gesteuerten Lauf und jede folgenrelevante Aktion einen Datensatz. Verlassen Sie sich nicht auf ein Design, bei dem eine Person den Datensatz erst nach einem Ereignis zusammenstellt. | Führen Sie einen repräsentativen Prozess aus und gleichen Sie die Ausführungsmenge mit den automatisch erzeugten Aufzeichnungen ab. |
| Artikel 12 Absatz 2 Buchstabe a | Protokolle erfassen Ereignisse, die für die Erkennung eines Risikos nach Artikel 79 Absatz 1 oder einer wesentlichen Änderung relevant sind. | Erfassen Sie Fehler, Policy-Sperren und Warnungen, anomalen Werkzeugzugriff, Überschreibungen, Release-Änderungen, unerwartete Ausgaben und daraus resultierende Wirkungen mit stabilen Kennungen. | Lösen Sie jedes definierte Risikosignal aus und bestätigen Sie, dass der Datensatz den betroffenen Lauf, die Version, das Ereignis, den Zeitpunkt und das Ergebnis identifiziert. |
| Artikel 12 Absatz 2 Buchstabe b | Protokolle erleichtern die Überwachung nach dem Inverkehrbringen gemäß Artikel 72. | Verwenden Sie Ereignisfelder, die Abfragen über Populationen, Trendanalysen, Vorfallkorrelation und Verknüpfungen mit dem Überwachungsplan des Anbieters unterstützen. | Reproduzieren Sie eine Überwachungskennzahl aus den Quelldatensätzen und verfolgen Sie eine Ausnahme bis in den Plan zur Überwachung nach dem Inverkehrbringen. |
| Artikel 12 Absatz 2 Buchstabe c | Protokolle unterstützen die Überwachung durch den Betreiber nach Artikel 26 Absatz 5. | Machen Sie Betriebszustand, Kontext der Gebrauchsanweisung, Risikosignal, Referenz der Benachrichtigung des Anbieters, Sperrereignis und gegebenenfalls Referenz der Meldung eines schwerwiegenden Vorfalls zugänglich. | Verfolgen Sie ein simuliertes Risiko von der Erkennung bis zur Sperrung oder Disposition und prüfen Sie die Referenzen für Benachrichtigungen an Anbieter und Behörden. |
| Artikel 12 Absatz 3 | Bei von Anhang III Nummer 1 Buchstabe a erfassten biometrischen Fernidentifizierungssystemen enthalten Protokolle jede Nutzungsperiode, die Referenzdatenbank, die abgeglichenen Eingabedaten und die Personen, die Ergebnisse nach Artikel 14 Absatz 5 überprüft haben. | Legen Sie eigene Felder für den Mindestumfang des biometrischen Datensatzes an. Wenden Sie auf die sensiblen Daten Zugriffskontrollen und Datenschutzregeln an. | Wählen Sie eine Nutzung aus und prüfen Sie, ob Anfangs- und Endzeit, Datenbankreferenz, abgeglichene Eingabe und Identitäten der Prüfer vorhanden und autorisiert sind. |
| Artikel 19 Absatz 1 | Ein Anbieter bewahrt Protokolle nach Artikel 12 unter seiner Kontrolle für einen dem bestimmungsgemäßen Zweck angemessenen Zeitraum und mindestens sechs Monate auf, sofern andere anwendbare Rechtsvorschriften nichts anderes vorsehen. | Ordnen Sie jedem vom Anbieter kontrollierten Datensatz eine Aufbewahrungsklasse, Quelle, Zweck, Mindestdauer, Verhalten bei rechtlicher Aufbewahrungssperre, Zugriffsregel und einen verifizierten Löschpfad zu. | Prüfen Sie die Speicherregelung, weisen Sie nach, dass betroffene Datensätze während der erforderlichen sechs Monate verfügbar bleiben, und testen Sie anschließend Sperre und autorisierte Löschung nach Ablauf der konfigurierten Frist. |
| Artikel 26 Absatz 6 | Ein Betreiber wendet dieselbe Mindestdauer von sechs Monaten auf automatisch erzeugte Protokolle unter seiner Kontrolle an, vorbehaltlich anderer anwendbarer Rechtsvorschriften. | Definieren Sie die Übergabe zwischen Anbieter und Betreiber: welche Partei jeden Datensatz kontrolliert, wie der Betreiber ihn sammelt und interpretiert und wie Verträge den Zugriff sichern. | Verfolgen Sie einen Produktionsdatensatz von seiner Erzeugung bis zum vom Betreiber kontrollierten Speicher und bestätigen Sie Abruf, Aufbewahrung und Eigentümerschaft. |
Eine konkrete Audit-Trail-Spezifikation für KI-Agenten
Artikel 12 nennt die Zwecke der Protokollierung und führt für die Systeme zur biometrischen Fernidentifizierung in Artikel 12 Absatz 3 eine konkrete Mindestliste von Feldern auf. Für andere Hochrisiko-Systeme definiert der Anbieter einen Feldumfang, der das System für seinen bestimmungsgemäßen Zweck nachvollziehbar macht. Die folgende Spezifikation ist ein belastbarer Ausgangspunkt für einen Agenten, der Daten abrufen, policy-gesteuerte Entscheidungen treffen, menschliche Prüfung anfordern und Werkzeuge aufrufen kann. Das herunterladbare Schema für Audit-Logs von KI-Agenten überführt diese Ereignisfamilien in einen versionierten, herstellerneutralen Vertrag mit vollständigen, abgelehnten und Datensätzen über fehlgeschlagene Manipulationsversuche.
Erfassen Sie Referenzen oder Hashes, wenn ein vollständiger Payload mit Datenminimierung, Vertraulichkeit oder Sicherheitsanforderungen kollidieren würde. Ein nützlicher Datensatz bewahrt die Bedeutung des Ereignisses und einen kontrollierten Weg zu den zugrunde liegenden Nachweisen.
| Ereignisfamilie | Zu erfassende Felder | Kontrollzweck | Abnahmetest |
|---|---|---|---|
| Ausführungsidentität | Mandant sowie Ausführungs- und Korrelations-IDs; Agent-ID; Release-ID, Version und Hash; Prozess-ID und Version; Umgebung; initiierender Principal; Subjekt, in dessen Namen gehandelt wird; Start- und Endzeitstempel | Definieren Sie System, Version, Befugnis und Zeitraum eines Laufs. | Verknüpfen Sie jedes Ereignis eines Stichprobenlaufs mit genau einem Identitätsdatensatz, ohne sich allein auf Zeitstempel zu verlassen. |
| Eingabe und Abruf | Eingabereferenz oder geschützter Payload; Quellen- und Datensatzreferenzen; Abrufabfrage oder Hash; Modell- und Prompt-Template-Version; Redaktionsstatus; Ereigniszeit | Zeigen Sie, welche Informationen in den Lauf eingingen und welche Version sie interpretiert hat. | Rekonstruieren Sie den genehmigten Eingabesatz und weisen Sie nach, dass geschützte Felder zugriffsbeschränkt bleiben. |
| Werkzeuganfrage | Werkzeugname; Aufruf- und Gate-IDs; Ziel; Argumente oder Argument-Hash; angeforderte Befugnis; Idempotenzschlüssel; Anfragezeit | Identifizieren Sie die vom Agenten vorgeschlagene folgenrelevante Aktion, bevor eine externe Wirkung eintritt. | Ordnen Sie die Anfrage ihrem Policy-Ergebnis zu und weisen Sie nach, dass eine doppelte Zustellung keine unerklärte zweite Wirkung erzeugen kann. |
| Policy-Entscheidung | Entscheidungs-ID; Gate-Typ; Ergebnis allow, warn, require_approval oder block; Policy-ID, Version und Pack-Hash; IDs der getroffenen Regeln; Begründungscodes; Entscheidungszeit | Zeigen Sie, welche Kontrolle die Aktion gesteuert hat und welche genaue Version ausgewertet wurde. | Bewerten Sie eine festgelegte Stichprobe mit den aufgezeichneten Fakten erneut und erklären Sie jede Abweichung als Versionsänderung. |
| Menschliche Entscheidung | Decision-Request-ID; erforderliche Rolle; Identität und Befugnis des Prüfers; Ergebnis approve, reject oder escalate; Begründung; Bestätigung; Anfrage- und Entscheidungszeit | Verbinden Sie eine wesentliche Beurteilung mit einer verantwortlichen Person und der zur Prüfung angehaltenen Aktion. | Weisen Sie nach, dass der Prüfer zum Entscheidungszeitpunkt befugt war und die Werkzeuganfrage bis zur Entscheidung pausiert blieb. |
| Werkzeugergebnis und Geschäftswirkung | Status; Ergebnisreferenz oder Hash; Fehler; Output-Policy-Entscheidung; Referenzen des Zustands vorher und nachher; nachgelagerte Transaktions-ID; Abschlusszeit | Unterscheiden Sie zwischen einem Vorschlag und einer Aktion, die das Zielsystem erreicht hat. | Gleichen Sie den Datensatz mit dem nachgelagerten System ab und erfassen Sie Erfolg, Fehler, Sperre, Abbruch und Wiederholung. |
| Überwachungs- und Vorfallsignal | Signaltyp; Schweregrad; betroffene Ausführung und Release; Schwellenwert- oder Detektorversion; Disposition; Verantwortlicher; Benachrichtigungs- und Vorfallsreferenzen | Unterstützen Sie die Überwachung nach Artikel 72 und die operative Reaktion nach Artikel 26 Absatz 5. | Reproduzieren Sie das Signal aus den Quelldatensätzen und verfolgen Sie es bis zu einer dokumentierten Disposition. |
| Integrität und Aufbewahrung | Datensatz-Hash; gegebenenfalls Hash des vorherigen Datensatzes; gegebenenfalls Signatur und Schlüssel-ID; Ledger- oder Manifestreferenz; Aufbewahrungsklasse; Ablauf; Sperrstatus; Löschereignis | Erkennen Sie spätere Änderungen und weisen Sie nach, dass der Datensatz während der genehmigten Frist verfügbar blieb. | Ändern Sie ein exportiertes Byte und verlangen Sie, dass die Verifizierung fehlschlägt; testen Sie Aufbewahrung, Sperre und Löschung getrennt. |
Aufbewahrung ist eine Kontrolle von Anbieter und Betreiber
Artikel 19 Absatz 1 weist Anbietern die Pflicht zu, automatisch erzeugte Protokolle nach Artikel 12 unter ihrer Kontrolle aufzubewahren. Artikel 26 Absatz 6 gibt Betreibern dieselbe Pflicht für Protokolle unter ihrer Kontrolle. Beide Regelungen verwenden dieselbe Struktur: einen dem bestimmungsgemäßen Zweck angemessenen Zeitraum, mindestens sechs Monate und eine Ausnahme, wenn anwendbares Unions- oder nationales Recht eine andere Regel vorsieht. Finanzinstitute bewahren diese Protokolle innerhalb der Dokumentation auf, die nach dem einschlägigen Unionsrecht für Finanzdienstleistungen geführt wird.
Die Frist von sechs Monaten ist für die von diesen Bestimmungen erfassten Protokolle eine Untergrenze. Artikel 18 verlangt gesondert, dass Anbieter bestimmte technische Unterlagen und Konformitätsdokumente zehn Jahre aufbewahren. Diese Fristen gelten für unterschiedliche Datensätze. Datenschutz-, Arbeits-, Branchen-, Litigation-Hold- und nationale Regeln können die zulässige Frist oder die speicherbaren Daten verändern.
Erstellen Sie ein Aufbewahrungsregister, bevor Sie eine Speicher-TTL festlegen. Halten Sie für jede Nachweisklasse ihre rechtliche oder genehmigte geschäftliche Quelle, den Zweck, die verantwortliche Partei, das führende System, Mindest- und Höchstdauer, Startauslöser, Zugriffsrollen, Regel für rechtliche Aufbewahrungssperren, Löschmethode und Testnachweis fest. Die Vorlage für eine Aufbewahrungsrichtlinie für Audit-Logs bietet eine Arbeitsstruktur.
- Kontrolle zuweisen: Benennen Sie die vom Anbieter und vom Betreiber kontrollierten Datensätze einschließlich Kopien, die ein Observability-Anbieter oder Laufzeitbetreiber erstellt.
- Ebenen abstimmen: Trace-Speicher, Nachweis-Ledger, exportiertes Bundle, Index, Backup und Lebenszyklus des Verschlüsselungsschlüssels benötigen kompatible Fristen.
- Inhalte schützen: Minimieren Sie personenbezogene Daten, trennen Sie sensible Payloads von breit abfragbaren Metadaten und erzwingen Sie zweckgebundenen Zugriff.
- Abruf testen: Ein aufbewahrter Datensatz ist wertvoll, wenn ein autorisierter Prüfer ihn innerhalb des erforderlichen Servicelevels finden, interpretieren und exportieren kann.
- Ablauf testen: Weisen Sie nach, dass das System eine rechtliche Aufbewahrungssperre einhält, autorisierte Löschung protokolliert und jede kontrollierte Kopie nach Ende der genehmigten Frist entfernt.
Manipulationsnachweis und Replay sind Assurance-Kontrollen
Artikel 12 nennt automatische Aufzeichnung und Nachvollziehbarkeit. Er schreibt keinen kryptografischen Mechanismus und keinen Replay-Endpunkt vor. Manipulationsnachweis und Replay sind Implementierungskontrollen, mit denen ein Anbieter zeigen kann, dass der Datensatz ausreichend vollständig und unverändert geblieben ist.
Verstehen Sie Replay als Rekonstruktion des aufgezeichneten Kontrollpfads. Eine erneute Ausführung eines Modells oder externen Werkzeugs kann ein anderes Ergebnis erzeugen oder eine Nebenwirkung wiederholen. Ein sicheres Replay liest die gespeicherte Sequenz, Versionen, Policy-Fakten, menschliche Entscheidungen und Ergebnisreferenzen. Eine separate Policy-Simulation kann aufgezeichnete Fakten anhand einer festgelegten Policy-Version erneut bewerten, ohne die Aktion zu versenden.
| Testen | Erwartetes Ergebnis | Fehlersignal |
|---|---|---|
| Abgleich der Population | Jeder in den Geltungsbereich fallende Lauf und jede folgenrelevante Aktion besitzt einen Datensatz, einschließlich regulärer Freigaben, Sperren, Fehler und Abbrüche. | Ausführungszahlen übersteigen Datensatz-Zahlen oder nicht zugeordnete Datensätze haben keine Quellausführung. |
| Kausale Reihenfolge | Die Policy-Entscheidung geht der gesteuerten Aktion voraus; eine erforderliche menschliche Entscheidung geht der Freigabe voraus; das Ergebnis folgt auf die Ausführung. | Eine Nebenwirkung besitzt keinen vorherigen Kontrolldatensatz oder Zeitstempel können die Reihenfolge nicht feststellen. |
| Fixierter Kontext | Der Datensatz löst Agent- und Modell-Release, Prozessversion, Policy-Version, Identitäten und zum Ereigniszeitpunkt aktive Befugnis auf. | Ein Prüfer sieht nur die aktuelle Konfiguration oder muss ableiten, welche Version ausgeführt wurde. |
| Abgleich des Ergebnisses | Werkzeugergebnis und Geschäftswirkung stimmen mit der nachgelagerten Quelle überein, einschließlich Wiederholungs- und Idempotenzverhalten. | Der Audit-Trail meldet Abschluss, während das Ziel keine passende Transaktion besitzt, oder doppelte Wirkungen haben keine getrennten Ursachen. |
| Integritätsverifizierung | Hashes, Signaturen, Kettenverknüpfungen, Ledger-Nachweise und Manifestprüfungen werden, sofern konfiguriert, verifiziert; eine kontrollierte Änderung macht die Verifizierung rot. | Ein bearbeitetes Artefakt bleibt gültig oder der Verifizierer kann die betroffene Datei oder den betroffenen Datensatz nicht identifizieren. |
| Sichere Rekonstruktion | Ein Prüfer kann die vollständige Sequenz lesen, ohne eine folgenrelevante Nebenwirkung erneut auszuführen. | Der einzige Rekonstruktionspfad versendet den ursprünglichen Werkzeugaufruf erneut oder hängt von einer nicht verfügbaren Modellantwort ab. |
Wie sich KLA-Laufzeitnachweise auf die Spezifikation abbilden
KLA erstellt einen Lineage Record für einen gesteuerten Lauf und verbindet Laufzeitereignisse über stabile Ausführungs- und Mandantenkennungen. Ausführungsspans können die Prozessversion und den Hash, Kennungen des Agent-Release, Umgebung, initiierenden Principal, On-behalf-of-Subjekt und die beim Lauf erfasste Client-Identität tragen. Workflow-Spans erfassen Knoten- und Policy-Ergebnisse, Policy-IDs und Regeln, Decision Requests, Prüferidentitäten, Zeitstempel und Fehler.
Das KLA-Governance-Gateway bewertet Werkzeug-Input- und Werkzeug-Output-Gates über die KLA Policy Engine, wenn Betreiber KLA_GOVERNANCE_GATEWAY für eine Umgebung aktivieren. Die eingecheckte Produktionskonfiguration des execution-worker aktiviert diesen Pfad derzeit nicht. Wenn er aktiviert ist, verwendet ein Gate die vier Ergebnisse allow, warn, require_approval und block. Entscheidungsbelege enthalten Ausführung, Gate, Werkzeug, Policy-Version, Policy-Pack-Hash, Begründungscodes, Decision Request, Trace und gegebenenfalls Output-Hash. Das Gateway versiegelt den Input-Gate-Beleg, bevor es das gesteuerte Werkzeug ausführt, und den Output-Gate-Beleg, bevor es das Ergebnis zurückgibt oder anhält. Ein Fehler beim Schreiben des Nachweises verhindert, dass das Gate fortschreitet.
| Kontrollbedarf | KLA-Baustein | Erzeugter Nachweis | Zu prüfende Grenze |
|---|---|---|---|
| Stabile Laufidentität | Agents, Releases, Processes und Lineage Records | Ausführung, Mandant, Prozessversion und Hash, Agent-Release, Umgebung, Principal und Korrelationskennungen | Bestätigen Sie, dass jede Integration die Kennungen weitergibt und optionale Identitätsfelder für den geprüften Prozess vorhanden sind. |
| Automatische Ereignissequenz | KLA Runtime und OpenTelemetry-Ausführungsspans | Lauf-, Knoten-, Policy-, Freigabe-, Fehler-, Zeit- und Ergebnisereignisse, geordnet in einem Lineage Record | Gleichen Sie die Ausführungspopulation ab und bestätigen Sie, dass die ausgewählten Werkzeuge die für den Zweck erforderlichen Referenzen auf Eingabe, Ergebnis und nachgelagerte Wirkung erzeugen. |
| Policy- und Werkzeugkontrolle | Umgebungsaktiviertes KLA-Governance-Gateway | Gate-Typ, Policy-Version, Entscheidung, Begründungen, Decision Request, Argument-Hash, Output-Hash und Idempotenzstatus; getroffene Regel-IDs, wenn die ausgewertete require_approval-Entscheidung sie liefert | Bestätigen Sie, dass das Gateway in der geprüften Umgebung aktiviert ist. Testen Sie alle vier Ergebnisse, optionale Nachweise getroffener Regeln, Ausfall des Policy-Dienstes, nach der Freigabe geänderte Argumente, Wiederholungen und Abbruch. |
| Menschliche Entscheidung | Decision Desk und dauerhafte Freigabedatensätze | Erforderliche Rolle, Prüferidentität, Entscheidung, Begründung, Zeitstempel, Policy-Kontext und korrelierte Ausführung | Testen Sie Prüferbefugnis, Maker-Checker-Regeln, sofern konfiguriert, und die vollständige Sequenz vom Anhalten bis zur Freigabe. |
| Manipulationssicherer Datensatz | Append-only-Nachweis-Ledger und Governance-Belege | Verifizierte Ledger-Schreibvorgänge; Ed25519-Signaturen und Hash-Kettenverknüpfungen, wenn die Belegsignierung aktiviert ist | Behandeln Sie den Signierungsstatus als beobachtete Deployment-Tatsache. Alarmieren Sie bei herabgesetzter Signierung und führen Sie einen kontrollierten Manipulationstest aus. |
| Übertragbares Prüfpaket | Evidence Room und versiegelte Evidence Bundles | Ausgewählte Lineage-, Policy-, Freigabe- und Ledger-Datensätze mit Manifest, Hashes, Merkle-Inklusionsdaten und Signaturen für die Offline-Verifizierung | Bestätigen Sie Exportpopulation, Redaktionsprofil, Verifizierergebnis, Schlüsselverfügbarkeit und Chain-of-Custody-Datensatz. |
| Aufbewahrung | Aufbewahrung der Evidence-Factory-Jobs und Konfiguration des Bundle-Speichers | Metadaten zur Aufbewahrung von Exportjobs, Ablauf und konfigurierte Aufbewahrung des Bundle-Speichers | Gleichen Sie diese Exportkontrollen mit der Aufbewahrung der Quell-Lineage- und Ledger-Datensätze ab. Legen und testen Sie die für das klassifizierte System und die Branche erforderliche Frist fest. Die Produktfähigkeit allein begründet keine genehmigte gesetzliche Frist. |
Implementierungscheckliste
Machen Sie die Spezifikation für jedes Hochrisiko-KI-System zu einem Release-Gate. Bewahren Sie Klassifizierungsdatensatz, bestimmungsgemäßen Zweck, Ereignisschema, Aufbewahrungsregister, Datenschutzprüfung, Tests und Überwachungsplan gemeinsam im Dokumentationssatz nach Anhang IV auf.
- Benennen Sie Anbieter, Betreiber, bestimmungsgemäßen Zweck, Grundlage des Hochrisikos, Systemgrenze, Agent- und Modell-Releases sowie jede Partei, die eine Kopie der Protokolle kontrolliert.
- Definieren Sie die Ausführungspopulation im Geltungsbereich und die folgenrelevanten Aktionen, die vollständige Werkzeug-, Policy-, menschliche Entscheidungs- und Ergebnisdatensätze benötigen.
- Veröffentlichen Sie ein versioniertes Ereignisschema mit Pflichtfeldern, Datenklassifizierungen, Redaktionsregeln, Kennungen, zulässiger Ereignisreihenfolge und Fehlerverhalten.
- Machen Sie die Datensatzerzeugung im Ausführungspfad automatisch und schließen Sie den Pfad, wenn ein fehlender Kontrolldatensatz eine folgenrelevante Aktion ungesteuert lassen würde.
- Gleichen Sie Ausführungen mit Datensätzen ab und testen Sie reguläre Freigaben, Warnungen, erforderliche Freigaben, Sperren, Fehler, Wiederholungen, Abbrüche und Ausfälle des Policy-Dienstes.
- Legen Sie die Aufbewahrung von Anbieter und Betreiber aus dem genehmigten Register fest, einschließlich eines Tests auf die Mindestfrist von sechs Monaten, wenn Artikel 19 oder Artikel 26 Absatz 6 gilt.
- Führen Sie sichere Rekonstruktion, Ergebnisabgleich, Zugriffskontrolle, rechtliche Aufbewahrungssperre, Löschung, Export und einen Manipulationstest mit einem Byte aus.
- Speisen Sie definierte Ereignisse in den Überwachungsplan nach Artikel 72 ein und verbinden Sie Signale mit Verantwortlichen, Dispositionen, Vorfällen und Korrekturmaßnahmen.
Häufig gestellte Fragen
Gilt Artikel 12 des EU AI Act für jeden KI-Agenten?
Artikel 12 gilt für Hochrisiko-KI-Systeme. Für einen Agenten müssen zunächst Klassifizierung und bestimmungsgemäßer Zweck dokumentiert werden. Organisationen können dieselben Protokollierungskontrollen für Agenten mit geringerem Risiko als Governance-Entscheidung einsetzen.
Welche Ereignisse muss ein KI-Agent nach Artikel 12 protokollieren?
Artikel 12 verlangt Ereignisse, die für Risikoerkennung, wesentliche Änderungen, Überwachung nach dem Inverkehrbringen und Betreiberüberwachung relevant sind. Für die Systeme zur biometrischen Fernidentifizierung in Artikel 12 Absatz 3 nennt er eine ausdrückliche Mindestliste von Feldern. Andere Systeme benötigen ein zweckangemessenes Schema. Für einen Agenten mit Werkzeugnutzung bilden Ausführungsidentität, Versionen, Eingaben oder Referenzen, Werkzeuganfragen, Policy-Ergebnisse, menschliche Entscheidungen, Ergebnisse, Fehler und Zeitstempel eine belastbare Grundlage.
Wie lange müssen Protokolle nach Artikel 12 aufbewahrt werden?
Artikel 19 Absatz 1 verlangt von Anbietern, automatisch erzeugte Protokolle unter ihrer Kontrolle für einen dem bestimmungsgemäßen Zweck angemessenen Zeitraum und mindestens sechs Monate aufzubewahren, sofern anwendbares Unions- oder nationales Recht nichts anderes vorsieht. Artikel 26 Absatz 6 gibt Betreibern dieselbe Regel für Protokolle unter ihrer Kontrolle. Für andere Datensätze und Branchen können andere Fristen gelten.
Verlangt Artikel 12 manipulationssichere Protokolle?
Der Artikel verlangt automatische Protokollierung und Nachvollziehbarkeit und nennt keinen kryptografischen Mechanismus. Append-only-Speicher, Hashes, Signaturen und unabhängige Verifizierung sind Assurance-Kontrollen, die Änderungen erkennen und einen belastbaren Nachweisprozess unterstützen.
Verlangt Artikel 12 Replay?
Der Artikel enthält keine ausdrückliche Replay-Anforderung. Eine sichere Rekonstruktion ist ein nützlicher Abnahmetest: Ein Prüfer sollte die aufgezeichnete Sequenz, Versionen, Entscheidungen und Ergebnisse lesen können, ohne ein Modell erneut auszuführen oder eine Nebenwirkung zu wiederholen.
Können gewöhnliche Anwendungslogs die Anforderung erfüllen?
Sie können beitragen, wenn sie automatisch und für den bestimmungsgemäßen Zweck vollständig, systemübergreifend korreliert, interpretierbar, zugriffsgesteuert, für den genehmigten Zeitraum aufbewahrt und für die Überwachung verfügbar sind. Servicespezifische Debug-Nachrichten enthalten häufig keine Policy-Versionen, menschlichen Befugnisse, Geschäftsergebnisse oder Populationsabgleiche.
Wie unterstützt KLA ein Protokollierungsdesign nach Artikel 12?
KLA verbindet Laufzeitspans, Policy-Ergebnisse, Werkzeug-Gates, Decision Requests und Ausführungsergebnisse in Lineage Records. Evidence-Room-Exporte enthalten ausgewählte Datensätze mit Integritätsmetadaten für die Offline-Verifizierung. Anbieter und Betreiber bleiben für Klassifizierung, ausreichenden Feldumfang, Aufbewahrung, Datenschutz, Überwachung und die abschließende Konformitätsbewertung verantwortlich.
Die wichtigsten Erkenntnisse
Eine hilfreiche Umsetzung von Artikel 12 beginnt mit Klassifizierung und bestimmungsgemäßem Zweck und zeichnet anschließend jeden in den Geltungsbereich fallenden Lauf sowie jede folgenrelevante Aktion automatisch auf. Artikel 19 und Artikel 26 Absatz 6 machen Aufbewahrung zu einer zugewiesenen Kontrolle. Ein versioniertes Ereignisschema, stabile Identitäten, Kontext von Policy und menschlichen Entscheidungen, Referenzen auf nachgelagerte Ergebnisse, Populationsabgleich, Manipulationstests und sichere Rekonstruktion machen diese Protokolle für Überwachung und Prüfung nutzbar. Verwenden Sie den Leitfaden zu Audit-Trails für KI-Agenten für die umfassendere Nachweisarchitektur, den Leitfaden zur Dokumentation nach Anhang IV für die technische Dokumentation und den Plan zur Überwachung nach dem Inverkehrbringen für den Betriebsprozess.