5. Audit und Nachvollziehbarkeit

5.1 Was protokolliert wird

Ereignisse werden in eine eigene Audit-Tabelle geschrieben. Jeder Eintrag enthält:

• Zeitstempel
• Nutzerkennung
• Aktion (etwa Dokument-Upload, Abfrage, Modellwechsel)
• betroffener Objekttyp und dessen Kennung
• Mandatsbezug
• strukturierte Detailangaben
• Trace-Kennung zur Verknüpfung mit den Betriebsprotokollen

Erfasst sind heute insbesondere Dokumenten-Uploads und deren Verarbeitungsstatus, Abfrageereignisse, der Wechsel des aktiven Chat- oder Embedding-Modells sowie Lebenszyklusereignisse der Infrastruktur.

5.2 Anfügend, nicht änderbar

Ein Datenbank-Trigger bricht jeden UPDATE- und DELETE-Versuch auf der Audit-Tabelle mit einem Fehler ab. Die Anwendung kann die Historie also auch dann nicht verändern, wenn sie es versuchte.

5.3 Die Grenzen, ausdrücklich

• Der Trigger ist keine Manipulationssicherheit. Er schützt gegen die Anwendung und gegen versehentliches SQL. Er schützt nicht gegen einen Datenbank-Superuser oder den Eigentümer des Schemas. Ein Entzug der Schreibrechte samt gesondertem Archivierungskonto ist vorgesehen und noch nicht umgesetzt.
• Audit-Schreibvorgänge sind bewusst nicht blockierend. Scheitert das Schreiben, wird die Anfrage trotzdem beantwortet und der Fehler protokolliert; das System zählt aufeinanderfolgende und gesamte Fehlversuche und stellt diesen Zähler zur Überwachung bereit. Der Vorteil ist, dass ein Datenbankproblem den Kanzleibetrieb nicht anhält. Der Preis ist, dass der Audit-Pfad theoretisch Lücken haben kann. Diesen Zähler sollte Ihre Überwachung auswerten.
• Nicht jede Aktion erzeugt heute einen Eintrag. Der Umfang wächst; wir behaupten keine lückenlose Protokollierung.