Le sette domande sull’AI che un CdA deve porre al management

1. Quali casi d’uso AI stanno già entrando nei processi critici della banca?

La risposta che dovete pretendere non è un elenco di pilot, ma una mappa di materialità. Per il Consiglio di amministrazione non conta quanti casi d’uso esistono; conta quali decisioni possono alterare. Un caso d’uso va considerato critico quando può incidere su almeno una di queste quattro aree: esito per il cliente, profilo di rischio della banca, continuità di una funzione importante o conformità regolatoria. In pratica: credito e monitoraggio del credito, frodi e antiriciclaggio e contrasto al finanziamento del terrorismo, pricing e offerte personalizzate, complaint handling, document analysis che alimenta decisioni regolamentate, reporting, IT operations a supporto di funzioni critiche, relazione con il cliente quando l'output AI può orientare o condizionare la decisione finale. La Banca centrale europea osserva che l'AI si sta espandendo proprio in IT operations, legal/document analysis e front-line applications, e che più dell'ottantacinque per cento delle grandi banche sotto supervisione europea la usa già in qualche forma. L'Autorità bancaria europea aggiunge che il novantadue per cento delle banche Unione europea sta già deployando AI.

Quello che dovete chiedere al management è quindi un inventario unico dei casi d’uso, non spezzettato tra business line, IT e innovation office, con almeno cinque attributi obbligatori: responsabile di business, responsabile del dato, responsabile del modello, responsabile del controllo di seconda linea, e livello di materialità prudenziale. Senza questo, il Consiglio di amministrazione vede attività sparse ma non vede il rischio aggregato. La Banca centrale europea segnala proprio che uno dei problemi tipici è la fragmented ownership, con responsabilità distribuite tra IT, data science, linee di business e funzioni di controllo senza un quadro di responsabilità chiaro.

Il criterio di giudizio del Consiglio di amministrazione deve essere semplice: se un casi d’uso tocca cliente, rischio, compliance o continuità operativa, non è più un esperimento. Da quel momento entra nel perimetro dei processi materiali e deve essere trattato con la stessa disciplina con cui trattate credito, outsourcing o modello interno.

2. Chi risponde davvero delle decisioni prese o influenzate dall'AI?

Qui la risposta corretta è: non basta dire risponde la banca. È troppo poco. Il Consiglio di amministrazione deve pretendere una catena di responsabilità nominale, non collettiva. La Bank for International Settlements è molto netto: The consiglio and senior management of financial institutions are ultimately accountable for their activities, including AI casi d’uso.

La risposta che dovreste volere dal management è questa: per ogni casi d’uso materiale esistono almeno quattro responsabilità distinte. Primo, un business owner responsabile del risultato economico e dell'uso corretto nel processo. Secondo, un model owner responsabile della performance, del monitoraggio, del drift e della documentazione tecnica. Terzo, un data owner responsabile di qualità, tracciabilità della filiera del dato, accessi, fidelizzazione e bias legati al dato. Quarto, un control owner di seconda linea, con potere di challenge vero, non solo consultivo. Per i casi che poggiano su fornitore esterni, aggiungete un quinto tassello: il vendor owner, responsabile della due diligence sul terzo e del piano di uscita. La Bank for International Settlements aggiunge infatti che l'accountability del consiglio e del senior management vale anche per attività, funzioni, prodotti e servizi forniti da terzi.

Da consiglieri, dovreste anche pretendere che esista un matrice delle responsabilita: responsabile, approvatore, consultato e informato formale per ogni casi d’uso materiale e che la delibera di messa in produzione specifichi tre cose: chi approva il rilascio, chi ha il diritto di veto e chi ha il potere di sospendere il sistema in esercizio. Se questi tre nomi non esistono, allora l'AI non è governata: è distribuita. E la Banca centrale europea lo dice con chiarezza: “AI does not dilute responsibility. If anything, it raises the bar”.

3. Dove sono i nostri dati, da chi dipendiamo e che cosa succede se un fornitore cade?

Questa, per un Consiglio di amministrazione, è una domanda di sovranità operativa, non di pura architettura IT. La vera risposta non è siamo sul cloud o abbiamo un large language model fornitore. La risposta che dovete pretendere è una mappa completa delle dipendenze: dati in ingresso, dati in training, dati in retrieval, API, modelli terzi, infrastruttura cloud, sub-esternalizzazione, diritti di audit, localizzazione dei dati, tempi di passaggio al sistema di riserva, e possibilità concreta di uscita. La Banca centrale europea avverte che la generative AI introduce un cambio di scala nelle dipendenze e che i principali rischi sono concentrazione, fornitore lock-in, data confidentiality, security, operational resilience ed exit strategies. La Bank for International Settlements aggiunge che l'uso di servizi AI di terze parti, intrecciato con i cloud fornitori, aumenta l'interconnettività e rende le istituzioni finanziarie più vulnerabili a minacce informatiche e interruzioni operative presso gli fornitori di servizi AI.

