Una banca utilizza un sistema antifrode evoluto. Il motore analizza un bonifico, attribuisce all’operazione un punteggio di rischio e non rileva anomalie sufficienti per bloccarla. Successivamente il correntista disconosce il pagamento: il sistema c’era, ma ha prodotto un falso negativo. Chi risponde del danno?

La domanda è attuale, ma rischia di essere affrontata in modo fuorviante se si attribuisce all’AI Act una funzione che il regolamento europeo non possiede. Il Regolamento (UE) 2024/1689 disciplina requisiti e obblighi relativi a determinati sistemi di intelligenza artificiale; non costituisce, però, la fonte principale per stabilire chi debba sopportare la perdita derivante da un bonifico fraudolento.

In questa materia continuano a essere centrali la disciplina dei servizi di pagamento, il riparto dell’onere probatorio previsto dal D.Lgs. n. 11/2010, gli standard tecnici sull’autenticazione e sul monitoraggio delle operazioni, la responsabilità contrattuale dell’intermediario, il DORA e, quando ne ricorrono effettivamente i presupposti, il GDPR.

Il vero problema, dunque, non è soltanto individuare il soggetto astrattamente responsabile. È comprendere quale prova tecnica debba essere prodotta per ricostruire il funzionamento del sistema antifrode nel caso concreto.

Il caso di Empoli: una pronuncia importante, ma da leggere con cautela

Il dibattito è stato riacceso dalla sentenza n. 32/2026 del Giudice di Pace di Empoli, relativa a un bonifico di 2.700 euro eseguito alle ore 4:46 verso un conto lituano e disconosciuto dal correntista. Secondo la ricostruzione riportata nelle fonti disponibili, il dispositivo del cliente sarebbe stato compromesso da un trojan bancario mascherato da aggiornamento di Google Chrome.

La banca aveva prodotto tracciature informatiche e notifiche relative all’operazione, ma il giudice ha ritenuto che la mera regolarità formale dell’impiego delle credenziali non dimostrasse né l’effettiva autorizzazione del cliente né la sua colpa grave. È stato inoltre valorizzato il fatto che l’intermediario non avesse fornito prova documentale dell’esistenza di sistemi automatizzati capaci di rilevare l’anomalia dell’operazione.

La decisione è interessante, ma occorre precisarne la portata. Si tratta di una pronuncia di primo grado resa da un giudice di pace e non di un orientamento consolidato. Soprattutto, la normativa europea non impone alla banca di adottare necessariamente un sistema di intelligenza artificiale o di machine learning.

Il Regolamento delegato (UE) 2018/389 impone ai prestatori di servizi di pagamento di disporre di meccanismi di monitoraggio idonei a individuare operazioni non autorizzate o fraudolente. Tali meccanismi devono considerare almeno l’importo, gli scenari di frode noti, gli elementi di autenticazione compromessi, i segni di infezione da malware e l’uso anomalo del dispositivo o del software.

La regola, quindi, è tecnologicamente neutra. Un sistema basato su regole deterministiche, se realmente efficace e aggiornato, può in astratto soddisfare l’obbligo; un sofisticato modello di machine learning, se mal configurato o privo delle variabili essenziali, può invece risultare inadeguato. Non è il nome della tecnologia a dimostrare la conformità, ma la capacità del presidio di rilevare e gestire i rischi concretamente prevedibili.

Prima distinzione: operazione non autorizzata e frode da manipolazione del pagatore

Prima di discutere di algoritmi è necessario qualificare correttamente il fatto. Non tutte le frodi mediante bonifico appartengono alla stessa categoria.

Nell’operazione non autorizzata il cliente nega di avere impartito l’ordine: le credenziali possono essere state sottratte, il dispositivo può essere stato controllato da remoto oppure l’operazione può essere stata generata attraverso una sessione compromessa.

Nella frode da manipolazione del pagatore, invece, il cliente dispone personalmente il bonifico, ma lo fa perché ingannato da un falso operatore, da un messaggio contraffatto o da un’altra tecnica di ingegneria sociale. In questo secondo scenario l’operazione può risultare formalmente autorizzata, pur essendo economicamente riconducibile a una frode.

La differenza è decisiva. Come rilevato dalla Banca d’Italia nel Rapporto sulle operazioni di pagamento fraudolente, le frodi da manipolazione del pagatore possono superare anche l’autenticazione forte e non attivano automaticamente lo stesso regime di rimborso previsto per le operazioni non autorizzate.

