Conto svuotato, banca responsabile per non aver implementato un sistema AI di “fraud detection”

Le banche italiane hanno comunicato l’innovazione digitale come se fosse un servizio. App intuitive, bonifici istantanei, assistenti virtuali 24 ore su 24. Il Giudice di Pace di Empoli, il 19 marzo 2026, ne ha condannata una per non aver usato l’intelligenza artificiale. Non per averla usata male. Non per averla usata in modo distorto. Per non averla usata affatto.

Un cliente si sveglia alla mattina. Il conto è stato svuotato di 2.700 euro mentre dormiva. Alle 4:46 del mattino un bonifico è partito verso un conto lituano intestato a uno sconosciuto. La banca - sapendo che c’era un malware, sapendo che l’operazione era anomala su ogni parametro immaginabile - non ha mosso un dito.

Questa è la notizia. Non il singolo rimborso da 2.700 euro. Non la piccola causa davanti a un giudice di pace toscano. La notizia è che un tribunale italiano ha formalmente richiesto a una banca la prova dell’esistenza di algoritmi di machine learning per il rilevamento delle transazioni anomale. E quando la prova non è arrivata, ha usato quell’assenza come elemento costitutivo della responsabilità civile. Il settore bancario ha due settimane per capire cosa significa. Dopo, sarà troppo tardi per fingere sorpresa.

Partiamo da ciò che è accaduto la notte del 2 maggio 2023. Un correntista - che chiameremo così, come la sentenza: semplicemente il ricorrente - viene infettato da un trojan bancario mascherato da aggiornamento di Google Chrome. Il malware assume il controllo del dispositivo mobile, intercetta le credenziali di accesso all’home banking e dispone un bonifico.

L’operazione fraudolenta aveva non uno, non due, ma cinque elementi che avrebbero dovuto far scattare qualsiasi sistema di sicurezza degno di questo nome:

1. ORARIO: ore 04:46 di mattina. Un orario statisticamente anomalo per qualsiasi operazione bancaria legittima.
2. BENEFICIARIO: mai utilizzato in precedenza come destinatario dal titolare del conto.
3. DESTINAZIONE: IBAN lituano. Un conto estero verso un paese che, secondo la Direttiva UE 2018/843, impone controlli antiriciclaggio rafforzati.
4. IMPORTO: 2.700 euro. Superiore alla soglia dei 1.000 euro che il Regolamento UE 2015/847 sui trasferimenti di fondi individua come soglia che richiede verifica rafforzata dell’identità del beneficiario.
5. CONTESTO: il malware aveva già assunto il controllo del dispositivo. Il sistema operava in un ambiente compromesso.

Cinque semafori rossi simultanei. Un sistema di fraud detection basato su machine learning - come quelli che ogni grande banca internazionale ha implementato da anni - avrebbe bloccato l’operazione automaticamente, o avrebbe almeno sospeso l’esecuzione in attesa di verifica.

La banca non ha fatto nulla. Il bonifico è partito.

Il Giudice di Pace, nella sentenza n. 32/2026, scrive con una chiarezza che raramente si riscontra in un documento giuridico: la banca “non ha fornito alcuna prova documentale dell’esistenza di sistemi automatizzati di rilevamento delle operazioni anomale, quali algoritmi di intelligenza artificiale o machine learning capaci di identificare transazioni sospette in base ai comportamenti abituali del cliente”.

Non mancano, quindi, le prove che l’AI funzionasse. Mancano le prove che esistesse.

Prima di arrivare all’AI, c’è una questione legale di base che merita di essere chiarita, perché è il fondamento su cui si regge tutta la sentenza.

Il D.Lgs. n. 11/2010, attuazione italiana della Direttiva PSD (Payment Services Directive) e modificato dal D.Lgs. 218/2017 che ha recepito PSD2, stabilisce una regola processuale di importanza capitale: quando un correntista nega di aver autorizzato un’operazione di pagamento, è la banca a dover dimostrare che l’operazione è stata autenticata, correttamente registrata e che il sistema non ha subito malfunzionamenti.

