L’AI antifrode sbaglia, chi risponde? È l’unico caso in cui l’AI Act si tira indietro

La sentenza n. 32/2026 del Giudice di Pace di Empoli ha risolto il caso facile. La banca non aveva niente da mostrare, e l’assenza è diventata responsabilità.

Il caso difficile è quello che nessun tribunale italiano ha ancora deciso, e che arriverà presto: la banca il sistema ce l’ha. È un motore di anomaly detection acquistato da un vendor internazionale, addestrato sui comportamenti abituali della clientela, integrato nel canale dispositivo. Alle 4:46 del mattino quel motore ha analizzato il bonifico verso la Lituania, ha calcolato uno score, lo ha confrontato con la soglia e ha lasciato passare l’operazione.

Il correntista ha perso comunque 2.700 euro. La banca, questa volta, ha la sua prova documentale.

Chi risponde?

Conviene anticipare subito il punto di metodo: la risposta non dipende dall’AI Act. Le quattro norme che la governano — il D.Lgs. n. 11/2010, l’art. 1228 c.c., il DORA e l’art. 82 GDPR — sono tutte anteriori al Regolamento (UE) 2024/1689, o comunque del tutto indipendenti dalla classificazione di rischio che esso opera.

Verso il cliente risponde la banca. Sempre. E non perché lo dica una sentenza, ma perché lo dicono quattro norme che si sovrappongono.

Ciò che si sposta non è il soggetto responsabile. È il contenuto di quello che la banca deve dimostrare.

A Empoli sarebbe bastato poco. Nel caso del falso negativo non basterà esibire il contratto con il vendor e una brochure di prodotto: occorrerà provare che quel sistema, al momento dei fatti, era conforme allo stato dell’arte. E qui c’è un dettaglio che il dibattito sul machine learning ha completamente coperto.

L’art. 2, par. 2, del Regolamento delegato (UE) 2018/389 — le norme tecniche di regolamentazione sull’autenticazione forte, in vigore dal 2019 — impone che i meccanismi di monitoraggio delle operazioni tengano conto almeno di ciascuno dei seguenti elementi:

- elenchi di elementi di autenticazione compromessi o rubati;

- l’importo di ciascuna operazione;

- gli scenari di frode noti;

- i segni di infezione da malware in qualsiasi sessione della procedura di autenticazione;

- anomalie nell’uso del dispositivo di accesso;

- l’ubicazione anomala del pagatore o del beneficiario.

L’art. 18, per l’analisi dei rischi in tempo reale, aggiunge l’ubicazione ad alto rischio del beneficiario.

Non sono buone pratiche di settore né raccomandazioni: sono il contenuto minimo obbligatorio di un sistema di monitoraggio dinamico, imposto a tutti i prestatori proprio per le operazioni di pagamento elettronico più esposte al rischio di frode.

Si rilegga adesso l’elenco dei cinque red flag del caso di Empoli. Orario, beneficiario mai utilizzato, IBAN estero, importo, ambiente compromesso da trojan. Non sono le intuizioni di un giudice di pace toscano: sono, quasi voce per voce, il contenuto obbligatorio di una fonte europea vigente da sette anni.

Questo cambia la fisionomia della difesa bancaria. Un istituto potrà anche esibire il modello più sofisticato del mercato, ma se quel modello non pesa la presenza di malware nella sessione o l’ubicazione del beneficiario, non è conforme a prescindere dalla sua architettura. Il machine learning non è un adempimento in sé: è il modo, oggi, di adempiere a un obbligo che è scritto altrove e che precede l’intelligenza artificiale di parecchi anni. La stessa logica dell’art. 32 GDPR, che parametra l’adeguatezza delle misure allo «stato dell’arte».

A questo punto il lettore si attende che entri in scena il Regolamento (UE) 2024/1689. È esattamente ciò che non accade, e non per una lacuna: per una scelta esplicita.