La Banca centrale europea sottolinea che l'AI sposta l'attenzione di vigilanza upstream, cioè verso rappresentatività del dato, tracciabilità della filiera del dato, qualità e salvaguardie contro i bias. Se non sapete da dove arriva il dato, come è stato ripulito, chi lo ha arricchito e come viene riusato, allora non sapete davvero che cosa state mettendo dentro il modello.

Come consiglio, dovreste pretendere tre evidenze molto concrete. Primo. un concentration dashboard che mostri quante funzioni importanti dipendono dallo stesso fornitore, dalla stessa interfaccia di programmazione delle applicazioni o dalla stessa famiglia di modelli. Secondo. un exit plan testato, non teorico, con tempi e costi di migrazione. Terzo. una mappa della catena di esternalizzazione, perché in AI e cloud il vostro fornitore spesso dipende da altri fornitori che voi non vedete. Se il management non è in grado di mostrarvi questi tre oggetti, allora la banca non ha ancora misurato il proprio rischio di dipendenza.

4. Che cosa significa davvero human in the loop nei nostri processi?

Qui il rischio più grande è accettare una risposta cosmetica. Umano nel ciclo decisionale non significa che un operatore vede l'output alla fine o può, in teoria, intervenire. Significa che l'essere umano ha un ruolo significativo, competente e verificabile in un punto del processo dove può ancora cambiare l'esito. L'Organizzazione per la cooperazione e lo sviluppo economico rileva che metà dei rispondenti nel settore finanziario italiano usa l'human oversight come salvaguardia chiave; la Banca centrale europea, nei workshop con le banche, scrive che “A human in the loop remains central to banks’ processes”, ma aggiunge anche che l'interpretazione pratica di questa formula è ancora molto variabile. Il Massachusetts Institute of Technology offre la chiave organizzativa più utile: i lavoratori vengono sempre più spostati verso compiti di controllo supervisivo as the 'human in the loop', cioè compiti di supervisione, interpretazione e correzione del processo, più che di esecuzione manuale.

Per il Consiglio di amministrazione, la domanda giusta non è dunque c'è o non c'è l'uomo?. La domanda è: in quale punto del flusso di lavoro interviene, con quale informazione, con quale potere e con quale accountability? Nei casi ad alto impatto dovreste chiedere che il management definisca almeno quattro livelli di intervento umano. Uno, in fase di design e approvazione del caso d'uso. Due, nel punto in cui il sistema produce un output che può cambiare la decisione. Tre, nella gestione delle eccezioni o dei reclami. Quattro, nell'audit ex post dei casi chiusi. Senza questa articolazione, human in the loop rischia di diventare una formula rassicurante ma vuota.

E qui serve molta precisione. La Banca centrale europea osserva che, per il credit scoring, l'AI spesso supporta la decisione umana, ma che nelle piccole erogazioni retail alcune decisioni possono essere automatizzate; aggiunge anche che nessuna delle banche del campione usa AI generativa nel credit scoring, citando costi, tempi di sviluppo e affidabilità come motivi di prudenza. Da Consiglio di amministrazione, questo vi dice una cosa precisa: quanto più la decisione è standardizzata e a basso importo, tanto più può crescere l'automazione; quanto più la decisione è ad alto impatto, tanto più l'oversight deve essere sostanziale e documentato.

5. I nostri framework di rischio, compliance e resilienza sono stati davvero adattati all'AI?

La risposta che dovete volere dal management è: no, non basta incorporare l'AI nel framework esistente senza modificarlo. La Banca centrale europea è chiarissima: l'AI deve essere governata come tema core di business e rischio; i rischi legati all'AI devono essere riflessi nel risk appetite, le decisioni sui casi d’uso materiali devono passare da valutazione prima dell'implementazione, il secondo livello deve eseguire solide valutazioni del rischio, e il monitoraggio successivo all'implementazione deve consentire al senior management di mantenere supervisione efficace. Questo è lo standard. Se il management vi dice abbiamo inserito l'AI nel nostro framework di rischio di modello, sta dicendo qualcosa di utile ma non sufficiente.