Questa inversione dell’onere della prova non è una novità giurisprudenziale creativa. È scritta nero su bianco nell’art. 10, comma 1, del decreto, nella versione più recente: cristallina, dice il giudice nella sentenza. E lo è davvero. La norma non lascia margini di interpretazione.

Eppure, la difesa della banca nel caso di Empoli è costruita esattamente all’inverso. Tenta sistematicamente di dimostrare che il cliente ha sbagliato qualcosa: ha navigato su un sito di streaming illegale, ha “consentito” l’installazione del malware, non ha verificato gli SMS alle 3:30 di notte, ha tardato due giorni prima di segnalare la frode.

Il giudice smonta ogni singolo argomento con una pazienza che sembra quasi ironica, considerando quanto siano deboli.

Il sito “illegale”: ipotesi della banca, non provata. Il nesso causale con il malware: non dimostrato, i trojan si diffondono attraverso decine di canali diversi. Il “consenso” all’installazione: il malware si presentava come aggiornamento di Google Chrome, l’app più diffusa al mondo. Non si chiama negligenza. Si chiama social engineering qualificato. Gli SMS alle 3:30 di notte: il giudice scrive che “pretendere che il cliente monitorasse il proprio smartphone alle ore 03:30 del mattino è una richiesta assurda e contraria al senso comune”. Il ritardo di due giorni: irrilevante, perché la frode si era già consumata interamente il 2 maggio.

La Cassazione, con l’ordinanza n. 29852/2023 e ancor più nettamente con la sentenza n. 3780 del 12 febbraio 2024, ha consolidato l’orientamento: la banca deve provare la riconducibilità dell’operazione alla volontà del cliente. Non basta produrre i log di sistema. Non basta mostrare che le credenziali erano quelle del correntista. Non basta l’SMS inviato. La prova deve essere positiva, non meramente tecnica.

Il colpo di grazia: la banca ammette che il suo sistema è stato aggirato

C’è un momento nella sentenza in cui il ragionamento del giudice diventa particolarmente tagliente. È il punto in cui analizza la difesa della banca nel merito tecnico.

La banca sostiene che il truffatore, tramite un’app terza, ha assunto il controllo del dispositivo del correntista e ha così carpito le credenziali di accesso all’home banking. Questa affermazione, scrive il giudice, “rappresenta una prova a favore del ricorrente”.

Perché? Perché se il sistema di Strong Customer Authentication (SCA) della banca ha consentito a un malware di operare liberamente usando le credenziali legittime - se un trojan bancario relativamente comune ha potuto aggirare la doppia autenticazione - allora quel sistema non era adeguato ai sensi della normativa vigente.

La giurisprudenza citata nella sentenza è uniforme: la Cassazione (n. 2950/2017, n. 10638/2016, n. 9158/2018, n. 26916/2020) ha ripetutamente affermato che la possibilità di utilizzo fraudolento dei codici di accesso da parte di terzi rientra nel rischio professionale del prestatore di servizi di pagamento. È prevedibile. È evitabile con misure adeguate. E quando non viene evitato, la responsabilità è dell’istituto, non del cliente.

La banca ha prodotto i log informatici e gli SMS di avviso. Ha ritenuto che questi fossero sufficienti. Il giudice ha risposto con due argomenti che annullano entrambe le difese in modo definitivo.

I log dimostrano solo che l’operazione è stata eseguita usando le credenziali del correntista. Ma questo è esattamente ciò che accade in ogni frode basata su malware: il truffatore usa le credenziali legittime, fa apparire l’operazione come autorizzata. Il log non distingue tra un cliente che dispone un bonifico e un malware che lo dispone a suo nome.

Gli SMS, poi, erano inutili per una ragione tecnica che la stessa banca avrebbe dovuto considerare: il malware controllava il telefono. Controllava le notifiche. Poteva intercettarle, nasconderle, approvarle autonomamente. E anche prescindendo da questo, erano stati inviati nel cuore della notte.