L’Allegato III, punto 5, lett. b) classifica come ad alto rischio i sistemi destinati «a valutare l’affidabilità creditizia delle persone fisiche o per stabilire il loro punteggio di credito», ma aggiunge — testualmente — «fatta eccezione per i sistemi di IA utilizzati per individuare le frodi finanziarie».

Il sistema antifrode è espressamente escluso dall’alto rischio. Con tutte le conseguenze del caso: non si applicano gli artt. da 8 a 15 (gestione del rischio, governance dei dati, conservazione dei log, accuratezza e robustezza, sorveglianza umana); non si applicano al sistema antifrode gli obblighi che l’art. 26 collega espressamente ai sistemi ad alto rischio — restano da verificare, caso per caso, quelli che la disposizione pone a prescindere dalla classificazione; non si applica l’art. 27 sulla valutazione d’impatto sui diritti fondamentali; e soprattutto non si applica l’art. 86, che riconosce il diritto di ottenere spiegazioni sulla decisione automatizzata soltanto quando essa si fonda su un sistema ad alto rischio. Il correntista resta tutelato dalle norme generali — GDPR e trasparenza bancaria — ma non da quel diritto rafforzato alla spiegazione che molti danno per acquisito.

Il Regolamento (UE) 2026/1744 dell’8 luglio 2026 (in GU L, 2026/1744, 24.7.2026), il cosiddetto AI Omnibus, ha riscritto il calendario dell’AI Act — i sistemi ad alto rischio dell’Allegato III slittano al 2 dicembre 2027, quelli dell’Allegato I al 2 agosto 2028 — ma non ha toccato quell’eccezione.

Restano applicabili alla banca, indipendentemente dalla classificazione, tre disposizioni che varrà la pena chiedere in giudizio: l’art. 4 sull’alfabetizzazione in materia di IA, applicabile dal 2 febbraio 2025 e non differito dall’Omnibus, che riguarda proprio il personale che legge e gestisce gli alert — sia pure in una versione che il Reg. (UE) 2026/1744 ha alleggerito, sostituendo all’obbligo di garantire un livello sufficiente di competenza quello di adottare misure che ne sostengano lo sviluppo; l’art. 5 sulle pratiche vietate; l’art. 50 sulla trasparenza, applicabile dal 2 agosto 2026, se nel processo di gestione della segnalazione interviene un sistema conversazionale.

Un avvertimento, però, a chi legge l’eccezione come un salvacondotto. È un’esclusione di categoria, non di tecnologia: se lo stesso motore comportamentale alimenta anche lo scoring creditizio o la profilazione della clientela — ipotesi tutt’altro che teorica, perché le feature sono le medesime — il sistema rientra nell’Allegato III e l’intero pacchetto di obblighi torna in vigore.

Che il vendor sia immune, naturalmente, non è vero. È vero che risponde altrove.

Risponde alla banca, in via contrattuale, ai sensi dell’art. 1218 c.c. E qui la norma decisiva — quella che deciderà le cause di regresso più di ogni valutazione tecnica sul modello — è l’art. 1229 c.c., che rende nulla ogni clausola di esonero o limitazione della responsabilità per dolo o colpa grave. Tutti i contratti di fraud detection contengono cap risarcitori commisurati a pochi mesi di canone. Davanti a un difetto grave di progettazione o di tuning, quel cap non regge.

Risponde, ancora, sul piano regolamentare: l’art. 30 del DORA impone, per i servizi TIC a supporto di funzioni essenziali o importanti, livelli di servizio quantitativi, diritti di audit e ispezione, accesso a dati e sistemi, strategie di uscita documentate. Che è un’osservazione dagli effetti processuali sgradevoli: la banca che in giudizio non riesce a produrre le metriche di performance del proprio motore antifrode sta dimostrando, contestualmente, di non avere un contratto conforme al DORA.

