Protokollierung
Was aufgezeichnet werden muss, was aufgezeichnet werden darf und wie ein Protokoll aussieht, das im Ernstfall trägt.
Was in ein Protokoll gehört
| Angabe | Warum |
|---|---|
| Zeitpunkt und Vorgangskennung | Zuordnung zum Geschäftsvorfall |
| System, Modell und Version mit Prüfsumme | Belegt, welcher Stand entschieden hat |
| Parameter | Temperatur, Kontextlänge, verwendete Vorlage mit Version |
| Ergebnis oder dessen Kennung | Was herauskam |
| Prüfende Person und Ergebnis der Prüfung | Belegt die menschliche Kontrolle |
Diese fünf sind ohne Klartext der Eingabe führbar und decken die meisten Nachweisbedarfe. Der Inhalt der Eingabe gehört nur hinein, wenn dafür ein eigener Zweck, eine Rechtsgrundlage und eine Löschfrist bestehen.
Was die Protokolle leisten müssen
- Unveränderlich oder mit nachvollziehbarer Änderungshistorie.
- Zugriffsbeschränkt, mit eigener Rechteverwaltung.
- Auswertbar, nicht nur speicherbar. Ein Protokoll, das man nicht durchsuchen kann, hilft im Ernstfall nicht.
- Mit definierter Löschfrist je Datenkategorie.
- Getrennt von den Fachdaten aufbewahrt, damit eine Löschung dort das Protokoll nicht entwertet.
Die drei Nachweisbedarfe
| Bedarf | Was belegt werden muss | Aufbewahrung |
|---|---|---|
| AI Act, Hochrisiko | Betrieb entsprechend der Gebrauchsanweisung, Aufsicht, Eingabedaten | mindestens sechs Monate |
| DSGVO | Rechtmäßigkeit, Betroffenenrechte, Löschung | nach Nachweisbedarf, oft drei Jahre |
| Fachrecht | Je nach Bereich: Buchhaltung, Berufsrecht, Produktsicherheit | nach Fachrecht |
Die drei Fristen sind unterschiedlich und kollidieren regelmäßig mit der Löschpflicht. Sie gehören je Datenkategorie getrennt festgelegt, nicht als eine Frist für alles.
Reproduzierbarkeit ist nicht das Ziel
Ein Modelllauf ist auf Grafikkarten nicht bitgleich wiederholbar. Wer versucht, das zu erzwingen, bezahlt mit Durchsatz und erreicht es trotzdem nicht zuverlässig. Belegt wird deshalb das Ergebnis, nicht die Wiederholbarkeit: Modellversion, Parameter, Eingabekennung, Ausgabe, Zeitpunkt.
Ein Protokolleintrag, konkret
{
"ts": "2026-08-25T09:14:22Z",
"vorgang": "AB-2026-04417",
"system": "angebotspruefung",
"modell": "modell-x-2026-06",
"modell_pruefsumme": "sha256:9f2c…",
"vorlage": "einkauf-angebot-extrakt v3",
"parameter": {"temperatur": 0, "kontext": 8000},
"ergebnis_id": "res-88f1c2",
"konfidenz": 0.91,
"geprueft_von": "m.huber",
"pruefergebnis": "uebernommen",
"aenderungen": 0
}Kein Klartext, kein Personenbezug im Protokoll selbst, und trotzdem vollständig auskunftsfähig. Das Ergebnis selbst liegt in der Fachanwendung mit deren Löschfristen.
Was bei einem Vorfall verlangt wird
- Zeitraum und Umfang der Betroffenheit, aus den Protokollen ableitbar.
- Welche Modellversion und welche Vorlage im Einsatz waren.
- Ob und wann eine Prüfung stattgefunden hat.
- Welche Entscheidungen darauf beruhten und wer sie verantwortet hat.
- Wann der Vorfall bemerkt, gemeldet und behoben wurde.
Wer diese fünf Punkte aus den Protokollen beantworten kann, ist auskunftsfähig. Wer sie rekonstruieren muss, ist es nicht. Siehe Audit vorbereiten.
Ein Log-Schema, das eine Prüfung übersteht
KOSTENLOSES KONTO
Log-Schema und Auswertungsabfragen
Ein vollständiges Schema für den Protokolleintrag je Anfrage, mit den Abfragen, die eine Prüfung tatsächlich stellt.
Zugangscode2 Elemente
Passende Kurse und Quellen
BSI zur Sicherheit von KI-Systemen
Technische Leitfäden zum sicheren Betrieb von KI-Systemen, kostenlos und ungewöhnlich konkret.
Für IT-Sicherheit und Betrieb im deutschsprachigen Raum; ungewöhnlich konkret für eine Behördenquelle.
ENISA-Veröffentlichungen
Berichte der EU-Agentur für Cybersicherheit, unter anderem zur Absicherung von KI-Systemen und zur Bedrohungslage. Kostenlos und in europäischem Bezug.
Für Sicherheitsverantwortliche, die einen europäischen Bezugsrahmen brauchen statt eines amerikanischen.