Affermare in termini generali che la banca risponda “sempre” sarebbe quindi impreciso. Il regime varia in relazione alla natura dell’operazione, all’effettiva autorizzazione, alla condotta del cliente, alla presenza di dolo o colpa grave e al nesso causale tra l’eventuale carenza del presidio antifrode e il danno.

Chi risponde verso il correntista nelle operazioni non autorizzate

Quando il cliente disconosce un’operazione, l’art. 10 del D.Lgs. n. 11/2010 pone sul prestatore di servizi di pagamento l’onere di dimostrare che il pagamento sia stato autenticato, correttamente registrato e contabilizzato e che non abbia subito malfunzionamenti o altri inconvenienti.

La Comunicazione della Banca d’Italia del 17 giugno 2024 chiarisce che, se l’intermediario non richiede l’autenticazione forte o non riesce a dimostrarne l’impiego, il rimborso deve normalmente essere riconosciuto, salvo il comportamento fraudolento del cliente. Anche quando la Strong Customer Authentication è stata correttamente applicata, l’intermediario deve comunque valutare in concreto l’eventuale dolo o colpa grave dell’utente.

La produzione del log che attesta l’uso di due fattori di autenticazione, pertanto, non esaurisce necessariamente la prova. Quel dato può dimostrare che il sistema abbia ricevuto credenziali formalmente valide, ma non identifica automaticamente la persona che le ha materialmente utilizzate e non prova, da solo, la consapevole volontà del correntista.

Nei confronti del cliente, inoltre, il ricorso a un fornitore esterno non trasferisce la responsabilità. L’art. 1228 c.c. imputa al debitore anche il fatto degli ausiliari impiegati nell’adempimento. Sul piano regolamentare, l’art. 28 DORA stabilisce che le entità finanziarie che utilizzano servizi TIC di terzi restano pienamente responsabili del rispetto degli obblighi applicabili.

Ciò non significa, tuttavia, che ogni perdita debba essere automaticamente accollata alla banca. L’intermediario può opporre e provare, secondo i presupposti di legge, il comportamento fraudolento del cliente o la sua colpa grave. Il punto è che tali circostanze non possono essere desunte dalla sola avvenuta autenticazione né dalla generica affermazione che il dispositivo dell’utente fosse compromesso.

Il GDPR non crea una responsabilità automatica aggiuntiva

Nel dibattito viene spesso richiamato anche l’art. 82 GDPR. Il riferimento è corretto soltanto se il danno deriva da un trattamento di dati personali contrario al regolamento: ad esempio, da misure di sicurezza inadeguate, da un accesso illecito o da una violazione dei principi applicabili al trattamento.

Non ogni falso negativo del sistema antifrode integra, di per sé, una violazione del GDPR. La Corte di giustizia, nella causa C-300/21, ha chiarito che il diritto al risarcimento richiede tre condizioni cumulative: violazione del regolamento, danno e nesso causale.

L’art. 82 GDPR non può quindi essere utilizzato come una clausola generale che si aggiunge automaticamente alla responsabilità bancaria. Occorre individuare la specifica violazione in materia di protezione dei dati e dimostrare che proprio da essa sia derivato il pregiudizio lamentato.

Che cosa esclude davvero l’AI Act

L’Allegato III, punto 5, lettera b), dell’AI Act considera ad alto rischio i sistemi destinati a valutare l’affidabilità creditizia delle persone fisiche o a stabilirne il merito di credito, ma esclude espressamente i sistemi utilizzati per individuare frodi finanziarie.

La conseguenza è rilevante: per il solo fatto di svolgere una funzione di fraud detection, il sistema non ricade nel pacchetto di obblighi previsto per i sistemi ad alto rischio dell’Allegato III. Non si applicano, in quanto tali, i requisiti rafforzati sulla gestione del rischio, sulla governance dei dati, sulla documentazione tecnica, sulla conservazione automatica dei log, sulla sorveglianza umana, sull’accuratezza e sulla robustezza previsti dagli artt. 8-15.

Non opera neppure il diritto alla spiegazione dell’art. 86, riservato alle decisioni basate sull’output di sistemi ad alto rischio elencati nell’Allegato III e capaci di produrre effetti giuridici o analogamente significativi.

Questa esclusione non significa però che l’AI Act diventi completamente irrilevante. Restano applicabili gli obblighi generali compatibili con la concreta architettura e con l’uso del sistema. Tra questi assume rilievo l’art. 4 sull’alfabetizzazione in materia di IA, modificato dal Regolamento (UE) 2026/1744: fornitori e deployer devono adottare misure volte a sostenere lo sviluppo delle competenze del personale che utilizza il sistema.

