Incident Response bei KI-Code: DORA, NIS2 und DSGVO im Vorfall

Während Sie noch den Vorfall eindämmen, verfällt schon der Nachweis. GitHub hält Git-Ereignisse wie Push oder Fetch sieben Tage im Enterprise-Audit-Log vor. Die Sitzungsprotokolle von Claude Code liegen nach den Standardeinstellungen 30 Tage lokal unter ~/.claude/projects/, und das Audit-Log von Cursor erfasst generierten Code laut Anbieterdokumentation überhaupt nicht. Ob ein Coding-Agent die fehlerhafte Änderung geschrieben hat, lässt sich vier Wochen später oft nicht mehr feststellen. Gefragt wird danach in keinem Meldebogen. Gebraucht wird die Antwort trotzdem, bei der Eingrenzung und in jeder späteren Diskussion darüber, welche Kontrolle die Änderung durchgelassen hat.

Die Uhr, die parallel läuft, ist kürzer als die meisten Notfallpläne annehmen. Die DORA-Erstmeldung muss binnen vier Stunden nach der Einstufung als schwerwiegend bei der BaFin liegen, spätestens aber 24 Stunden nach Kenntnis vom Vorfall. Eine Ursachenanalyse ist in dieser Zeit nicht fertig und muss es auch nicht sein. Hinterlegt sein muss dagegen der LEI im Benutzerprofil des MVP-Portals, sonst ist das Fachverfahren gar nicht erst freigeschaltet. Wer das während des Vorfalls bemerkt, verliert Stunden an der Benutzerverwaltung eines Portals.

Feld 4.1 des DORA-Meldebogens unterscheidet fünf Ursachenklassen: böswillige Handlungen, Prozessversagen, Systemversagen oder -störung, menschliches Versagen und externe Ereignisse. Die Beteiligung eines KI-Agenten ist keine eigene Kategorie.

Eine fehlerhafte Codeänderung wird je nach Befund dem Änderungsmanagement, unzureichenden oder fehlgeschlagenen Softwaretests oder der Softwarekompatibilität und -konfiguration zugeordnet. Ob ein Mensch oder ein Coding-Agent den Commit vorbereitet hat, ändert an dieser Einordnung nichts. Für die Reaktion auf den Vorfall bleibt die Entstehungsgeschichte dennoch relevant: Sie kann die Eingrenzung beschleunigen, die Nachweiskette stützen und zeigen, warum eine Kontrolle nicht gegriffen hat.

Kurz gefasst

• Für die Meldung zählen Anwendungsbereich, Auswirkungen, Meldeschwelle und Zeitpunkt der Kenntniserlangung, nicht die Frage, wer den Code erstellt hat.
• Die Beteiligung eines Coding-Agenten kann im DORA-Freitextfeld erwähnt werden. Sie darf die Erstmeldung aber nicht verzögern.
• Operativ gilt: zuerst eindämmen und den Dienst wiederherstellen. Flüchtige Spuren werden parallel gesichert, sofern dies die Eindämmung nicht wesentlich verzögert.
• Keine einzelne Spur belegt die Agentenbeteiligung für sich allein. Belastbar wird die Aufarbeitung erst durch das Zusammenspiel von geschützter Git-Historie, Review- und Testnachweisen, Deployment-Daten sowie exportierten Sitzungs- und Audit-Logs.

Stand: 25. August 2026. Dieser Beitrag bietet eine fachliche Einordnung und ersetzt keine Rechtsberatung.

Der DORA-Meldebogen sieht kein Feld für die Agentenbeteiligung vor

Die BaFin-Ausfüllhilfe zur DORA-Vorfallmeldung erfasst die Ursachen in den Feldern 4.1 bis 4.5. Feld 4.1 gibt die fünf Oberkategorien vor. Die Felder 4.2 und 4.3 konkretisieren diese Kategorien. Für eine fehlerhafte Codeänderung kommen je nach Sachverhalt insbesondere diese Einträge in Betracht:

• Prozessversagen, darunter Änderungsmanagement
• Prozessversagen, darunter unzureichende Softwaretests oder Versagen von Softwaretests
• Systemversagen oder -störung, darunter Softwarekompatibilität und -konfiguration

