Deutsche Bank: resilienza operativa con AI agentica

Agosto 2026, una banca cambia il modo di provare la propria tenuta

Nell'agosto 2026 Deutsche Bank ha portato i propri esercizi regolamentari di resilienza su una piattaforma agentica costruita con Google Cloud. La decisione distintiva riguarda il punto di aggancio: gli agenti leggono le dipendenze vere della produzione, anziché ipotesi scritte a mano da un gruppo di esperti.

Il racconto arriva dal blog ufficiale di Google Cloud del 18 agosto 2026^[1], firmato da Pankaj Ojha, Director e Lead Architect della Agentic Resilience Platform di Deutsche Bank, insieme a Florian Graf di Google Cloud Consulting.

Per anni il tabletop bancario ha seguito un rito preciso. Un gruppo di specialisti scrive uno scenario di crisi, lo discute in sala, produce un verbale. La preparazione costava settimane di lavoro manuale e restituiva una fotografia ferma al giorno in cui era stata scattata.

Lo spostamento descritto va in un'altra direzione: da esercizio periodico a modello di intelligenza continua.

L'idea originale: prima il contesto, poi il modello

Il cuore del progetto sta in una frase del testo pubblicato: la piattaforma costruisce il contesto aziendale a partire da architettura, flussi di dati, log, storico degli incidenti, segnali di alerting e telemetria operativa.

Questo ordine conta parecchio. La scelta del modello generativo arriva dopo, quando il materiale su cui ragionare esiste già ed è quello autentico. Chi inverte i due passaggi ottiene uno scenario elegante che descrive una banca immaginaria.

È la lezione che torna in molti deployment enterprise riusciti: il vantaggio nasce da una decisione architetturale, raramente dalla potenza del modello scelto. Qui la decisione è il grounding sui segnali operativi.

Un dettaglio rende l'idea replicabile anche fuori dal perimetro di un gruppo bancario globale. Log, ticket, mappe delle dipendenze e storico dei guasti esistono in qualunque organizzazione con un reparto IT, e restano quasi sempre fermi negli archivi.

Che cosa produce davvero la piattaforma

Il testo elenca quattro output concreti, tutti orientati alla prova documentale.

• scenari costruiti sulle dipendenze reali dei sistemi
• evidenze operative simulate
• verbali strutturati delle sessioni
• artefatti pronti per il regolatore

L'ultimo elemento merita attenzione. Un artefatto pronto per il regolatore vale quanto l'esercizio stesso, perché la vigilanza europea chiede prove coerenti e ripetibili, più che intenzioni dichiarate in slide.

Gli scenari arrivano con timeline chiare, punti di decisione e risposte attese, sempre secondo la descrizione pubblicata. La differenza rispetto al passato sta nella catena: ogni passaggio resta legato a un comportamento osservato del sistema, quindi l'evidenza si regge davanti a un ispettore.

Qui la storia diventa interessante per chi costruisce prodotto. Lo stesso strato agentico viene esteso alla root-cause analysis, quando serve contesto operativo reale su un guasto avvenuto davvero. Un motore nato per simulare guasti ipotetici funziona anche sui guasti autentici, perché il materiale di partenza coincide.

DORA e il peso dell'evidenza

Il Digital Operational Resilience Act europeo ha reso le attese di vigilanza più esplicite, armonizzate e fondate su prove, come ricorda il testo di Google Cloud.

Le istituzioni devono dimostrare che i servizi critici e le infrastrutture digitali reggono l'urto, sostengono una risposta coordinata e tornano operative in modo controllato. Tre verbi e tre capacità da provare con documenti alla mano.

Per una banca con applicazioni interdipendenti, flussi di dati e fornitori terzi intrecciati, la preparazione manuale incontra un limite fisico. Le combinazioni da provare crescono più in fretta delle ore disponibili. A quel punto l'automazione del contesto smette di essere un lusso.

