Andrea Innocenti Banche e intelligenza artificiale convergono su un terreno in cui precisione, controllo e sostenibilità economica sono decisivi. Per intelligenza artificiale si intende un insieme di tecniche in grado di apprendere da dati, generare previsioni e automatizzare decisioni, con livelli diversi di trasparenza e controllo. Nelle istituzioni finanziarie, l’obiettivo non è l’effetto vetrina, ma la riduzione del rischio, il miglioramento del servizio e la solidità del ritorno sugli investimenti.
Il tema è rilevante perché le banche gestiscono processi regolati, dati sensibili e margini che richiedono rigore. La scelta tra modelli proprietari e modelli a codice aperto il governo dei dati i costi di esercizio e la sicurezza formano un quadro integrato. Questo articolo mappa le aree progettuali più diffuse, confronta soluzioni di casa e open-source e offre criteri pratici per misurare rendimento dell’investimento su credito e rischi.
Mappa dei progetti nelle principali tipologie di istituti
Tipicamente, le banche distribuiscono l’IA in quattro cluster. Le realtà retail adottano scoring e underwriting per credito al consumo e mutui, con modelli che bilanciano predittività e spiegabilità. Le banche corporate spingono su early warning per deterioramento, analisi bilancistica e lettura automatica di documenti. Le funzioni di controllo implementano anti-money laundering e fraud detection basati su grafi e sequenze.
I canali commerciali usano motori di raccomandazione, natural language processing per estrarre intenti e assistenti per operatori e clienti. Questa mappa aiuta a valutare dove l’IA produce impatti misurabili e dove servono cicli di validazione più lunghi.
Progetti trasversali includono la normalizzazione anagrafica la deduplicazione clienti, l’entity resolution tra sistemi e la classificazione testuale di note, reclami e verbali. In questi ambiti, la standardizzazione del dato genera benefici che si propagano a valle, potenziando modelli di credito e controlli di rischio. Nei portafogli più complessi, i team sperimentano approcci ibridi che combinano regole, segnali comportamentali e modelli generativi per estrarre conoscenza da documenti lunghi.
Modelli in-house vs open-source: scelte architetturali
La scelta tra modelli interni e open-source dipende da controllo, costi e rischio operativo. I modelli sviluppati in casa offrono massima aderenza ai processi, tracciabilità dei dati e integrazione con i sistemi legacy; richiedono tuttavia competence center robusti, MLOps maturi e cicli di manutenzione stabili. Gli approcci open-source consentono velocità e riuso: librerie testate, comunità ampie, audit del codice. Il compromesso risiede nella gestione della dipendenza da componenti terze e nel presidio di sicurezza dell’intera catena.
Una strategia ricorrente è l’ibrido: feature engineering e pre-processing con strumenti open, modelli core proprietari per le decisioni critiche, e model serving su infrastrutture interne. Per i modelli generativi linguistici si valutano opzioni fine-tuned in ambienti isolati, minimizzando l’uscita di dati sensibili. La domanda chiave non è “cosa è migliore in assoluto”, ma “qual è l’assetto più governabile, auditabile e sostenibile rispetto al processo oggetto di automazione”.
Governo dei dati e sicurezza: dal catalogo all’audit
Il governo dei dati si fonda su tre pilastri: qualità, lineage e accesso. La qualità garantisce coerenza tra origini, la lineage spiega come i dati si trasformano lungo il flusso, l’accesso implementa il principio del minimo privilegio. Nei contesti bancari, i dati sensibili impongono data minimization e un controllo granulare dei consensi. Ogni modello deve essere associato a set di dati documentati, con metriche di bias, drift e prestazioni versionate.
La sicurezza non è un add-on, ma parte dell’architettura. Sono centrali segregazione degli ambienti cifratura a riposo e in transito, gestione delle chiavi, segreti rotabili e logging immutabile. Per i sistemi generativi, si adottano filtri di prompt, politiche di redazione e whitelist dei connettori. Nei processi che trattano documenti, il redacting automatizzato limita l’esposizione di dati personali e confidenziali, riducendo rischio legale e reputazionale.
Costi e TCO: dove si paga davvero
Il costo non coincide con lo sviluppo iniziale. Il TCO di un sistema IA include addestramento, feature store, orchestrazione, monitoraggio, retraining, test di regressione e aggiornamenti di sicurezza. Le componenti open-source riducono il costo di licenza, ma richiedono investimenti in integrazione e supporto; le soluzioni proprietarie contrattualizzano SLA, al prezzo di minore flessibilità. La stima dei costi deve includere marginalità per volume, latenza accettabile e ridondanza.
Per i modelli generativi il costo di inferenza può crescere con il contesto e la frequenza di chiamata. Tecniche come distillazione, quantizzazione e cache semantica riducono l’impronta computazionale. Nei casi d’uso di credito, i costi di calcolo restano prevedibili se il modello opera in batch; nella prevenzione frodi, la bassa latenza richiede architetture streaming che incidono sul budget operativo. La chiave è misurare il costo per decisione utile.
ROI su credito e rischi: casi d’uso misurabili
Il rendimento dell’investimento si misura legando i modelli a metriche di business. Nello scoring di credito, si valutano tassi di approvazione a rischio costante, riduzione delle perdite attese, miglioramento della discriminazione (AUC, KS) e tempi di delibera. Nel monitoraggio portafoglio, gli indicatori includono anticipo degli alert, precisione degli early warning e riduzione del lavoro manuale qualificato. Nelle frodi, la metrica faro è la riduzione delle perdite nette a parità di falsi positivi accettabili.
La misurazione deve distinguere tra uplift diretto (perdite evitate, margine incrementale) e benefici indiretti (tempo risparmiato, qualità del dato, compliance). I progetti ad alta sostanza economica presentano obiettivi semplici e dataset stabili; quelli a valore esplorativo vanno incanalati in sandbox con traguardi misurabili e exit criteria chiari. Nessun ROI è reale senza un collegamento tracciabile tra decisione, esito e conto economico.
Approfondimenti: tassonomia e ambiguità nei dati testuali
Nelle basi documentali bancarie emergono ambiguità linguistiche che confondono i modelli. Termini come “guida”, “svolta” o nomi geografici possono miscelare contesti non finanziari. Un catalogo ben curato separa domini e usa ontologie per disambiguare. Esempi utili in fase di test includono etichette di ricerca come “la guida cuneo”, “svolta di salerno”, “caso ragusa svolta”, “guida antonio”, “paesi con guida a sinistra”, “la svolta pinerolo”, “guida a sinistra paesi”, “svolta bolognina”. In un contesto bancario, queste stringhe vanno classificate come rumore o come categorie esterne, evitando che influenzino lo scoring o la prioritizzazione dei controlli.
Pratiche robuste prevedono data contracts tra IT e funzioni di rischio, liste di stop-words adattive e set di convalida con esempi difficili. L’obiettivo è mantenere i modelli focalizzati sul lessico della banca, riducendo derive semantiche. La qualità semantica è parte integrante del governo dei dati e si riflette direttamente su accuratezza, explainability e audit.
Dal principio alla pratica: criteri di scelta stabili
Per prioritizzare i progetti, è utile una griglia immutabile: impatto economico atteso, stabilità del dato, complessità di integrazione, requisiti di explainability costo marginale per decisione e rischio operativo. Le banche che scalano l’IA in modo sano investono sul data foundation allocano budget sul run (monitoraggio e retraining), e scelgono tecnologie in funzione del presidio, non della moda. La guida reale della svolta è la capacità di misurare e governare: dati affidabili, modelli tracciabili e processi che reggono alla verifica.