Feld 4.5 ist ein Freitextfeld für die Ereignisabfolge und ergänzende Angaben zur Ursache. Dort kann ein Unternehmen festhalten, dass ein Coding-Agent beteiligt war. Verlangt wird diese Angabe nicht, und ein strukturiertes Feld für die Agentenbeteiligung gibt es nicht.

Für BSIG und DSGVO lässt sich aus öffentlichen Quellen nur Folgendes sagen: Der Gesetzestext des BSIG verlangt keine Angabe dazu, wer eine fehlerhafte Änderung geschrieben hat. Art. 33 Abs. 3 DSGVO nennt als Mindestangaben unter anderem die Art und die Folgen der Verletzung sowie die ergriffenen Maßnahmen, aber keine Angabe dazu, wer den Code erstellt hat. Das Meldeportal des BSI ist nur nach Registrierung zugänglich, seine Formularfelder sind öffentlich nicht dokumentiert. Aus öffentlichen Quellen lässt sich deshalb nicht belastbar sagen, ob es eine Auswahlmöglichkeit für eine KI-Beteiligung vorsieht.

Dass DORA nicht nur Angriffe erfasst, zeigen die ersten EU-weiten Zahlen. Die europäischen Aufsichtsbehörden zählten für 2025 insgesamt 3.383 gemeldete schwerwiegende IKT-Vorfälle. 51 Prozent wurden als Systemausfälle und 10 Prozent als cybersicherheitsbezogene Vorfälle eingeordnet. Die Zahlen zeigen damit, dass DORA deutlich mehr als Angriffe erfasst.

Eine noch ungeklärte Agentenbeteiligung hindert die formale Meldung nicht. Sie wird dort wichtig, wo das Formular endet: bei der technischen Eingrenzung, bei einem späteren Streit über Freigabe und Sorgfalt sowie bei der Aufarbeitung des Vorfalls und der Vermeidung ähnlicher Fehler.

Die Auswirkungen entscheiden über die Einstufung

Ein selbst verursachter Fehler beim Deployment kann ein Sicherheitsvorfall sein. § 2 Nr. 40 BSIG stellt auf eine Beeinträchtigung von Verfügbarkeit, Integrität oder Vertraulichkeit ab, nicht auf Vorsatz oder einen Angriff. Als erheblich gilt der Vorfall nach § 2 Nr. 11, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen kann, oder wenn er Dritte erheblich geschädigt hat oder schädigen kann. Welche Kontrollen dafür schon vor dem Vorfall dokumentiert sein müssen, führt der Beitrag zu NIS2 und Coding Agents aus.

Der Verdacht auf böswilliges Handeln ist nach dem BSIG eine Angabe in der Meldung, aber keine allgemeine Voraussetzung für die Meldepflicht. § 32 Abs. 1 Nr. 1 BSIG verlangt in der Erstmeldung gerade die Angabe, ob ein Verdacht auf rechtswidrige oder böswillige Handlungen besteht. Die Vorschrift geht damit ausdrücklich davon aus, dass auch Vorfälle ohne einen solchen Verdacht meldepflichtig sein können.

Die Durchführungsverordnung (EU) 2024/2690 schließt planmäßige Betriebsunterbrechungen und die geplanten Folgen planmäßiger Wartung von der Einstufung aus. Eine ungeplante Unterbrechung infolge eines fehlgeschlagenen Deployments ist nicht schon deshalb von der Einstufung ausgenommen, weil das Deployment geplant war. Für die von der Verordnung erfassten Anbieterkategorien gelten zudem konkrete Schwellen. Bei Cloud-Diensten kann eine vollständige Nichtverfügbarkeit von mehr als 30 Minuten genügen. Für andere NIS2-Sektoren gilt weiterhin der offene Maßstab des § 2 Nr. 11 BSIG.

Auch im Datenschutzrecht ist ein Angriff von außen keine Voraussetzung. Die EDSA-Leitlinien 9/2022 beziehen ausdrücklich interne Vorgänge ein. Eine vorübergehende Nichtverfügbarkeit personenbezogener Daten kann eine Verletzung des Schutzes personenbezogener Daten sein, wenn der fehlende Zugang den Schutz dieser Daten beeinträchtigt. Danach sind zwei Fragen getrennt zu prüfen: Muss die Verletzung nach Art. 33 Abs. 5 dokumentiert werden, und erreicht sie die Risikoschwelle für eine Meldung an die Aufsicht?

