Was protokolliert wird
Das Audit-Protokoll hält fest, wer wann was am System geändert hat. Es ist keine zweite Buchführung Ihrer Produktionsdaten, sondern die Spur der Eingriffe: Konfiguration, Rechtevergabe, Plugins, Korrekturen.
Die Grundregel
Abschnitt betitelt „Die Grundregel“Ein neuer Datensatz erzeugt keinen Eintrag. Er trägt Erfasser und Zeitpunkt bereits selbst; eine Spiegelung wäre dieselbe Information zweimal. Protokolliert wird stattdessen:
| Fall | Eintrag? | Warum |
|---|---|---|
| Datensatz erfassen | nein | die Zeile trägt Erfasser und Zeit selbst |
| Datensatz korrigieren oder löschen | ja | der Vorzustand verschwindet aus der Zeile |
| Verhalten des Systems ändern (Tag, Recht, Plugin) | ja | steht in keiner Fachtabelle |
| Handlung der KI | ja | Anforderung des EU AI Act |
Zyklische Maschinenwerte laufen nie ins Protokoll. Sie sind Messwerte, keine Eingriffe.
Woraus ein Eintrag besteht
Abschnitt betitelt „Woraus ein Eintrag besteht“| Feld | Inhalt |
|---|---|
| Time | Zeitpunkt |
| Actor | Art des Handelnden (user, ai, machine, operator) und dessen Kennung |
| Action | die Handlung, zum Beispiel tag.update |
| Target | woran sie geschah |
| Detail | die Umstände, je nach Handlung verschieden |
Ein machine-Eintrag ist normal, kein Sonderfall: ein Konnektor, der einen Wert schreibt,
weil ein Telegramm ankam, handelt ohne Mensch dahinter. Ein ai-Eintrag ebenso — dass die
KI baut und handelt, ist Teil des Produkts, und genau deshalb wird sie mitgeschrieben.
Was Einträge erzeugt
Abschnitt betitelt „Was Einträge erzeugt“| Bereich | Handlungen |
|---|---|
| Datenmodell | record_type.create, record_type.rename, record_type.delete, field.create, field.update, field.change-type, field.delete |
| Tags | tag.create, tag.update, tag.rename, tag.move, tag.copy, tag.delete, tag.deleteFolder |
| Verbindungen | connection.create, connection.update, connection.delete |
| Skripte | script.create, script.update, script.move, script.copy, script.delete |
| Navigation | navigation.node.create, navigation.node.update, navigation.node.move, navigation.node.delete, navigation.reorder, navigation.tree.save |
| Rollen | role.create, role.delete |
| Benutzer | tenant-user.create, tenant-user.deactivate, tenant-user.reactivate, tenant-user.assignRole, tenant-user.unassignRole, tenant-user.setSecurityRole, tenant-user.delete |
| Plugins | plugin.install, plugin.install.rejected, plugin.enable, plugin.disable, plugin.uninstall, plugin.net.request |
| Vertrauensanker | trust_anchor.create, trust_anchor.revoke |
| Vorlagen | configuration.load |
| Zugänge | display-token.issue, display-token.revoke, offline-token.issue, offline-token.revoke |
| Datensätze | record.update |
Auch das Abgelehnte steht drin. Ein verweigerter Plugin-Upload, eine abgewiesene Benutzeraktion, ein geblockter Netzzugriff eines Plugins — jeder dieser Versuche hinterlässt einen Eintrag mit dem Grund im Detail. Ein Protokoll, das nur die Erfolge kennt, verschweigt genau das, was man später sucht.
Bei record.update stehen im Detail die Namen der geänderten Felder, nicht deren
Werte. Das Protokoll ist die Spur der Änderung, keine zweite Kopie Ihrer Daten.
Unveränderlich, und wie lange
Abschnitt betitelt „Unveränderlich, und wie lange“Einträge lassen sich weder ändern noch löschen. Das erzwingt die Datenbank selbst: das Recht dazu ist keiner Rolle erteilt, und ein zusätzlicher Riegel weist jeden Versuch ab. Auch das Laden einer Vorlage, das den Mandanten sonst leerräumt, lässt das Protokoll unberührt.
Es gibt heute keine Verfallsfrist: nichts löscht alte Einträge. Wie lange ein Protokoll aufbewahrt werden muss, ist bewusst noch nicht festgelegt und wird am Maßstab des EU AI Act entschieden.
Protokoll ist nicht Logging
Abschnitt betitelt „Protokoll ist nicht Logging“Die Betriebsmeldungen der Anwendung sind eine andere Sache: sie helfen bei der Fehlersuche, sind kurzlebig und gehören nicht ins Audit. Beides wird nie vermischt.