Template: Logging-Konzept nach Art. 12 EU AI Act

Wofür

Das Logging-Konzept dokumentiert, welche Ereignisse ein Hochrisiko-KI-System automatisch aufzeichnet, wie lange die Logs aufbewahrt werden und wer darauf zugreifen kann. Es beantwortet die Frage, die im Ernstfall — bei einem Vorfall, einer Beschwerde oder einer Aufsichts-Anfrage — zuerst gestellt wird: Lässt sich rekonstruieren, was das System wann getan hat? Ohne belastbares Logging ist jede nachträgliche Aufklärung Spekulation. Das Konzept wird pro KI-System geführt und bei Architektur-Änderungen, neuen Einsatzkontexten oder geänderten Aufbewahrungspflichten fortgeschrieben.

Wann es Pflicht ist

Art. 12 der KI-Verordnung (VO 2024/1689) verpflichtet Provider, Hochrisiko-KI-Systeme technisch so zu gestalten, dass Ereignisse über die Lebensdauer des Systems automatisch aufgezeichnet werden. Die Protokollierung muss eine dem Intended Purpose angemessene Rückverfolgbarkeit sicherstellen — insbesondere um Situationen zu erkennen, die zu einem Risiko im Sinne von Art. 79 Abs. 1 führen können oder eine wesentliche Änderung darstellen, sowie um das Post-Market Monitoring nach Art. 72 und die Überwachung des Betriebs durch den Deployer nach Art. 26 Abs. 5 zu ermöglichen. Flankierend gilt: Provider bewahren die ihrer Kontrolle unterliegenden Logs auf (Art. 19), Deployer die ihren (Art. 26 Abs. 6) — jeweils für einen dem Zweck angemessenen Zeitraum von mindestens sechs Monaten, soweit anwendbares Recht nichts anderes bestimmt. Das Logging-Konzept ist der strukturierte Nachweis, dass diese Anforderungen im System-Design verankert sind, und fließt in die technische Dokumentation nach Anhang IV ein.

Das Artefakt selbst

# Logging-Konzept — [KI-System-Name], Version [X.Y]

## 1. Geltungsbereich
- KI-System / Modell-Version:
- Einsatzkontext(e) und Intended Purpose:
- Verantwortlich (Rolle, nicht Person):
- Datum / Review-Zyklus:

## 2. Protokollierte Ereignisse (Art. 12 Abs. 1, 2)
| Ereignis-Typ | Ausgelöst durch | Erfasste Felder | Zweck-Bezug |
|---|---|---|---|
| Nutzungszeitraum (Start/Ende) | | | Rückverfolgbarkeit |
| Eingabedaten-Referenz | | | Vorfall-Rekonstruktion |
| System-Output / Empfehlung | | | Betriebsüberwachung Art. 26 Abs. 5 |
| Human-Override / Eingriff | | | Human Oversight |
| Modell-/Konfigurations-Änderung | | | Wesentliche Änderung |
| Fehler, Ausfälle, Anomalien | | | Risiko-Erkennung Art. 79 Abs. 1 |

## 3. Nicht protokollierte Ereignisse
- Bewusst ausgeschlossen + Begründung (z. B. Datenminimierung):

## 4. Aufbewahrung (Art. 19, Art. 26 Abs. 6)
- Aufbewahrungsdauer + Begründung der Angemessenheit:
- Abweichende Fristen aus Fachrecht (z. B. sektorale Vorgaben):
- Löschkonzept und Löschnachweis:

## 5. Zugriff und Rollen
- Zugriffsberechtigte Rollen (Provider-seitig / Deployer-seitig):
- Bereitstellungsweg für Deployer (Export, API, Dashboard):
- Zugriffs-Protokollierung (wer hat wann Logs eingesehen):

## 6. Integrität und Schutz
- Schutz vor nachträglicher Veränderung (Append-only, Hashing, WORM):
- Speicherort und Verschlüsselung:
- Personenbezug in Logs + DSGVO-Abgleich (Verweis auf Datenschutz-Doku):