L’Omnibus digitale sull’IA ha inoltre differito al 2 dicembre 2027 l’applicazione delle regole relative ai sistemi ad alto rischio dell’Allegato III, senza eliminare l’eccezione per il fraud detection finanziario.

Occorre poi verificare la finalità effettiva del sistema. Se il medesimo motore non si limita a individuare frodi, ma alimenta anche il merito creditizio, l’accesso a servizi finanziari o altre decisioni ricomprese nell’Allegato III, la classificazione non può essere risolta richiamando automaticamente l’eccezione antifrode. Deve essere esaminata la finalità prevista di ciascun componente e l’uso concreto dell’output.

Vi è infine un’ulteriore questione preliminare: non ogni software antifrode è un sistema di IA ai sensi del regolamento. Un motore composto esclusivamente da regole definite dall’uomo potrebbe non possedere quella capacità inferenziale che caratterizza la nozione europea di sistema di intelligenza artificiale. Prima di discutere di esclusioni e obblighi, occorre quindi qualificare tecnicamente la soluzione utilizzata.

Il falso negativo non è un solo errore

La formula “l’algoritmo ha sbagliato” è troppo generica per descrivere ciò che può essere accaduto. Un’operazione fraudolenta può essere lasciata passare per ragioni molto diverse:

mancanza o inadeguatezza delle variabili: il sistema non acquisisceva dati rilevanti, come il nuovo beneficiario, l’anomalia del dispositivo, la geolocalizzazione o i segnali di compromissione della sessione;
errore del modello: le variabili erano disponibili, ma il modello ha attribuito un rischio troppo basso;
soglia eccessivamente permissiva: lo score era significativo, ma la soglia di blocco o di revisione era stata collocata a un livello superiore per ridurre i falsi positivi e l’attrito con la clientela;
alert non gestito: il sistema ha rilevato l’anomalia, ma l’operatore ha ignorato, chiuso o gestito tardivamente la segnalazione;
eccezione applicativa: una regola di esenzione, una whitelist o un problema di integrazione tra sistemi ha escluso l’operazione dal controllo;
model drift o mancato aggiornamento: il modello non era più adeguato alle nuove tecniche di frode o ai cambiamenti nel comportamento della clientela;
errore nella gestione del dato: timestamp non sincronizzati, feature errate, dati incompleti o problemi di qualità hanno alterato l’analisi.

Ciascuna ipotesi individua un diverso possibile centro di responsabilità: progettazione del prodotto, configurazione da parte della banca, gestione organizzativa, formazione del personale, qualità dei dati o integrazione con i sistemi del fornitore.

La prova tecnica: che cosa dovrebbe essere acquisito

In un contenzioso di questo tipo, la semplice stampa dell’operazione o la schermata che riporta “autenticazione riuscita” non consente una verifica attendibile. La questione deve essere affrontata ricostruendo l’intera sequenza decisionale.

1. Tracciature della sessione e dell’operazione

Devono essere acquisiti i log relativi all’accesso, alla creazione o selezione del beneficiario, alla disposizione del bonifico, all’autenticazione e all’esecuzione. Sono rilevanti l’identificativo della sessione, gli indirizzi IP, le informazioni sul dispositivo, l’eventuale device binding, l’orario con indicazione del fuso, la sincronizzazione degli orologi di sistema e la sequenza delle chiamate applicative.

2. Prova della Strong Customer Authentication

Non basta indicare che sono stati utilizzati due fattori. Occorre verificare quali elementi siano stati impiegati, come siano stati generati e validati, se sia stato rispettato il collegamento dinamico tra codice, importo e beneficiario e se il dispositivo risultasse nuovo, modificato o già associato al cliente.

3. Evidenze del motore antifrode

Per la singola operazione dovrebbero essere disponibili almeno:

versione del modello o del set di regole in esercizio;
data e ora della relativa messa in produzione;
variabili effettivamente utilizzate e valori assunti nel caso concreto;
score prodotto dal sistema;
soglia applicabile in quel momento;
decisione automatica risultante;
eventuali regole di whitelist, esenzione o override;
messaggi di errore, timeout o perdita di dati nell’integrazione.

4. Gestione umana dell’alert

Se è stata generata una segnalazione, devono essere ricostruiti l’utente o la funzione che l’ha presa in carico, il tempo di lavorazione, le informazioni visualizzate, la decisione assunta e le relative motivazioni. L’intervento umano meramente nominale non è sufficiente: occorre verificare se l’operatore disponesse di competenze, informazioni e tempo adeguati per una valutazione effettiva.

