Schaden durch einen KI-Agenten: Wer zahlt, und mit welchem Beweis

Wer zahlt für den Schaden eines KI-Agenten: Die Antwort kommt aus zwei europäischen Texten und aus einer Protokolldatei. Die Verordnung (EU) 2024/1689 verlangt von Hochrisikosystemen die Aufzeichnung von Ereignissen. Die Richtlinie (EU) 2024/2853 über die Haftung für fehlerhafte Produkte führt dagegen dazu, die Fehlerhaftigkeit zu vermuten, wenn die angeforderten Beweismittel außerhalb des Verfahrens bleiben.

Dazwischen steht die alltägliche Praxis: Ein Agent, der Buchhaltung und Zahlungen berührt, hinterlässt eine Spur, oder eine Lücke.

Das Protokoll der Handlungen ist der einzige Zeuge

Die Verordnung (EU) 2024/1689 verlangt in Artikel 12 von Hochrisikosystemen die automatische Aufzeichnung von Ereignissen über die gesamte Lebensdauer des Systems. Die Norm betrifft die Konzeption, noch vor den operativen Entscheidungen: Das System muss aufzeichnungsfähig sein.

Wenn ein Agent eine Zahlung falsch ausführt, bleibt sein Protokoll der einzige Zeuge des Ablaufs.

Menschen erinnern sich an das Ergebnis. Das Protokoll bewahrt die Reihenfolge der Schritte: welches Dokument eingegangen ist, welches Werkzeug aufgerufen wurde, mit welchem Parameter, zu welcher Uhrzeit. Wer die Entscheidungskette rekonstruieren will, braucht diese Spur, auch für Dritte lesbar.

Sechs Monate Aufbewahrung, und wer dafür haftet

Artikel 19 legt die Aufbewahrung der von ihren Hochrisikosystemen erzeugten Protokolle den Anbietern auf. Der Mindestzeitraum beträgt sechs Monate, sofern das Unionsrecht oder das nationale Recht keine anderen Fristen festlegt.

Artikel 26 Absatz 6 wiederholt die Pflicht für die Betreiber, also für die Unternehmen, die das System in ihrer eigenen Tätigkeit einsetzen.

Für Finanzinstitute gilt eine Regel mehr: Sie führen die Protokolle innerhalb der Dokumentation, die das Unionsrecht über Finanzdienstleistungen ohnehin verlangt. Für eine Bank wird das Protokoll des Agenten damit zur Aufsichtsdokumentation. Es ändern sich die Fristen, es ändert sich das Format, es ändert sich, wer es anfordern kann.

Hochrisiko: der Anwendungsbereich und das Datum 2. Dezember 2027

Diese Pflichten gelten für Hochrisikosysteme, also muss der Anwendungsbereich vor allem anderen bestimmt werden. Ein Assistent, der interne E-Mails zusammenfasst, bleibt außen vor; ein System, das die Kreditwürdigkeit einer natürlichen Person bewertet, fällt unter Anhang III.

Für die Fälle des Anhangs III hat das Digital-Omnibus-Paket die Anwendung auf den 2. Dezember 2027 verschoben.

Dieses Datum ist ein Projektfenster. Wer heute einen Dreijahresvertrag über eine agentische Plattform unterzeichnet, kauft ein System, das vor Vertragsende konform sein muss. Die Frage für das Einkaufsgremium wird damit vertraglich: Garantiert der Anbieter das normgerechte Logging bis zu diesem Datum, und mit welcher Vertragsstrafe?

Die Richtlinie 2024/2853 vermutet die Fehlerhaftigkeit

Die Richtlinie (EU) 2024/2853^[1] behandelt Software als Produkt. Artikel 9 erlaubt dem Gericht, dem Beklagten die Offenlegung der in seinem Besitz befindlichen relevanten Beweismittel aufzugeben.

Artikel 10 Absatz 2 Buchstabe a fügt die Folge hinzu: Die Fehlerhaftigkeit wird vermutet, wenn der Beklagte diese Offenlegung unterlässt.

Hier liegt der Punkt, der jene betrifft, die bauen. Eine Architektur ohne überprüfbare Protokolle erzeugt eine Beweisunmöglichkeit, und die Norm legt sie zulasten dessen aus, der sie zu tragen hat. Die technische Schuld bei der Beobachtbarkeit wird zur prozessualen Schuld.

Zwischen Unternehmen entscheidet der Vertrag

Zwischen Unternehmen wird die Partie über den Vertrag gespielt. Die Richtlinie schützt die geschädigte Person; das Verhältnis zwischen Kunde und Plattformanbieter läuft dagegen über Klauseln, Service-Levels und Haftungsgrenzen. In diesem Streit sagt das Protokoll, wer den Fehler verursacht hat.