Im laufenden Vorfall sollten zwei Arbeitsstränge parallel laufen. Das Störungsmanagement stellt den Dienst wieder her. Der Incident-Response-Strang bewertet Auswirkungen und Meldeschwellen, sichert Beweise und stößt erforderliche Meldungen an. In der Praxis überschneiden sich beide Stränge.

NIS2, DSGVO und DORA: drei Meldewege, drei Uhren

Bis zur ersten Meldung muss die Ursache meist noch nicht vollständig geklärt sein. Entscheidend ist, wann die Organisation Kenntnis vom Vorfall erlangt, ob sie in den Anwendungsbereich fällt und ob die jeweilige Schwelle erreicht ist. Bei DORA kommt der Zeitpunkt der Einstufung als schwerwiegend hinzu.

Die 24- und 72-Stunden-Fristen des BSIG laufen parallel ab Kenntniserlangung. Die zweite Frist beginnt nicht nach der Erstmeldung. Bei DORA ist es anders: Die 72-Stunden-Frist beginnt mit der Übermittlung der Erstmeldung, die Monatsfrist mit der Zwischenmeldung.

Für die DSGVO beginnt die Uhr bei hinreichender Gewissheit, nicht erst nach einer vollständigen Ursachenanalyse. Eine kurze erste Prüfung ist zulässig, sie muss aber sofort beginnen. Dass eine unterbrochene interne Eskalationskette den Fristbeginn nicht verschiebt, zeigt die niederländische Entscheidung gegen Booking.com vom 10. Dezember 2020. Die Aufsicht verhängte 475.000 Euro wegen verspäteter Meldung. Dass der Vorfall intern nicht rechtzeitig beim Sicherheitsteam ankam, änderte am Fristbeginn nichts. Die Aufsicht beanstandete zudem, dass Booking.com eine vertiefte Untersuchung abwartete, statt zunächst mit dem gesicherten Kenntnisstand zu melden und die Angaben später zu ergänzen.

Für das DORA-Meldeverfahren ist der technische Meldeweg selbst Teil der Vorbereitung. Die BaFin beschreibt die Übermittlung über ihr MVP-Portal. Für die Freischaltung des Fachverfahrens muss der LEI im Benutzerprofil hinterlegt sein. Wer erst während des Vorfalls die Freischaltung beantragt und den LEI hinterlegt, riskiert, die Vier-Stunden-Frist zu versäumen.

Ein Incident-Response-Plan sollte deshalb für jedes Meldeverfahren bereits Adressat, Meldeschwelle, Fristbeginn, Fristen, Meldeverantwortliche und eine Vertretungsregelung enthalten. Noch offene Angaben werden in den Folge- und Abschlussmeldungen ergänzt. Organisatorisch vorhersehbare Fragen sollten nicht erst während des Vorfalls geklärt werden.

Eindämmung zuerst, Beweise parallel sichern

Bei der technischen Eingrenzung geht es zunächst nicht darum, wer die Änderung geschrieben hat, sondern welche Änderung das Symptom ausgelöst hat. Drei Wege sind typisch:

1. Den Zeitpunkt, zu dem das Symptom erstmals auftrat, mit Deployments und Feature-Releases abgleichen.
2. Feature-Flags kontrolliert testen und dabei Abhängigkeiten dokumentieren sowie einen Rücksetzplan bereithalten. Miteinander gekoppelte Flags dürfen nicht ohne Prüfung ihrer Abhängigkeiten ein- und ausgeschaltet werden.
3. Bei einem reproduzierbaren Fehler git bisect zwischen dem letzten bekannten guten und dem ersten fehlerhaften Stand einsetzen.

Ein großer Sammelcommit aus einer Agentensitzung erschwert die Eingrenzung, weil viele Änderungen in einem Commit gebündelt sind. git bisect kann den ersten fehlerhaften Commit ermitteln. Es zeigt jedoch weder, welche Zeile im Commit von wem stammt, noch warum sie geschrieben wurde.

Ein Rollback auf ein bekanntes, funktionsfähiges Artefakt stellt den Dienst wieder her, ohne die Git-Historie zu löschen. Er scheidet aus, wenn bereits eine irreversible Migration ausgeführt wurde oder der aktuelle Datenstand nicht mehr zum alten Artefakt passt. Die Wiederherstellung hat Vorrang. Die Beweissicherung erfolgt parallel, sofern sie die Eindämmung nicht wesentlich verzögert.