## 7. Auswertung
- Anbindung an Post-Market Monitoring (Art. 72):
- Alarm-Schwellen für risikorelevante Muster:
- Zuständigkeit für regelmäßige Log-Reviews:

## 8. Freigabe
- Geprüft durch / am:
- Nächstes Review:

Ausfüll-Anleitung

1. Abschnitt 2 aus dem Intended Purpose ableiten — nicht aus dem, was die Infrastruktur ohnehin loggt. Maßstab ist: Welche Ereignisse braucht man, um eine Fehlentscheidung des Systems nachträglich zu rekonstruieren?
2. Jedes Ereignis mit Zweck-Bezug versehen. Ein Log-Eintrag ohne benannten Zweck ist entweder überflüssig (Datenminimierung) oder sein Zweck wurde nicht durchdacht — beides fällt im Audit auf.
3. Abschnitt 3 nicht leer lassen. Bewusste Ausschlüsse (etwa Klartext-Eingaben mit sensiblen Daten) dokumentieren und begründen — das zeigt, dass die Abwägung zwischen Rückverfolgbarkeit und Datenschutz stattgefunden hat.
4. Abschnitt 4: die Mindestdauer von sechs Monaten ist ein Boden, kein Zielwert. Die Angemessenheit richtet sich nach Zweckbestimmung und Fachrecht — Begründung ausformulieren, nicht nur die Frist nennen.
5. Abschnitt 5: klären, wie der Deployer an die Logs kommt, die er für seine Pflichten nach Art. 26 braucht. "Auf Anfrage beim Support" ist keine belastbare Antwort.
6. Abschnitt 6: Manipulationsschutz konkret benennen. Logs, die jeder Admin editieren kann, taugen nicht als Evidenz.
7. Abschnitt 7: Logging ohne Auswertung ist Speicherplatz, keine Governance. Mindestens einen definierten Review-Rhythmus und eine zuständige Rolle eintragen.
8. Verantwortlichkeit als Rolle führen (z. B. "Platform Operations Lead"), damit das Konzept Personalwechsel übersteht.

Audit-Erwartung

Auditoren prüfen das Logging-Konzept gegen die gelebte Realität: Sie lassen sich Beispiel-Logs zeigen und vergleichen sie mit der Ereignis-Tabelle in Abschnitt 2 — jede dort versprochene Aufzeichnung muss sich in echten Logs wiederfinden. Quergelesen wird mit dem Risk Assessment nach Art. 9 (risikorelevante Ereignisse aus der Risikoanalyse müssen protokolliert werden) und der technischen Dokumentation nach Anhang IV. Rote Flaggen sind Konzepte, die nur Infrastruktur-Logs beschreiben (CPU, Uptime) statt entscheidungsrelevanter Ereignisse, fehlender Manipulationsschutz und ungeklärter Deployer-Zugriff. Stark wirkt ein Konzept, das den Weg vom Log-Eintrag zur Vorfall-Rekonstruktion an einem durchgespielten Beispiel zeigt.

Verwandte Artefakte

• Template: AI Risk Assessment nach Art. 9 — risikorelevante Ereignisse müssen sich im Logging wiederfinden
• Template: Technische Dokumentation nach Anhang IV — dort wird das Logging-Konzept referenziert
• Template: Datenqualitäts-Statement nach Art. 10 — Datenherkunft und Log-Datenschutz hängen zusammen
• Welche Use-Cases überhaupt hochrisiko sind: Use-Case-Bibliothek auf hochrisiko-ki.com

Mehr Kontext zu den Provider-Pflichten im EU AI Act gesamt: Leitfaden auf eu-ai-verordnung.de.

AEGIRA AI Guardian operationalisiert diese Artefakte als laufende Trust-Infrastructure — aegira.ai.