Deutsche Bank: operative Resilienz mit agentischer KI

August 2026: Eine Bank verändert, wie sie ihre Widerstandsfähigkeit nachweist

Im August 2026 hat die Deutsche Bank ihre regulatorischen Resilienzübungen auf eine gemeinsam mit Google Cloud gebaute agentische Plattform verlagert. Die entscheidende Weichenstellung betrifft den Ankerpunkt: Die Agenten lesen die echten Abhängigkeiten der Produktion, statt von Annahmen auszugehen, die eine Expertenrunde von Hand aufgeschrieben hat.

Der Bericht stammt aus dem offiziellen Google-Cloud-Blog vom 18. August 2026^[1], verfasst von Pankaj Ojha, Director und Lead Architect der Agentic Resilience Platform der Deutschen Bank, gemeinsam mit Florian Graf von Google Cloud Consulting.

Jahrelang folgte das Tabletop im Bankwesen einem festen Ritual. Eine Gruppe von Spezialisten schreibt ein Krisenszenario, diskutiert es im Raum, erstellt ein Protokoll. Die Vorbereitung kostete Wochen manueller Arbeit und lieferte eine Momentaufnahme, die am Tag ihrer Entstehung stehen blieb.

Die beschriebene Verlagerung geht in eine andere Richtung: von der periodischen Übung zum Modell kontinuierlicher Intelligenz.

Die eigentliche Idee: erst der Kontext, dann das Modell

Der Kern des Projekts steckt in einem Satz des veröffentlichten Textes: Die Plattform baut den Unternehmenskontext aus Architektur, Datenflüssen, Logs, Incident-Historie, Alerting-Signalen und operativer Telemetrie auf.

Diese Reihenfolge ist entscheidend. Die Wahl des generativen Modells kommt danach, wenn das Material, über das nachgedacht werden soll, bereits existiert – und zwar in echter Form. Wer die beiden Schritte vertauscht, erhält ein elegantes Szenario, das eine erfundene Bank beschreibt.

Es ist die Lehre, die in vielen gelungenen Enterprise-Deployments wiederkehrt: Der Vorteil entsteht aus einer Architekturentscheidung, selten aus der Leistungsfähigkeit des gewählten Modells. Hier ist die Entscheidung das Grounding auf den operativen Signalen.

Ein Detail macht die Idee auch außerhalb des Perimeters eines globalen Bankkonzerns übertragbar. Logs, Tickets, Abhängigkeitskarten und Störungshistorien existieren in jeder Organisation mit einer IT-Abteilung – und liegen fast immer unangetastet im Archiv.

Was die Plattform tatsächlich produziert

Der Text nennt vier konkrete Outputs, alle auf den dokumentarischen Nachweis ausgerichtet.

• Szenarien, die auf den realen Abhängigkeiten der Systeme aufbauen
• simulierte Betriebsnachweise
• strukturierte Protokolle der Sitzungen
• aufsichtsfertige Artefakte

Das letzte Element verdient Aufmerksamkeit. Ein aufsichtsfertiges Artefakt ist so viel wert wie die Übung selbst, denn die europäische Aufsicht verlangt kohärente und wiederholbare Nachweise statt in Folien erklärter Absichten.

Die Szenarien kommen mit klaren Zeitachsen, Entscheidungspunkten und erwarteten Reaktionen – auch das gemäß der veröffentlichten Beschreibung. Der Unterschied zu früher liegt in der Kette: Jeder Schritt bleibt an ein beobachtetes Verhalten des Systems gebunden, damit der Nachweis vor einem Prüfer standhält.

Hier wird die Geschichte für alle interessant, die Produkt bauen. Dieselbe agentische Schicht wird auf die Root-Cause-Analyse ausgeweitet, wenn es um echten operativen Kontext zu einer tatsächlich eingetretenen Störung geht. Eine Engine, die zur Simulation hypothetischer Ausfälle entstand, funktioniert auch bei echten Ausfällen, weil das Ausgangsmaterial dasselbe ist.

DORA und das Gewicht des Nachweises

Der europäische Digital Operational Resilience Act hat die aufsichtlichen Erwartungen expliziter, harmonisierter und nachweisgestützter gemacht, wie der Text von Google Cloud in Erinnerung ruft.

Die Institute müssen belegen, dass kritische Dienste und digitale Infrastrukturen dem Druck standhalten, eine koordinierte Reaktion tragen und kontrolliert wieder in den Betrieb zurückkehren. Drei Verben und drei Fähigkeiten, die mit Dokumenten in der Hand zu beweisen sind.

Für eine Bank mit voneinander abhängigen Anwendungen, verflochtenen Datenflüssen und Drittanbietern stößt die manuelle Vorbereitung an eine physische Grenze. Die zu prüfenden Kombinationen wachsen schneller als die verfügbaren Stunden. An diesem Punkt hört die Automatisierung des Kontexts auf, Luxus zu sein.

