Verordnung (EU) 2022/2554

Was DORA an Protokollierung im Finanzsektor verlangt, und was Logsiegel dazu beiträgt

Seit Januar 2025 müssen Finanzunternehmen in der EU ihre digitale Betriebsstabilität nach DORA nachweisen. Wer dort einen KI-Agenten einsetzt, ob selbst oder über einen Dienstleister, muss hinterher belegen können, was der Agent getan hat, und dass das Protokoll darüber unverändert ist.

Für wen das gilt

Banken, Versicherer, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Kryptowerte-Dienstleister, Handelsplätze und weitere in Art. 2 aufgezählte Finanzunternehmen. Über Art. 28 ff. mittelbar auch ihre IKT-Drittdienstleister, also jeder Anbieter, dessen KI-Dienst in einem Finanzunternehmen läuft und der dem Kunden Prüfbarkeit schuldet.

Was das Regelwerk an Aufzeichnungen verlangt

DORA selbst formuliert die Pflichten allgemein; die Details zur Protokollierung stehen in den technischen Regulierungsstandards (RTS) zum IKT-Risikomanagementrahmen:

Fundstelle	Anforderung
Art. 9	Schutz und Prävention: Finanzunternehmen überwachen und kontrollieren IKT-Systeme fortlaufend und setzen Instrumente ein, die die Integrität von Daten und Systemen sichern.
Art. 10	Erkennung: Mechanismen, um anomale Aktivitäten umgehend zu erkennen, einschließlich Problemen bei der Leistung von IKT-Netzen und IKT-bezogenen Vorfällen.
Art. 17 Abs. 3	Vorfallmanagement: Verfahren, um IKT-bezogene Vorfälle zu identifizieren, nachzuverfolgen, aufzuzeichnen, zu kategorisieren und zu klassifizieren; Ursachenanalyse und Dokumentation.
RTS, Del. VO (EU) 2024/1774, Art. 12	Protokollierung: Finanzunternehmen legen fest, welche Ereignisse zu protokollieren sind, wie lange Protokolle aufbewahrt werden und wie Protokolldaten gegen unbefugten Zugriff und Veränderung geschützt werden.
Art. 28 bis 30	IKT-Drittparteienrisiko: Verträge mit IKT-Dienstleistern müssen unter anderem Zugangs-, Inspektions- und Auditrechte des Finanzunternehmens und der Aufsicht vorsehen; der Dienstleister muss die Nachweise liefern können.
Art. 19	Meldung schwerwiegender IKT-Vorfälle an die Aufsicht mit Erst-, Zwischen- und Abschlussbericht. Die Berichte brauchen belastbare Fakten darüber, was im System geschah.

Was Logsiegel dazu beiträgt heute

Unveränderte Aufzeichnung, prüfbar. Jeder Eintrag ist per Hash mit dem vorigen verkettet; in Abständen wird eine Merkle-Wurzel gebildet und mit Ed25519 signiert (Prüfpunkt). Nachträgliche Änderung, Umsortierung oder Kürzung lässt logsiegel verify fehlschlagen. Das ist der Schutz der Protokolldaten gegen Veränderung, den die RTS in Art. 12 verlangen, in einer Form, die ein Prüfer selbst nachrechnen kann.
Vorfall-Rekonstruktion. Nach einem Vorfall zeigt das Protokoll, welche Anfragen der Agent wann mit welchem Modell verarbeitet hat und wo Fehler (anomaly) auftraten. Der Abschlussbericht nach Art. 19 stützt sich auf Aufzeichnungen, deren Unverändertheit belegbar ist.
Belege für Auftraggeber und Aufsicht. logsiegel receipt erzeugt für eine einzelne Aktion eine Datei aus Eintrag, Einschluss-Beweis und signiertem Prüfpunkt. Ein Prüfer, Kunde oder Gericht prüft sie offline gegen Ihren veröffentlichten Schlüssel, ohne Zugriff auf Ihre Systeme und ohne den Rest des Protokolls zu sehen. Ein IKT-Dienstleister erfüllt so Auditrechte nach Art. 30, ohne dem Kunden Zugriff auf seine Systeme oder Einblick in andere Mandanten zu geben.
Aufbewahrung nachweisbar. Ein signierter Prüfpunkt belegt, dass das Protokoll zu einem Zeitpunkt eine bestimmte Länge und einen bestimmten Inhalt hatte. Wer später kürzt, wird gegen jeden früher ausgegebenen Prüfpunkt oder Beleg auffällig.
Lesbares Dossier. logsiegel export schreibt das Protokoll als Markdown-Dossier für Menschen, die keine Kommandozeile bedienen wollen.
Nur Metadaten im Protokoll. In die Kette gelangen Ereignis-Metadaten und gesalzene Prüfsummen; Eingaben und Ausgaben liegen getrennt, je Eintrag verschlüsselt. Ein Eintrag lässt sich per Schlüssel-Löschung (Crypto-Shredding) inhaltlich löschen, ohne dass die Kette bricht. Auch in Belegen an die Aufsicht bleiben Kundendaten außen vor.