Ciò che il correntista non ha è una via d’azione diretta. La Direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi — che si applicherà ai prodotti immessi sul mercato dal 9 dicembre 2026, con lo stesso termine di recepimento — include espressamente il software e i sistemi di IA nella nozione di prodotto, ma copre morte, lesioni personali, danni a beni e distruzione o corruzione di dati. Il danno puramente patrimoniale resta fuori dal regime armonizzato. I 2.700 euro di Empoli sono, tecnicamente, danno meramente economico.

E la proposta di direttiva sulla responsabilità civile da intelligenza artificiale, che avrebbe potuto colmare lo spazio, è stata ritirata dalla Commissione nel 2025.

Il risultato è netto: nessun canale diretto tra chi subisce il danno e chi ha costruito il modello. La responsabilità condivisa, nel senso che l’espressione evoca — cliente che cita banca e fornitore insieme — non esiste nel nostro ordinamento.

Esiste, ma non passa per la linea banca-fornitore. Passa dentro la banca, ed è lì che si giocheranno le prossime cause.

La soglia la sceglie l’istituto. Ogni sistema di anomaly detection produce un punteggio; dove tagliare quel punteggio è una decisione di business, non un parametro tecnico, perché ogni operazione bloccata è attrito commerciale e costo di back office. Chi tara il modello per non infastidire la clientela assume su di sé il rischio dei falsi negativi. Non è difetto del prodotto: è la diligenza qualificata dell’art. 1176, comma 2, c.c.

L’alert può essere scattato e non seguito. Se il sistema ha segnalato e un operatore ha rilasciato comunque l’operazione, non siamo davanti a un errore algoritmico ma a un’inadeguatezza organizzativa — di nuovo l’art. 1228 c.c., e sul piano dell’AI Act quell’art. 4 sull’alfabetizzazione del personale che nessuno considera una norma processualmente rilevante e che invece lo diventerà.

Il modello può essere stato ri-addestrato dalla banca sui propri dati. L’art. 25, par. 1, del Regolamento (UE) 2024/1689 stabilisce che chi appone il proprio nome su un sistema o lo modifica sostanzialmente ne assume la qualifica di fornitore. Formalmente non opera qui, perché il sistema non è ad alto rischio. Ma è il principio che orienterà i giudici: una banca che riaddestra il motore non sta usando il prodotto di un terzo, ne sta facendo uno proprio.

In tutti e tre i casi il conflitto smette di essere «banca contro fornitore» e diventa interno all’istituto: la soglia, la gestione degli alert e il riaddestramento sono decisioni delle funzioni aziendali, e l’art. 1228 c.c. le riporta tutte, senza residui, sulla banca come unico soggetto responsabile verso il cliente.

C’è un ultimo elemento, ed è quello che renderà queste cause diverse da tutte le precedenti in materia di frodi informatiche.

Il correntista non vedrà mai il modello. Gli strumenti a sua disposizione sono l’ordine di esibizione ex art. 210 c.p.c., l’accesso ex art. 15 GDPR e l’inversione dell’onere probatorio dell’art. 10 del D.Lgs. n. 11/2010. Contro di essi la banca opporrà — legittimamente — il segreto commerciale tutelato dal D.Lgs. n. 63/2018, e il fornitore le si affiancherà, perché la soglia di detection e il set di feature sono il suo vantaggio competitivo.

Il giudice si troverà a bilanciare diritto di difesa e riservatezza industriale su una materia che nessuna delle due parti è in grado di spiegare senza un consulente tecnico. Il metodo di bilanciamento, però, non è nuovo, e non va cercato nel diritto bancario: lo ha già costruito il giudice amministrativo.

Il Consiglio di Stato, con la sentenza della sesta sezione 8 aprile 2019, n. 2270, ha affermato che il meccanismo attraverso il quale si concretizza la decisione robotizzata «deve essere “conoscibile”, secondo una declinazione rafforzata del principio di trasparenza, che implica anche quello della piena conoscibilità di una regola espressa in un linguaggio differente da quello giuridico».