Wichtig ist die Unterscheidung zwischen Identifikation und dauerhafter Sicherung. Ein notierter Commit-Hash verweist auf ein Objekt, sichert dessen dauerhafte Verfügbarkeit aber nicht. Soll ein Commit unabhängig von der Lebensdauer von Branches und Reflogs verfügbar bleiben, muss er über eine geschützte Referenz erhalten bleiben oder unveränderbar exportiert werden, etwa in ein forensisches Repository, ein Git-Bundle oder ein revisionssicheres Archiv.

Dasselbe gilt für andere Spuren. Ein Link zu einer Sitzung sichert deren Inhalt nicht. Je nach Werkzeug ist die Aufbewahrungsfrist kurz oder wird vom Anbieter nicht öffentlich angegeben. Exportiert werden müssen daher die tatsächlich verfügbaren Inhalte und Metadaten, nicht nur ihre URLs.

Runbook bis zur Erstmeldung

1. Auswirkungen und Anwendungsbereich einordnen. Auswirkungen auf Verfügbarkeit, Integrität und Vertraulichkeit sowie betroffene Dienste, Kunden, Daten und Länder erfassen. Anschließend die einschlägigen Meldeschwellen prüfen.
2. Zeitpunkte festhalten. Dokumentieren, wann und durch wen der Vorfall bekannt wurde. Bei DORA zusätzlich festhalten, wann der Vorfall als schwerwiegend eingestuft wurde.
3. Eindämmen und wiederherstellen. Datenverkehr umleiten, die betroffene Funktion deaktivieren und zwischen Rollback und einer Korrektur im laufenden Stand entscheiden. Wurden in der betroffenen Agentensitzung produktive Zugangsdaten oder Berechtigungen verwendet, die Zugangsdaten sperren oder rotieren und nicht mehr benötigte Berechtigungen entziehen.
4. Auslösende Änderung eingrenzen. Deployment-Historie, kontrollierte Tests mit Feature-Flags und git bisect nutzen. Nicht anhand der Autorenangabe nach dem Fehler suchen, sondern anhand von Deployment-Zeitpunkt, Verhalten und Codeänderung.
5. Flüchtige Spuren parallel sichern. Soweit dies ohne wesentliche Verzögerung möglich ist, Commit-Objekte, das tatsächlich ausgerollte Artefakt, CI- und Deployment-Logs, Pull-Request- und Review-Daten, Audit-Logs sowie Sitzungsinhalte in einer unveränderbaren Ablage archivieren. Die Kopien außerhalb des betroffenen Repositories ablegen.
6. Schrittweise melden. Den aktuellen, belegten Kenntnisstand melden, statt die vollständige Klärung von Ursache oder Agentenbeteiligung abzuwarten.
7. Datenschutzverletzungen gesondert dokumentieren. Art. 33 Abs. 5 DSGVO gilt auch dann, wenn die Risikoprüfung ergibt, dass keine Meldung erforderlich ist.

git commit --amend und ein Rebase erzeugen neue Commit-Objekte und können Trailer oder Commit-Nachrichten entfernen. Das lokale Reflog wird nicht gepusht, und nicht mehr erreichbare Reflog-Einträge werden nach den Git-Standardeinstellungen nach 30 Tagen bereinigt. Ein neuer Build kann frühere Artefakte überschreiben, wenn die Ablage keine unveränderbare Versionierung vorsieht. Logrotation und die Aufbewahrungsfristen des Anbieters können andere Spuren schon früher entfernen.

Forensik: Keine einzelne Spur belegt die Agentenbeteiligung

Repository, Hosting-Plattform und Coding-Agent dokumentieren jeweils unterschiedliche Teile der Entstehungsgeschichte. Keine Quelle belegt die Agentenbeteiligung für sich allein und vollständig. Wie umfangreich eine solche Kette in einem beaufsichtigten Haus ausfällt, zeigt der Beitrag dazu, wie eine Korrektur am Rechenkern acht Nachweise nach sich zieht.

Der Linux-Kernel empfiehlt seit Version 7.0 einen Assisted-by:-Trailer. Die Formulierung „should“ kennzeichnet eine Empfehlung, keine Pflicht. checkpatch.pl prüft lediglich, ob ein vorhandener Trailer einen Wert enthält. Ob der Trailer fehlt oder inhaltlich stimmt, wird nicht geprüft.