Ein methodischer Punkt gehört festgehalten: Diese Geschichte handelt von Compliance und Engineering zugleich, und beide Ebenen stützen einander.

Der Reibungspunkt: doppelte Orchestrierung – und die fehlende Zahl

Jede belastbare Erfolgsgeschichte enthält eine Korrektur, diese zeigt gleich zwei.

Die erste steht im Text selbst: Die Plattform setzt auf eine doppelte Orchestrierung, gedacht, um Kontrolle und Flexibilität zusammenzuhalten. Eine Architektur mit zwei Modi entsteht fast immer aus einer Spannung, die im Feld aufgetreten ist – wenn sich ein einzelner Modus als zu starr oder als zu frei erweist.

Die zweite betrifft die kritische Lektüre des Materials. Der Bericht nennt eine Organisation, einen Architekten und einen klaren Perimeter, dennoch fehlt das Vorher/Nachher zu einer Kennzahl mit Nenner: eingesparte Vorbereitungsstunden, pro Quartal durchgeführte Übungen, vom Prüfer geschlossene Feststellungen.

Solange diese Angabe fehlt, bleibt es eine solide technische Ankündigung, weit entfernt von einer gemessenen Fallstudie. Ich schreibe das mit Respekt vor der beschriebenen Arbeit: Die Klarheit über den Perimeter ist bereits ein Zeichen operativer Reife.

Was sich für Entscheider ändert

Die Lesart ändert sich deutlich, je nachdem, welche Position man einnimmt.

• Gründer und Geschäftsführer im Mittelstand: Das übertragbare Playbook ist die geordnete Erfassung des Kontexts – vor den Agenten
• CTOs und Head of Product: Das Grounding auf Logs und Telemetrie ist der Teil, der in der Produktion trägt
• Aufsichtsrat und Investoren: Die Messlatte verschiebt sich auf den fortlaufenden dokumentarischen Nachweis, über die jährliche Übung hinaus
• Manager und Teamleads: Eine einzige Engine deckt Simulation und Ursachenanalyse ab

Für ein mittelständisches Unternehmen bleibt der Punkt konkret. Eine vollständige agentische Plattform liegt außer Reichweite, die Abhängigkeitskarte und die Incident-Historie lassen sich jedoch mit den Ressourcen eines kleinen Teams in Ordnung bringen. Diese Arbeit schafft für sich genommen Wert, noch vor jedem Agenten.

Wer die Technologie verantwortet, findet hier ein Einkaufskriterium: den Anbieter fragen, von welchen internen Signalen die Argumentation ausgeht und was es kostet, sie dorthin zu bringen.

Die MIT Sloan Management Review^[2] beschreibt den KI-Schub als fortlaufende Disruption, weit entfernt vom einmaligen Ereignis, das man einmal verkraftet. Eine Plattform, die die Szenarien bei jeder Architekturänderung neu erzeugt, antwortet genau auf diese Bedingung.

Was Sie aus dieser Geschichte mitnehmen können

Der erste Übertrag betrifft die Reihenfolge der Schritte. Zuerst wird der operative Kontext geordnet, dann wird das Modell gewählt. Die umgekehrte Abfolge erzeugt brillante Demos und nutzlose Protokolle.

Der zweite betrifft die Wiederverwendung. Eine Engine, die für eine regulatorische Pflicht gebaut wurde, hat ein zweites Leben in der Ursachenanalyse echter Störungen gefunden, und das verdoppelt den Ertrag bei gleicher Anfangsinvestition.

Der dritte betrifft die Ehrlichkeit der Zahlen. Ein Blogbeitrag, mitgezeichnet von denen, die die Plattform gebaut haben, zählt als direkte Zeugenaussage, die unabhängige Überprüfung bleibt ein nachgelagerter Schritt. Diginomica hat beschrieben^[3], wie selbst ein etablierter SaaS-Anbieter wie Canva den Kurs korrigieren musste, während er das Produkt an die KI anpasste: Korrekturen gehören zum Handwerk.

Der vierte betrifft die Zeit. Eine von Hand vorbereitete Krisenübung fotografiert das Unternehmen von vor sechs Monaten, während sich die Infrastruktur jede Woche verändert.

Die offene Frage

Es bleibt eine Frage, die für jede Organisation gilt, unabhängig von Branche und Größe: Wie viel von dem operativen Kontext, den Sie bereits besitzen, ist heute maschinenlesbar?

Logs, Abhängigkeitskarten, Störungshistorie, Telemetrie: Das Material existiert fast überall, verstreut über Systeme, die unterschiedliche Sprachen sprechen. Dort liegt der mühsame Teil, lange vor dem Agenten. Wer ihn jetzt angeht, ist vorbereitet, wenn die Aufsicht – oder der Kunde – den Nachweis verlangt.

Ich warte auf die erste veröffentlichte Zahl mit Vorher/Nachher. Wenn sie kommt, wird aus diesem Vorgang eine vollwertige Fallstudie.