Drei typische Fälle mit entgegengesetzten Ergebnissen. Das Modell hat aus korrekten Daten eine falsche Ausgabe erzeugt. Der Orchestrator hat dem Agenten einen bereits verunreinigten Kontext übergeben. Die Bedienperson hat einen als zweifelhaft markierten Vorschlag freigegeben.

Jeder dieser Fälle verschiebt die Verantwortung auf ein anderes Subjekt. Und jeder unterscheidet sich von den anderen einzig durch die Ausführungsspur, Feld für Feld. Ein Gutachten, das zwei Jahre später kommt, arbeitet mit dem, was das System damals geschrieben hat.

Policen auf die KI-Leistung verlangen Maßnahmen

Der Versicherungsmarkt hat begonnen, Deckungen speziell für die Leistung von KI-Systemen zu schreiben, neben den klassischen Haftpflicht- und Cyber-Policen. Der Gegenstand ändert sich: Versichert wird die Abweichung zwischen dem versprochenen und dem erzielten Ergebnis.

Eine Deckung dieser Art lebt von Messung. Um einen Schaden zu regulieren, muss man den Fehler, sein Datum und seine wirtschaftliche Wirkung zeigen.

Das Underwriting folgt derselben Logik. Wer die Police verkauft, schaut auf das Design der Kontrollen, die Qualität des Loggings und die Aufbewahrungsfristen. Wer lückenhafte Protokolle vorlegt, zahlt mehr oder bleibt von der Deckung ausgeschlossen. Das Logging verlässt damit das Compliance-Kapitel und geht in den Preis des Risikos ein.

Was ein Agent in Buchhaltung und Zahlungsverkehr protokollieren muss

Ein Agent, der in Buchhaltung und Zahlungsverkehr arbeitet, ist um eine einzige Frage herum zu entwerfen: Wer hat was entschieden, mit welcher Vollmacht, auf welchen Daten, zu welchem Zeitpunkt. Jedes Feld des Protokolls antwortet auf einen Teil dieser Frage.

• Identität des Agenten: eigene Zugangsdaten, niemals die geteilten des menschlichen Nutzers.
• Aktive Delegation: Umfang, Betragsschwellen, zugelassene Gegenparteien, Ablauf des Mandats.
• Version: Modell, System-Prompt, Werkzeugkatalog, jeweils mit Prüfsumme.
• Abgerufene Eingaben: Kennung und Hash jedes Dokuments, das in den Kontext gelangt ist.
• Werkzeugaufrufe: Parameter, Ergebnis, Fehlercode, Wiederholungsversuche.
• Menschliche Freigabe: wer freigegeben hat, was am Bildschirm zu sehen war, in welchem Moment.
• Zeit: synchronisierter Zeitstempel, deklarierte Quelle, Zeitzone in UTC angegeben.
• Integrität: Schreiben im Append-Modus, Hash-Kette, unveränderbarer Datenträger.

Zwei Details trennen ein nützliches Protokoll von einer Debug-Datei. Das erste ist die Verbindung zwischen dem Vorschlag des Agenten und der Buchung, gehalten über eine gemeinsame Kennung, die auch nachgelagert trägt, im Zahlungssystem. Das zweite ist die Aufzeichnung der abgewiesenen Handlungen: Die Verteidigung führt oft darüber, zu zeigen, was die Kontrolle gestoppt hat.

Das Protokoll muss außerdem auch für jene lesbar bleiben, die dem Code fremd sind. Ein externer Prüfer öffnet die Datei und muss Zeile für Zeile verstehen, welches Mandat die Handlung deckte. Diese Anforderung ändert das Format: stabile Feldnamen, explizite Werte, deklarierte Versionen.

Drei Fragen für das Team, das Agenten in den Produktivbetrieb bringt

Die nützlichen Fragen vor dem nächsten Release auf Finanzprozessen sind drei.

1. Trägt das Protokoll als Beweis gegenüber einem Dritten, oder braucht man einen Ingenieur, um es zu lesen?
2. Erreicht die Aufbewahrung die mindestens sechs Monate und, für Finanztätigkeiten, die Fristen der Aufsichtsdokumentation?
3. Exportiert der Anbieter die Protokolle in einem offenen Format, oder hält er sie in seiner eigenen Umgebung?

Die dritte wiegt schwerer als die anderen. Ein Protokoll, das einzig in der Konsole des Anbieters lebt, erzeugt einen architektonischen Lock-in auf den Beweis: Im Streitfall hängt das Unternehmen von der technologischen Gegenseite ab, um seine eigene Sorgfalt zu belegen.

Entscheidungen für den nächsten Planungszyklus: Export der Protokolle als vertragliche Anforderung, Hash-Kette für jeden Vorgang, der Geld bewegt, namentliche Identität für jeden Agenten. Zu überarbeiten ist auch die Haftungsklausel, im Licht der Richtlinie 2024/2853.

Das Protokoll ist Verteidigungsinfrastruktur. Es wird vor dem Schaden gebaut, denn danach bleibt nur, was geschrieben wurde.