Dass ein Trailer falsch sein kann, ist kein theoretischer Einwand. Microsoft dokumentierte in VS Code Issue 314311 einen Zeitraum vom 22. April bis 6. Mai 2026, in dem Commit-Nachrichten Copilot als Co-Autor auswiesen, obwohl der Commit Vervollständigungen enthielt, die nicht von Copilot stammten. Der Trailer konnte sogar erscheinen, wenn KI-Funktionen deaktiviert waren.

Auch übliche Git-Vorgänge können die Markierung entfernen. Bei einem Squash-Merge mit mehreren Commits enthält die GitHub-Standardnachricht den Pull-Request-Titel und die Liste der Commit-Betreffzeilen. Ein Trailer im Beschreibungstext eines einzelnen Commits wird dabei nicht automatisch in die Branch-Historie übernommen. Das alte Objekt kann lokal noch erreichbar sein, doch diese Spur ist weder zentral erfasst noch dauerhaft gesichert.

Aussagekräftiger ist eine serverseitig erzeugte Nachweiskette. Beim Copilot Cloud Agent weist GitHub den Agenten als Autor aus, die Person, die die Sitzung gestartet hat, wird im Commit als Co-Autor genannt, die Commits sind signiert und enthalten einen Link zum Sitzungsprotokoll. Das verbessert die Nachvollziehbarkeit. Der Link ersetzt dennoch keinen Export, solange die Aufbewahrungsfrist des Inhalts nicht Teil der eigenen Nachweisstrategie ist.

Bei lokalen Agenten hängt die Beweislage vom Betriebsmodus ab. Claude Code speichert Sitzungsprotokolle lokal standardmäßig 30 Tage im Klartext unter ~/.claude/projects/. Der Wert cleanupPeriodDays ist konfigurierbar. Das Enterprise-Audit-Log von Cursor dokumentiert administrative und sicherheitsrelevante Ereignisse, aber laut eigener Dokumentation keine Agentenantworten und keinen generierten Code. GitHub hält Copilot- und Agentenereignisse im Enterprise-Audit-Log 180 Tage vor, Git-Ereignisse wie Push oder Fetch dagegen sieben Tage. Für längere Aufbewahrungszeiträume müssen Teams die relevanten Daten selbst exportieren oder fortlaufend in ein eigenes System übertragen.

Das ist ein echter Zielkonflikt. Datenminimierung und Zero-Data-Retention, also der vertraglich zugesicherte Verzicht auf die reguläre Speicherung bestimmter Inhaltsdaten, verringern die Menge an Prompts und Quellcode, die bei Drittanbietern dauerhaft vorgehalten wird. Umfang, Metadaten und mögliche Ausnahmen hängen vom jeweiligen Anbieter und Vertrag ab. Gleichzeitig fällt damit ein möglicher Nachweis der Agentenbeteiligung weg. Die Lösung ist nicht, pauschal mehr beim Anbieter zu speichern. Sie besteht in einem bewusst ausgestalteten, eigenen Protokollierungskonzept: welche Metadaten gebraucht werden, wer darauf zugreifen darf, wie lange sie aufbewahrt werden und wie Quellcode und personenbezogene Daten geschützt bleiben.

Agentenbeteiligung gehört ins Postmortem, ersetzt aber keine Ursachenanalyse

Die Recherche für diesen Beitrag hat drei öffentlich zugängliche Sammlungen von Postmortem-Vorlagen und Leitfäden systematisch durchsucht: die PagerDuty Postmortem Docs, den Howie Guide und den Etsy Debriefing Facilitation Guide. Keines dieser Formate sieht ein eigenes Feld dafür vor, ob die auslösende Änderung ganz oder teilweise von einem Coding-Agenten stammt. Das ist kein Beleg dafür, dass kein Unternehmen intern solche Felder nutzt. Es zeigt nur, dass die verbreiteten öffentlich zugänglichen Vorlagen diesen Fall noch nicht abbilden.