Sul versante opposto, la quarta sezione, con la sentenza 4 giugno 2025, n. 4857, ha stabilito che l’accesso al codice sorgente di una piattaforma cede alla riservatezza commerciale, salvo che sia indispensabile e strettamente strumentale alla difesa in giudizio: e «indispensabile» significa che non esistono altri mezzi di prova idonei a dimostrare i fatti controversi, restando precluso l’accesso meramente esplorativo.

Sono pronunce nate nel processo amministrativo e nel contenzioso sugli appalti, non trasferibili come tali a una causa fra correntista e banca. Ma il criterio è quello, ed è l’unico che un giudice civile abbia oggi a disposizione: conoscibilità come regola, riservatezza come eccezione, indispensabilità probatoria come unità di misura del bilanciamento. Nuovo è soltanto l’oggetto. Non una piattaforma i cui criteri diventano leggibili una volta aperto il codice, ma un modello statistico i cui criteri non sono pienamente leggibili nemmeno per chi lo ha addestrato.

Fino a dove arrivano le norme oggi vigenti, la risposta alla domanda iniziale è questa: risponde la banca, sempre e per intero; il fornitore risponde alla banca e solo nei limiti che la banca ha saputo negoziare; il correntista non ha alcuna azione verso chi ha scritto il codice.

Vale la pena aggiungere che il quadro si sta già muovendo. L’art. 5 quater del Regolamento (UE) n. 260/2012, inserito dal Regolamento (UE) 2024/886, impone ai prestatori dell’area euro, dal 9 ottobre 2025, di verificare la corrispondenza tra IBAN e nome del beneficiario e di avvisare il pagatore prima che questi possa autorizzare il bonifico. Non era applicabile ai fatti del maggio 2023. Ma quel bonifico verso un beneficiario mai utilizzato, oggi, imporrebbe un avviso di mancata corrispondenza prima dell’esecuzione — e la mancata prestazione di quel servizio, in quanto inadempimento agli obblighi di corretta esecuzione, espone in linea di principio il prestatore all’obbligo di rimborso: non una condanna automatica, ma un’inadempienza che resta da provare nel suo nesso causale con l’esecuzione inesatta dell’operazione.

Il pacchetto PSD3/PSR, che estenderà e sistematizzerà questi obblighi — con regole espresse sul monitoraggio delle operazioni e sulla responsabilità del prestatore per le frodi da impersonificazione — non è però ancora diritto vigente: alla data di chiusura di questo articolo il testo di compromesso ha superato il voto della commissione ECON del Parlamento europeo, il 5 maggio 2026, ma attende l’adozione formale in plenaria e in Consiglio e la pubblicazione in Gazzetta ufficiale, con applicazione generale differita di ventuno mesi (1). Chi lo cita oggi come norma vigente sbaglia; chi lo ignora nella pianificazione sbaglia altrettanto.

Perché la domanda successiva è già visibile all’orizzonte, ed è speculare a quella di oggi: cosa accade quando il sistema antifrode funziona troppo bene, blocca un’operazione legittima e il cliente perde l’affare della sua vita? 

Lì l’onere della prova si capovolge di nuovo. E stavolta a invocarlo sarà la banca.

________

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

(1) Stato dell’iter al 24 agosto 2026: il pacchetto europeo composto dalla proposta di terza direttiva sui servizi di pagamento (PSD3) e dal regolamento sui servizi di pagamento (PSR) ha raggiunto un accordo politico provvisorio tra Parlamento e Consiglio il 27 novembre 2025; i testi di compromesso sono stati resi disponibili dal Consiglio il 23 aprile 2026 e sono stati successivamente esaminati in sede ECON. Alla data indicata, tuttavia, gli atti non risultano ancora formalmente adottati e pubblicati nella Gazzetta ufficiale dell’Unione europea; pertanto, non sono ancora entrati in vigore né sono applicabili.