Il Consiglio di amministrazione dovrebbe pretendere almeno otto adattamenti puntuali. Uno: risk appetite con soglie specifiche per spiegabilità, accuracy, drift, bias, incidenti, dipendenze terze e qualità del dato. Due: model risk management aggiornato per modelli che apprendono o che si basano su componenti esterne. Tre: data governance rafforzata. Quattro: compliance e conduct risk per garantire che l'output AI non produca discriminazioni, mis-selling o comunicazioni fuorvianti. Cinque: cyber & operational resilience, perché AI, cloud e terze parti sono ormai un unico blocco di rischio. Sei: business continuity e fallback manuale. Sette: incident reporting dedicato, con tassonomia specifica per AIa. Otto: internal audit coverage con skill adeguate. La Bank for International Settlements riassume il quadro regolatorio in poche parole: affidabilità e solidita, accountability, trasparenza, equità ed etica, con crescente enfasi su riservatezza e protezione dei dati, sicurezza e protezione.

Non sottovalutate il lato cyber. L'Organizzazione per la cooperazione e lo sviluppo economico nota che quasi metà dei rispondenti nel settore finanziario italiano non ha ancora implementato presidi contro specifica per AI minacce informatiche. Questo è un segnale molto importante per un Consiglio di amministrazione: la maturità d'uso cresce più rapidamente della maturità di difesa. Se l'AI entra nei processi critici e la banca non aggiorna i suoi presìdi cyber e di resilienza operativa, il rischio non è teorico: è già in formazione.

6. Quando la nostra AI inizierà a generare ricavi?

Questa è una domanda da Consiglio di amministrazione, ma va riformulata bene. La risposta corretta non è quando vedremo l'ROI?, bensì: quali casi d’uso hanno una linea di vista credibile sui ricavi, con che tempi e con quali KPI? Se vi fate promettere ricavi dall'AI in astratto, riceverete narrativa. Se chiedete una revenue bridge per casi d’uso, riceverete finalmente gestione. La prima cosa da fissare è che nei primi sei-nove mesi, salvo casi eccezionali, l'AI non genera ricavi materiali: produce soprattutto efficienza, riduzione dei tempi, minor costo di processo, migliore qualità operativa e, al massimo, protezione dei ricavi - cioè meno churn, meno abbandono in ononboarding, meno frodi, meno errori, migliore fidelizzazione. La stessa Banca centrale europea, nei workshop con le banche, osserva che i benefici di business esistono, ma che “the financial quantification of realised benefits remains a challenge”.

Il punto di svolta arriva quando l'AI smette di vivere in casi d’uso isolati e viene inserita in flusso di lavoro core. Boston Consulting Group dice che in banca il settantacinque per cento del valore dell'AI proviene in media dalle funzioni di business core, e cita in particolare digital marketing, customer journey, pricing, sales, transaction and payment services, credits and loans, customer service; aggiunge che le organizzazioni più avanzate raggiungono un tempo necessario per produrre impatto di nove-dodici mesi, contro dodici-diciotto mesi dei operatori in ritardo. Tradotto per il Consiglio di amministrazione: i primi veri ricavi non arriveranno dal assistente digitale usato per scrivere mail o riassumere documenti, ma da casi d’uso che spostano conversione, pricing, acquisizione, quota del portafoglio cliente, autorizzazione più rapida del credito, qualità della relazione e riduzione dei tassi di abbandono.

Per avere una misura di potenziale, ma non una promessa da mettere a budget, potete guardare a due riferimenti. Accenture stima che gli early adopters potrebbero vedere nei prossimi tre anni ventidue per cento a trenta per cento di productivity improvement, seicento punti base di revenue growth e trecento punti base di rendimento del capitale proprio. Boston Consulting Group, sul retail banking, stima che l'AI possa aumentare la redditività del trenta per cento e ridurre i costi del trenta per cento a quaranta per cento entro il 2030, ma questo è uno scenario di piena trasformazione, non il business case di un singolo esercizio. Usate questi numeri come ordine di grandezza strategico, non come indicazione annuale.

Quello che dovete pretendere, invece, è una revenue bridge use-case by use-case. Per ciascun programma materiale il management deve dirvi: baseline attuale, leva economica attesa, KPI di leading indicator, orizzonte temporale, e responsabile del risultato. Le leve, in banca, sono quasi sempre queste: aumento del tasso di conversione in acquisizione iniziale del cliente, incremento dello quota del portafoglio cliente, miglioramento del pricing, minore churn, riduzione dei perdite da frode, aumento della capacity commerciale per relationship manager e advisory, riduzione dei tempi di risposta che migliora il adozione dell'offerta. Se il management non vi porta questa tabella e vi parla genericamente di AI che genera ricavi, fermatelo. Boston Consulting Group segnala che il sessanta per cento delle banche non ha ancora definito KPI finanziari per misurare l'impatto: non entrate in quel sessanta per cento.

7. Quali sono i costi preventivabili per una banca?