Die Praxis schuldzuweisungsfreier, sogenannter blameless Postmortems hat einen operativen Grund. Angst vor persönlicher Bestrafung senkt die Bereitschaft, Annahmen, Abkürzungen und Unsicherheiten offenzulegen. PagerDuty schreibt, dass dieses Schweigen die Zeit bis zur Reaktion und Behebung verlängert. Das bedeutet nicht, Verantwortung, Regelverstöße oder Konsequenzen auszublenden. Ein verantwortungsbewusster, aber nicht vorschnell schuldzuweisender Ansatz kann benennen, wer welche Entscheidung getroffen hat und welche Vorgabe dabei verletzt wurde, ohne eine Person vorschnell zur alleinigen technischen Ursache zu machen.

Bei einer Änderung mit Agentenbeteiligung wird diese Trennung noch wichtiger. Der Agent trägt keine organisatorische Verantwortung. Verantwortlich bleiben die Personen und Organisationseinheiten, die Zugriffsrechte, Arbeitsauftrag, Review, Tests und Freigabe festgelegt haben. Aus der DORA-Taxonomie lässt sich deshalb für die interne Analyse eine nützlichere Frage ableiten: Welche vorgesehene Kontrolle hat die fehlerhafte Änderung nicht aufgehalten?

Ein Postmortem für einen Vorfall mit Agentenbeteiligung sollte die üblichen Abschnitte um fünf Angaben ergänzen:

1. Sicherheit der Zuordnung: Ist die Agentenbeteiligung belegt, nur behauptet oder unbekannt?
2. Betriebsmodus und verfügbare Spuren: In welchem Betriebsmodus lief der Agent: als IDE-Assistent, lokaler Agent oder Cloud-Agent? Welche Sitzungs-, Audit- und Repository-Daten lagen bei der Analyse noch vor?
3. Freigabekette: Wer hat die Änderung geprüft, welche Tests liefen und welches Artefakt wurde tatsächlich ausgerollt?
4. Kontrolle, die nicht gegriffen hat: Welche Kontrolle hätte den Fehler erkennen oder aufhalten sollen, und warum griff sie nicht?
5. Maßnahme und erwartete Wirkung: Was soll sich ändern, warum sollte diese Änderung wirken, wer ist dafür verantwortlich und bis wann wird sie überprüft?

Das Datenschutzverfahren im Fall InfoMentor zeigt, warum ein nachvollziehbarer Umsetzungsstatus und wirksame Kontrollen wichtiger sind als die Personenfrage. Ein Fix für eine bekannte Schwachstelle war im Ticket als abgeschlossen markiert, bevor er vollständig im System umgesetzt war. Die Aufsicht sah unzureichende Nachverfolgung und Tests. Für Änderungen mit Agentenbeteiligung gilt dieselbe Lehre. Das Werkzeug ersetzt keinen Testnachweis, und ein als erledigt markiertes Ticket ist kein Beleg für eine wirksame Änderung.

Die Prüftiefe sollte sich an der Tragweite der Änderung orientieren, nicht daran, wer sie erstellt hat. Eine Änderung an Berechtigungen, Datenmigrationen oder Zahlungslogik erfordert eine gründlichere Prüfung und eine andere Freigabe als eine Textkorrektur, unabhängig davon, ob sie von einem Menschen oder einem Agenten vorbereitet wurde. Wie sich diese Staffelung im Pull Request abbilden lässt, behandelt der Beitrag Der wahre Engpass sitzt im Pull Request.

Rechtlicher Ausblick: Welche Rolle die Nachweiskette im Produkthaftungsrecht spielen kann

Die technische Nachweiskette kann künftig auch haftungsrechtlich Gewicht bekommen. Die Produkthaftungsrichtlinie (EU) 2024/2853 führt einen gerichtlichen Offenlegungsmechanismus ein. Deutschland setzt ihn mit dem Entwurf eines neuen Produkthaftungsgesetzes um. Mit Stand vom 25. August 2026 hatte der Bundestag den Entwurf in erster Lesung beraten, der Rechtsausschuss hatte zudem eine Anhörung durchgeführt. Das geltende deutsche Produkthaftungsrecht enthält diese Regeln noch nicht, und auch die Paragrafennummern des Entwurfs können sich ändern.

Zu unterscheiden sind zwei Mechanismen.