Was in Arbeit ist geplant

Unabhängiger Zeuge, der Prüfpunkte gegenzeichnet. Für Finanzunternehmen die Stufe, in der auch der Dienstleister selbst kein zweites Protokoll führen kann.
Qualifizierte Zeitstempel nach eIDAS für Prüfpunkte, damit Zeitangaben nicht mehr nur Behauptung des Betreibers sind.
MCP-Proxy für Werkzeugaufrufe von Agenten (Zahlungen, Buchungen, Abfragen) an der Schnittstelle.

Was Logsiegel nicht leistet

Erkennung in Echtzeit. Logsiegel ist kein SIEM und kein Monitoring; es macht Aufzeichnungen beweisbar, es alarmiert nicht. Art. 10 erfüllen Sie mit Ihren Erkennungssystemen, Logsiegel liefert ihnen unveränderte Fakten.
Melde- und Vorfall-Workflow. Klassifizierung, Fristen und Berichte nach Art. 17 bis 19 bleiben Ihr Prozess.
Tests der Betriebsstabilität (Art. 24 ff.) und das Register der Drittparteien-Verträge (Art. 28 Abs. 3) sind eigene Pflichten.
Vollständigkeit. Bewiesen wird, dass Aufgezeichnetes unverändert ist, nie, dass alles aufgezeichnet wurde. Das ist eine Integrationsfrage: Der Adapter muss an einer Stelle sitzen, die jede Aktion passieren muss (LiteLLM heute, MCP-Proxy in Arbeit).
Schutz gegen den Betreiber selbst. Wer den Signaturschlüssel hält, könnte das Protokoll neu schreiben und neu signieren. Das fällt genau dann auf, wenn jemand anderes einen früheren Prüfpunkt oder Beleg besitzt. Geben Sie Prüfpunkte deshalb aus der Hand; die Gegenzeichnung durch einen unabhängigen Zeugen ist die nächste Ausbaustufe.
Zeitangaben. Zeitstempel im Protokoll sind bis zur Gegenzeichnung durch einen Zeugen oder einen qualifizierten Zeitstempeldienst eine Behauptung des Betreibers.
Rechtliche Bewertung. Ob Ihr System unter das Regelwerk fällt, welche Pflichten konkret greifen und ob ein Beleg im Einzelfall genügt, entscheidet Ihre Rechts- oder Compliance-Prüfung, nicht dieses Werkzeug.

So setzen Sie es dafür ein

1. Installieren und ein Protokoll anlegen

Das SDK ist Python, Apache 2.0, ohne Server und ohne Konto. Der Ursprung (origin) benennt das System, dessen Handeln protokolliert wird.

pip install logsiegel
logsiegel init ./trail --origin "acme.example/support-agent"

2. Adapter an der Stelle einbinden, die jede Aktion passieren muss

Läuft Ihr KI-Verkehr über LiteLLM, wird jede Vervollständigung ein signierbarer inference-Eintrag, Fehler werden als anomaly aufgezeichnet. Menschliche Eingriffe protokollieren Sie ausdrücklich als eigenes Ereignis.

import litellm
from logsiegel.integrations.litellm_logger import LogsiegelLogger

litellm.callbacks = [LogsiegelLogger("/var/lib/logsiegel/prod", store_payload=True)]

3. Prüfpunkte setzen und aus der Hand geben

Setzen Sie Prüfpunkte regelmäßig (etwa per Cron) und legen Sie sie außerhalb Ihrer Infrastruktur ab: beim Prüfer, beim Kunden, in einem fremden Repository. Erst ein Prüfpunkt, den Sie nicht mehr allein kontrollieren, macht das Protokoll gegen Sie selbst beweiskräftig.

logsiegel checkpoint ./trail
logsiegel verify ./trail

4. Prüfpunkte dem Auftraggeber regelmäßig übergeben

Als IKT-Dienstleister übermitteln Sie dem Finanzunternehmen die signierten Prüfpunkte, etwa täglich. Der Kunde kann damit jederzeit prüfen, dass Ihr Protokoll seither nur gewachsen ist (Konsistenz-Beweis), ohne den Inhalt zu sehen.

5. Bei einer Anfrage den Beleg aushändigen

Statt Datenbankauszügen liefern Sie einen einzelnen Beleg. Die Gegenseite prüft ihn im Browser unter logsiegel.com/verifier oder per Kommandozeile, beides offline.

logsiegel receipt ./trail --seq 1284 --out receipt.json
logsiegel verify-receipt receipt.json --pubkey logsiegel.pub

Weitere Regelwerke: EU AI Act DSGVO NIS2 / KRITIS ISO/IEC 27001 ISO/IEC 42001 GoBD eIDAS Übersicht

Rechtsstand September 2026. Diese Seite ist eine technische Einordnung durch das Projekt, keine Rechtsberatung und keine Konformitätsaussage. Fundstellen bitte am jeweils aktuellen Normtext prüfen. Korrekturen gern per GitHub-Issue.