5. Prestazioni e validazione del sistema

La valutazione non può limitarsi al singolo output. Sono rilevanti le metriche del modello nel periodo interessato, i tassi di falsi positivi e falsi negativi, i test indipendenti, gli audit, gli aggiornamenti, gli incidenti analoghi e le modifiche delle soglie. L’art. 3 del Regolamento delegato (UE) 2018/389 richiede che l’attuazione delle misure di sicurezza sia documentata, testata, valutata e sottoposta ad audit da soggetti dotati di competenze in sicurezza informatica e pagamenti.

6. Integrità e provenienza delle evidenze

È necessario documentare il sistema sorgente, la procedura di esportazione, il formato nativo, le trasformazioni effettuate, le funzioni hash, i soggetti che hanno avuto accesso ai dati e le politiche di conservazione. Una tabella elaborata per il processo, priva dei dati originari e della relativa provenienza, ha un valore tecnico inevitabilmente più debole.

La disciplina europea offre un supporto importante a questa impostazione. L’art. 29 del Regolamento delegato (UE) 2018/389 richiede la tracciabilità delle operazioni e delle interazioni, in modo da consentire la conoscenza ex post degli eventi rilevanti nelle diverse fasi. Il DORA impone inoltre la registrazione e il controllo delle modifiche ai sistemi e ai parametri di sicurezza, nonché il monitoraggio delle attività degli utenti e delle anomalie.

Non sempre serve il codice sorgente

Nelle controversie algoritmiche si tende a identificare la trasparenza con l’accesso al codice sorgente. È un’equazione spesso sbagliata.

Per verificare un falso negativo sono normalmente più utili la versione del modello, i dati di ingresso, le feature effettivamente valorizzate, lo score, la soglia, la decisione restituita e gli eventuali interventi successivi. Il codice, isolato dal contesto operativo e dai dati, può non spiegare perché quella specifica operazione sia stata lasciata passare.

Il principio è coerente con la sentenza della Corte di giustizia del 27 febbraio 2025, causa C-203/22, Dun & Bradstreet Austria. In materia di decisione automatizzata, la Corte ha chiarito che le informazioni devono consentire all’interessato di comprendere quali dati siano stati utilizzati e in che modo abbiano inciso sul risultato. La mera comunicazione di una formula complessa o dell’algoritmo non costituisce necessariamente una spiegazione intelligibile.

Quella pronuncia riguarda lo scoring creditizio e non può essere trasferita automaticamente a ogni sistema antifrode. Offre però un criterio metodologico utile: la spiegazione deve ricostruire la logica concretamente applicata al caso, non limitarsi a esibire un oggetto tecnico incomprensibile.

Diritto di accesso e segreto commerciale

Il correntista può esercitare il diritto di accesso previsto dall’art. 15 GDPR per ottenere i dati personali trattati e, nei casi di decisione automatizzata ricadenti nell’art. 22, informazioni significative sulla logica utilizzata. Non si tratta, tuttavia, di un diritto generalizzato alla documentazione aziendale né di uno strumento sostitutivo dell’ordine di esibizione processuale.

Lo score associato al cliente, gli indicatori riferiti alla sua sessione e le inferenze elaborate sul suo comportamento possono costituire dati personali. Diversamente, metriche aggregate, informazioni su altri clienti e parti del sistema prive di riferibilità all’interessato possono restare fuori dal perimetro dell’accesso.

La banca e il fornitore possono inoltre invocare il segreto commerciale. Anche in questo caso, però, non è ammissibile un diniego automatico. Nella sentenza Dun & Bradstreet la Corte di giustizia ha stabilito che, quando le informazioni richieste contengono dati di terzi o segreti commerciali, esse devono essere messe a disposizione dell’autorità di controllo o del giudice competente, cui spetta bilanciare gli interessi e determinare la portata dell’accesso.

Nel processo civile il problema può essere gestito con un ordine di esibizione mirato, una consulenza tecnica, l’oscuramento delle informazioni non pertinenti e specifiche misure di riservatezza. La richiesta deve essere proporzionata e riferita alle evidenze realmente necessarie; il segreto industriale, per contro, non può trasformarsi in un’area sottratta a qualsiasi verifica.

Il ruolo del fornitore del sistema