Erstens kann ein Gericht nach Art. 9 der Richtlinie die Offenlegung relevanter Beweismittel anordnen, wenn ein Kläger seinen Anspruch ausreichend plausibel gemacht hat. Art. 10 Abs. 2 lit. a sieht bei unterlassener Offenlegung eine Fehlervermutung vor. Im deutschen Entwurf ist der Auslöser enger gefasst und setzt eine missachtete gerichtliche Anordnung voraus. Wer einer solchen gerichtlichen Anordnung nicht nachkommt, muss nach dem Entwurf mit dieser Fehlervermutung rechnen.

Zweitens sieht Art. 10 Abs. 2 lit. b eine Fehlervermutung bei einem Verstoß gegen verbindliche Produktsicherheitsanforderungen vor. Fehlende Aufzeichnungen können hier nur dann eine Rolle spielen, wenn eine andere Vorschrift die Aufzeichnung tatsächlich verlangt. Aus dem Produkthaftungsrecht selbst folgt keine allgemeine Pflicht, Agentenprompts, Commit-Trailer oder Sitzungsprotokolle zu speichern.

Der Mechanismus erfasst nur einen Ausschnitt der Schäden, die bei typischen Softwarevorfällen auftreten können. Anspruchsberechtigt sind natürliche Personen. Erfasst werden vor allem Personen- und bestimmte Sachschäden sowie der Verlust nicht beruflich genutzter Daten. Das verschuldensunabhängige Haftungsregime der Richtlinie erfasst reine Vermögensschäden wie entgangenen Umsatz oder Vertragsstrafen nicht. Vertragliche und deliktische Ansprüche aus anderen Rechtsgrundlagen bleiben davon unberührt. Wer bei KI-generiertem Code sonst noch einsteht und welche Rolle die Lizenzkette dabei spielt, ist im Beitrag zu Urheberrecht und KI-generiertem Code ausgeführt.

Ob Git-Historie, Review-Freigaben, Testnachweise und Agentenprotokolle im konkreten Verfahren relevante Beweismittel wären, ist offen. Diesen Zusammenhang leite ich hier aus technischer Sicht her, eine veröffentlichte deutsche Rechtsmeinung ist das nicht. Für Produkte, bei denen Personenschäden möglich sind, ist er dennoch praktisch relevant. Eine laufend dokumentierte Nachweiskette lässt sich später leichter offenlegen als eine Kette, die erst im Nachhinein rekonstruiert werden muss.

Letztlich bestimmen die Auswirkungen, ob und an wen ein Vorfall gemeldet werden muss. Dokumentierte Freigaben und gesicherte Spuren entscheiden darüber, ob die Aufarbeitung zu belastbaren Ergebnissen führt oder bei einer Vermutung über die Agentenbeteiligung stehen bleibt.

Quellen

• BaFin: Inhaltliche Hinweise DORA-Meldungen, Stand Mai 2026
• ESAs: 2025 Report on major ICT-related incidents
• BSIG: § 2 Begriffsbestimmungen und § 32 Meldepflichten
• Europäische Kommission: Durchführungsverordnung (EU) 2024/2690
• Europäische Kommission: Delegierte Verordnung (EU) 2025/301 und Durchführungsverordnung (EU) 2025/302 mit den DORA-Meldevorlagen
• EDSA: Leitlinien 9/2022 zur Meldung von Verletzungen des Schutzes personenbezogener Daten
• Autoriteit Persoonsgegevens: Bußgeld gegen Booking.com wegen verspäteter Meldung, im EDSA-Artikel-60-Register als EDPBI:NL:OSS:D:2020:173 geführt
• Persónuvernd: Entscheidung zum Sicherheitsvorfall bei InfoMentor ehf., Az. 2020010355
• GitHub: Agent-Sitzungen und Zuordnung von Commits, Commit-Signaturen und Audit-Logs
• Linux Kernel: coding-assistants.rst
• Microsoft: VS Code Issue 314311 zur fehlerhaft gesetzten Copilot-Zuordnung
• Anthropic: Claude Code Data usage und Settings reference
• Cursor: Compliance and Monitoring
• Europäische Union: Produkthaftungsrichtlinie (EU) 2024/2853
• Deutscher Bundestag: BT-Drs. 21/4297
• Git: git gc, Aufbewahrungsfristen des Reflogs
• PagerDuty: Postmortem Docs, Blameless Culture und Howie, The Post-Incident Guide
• Etsy: Debriefing Facilitation Guide
• Google: SRE Book, Postmortem Culture