Arriviamo al cuore del problema. Al punto che trasforma questa sentenza da semplice precedente in segnale sistemico per il settore bancario.

Il giudice non si limita a dire che la banca non ha dimostrato di aver adottato misure di sicurezza adeguate in astratto. Individua specificatamente cosa mancava: algoritmi di intelligenza artificiale e machine learning per il rilevamento delle transazioni anomale basato sui comportamenti abituali del cliente.

Questo è un elemento nuovo nella giurisprudenza italiana. Non nuovissimo - la sentenza cita Trib. Milano n. 5967/2022 e Trib. Roma n. 16478/2022 per l’obbligo di monitorare l’operatività dei conti e bloccare le operazioni anomale. Ma il riferimento esplicito all’AI e al machine learning come tecnologie attese come standard di diligenza è una svolta.

Questa non è un’operazione mediatica. Non è il solito «le banche devono fare di più». È una lettura giuridica precisa di cosa significhi «misure di sicurezza adeguate» nel 2026, con un caso concreto, cinque red flags conclamati e un bonifico partito alle 4:46 del mattino verso la Lituania.

La logica è impeccabile. Se un sistema di fraud detection basato su ML è già in uso presso le principali banche internazionali - e lo è, ampiamente, da anni - allora la sua assenza non è più una scelta tecnologica neutrale. È una scelta di non investire in sicurezza. E quando quella scelta produce un danno verificabile, la responsabilità civile consegue.

Il problema non è solo tecnico. È di governance. Quante banche italiane hanno implementato sistemi di questo tipo? Quante si sono fermate all’autenticazione forte come requisito PSD2 e hanno ritenuto di aver soddisfatto il loro obbligo di sicurezza? Quante si fidano ancora dell’SMS come strumento di difesa sufficiente contro i trojan bancari moderni?

Per contestualizzare: i trojan bancari di nuova generazione non si limitano a rubare credenziali. Intercettano i token OTP in tempo reale, manipolano le notifiche push, reindirizzano le sessioni di home banking su server controllati dagli attaccanti. Contro questi strumenti, l’SMS alert è il equivalente di mettere un cartello “vietato rubare” davanti a una cassaforte aperta.

La normativa antiriciclaggio: il livello di obbligo che nessuno menziona

C’è un altro piano della sentenza che merita attenzione, perché raramente viene portato al centro del dibattito sulle frodi bancarie digitali.

Il bonifico era diretto verso un conto lituano intestato a un beneficiario sconosciuto. L’importo era di 2.700 euro. Queste due caratteristiche, combinate, attivano obblighi normativi specifici che vanno ben oltre il D.Lgs. 11/2010.

La Direttiva UE 2018/843 (Quinta Direttiva Antiriciclaggio) impone agli intermediari finanziari controlli rafforzati per le transazioni ad alto rischio. I bonifici verso beneficiari nuovi e sconosciuti, verso paesi stranieri e per importi superiori a determinate soglie rientrano esplicitamente in questa categoria.

Il Regolamento UE 2015/847 sui trasferimenti di fondi, all’art. 7, stabilisce che per trasferimenti superiori a 1.000 euro il prestatore di servizi di pagamento del beneficiario deve verificare l’accuratezza dei dati informativi basandosi su documenti ottenuti da fonte affidabile. Nel caso di specie, non risulta che sia stata effettuata alcuna verifica aggiuntiva.

Questo apre una prospettiva più ampia. La sentenza di Empoli non è solo un caso di frode informatica e responsabilità bancaria per mancato presidio tecnologico. È anche un caso di inadempimento agli obblighi di adeguata verifica rafforzata imposti dal diritto europeo. Due livelli di responsabilità sovrapposti. Entrambi a carico dell’istituto.

La banca ha prodotto prove di aver inviato notifiche push e SMS alert al cliente alle ore 03:30, 04:46 e 05:02 del 2 maggio 2023. Ha poi argomentato che il cliente “avrebbe potuto bloccare l’operazione se avesse prestato attenzione a tali comunicazioni”.