Qui il primo consiglio, da Consiglio di amministrazione, è molto netto: non accettate un solo numero. L'AI in banca non ha un costo unico; ha almeno quattro famiglie di costo che il management deve separare. Primo. costi di fondazione, cioè dati, integrazioni, accessi, piattaforme, sicurezza, policy, registro dei modelli, monitoraggio. Secondo. costi dei casi d’uso, cioè sviluppo, test, messa a punto, integrazione di processo, esperienza utente, gestione del cambiamento. Terzo. costi di controllo, cioè compliance, spiegabilità, audit, legal, di terze parti due diligence, rafforzamento della sicurezza informatica, resilienza, fallback. Quarto: costi di esercizio, cioè licenze, cloud, compute, monitoraggio continuo, riaddestramento, supporto operativo, vendor management ed eventuali costi di uscita. Se il management vi presenta solo il costo del pilot o della licenza del modello, vi sta sottostimando il programma.

Sui benchmark pubblici bisogna essere onesti. Non esiste, nelle fonti aperte, un costo medio standard affidabile per banca, perché il range dipende da ambizione, architettura esistente, outsourcing, qualità del dato e profondità della trasformazione. Il benchmark più difendibile che abbiamo è questo: Boston Consulting Group rileva che un'azienda su tre prevede di spendere oltre 25 milioni di dollari in AI nel 2025, e che alcune spenderanno nell'ordine dello zero virgola cinque per cento a uno per cento dei ricavi. Accenture aggiunge che alcuni casi d’uso sono simple and relatively inexpensive, mentre altri - come costruire un digital twin della funzione mutui - sono complessi e richiedono molta expertise, dati e computation. Quindi la risposta corretta da portare al Consiglio di amministrazione non è spenderemo poco o molto, ma spenderemo in modo molto diverso a seconda che stiamo facendo assistenza interna, trasformazione di processo o rifacimento di una catena decisionale critica.

Come criterio di budgeting, dovreste chiedere al management una vista triennale del total cost of ownership, non un budget annuale sperimentale. E dovreste farvi presentare almeno tre scenari: uno scenario minimo di casi d’uso selettivi e interni; uno scenario intermedio di scala su più funzioni; uno scenario trasformativo esteso a tutta la banca.

Per dare un ordine di grandezza, e solo come ancora alta di pianificazione derivata dal benchmark Boston Consulting Group, una banca con due miliardi di ricavi che punti a un vero scale-up enterprise deve considerare plausibile un envelope nell'ordine di dieci-venti milioni annui; una banca con cinque miliardi di ricavi, venticinque-cinquanta milioni annui. Non prendeteli come medie di mercato: prendeteli come livelli di impegno compatibili con una trasformazione seria, comprensiva di governance, controllo, formazione e resilienza. Se il management vi propone numeri molto inferiori, chiedete subito che cosa è stato escluso: bonifica dei dati? cloud? vendor control? audit? cyber? fallback? formazione?

Infine, fate attenzione ai costi nascosti, che nei programmi AI bancari sono spesso quelli che esplodono dopo l'entusiasmo iniziale. I principali sono sei: bonifica e integrazione dei dati; adattamento dei sistemi legacy; spiegabilità e validazione; revisione contrattuale e due diligence sui fornitore; formazione dei team e dei manager; progettazione di fallback e piani di continuità. Accenture insiste che i programmi più seri devono calcolare il punto in cui cost and return curves are likely to intersect; Boston Consulting Group aggiunge che le banche più mature usano finanziamento per fasi successive e revisioni trimestrali del portafoglio. Questo è esattamente il linguaggio che il Consiglio di amministrazione deve imporre: non budget a pioggia, ma rilascio progressivo di capitale in funzione di milestone, KPI e rischio residuo.

Chiusura da Atlante

Se devo condensare tutto in una frase, è questa: non chiedete al management se l'AI funziona; chiedetegli se è governabile, misurabile, interrompibile e redditizia nei processi che contano. La Banca centrale europea vi sta dicendo che l'AI è già entrata nella materialità bancaria; il Bank for International Settlements vi sta dicendo che la responsabilità resta in capo a voi e al senior management; il Massachusetts Institute of Technology vi sta dicendo che il lavoro si sta spostando verso supervisione e giudizio; Boston Consulting Group e Accenture vi stanno dicendo che il valore arriverà solo quando l'AI uscirà dai pilot e verrà innestata nei core flusso di lavoros con KPI finanziari chiari. La sintesi, per un Consiglio di amministrazione, è brutale ma utile: se non avete inventario, accountability, KPI economici, costi totali e piani di fallback, non avete una strategia AI. Avete solo un portafoglio di esperimenti.