Vale la pena fissare un punto di metodo: questa storia parla di conformità e di ingegneria insieme, e i due piani si sorreggono a vicenda.

Il punto di frizione: doppia orchestrazione, e il numero che manca

Ogni storia di successo verificata contiene una correzione, e questa ne mostra due.

La prima è dichiarata nel testo stesso: la piattaforma adotta una doppia orchestrazione, pensata per tenere insieme controllo e flessibilità. Un'architettura a due modalità nasce quasi sempre da una tensione emersa sul campo, quando una modalità singola si rivela troppo rigida oppure troppo libera.

La seconda riguarda la lettura critica del materiale. Il racconto porta un'organizzazione nominata, un architetto nominato e un perimetro chiaro, eppure manca il before/after su una metrica con denominatore: ore di preparazione risparmiate, esercizi eseguiti per trimestre, rilievi chiusi dall'ispettore.

Finché quel dato manca, resta un annuncio tecnico solido, distante da un caso di studio misurato. Lo scrivo con rispetto per il lavoro descritto: la chiarezza sul perimetro è già un segnale di maturità operativa.

Che cosa cambia per chi decide

La lettura cambia parecchio a seconda del posto che occupi.

• Founder e CEO di PMI: il playbook replicabile è la raccolta ordinata del contesto, prima degli agenti
• CTO e Head of Product: il grounding su log e telemetria è la parte che regge in produzione
• Board e investitori: l'asticella si sposta sulla prova documentale continua, oltre l'esercizio annuale
• Manager e team lead: un unico motore copre simulazione e analisi delle cause

Il punto per una media impresa resta concreto. Una piattaforma agentica completa sta fuori portata, mentre la mappa delle dipendenze e lo storico degli incidenti si mettono in ordine con le risorse di un team piccolo. Quel lavoro produce valore per conto proprio, anche prima di qualunque agente.

Chi guida la tecnologia trova qui un criterio di acquisto: chiedere al fornitore da quali segnali interni parte il ragionamento, e quanto costa portarceli.

La MIT Sloan Management Review^[2] descrive la spinta dell'AI come una disruption continua, lontana dall'evento singolo da assorbire una volta sola. Una piattaforma che rigenera gli scenari a ogni cambio di architettura risponde proprio a quella condizione.

Cosa puoi portare via da questa storia

Il primo trasferimento riguarda l'ordine delle mosse. Prima si mette in fila il contesto operativo, poi si sceglie il modello. La sequenza inversa produce demo brillanti e verbali inutili.

Il secondo riguarda il riuso. Un motore costruito per un obbligo regolamentare ha trovato una seconda vita sull'analisi delle cause dei guasti reali, e questo raddoppia il ritorno a parità di investimento iniziale.

Il terzo riguarda l'onestà dei numeri. Un blog co-firmato da chi ha costruito la piattaforma vale come testimonianza diretta, mentre la verifica indipendente resta un passaggio successivo. Diginomica ha raccontato^[3] come perfino un fornitore SaaS affermato come Canva abbia dovuto correggere la rotta mentre adattava il prodotto all'AI: le correzioni fanno parte del mestiere.

Il quarto riguarda il tempo. Un esercizio di crisi preparato a mano fotografa l'azienda di sei mesi fa, mentre l'infrastruttura cambia ogni settimana.

La domanda aperta

Resta una domanda valida per qualunque organizzazione, a prescindere da settore e dimensione: quanto del contesto operativo che già possiedi è leggibile da una macchina, oggi?

Log, mappe delle dipendenze, storico dei guasti, telemetria: il materiale esiste quasi ovunque, sparso tra sistemi che parlano linguaggi diversi. La parte faticosa sta lì, ben prima dell'agente. Chi la affronta adesso si trova pronto quando il regolatore, oppure il cliente, chiederà la prova.

Attendo il primo numero pubblicato con before/after. Quando arriverà, questa vicenda diventerà un caso di studio pieno.