Elaboriamo. La banca sa che il cliente è vittima di una frode informatica. Sa che un malware controllava il dispositivo del cliente. Sa che quel malware poteva intercettare le notifiche. E costruisce una linea difensiva che si fonda sul presupposto che il cliente avrebbe dovuto svegliarsi alle 3:30 di notte, controllare il telefono, leggere l’SMS e bloccare il bonifico.

Il giudice risponde con una frase che meriterebbe di essere incorniciata in ogni ufficio compliance di ogni banca italiana: “Pretendere che il cliente monitorasse il proprio smartphone alle ore 03:30 del mattino è una richiesta assurda e contraria al senso comune”.

C’è qualcosa di rivelatore nella scelta di questa strategia difensiva. Non è un errore. È una scelta consapevole. Addossare la colpa al cliente, costruire una narrativa di negligenza del correntista, è la risposta standard del settore bancario italiano a questi casi. Ha funzionato per anni, in parte perché i clienti non sapevano della norma sull’inversione dell’onere della prova, in parte perché i giudici non sempre avevano la preparazione tecnica per valutare le argomentazioni sul funzionamento dei sistemi di sicurezza.

Ora la situazione sta cambiando. La Cassazione si è espressa. I tribunali di merito si sono espressi. E un giudice di pace di una città toscana di medie dimensioni ha scritto una sentenza che dimostra una comprensione del funzionamento dei trojan bancari, dei limiti dell’autenticazione forte, delle aspettative di comportamento di un utente medio, e delle implicazioni dei sistemi di machine learning per il fraud detection che molti direttori IT bancari farebbero bene a leggere con attenzione.

La sentenza n. 32/2026 non è definitiva. Il Giudice di Pace si pronuncia in primo grado. La banca può impugnare. La giurisprudenza si consolida attraverso anni di pronunce, non attraverso una singola sentenza.

Ma il segnale è chiarissimo.

Per le banche, l’implicazione più immediata riguarda il profilo probatorio. Non basta più produrre log e SMS per difendersi in un contenzioso su operazioni non autorizzate. Serve dimostrare positivamente di aver implementato misure di sicurezza adeguate al livello di rischio attuale. Questo include - e la sentenza lo dice esplicitamente - sistemi di rilevamento anomalie basati sull’analisi comportamentale del cliente.

Per il settore nel suo complesso, si apre una questione di compliance che va ben oltre i singoli casi. Quante banche sono oggi in grado di produrre quella prova? Quante hanno documentato l’architettura dei propri sistemi antifrode in modo da renderla disponibile in un contenzioso civile? Quante possono dimostrare che i loro algoritmi di fraud detection avrebbero rilevato - o avrebbero dovuto rilevare - una transazione con le caratteristiche di quella del 2 maggio 2023?

Per inciso: il fatto che la banca non abbia contestato nella propria comparsa di risposta le violazioni GDPR (artt. 32 e 34) ha portato il giudice a ritenere configurata anche la responsabilità ai sensi del Regolamento 2016/679. Sottrazione di credenziali e dati personali del cliente da parte di terzi non autorizzati, mancata comunicazione della violazione all’interessato. Due ulteriori livelli di inadempimento non contestati, e quindi impliciti nella condanna.

Per i correntisti, il messaggio è più semplice: la legge è dalla vostra parte, ma solo se sapete come usarla. L’inversione dell’onere della prova esiste da quando il D.Lgs. 11/2010 è entrato in vigore. La maggior parte dei correntisti che hanno perso denaro per frodi informatiche non lo sapeva, o ha rinunciato a procedere. Molti istituti hanno contato su questa ignoranza.

La sentenza di Empoli è anche questo: un’istruzione d’uso per chi si trovasse nella stessa situazione. Disconoscete l’operazione. Chiedete alla banca di dimostrare l’autorizzazione. Chiedete prova dell’adeguatezza dei sistemi di sicurezza. Chiedete documenti sui sistemi di rilevamento anomalie. Se non arrivano, la strada processuale è quella percorsa dal ricorrente di questa storia.

