DORAs Durchsetzungsphase will Nachweise, keine Policy-PDFs.
Den größten Teil ihrer frühen Zeit belohnte die Compliance im Finanzsektor gute Dokumentation. Sie schrieben die Policy, mappten die Controls, hielten den Ordner aktuell, und wenn die Aufsicht kam, übergaben Sie einen gut sortierten Satz PDFs. Das Dokument war das Ergebnis. Eine Organisation, die ihre Resilienz überzeugend beschreiben konnte, war für regulatorische Zwecke resilient.
Nur schließt sich diese Ära. DORA, die EU-Verordnung über die digitale operationale Resilienz, gilt seit dem 17. Januar 2025, und 2026 trat sie in ihre Durchsetzungsphase ein. Wie die Dawiso-Analyse zu KI-Agenten im Bankwesen unter DORA berichtet, und wie die Berichterstattung von Auriga und ATM Marketplace zur KI-Governance für Finanzinstitute bestätigt, haben Aufseher geändert, was sie akzeptieren. Sie sind davon abgerückt, Policy-Dokumente für bare Münze zu nehmen, und erwarten datengestützte Resilienznachweise. Der Ordner ist nicht mehr das Ergebnis. Der Beweis ist es.
Diese Verschiebung trifft genau die Systeme am härtesten, die Banken jetzt eilig ausrollen. Denn ein Policy-PDF, das beschreibt, wie Ihre Agenten sich verhalten, und eine Nachweisspur, die belegt, wie sie sich verhielten, sind zwei völlig verschiedene Artefakte, und nur das zweite übersteht eine Prüfung in der Durchsetzungsphase.
Die Lücke, die die Durchsetzungsphase offenlegt
Eine Policy ist eine Beschreibung beabsichtigten Verhaltens. Ein Nachweis ist eine Aufzeichnung tatsächlichen Verhaltens. In der Welt vor der Durchsetzung konnten sie füreinander einstehen, weil niemand das zweite gegen das erste prüfte. Die Durchsetzungsphase beendet diese Ersetzung.
Warum das jetzt zählt und nicht vor fünf Jahren, liegt an dem, was Banken ausrollen. Die Dawiso-Berichterstattung prognostiziert, dass 2026 rund 44 % der Finanzteams agentische KI nutzen werden, ein großer Sprung. Das ist die Kollision im Zentrum dieser Geschichte. Ein Aufsichtsregime, das gerade begonnen hat, Nachweise tatsächlichen Verhaltens zu verlangen, trifft auf eine Welle von Systemen, deren tatsächliches Verhalten probabilistisch ist, sich mit jedem Modell-Update ändert und in den meisten Deployments kaum aufgezeichnet wird.
Die dort benannten Risiken sind konkret und nicht abstrakt. Unkontrollierter Agentenzugriff auf interne Systeme. Unzureichendes Logging, das die Rekonstruktion von Vorfällen unmöglich macht. Lesen Sie beides zusammen, und Sie haben genau den Fehlermodus, den DORAs Durchsetzungsphase fangen soll: ein System, das auf Ihren Kernplattformen handeln kann und hinterher nicht sagen kann, was es tat und warum. Das Policy-PDF sagte, es sei governt. Die Prüfung verlangt den Beweis, und es gibt nichts zu zeigen.
Ein Agent, der nicht rekonstruieren kann, was er tat, besteht keine DORA-Prüfung
Das ist der Satz zum Verinnerlichen, denn er verwandelt eine vage Compliance-Sorge in eine konkrete Architekturanforderung.
DORAs Resilienzerwartungen setzen voraus, dass Sie rekonstruieren können, wenn etwas schiefgeht. Vorfallmeldung, Ursachenanalyse und die gesamte Resilienzhaltung ruhen auf der Fähigkeit, im Nachhinein zu beantworten, was geschah, in welcher Reihenfolge und auf welcher Grundlage. Für deterministische Software ist das gelöst: Die Logs sind die Geschichte, und der Code, der sie erzeugte, ändert sich zwischen Vorfall und Untersuchung nicht.
Ein Agent bricht diese Annahme zweifach. Erstens handelt er auf lebendem Kontext und denkt probabilistisch, "was hätte er getan" ist also durch erneutes Ausführen des Codes nicht wiederherstellbar. Zweitens ist bei unzureichendem Logging, wie die Berichterstattung es ausdrücklich benennt, selbst "was hat er tatsächlich getan" nicht wiederherstellbar. Ein Agent, der eine Akte las, darüber nachdachte und eine Entscheidung ablegte, aber keine prüfbare Aufzeichnung der gesehenen Eingaben, der angewandten Policy und des gefällten Verdikts hinterließ, hat ein Ergebnis erzeugt, das niemand rekonstruieren kann.
Unter dem alten Regime war das überlebbar, weil Sie auf die Policy zeigen konnten. Unter Durchsetzung ist es disqualifizierend. Ein Agent, dessen Entscheidungen nicht rekonstruierbar sind, kann nicht als resilient gezeigt werden, und ein System, das nicht als resilient gezeigt werden kann, besteht nicht. Das Fehlen von Nachweisen ist keine Dokumentationslücke, die man später schließt. Es ist ein dauerhaftes Loch, denn Sie können Entscheidungen, die das System bereits ohne Aufzeichnung traf, nicht rückwirkend festhalten.
Compliance als ausführbare Policy, Nachweis als Nebenprodukt
Der Ausweg ist kein besseres Policy-PDF. Es ist eine Architektur, in der die Policy ausführbar ist und der Nachweis automatisch entsteht, als Bedingung dafür, dass das System überhaupt läuft.
Zwei Eigenschaften leisten die Arbeit, und sie entsprechen direkt dem, was "Nachweise, keine Policies" verlangt.
Compliance als ausführbare Policy. Statt eines Dokuments, das die Regeln beschreibt, sind die Regeln Code, der Ihrem Compliance-Team gehört, den es versioniert und signiert und der im Moment jeder Entscheidung ausgewertet wird. Jede folgenschwere Aktion läuft durch einen Policy-Entscheidungspunkt, der ein maschinenlesbares Verdikt zurückgibt: erlauben, unter dokumentierten Auflagen erlauben, verweigern oder einen Menschen verlangen. Das nicht delegierbare regulatorische Gewicht löst sich per Policy zu einer Person auf; der Agent analysiert nur. Die Policy ist keine Behauptung über Verhalten mehr. Sie ist der Mechanismus, der das Verhalten erzeugt, und sie lässt sich testen, neu freigeben und belegen.
Eine append-only, hash-verkettete Nachweisspur. Jede Entscheidung schreibt eine unveränderliche Aufzeichnung, bevor sie bindend wird, über die vom Agenten gesehenen Eingaben, die Policy-Version, gegen die er lief, und das gefällte Verdikt. Die Hash-Verkettung macht die Spur manipulationssichtbar: Sie können nicht nur beweisen, was geschah, sondern dass die Aufzeichnung nicht nachträglich verändert wurde. Und sie schlägt geschlossen fehl. Kein Nachweisspeicher, keine Entscheidung. Das System kann physisch nicht handeln, ohne die Aufzeichnung zu hinterlassen, nach der eine Aufsicht fragen wird.
Zusammengenommen hört Rekonstruktion auf, eine Hoffnung zu sein, und wird eine Abfrage. Kommt die Frage der Durchsetzungsphase, was dieser Agent tat, auf welcher Grundlage und ob Sie belegen können, dass die Aufzeichnung intakt ist, ist die Antwort ein Report, den Sie fahren, keine Untersuchung, die Sie starten. Der Nachweis existiert, weil die Architektur die Entscheidung nicht hätte erzeugen können, ohne ihn zu erstellen.
Das ist der Unterschied zwischen Resilienz beschreiben und sie zeigen, und genau diesen Unterschied soll DORAs Durchsetzungsphase prüfen.
Die Umdeutung
Die Frage, die Banken noch stellen und die einen weiteren Ordner erzeugt, lautet "haben wir eine Policy, die unsere KI-Agenten abdeckt?". In der Durchsetzungsphase beantwortet diese Frage eine Prüfung, die niemand mehr abnimmt. Die Policy zu haben ist die Eintrittskarte. Das Verhalten zu belegen ist die Prüfung.
Die bessere Frage lautet: wenn eine Aufsicht uns bittet, exakt zu rekonstruieren, was einer unserer Agenten tat, auf welchen Daten, unter welcher Regel, und zu belegen, dass die Aufzeichnung unberührt ist, können wir das als Report fahren, oder müssen wir einräumen, dass wir es nicht erfasst haben? Lautet die ehrliche Antwort Letzteres, schließt kein Policy-PDF die Lücke, denn die Lücke liegt nicht in Ihrer Dokumentation. Sie liegt in Ihrer Architektur, und die Durchsetzungsphase liest Architektur, nicht Absichten.
Die Aufseher haben geändert, was sie akzeptieren. Die ausgerollten Systeme haben die Änderung dringend gemacht. Und die Organisationen, die die Nachweisspur in den Agenten bauen, statt eine Policy darüber zu schreiben, sind die einzigen, die die Prüfung bestehen, der sie nun sicher begegnen.
Wenn Sie prüfen wollen, ob Ihre agentischen Prozesse eine Rekonstruktion liefern könnten, die eine DORA-Aufsicht akzeptiert, buchen Sie einen Termin und bringen Sie uns den mit, der die meisten internen Systeme berührt.