Verso il correntista, il primo interlocutore resta normalmente la banca con la quale è instaurato il rapporto di pagamento. Se l’inadempimento dipende da un prodotto o servizio fornito da un terzo, l’intermediario potrà esercitare le azioni contrattuali e di regresso previste dal rapporto con il vendor.

Il DORA attribuisce particolare rilievo proprio alla qualità dei contratti TIC. L’art. 30 richiede una descrizione chiara delle funzioni, livelli di servizio, obblighi di assistenza, accesso ai dati, diritti di audit e ispezione e, per le funzioni essenziali o importanti, strategie di uscita documentate.

In questa prospettiva, il contratto dovrebbe disciplinare anche:

la disponibilità dei log e i tempi di conservazione;
la documentazione delle versioni del modello e delle modifiche;
le metriche minime di prestazione;
le procedure di validazione e di gestione del model drift;
l’assistenza tecnica in caso di contestazione o incidente;
le responsabilità per configurazione, tuning e qualità dei dati;
le modalità di produzione delle evidenze in giudizio.

Non esiste, invece, un’automatica azione diretta del correntista contro il produttore del modello per il solo fatto che il software abbia prodotto un falso negativo. La Direttiva (UE) 2024/2853 sulla responsabilità da prodotti difettosi comprende il software nella nozione di prodotto, ma il danno meramente economico consistente nella somma sottratta non rientra, di regola, nelle categorie di danno armonizzate dalla direttiva. Restano teoricamente valutabili gli ordinari rimedi nazionali, ove ne ricorrano tutti i presupposti, ma con un onere probatorio ben diverso.

La verifica del beneficiario e il quadro in evoluzione

Dal 9 ottobre 2025 i prestatori situati negli Stati dell’area euro devono offrire il servizio di verifica del beneficiario previsto dall’art. 5-quater del Regolamento (UE) n. 260/2012, introdotto dal Regolamento (UE) 2024/886.

Prima dell’autorizzazione del bonifico, il prestatore deve verificare la corrispondenza tra l’IBAN e il nome del beneficiario e segnalare eventuali difformità. Se il servizio non viene correttamente prestato e l’inadempimento determina un’esecuzione inesatta, il regolamento prevede il rimborso da parte del prestatore del pagatore.

Anche questa tutela non va però trasformata in un automatismo. Se nome e IBAN corrispondono, la verifica non è in grado di stabilire che il beneficiario stia partecipando a una frode. Se il sistema segnala una discrepanza e il cliente decide consapevolmente di proseguire, la valutazione della responsabilità cambia. Resta quindi indispensabile ricostruire l’avviso effettivamente mostrato, il momento in cui è stato presentato e la risposta dell’utente.

Il pacchetto PSD3/PSR è destinato a rafforzare ulteriormente la prevenzione delle frodi e la tutela nelle ipotesi di impersonificazione. Alla data di aggiornamento di questo contributo, tuttavia, il procedimento legislativo non risulta ancora completato: le future disposizioni non possono essere applicate come se fossero già diritto vigente.

Conclusioni: il campo decisivo è la verificabilità

L’esclusione dei sistemi di fraud detection finanziaria dall’elenco ad alto rischio dell’AI Act crea certamente una discontinuità: proprio in un settore nel quale accuratezza, registrazione degli eventi e sorveglianza umana sono decisive, il regolamento non impone il pacchetto rafforzato previsto per altre applicazioni.

Questo vuoto relativo non equivale, però, a un’assenza di regole. Gli obblighi di monitoraggio delle operazioni, tracciabilità, sicurezza, gestione del rischio TIC e responsabilità dell’intermediario esistono già e operano indipendentemente dalla classificazione del sistema ai sensi dell’AI Act.

A mio avviso, il punto centrale è un altro: un sistema antifrode non può essere considerato adeguato soltanto perché esiste, perché utilizza il machine learning o perché ha prodotto uno score. Deve essere possibile ricostruire quali dati abbia esaminato, quali segnali abbia rilevato, quale versione fosse in esercizio, quale soglia sia stata applicata e chi abbia assunto la decisione finale.

Nel contenzioso che verrà, la differenza non sarà tra banca tecnologica e banca non tecnologica. Sarà tra chi dispone di una catena di evidenze completa, integra e verificabile e chi può produrre soltanto una dichiarazione generica sul corretto funzionamento del proprio sistema.

Fonti essenziali

Il contributo ha finalità informativa e di approfondimento tecnico-giuridico e non sostituisce la valutazione del singolo caso concreto.

Quando l’AI antifrode lascia passare un bonifico: responsabilità bancaria, prova digitale e limiti dell’AI Act