C’è un’ironia strutturale in questa vicenda che vale la pena nominare esplicitamente.

Negli ultimi tre anni, il settore bancario italiano e internazionale ha investito enormi risorse comunicative per raccontare la propria trasformazione digitale guidata dall’intelligenza artificiale. Chatbot per il customer service. Sistemi di scoring del credito. Assistenti virtuali per la consulenza finanziaria. Algoritmi per la personalizzazione dei prodotti. L’AI è ovunque, nelle comunicazioni commerciali delle banche.

Poi un giudice di pace chiede: «Mostratemi l’AI che usa per bloccare le frodi». Silenzio.

Non è solo un’osservazione morale. È una scelta allocativa precisa. I sistemi di fraud detection basati su ML richiedono investimenti significativi in infrastruttura, dati e competenze. Producono valore per il cliente, non per la banca - anzi, in alcuni casi riducono i volumi di transazione fermando operazioni che poi si rivelano legittime. Il chatbot di customer service, invece, riduce i costi operativi e ha un impatto direttamente misurabile sul conto economico.

È la logica dell’ottimizzazione a breve termine applicata alla sicurezza. Funziona finché non arriva una sentenza a dirti che l’assenza di quel sistema è ora responsabilità civile.

La domanda che dovrebbe tenere svegli i CTO e i chief risk officer bancari non è se adeguarsi alla sentenza di Empoli. È questa: quante altre sentenze simili stanno per arrivare? Quanti contenziosi aperti nei tribunali italiani, in questo momento, hanno come elemento centrale proprio quel vuoto probatorio - l’impossibilità di dimostrare l’esistenza di sistemi adeguati?

La sentenza n. 32/2026 apre una questione che non chiude. Che cosa, esattamente, costituisce un sistema di fraud detection «adeguato» ai fini della normativa vigente? Chi stabilisce lo standard?

Il giudice di Empoli identifica il machine learning come aspettativa implicita. Ma il diritto bancario italiano e europeo non prescrive architetture tecnologiche specifiche. L’art. 10 del D.Lgs. 11/2010 parla di «misure di sicurezza adeguate». La PSD2 parla di «autenticazione forte». Il GDPR parla di «misure tecniche e organizzative adeguate». Nessuna di queste norme dice: «dovete usare un modello di anomaly detection basato su LSTM o isolation forest».

Questo significa che lo standard verrà costruito caso per caso, dalla giurisprudenza, in dialogo con l’evoluzione tecnologica. Una banca che oggi implementa un sistema di ML rudimentale non sarà al riparo dalla prossima sentenza se quel sistema si rivela insufficiente rispetto alle tecniche di attacco disponibili nel 2026. Lo standard si muove. La responsabilità civile segue.

Il settore ha forse un anno o due prima che questo filone giurisprudenziale si consolidi in modo sufficientemente uniforme da rendere sistematica la perdita dei contenziosi per le banche prive di documentazione adeguata. In quel periodo, chi si attrezza - e chi sa documentare ciò che ha - avrà un vantaggio difensivo significativo.

Chi continuerà a gestire questi casi con log e SMS, sperando che il correntista non sappia dell’inversione dell’onere della prova, si troverà nella posizione della banca di Empoli.

Con una sentenza di condanna firmata il 18 marzo 2026. Che è diventata pubblica il 19. Che viene commentata oggi

La prossima settimana andremo più a fondo su un aspetto che questa sentenza lascia volutamente aperto: cosa succede quando la banca ha un sistema AI antifrode, ma quel sistema ha classificato erroneamente l’operazione come legittima? Chi risponde allora? L’istituto, il fornitore del sistema, o si configura una forma di responsabilità condivisa?

Perché le banche che si adeguano alla sentenza di Empoli implementando sistemi di ML si troveranno presto di fronte a quella domanda. E la risposta non è ancora scritta da nessuna parte.

________

*Avv. Alberto Bozzo, DPO e CAIO, Referente Enia per la Regione Veneto