Executive Summary
L’intelligenza artificiale sta già attraversando l’intera catena del valore bancaria: rischio di credito, rilevazione delle frodi, AML, servizio clienti, sviluppo software, reporting regolamentare, cyber defence, resilienza operativa e produttività interna. Per le banche europee, la domanda decisiva non è più se l’AI verrà utilizzata. Verrà utilizzata. La domanda decisiva è se potrà essere governata, dimostrata e scalata senza indebolire il controllo.
L’AI governance nel banking non è un’appendice etica, una policy tecnologica o una checklist di compliance. È il modello operativo che collega EU AI Act, DORA, GDPR, model risk management, third-party risk, data governance, cyber resilience e board accountability. Le istituzioni vincenti non saranno quelle con il maggior numero di piloti AI. Saranno quelle che sapranno dove l’AI è utilizzata, classificheranno i rischi in modo coerente, controlleranno dati e modelli, governeranno le dipendenze da terze parti e forniranno al board evidenze, non slogan.
Perché l’AI governance nel banking è diversa
L’intelligenza artificiale nel settore bancario non è più un tema futuro. Sta già entrando nel rischio di credito, nella rilevazione delle frodi, nell’AML, nel servizio clienti, nello sviluppo software, nel reporting regolamentare, nella cyber defence, nella resilienza operativa e nella produttività interna. Nel 2025, la European Banking Authority ha riportato che l’adozione dell’AI nel settore bancario e dei pagamenti dell’UE è andata ben oltre la discussione: il 92% delle banche dell’UE sta già implementando AI e il restante 8% sta pilotando o discutendo use case AI. Questo cambia completamente la domanda di governance. L’AI governance nel banking non può più essere trattata come un add-on etico, un’appendice di validazione modello o una policy detenuta da un team specialistico. È diventata parte del sistema di gestione della banca.
Il punto centrale è questo: l’AI governance non serve a rallentare l’AI. Serve a rendere l’AI scalabile in un’istituzione vigilata.
Molte banche inquadrano ancora l’AI governance come esercizio di compliance. È comprensibile, ma strategicamente troppo stretto. In Europa contano EU AI Act, DORA, GDPR, regole di outsourcing, aspettative di model risk management, requisiti di internal governance e priorità dell’ECB Banking Supervision. Ma la vera sfida non è raccogliere riferimenti regolamentari. La vera sfida è tradurli in un modello operativo che consenta a una banca di identificare, approvare, implementare, monitorare e challenge i sistemi AI attraverso business, technology, risk, compliance, data, cyber, legal, audit e board.
È qui che molti framework di AI governance falliscono. Sembrano completi sulla carta, ma non cambiano il modo in cui vengono prese le decisioni.
Una banca può pubblicare una policy AI. Può creare un AI committee. Può nominare un AI Officer. Può richiedere impact assessment, documentazione del modello, controlli di qualità dei dati e human oversight. Nulla di tutto questo è sbagliato. Ma se questi elementi non sono collegati a decisioni di investimento, standard architetturali, risk appetite, vendor onboarding, change governance, incident management e board reporting, la banca non ha AI governance. Ha burocrazia AI.
La differenza conta perché il banking non è un ambiente tecnologico ordinario. Le banche non processano semplicemente dati. Allocano credito, gestiscono depositi, rilevano criminalità finanziaria, calcolano capitale, proteggono pagamenti, trattano dati personali sensibili e operano infrastrutture economiche critiche. Quando l’AI viene incorporata in questi processi, diventa parte dell’ambiente di controllo dell’istituzione. La domanda quindi non è se l’AI sia innovativa. La domanda è se sia governata come parte della banca.
L’AI governance nel banking è diversa per quattro ragioni.
- 1Le conseguenze del fallimento sono diverse. Un sistema AI mal governato può creare esiti di credito discriminatori, falsi fraud alert, danno al cliente, debole rilevazione AML, errata classificazione del rischio, esposizione cyber non controllata, errori di reporting regolamentare o eccessiva dipendenza da un modello di terza parte. In un’app consumer, un cattivo output AI può creare rischio reputazionale. In una banca può incidere su clienti, capitale, conduct, resilienza e fiducia del supervisore.
- 2Lo stack regolamentare è diverso. L’EU AI Act introduce regole orizzontali per i sistemi AI, inclusi requisiti per l’AI ad alto rischio. DORA introduce un quadro vincolante per la resilienza operativa digitale nel settore finanziario. Il GDPR rimane centrale ogni volta che sono coinvolti dati personali, profilazione o decisioni automatizzate. La regolamentazione bancaria già richiede robusta internal governance, risk management, outsourcing oversight e controllo dei modelli. L’AI non sostituisce nessuno di questi framework. Li interseca tutti.
- 3L’ambiente operativo è diverso. La maggior parte delle grandi banche gestisce ecosistemi tecnologici complessi con sistemi legacy, data ownership frammentata, molteplici cloud provider, sviluppo esternalizzato, piattaforme regionali, requisiti regolamentari locali e funzioni di controllo sovrapposte. L’AI governance non può quindi essere disegnata come un framework accademico pulito. Deve funzionare nella realtà enterprise.
- 4Il modello di accountability è diverso. Nel banking, nessuno dovrebbe dire in modo credibile: “Il modello ha deciso.” Il management resta accountable. Il board resta accountable per l’oversight. Risk e Compliance restano accountable per il challenge. Technology resta accountable per implementazione sicura e resiliente. Il business resta accountable per il use case e i suoi risultati. L’AI governance deve rendere questa accountability visibile prima che il modello vada live, non dopo che qualcosa è andato storto.
Un modello pratico di AI governance dovrebbe quindi partire da un principio semplice: ogni use case AI materiale deve avere un owner chiaramente accountable, una finalità documentata, una classificazione del rischio definita, fonti dati approvate, controlli tecnici e business, human oversight dove richiesto, dispositivi di monitoring e un percorso chiaro di escalation.
Sembra ovvio. In pratica è difficile.
La difficoltà non è che le banche non abbiano funzioni di controllo. La difficoltà è che l’AI le attraversa. Data governance può possedere la qualità dei dati. Technology può possedere le piattaforme. Cyber può possedere i controlli di sicurezza. Risk può possedere il model risk. Compliance può possedere l’interpretazione regolamentare. Legal può possedere temi contrattuali e di responsabilità. Procurement può possedere il third-party onboarding. Audit può possedere l’assurance indipendente. Il business può possedere il use case. Il board può chiedere progresso. Senza un modello integrato di AI governance, ogni funzione vede solo una parte del rischio.
L’AI governance è la disciplina che riunisce queste parti.
L’EU AI Act: trigger di governance, non framework autonomo
L’EU AI Act viene spesso discusso come se fosse l’intera storia dell’AI governance. Non lo è. È un trigger importante, ma non il framework completo.
Per le banche, l’AI Act è particolarmente rilevante perché alcuni use case nei servizi finanziari possono rientrare nella categoria ad alto rischio. L’esempio più evidente è la valutazione del merito creditizio. Secondo l’Annex III dell’AI Act, i sistemi AI utilizzati per valutare il merito creditizio di persone fisiche o stabilire il loro credit score sono classificati come ad alto rischio, salvo quando il sistema è utilizzato per rilevare frodi finanziarie. Questa eccezione è importante perché mostra che la classificazione dipende non solo dalla tecnologia, ma anche dalla finalità e dal contesto d’uso.
Qui inizia la governance pratica.
Una banca non può semplicemente chiedere se uno strumento è “AI”. Questa è solo la prima domanda. Deve chiedere cosa fa il sistema, chi è impattato, se supporta o prende una decisione, se la decisione produce effetti legali o similmente significativi, se il use case è collegato a categorie ad alto rischio, se vengono trattati dati personali, se il modello è sviluppato internamente o fornito da terzi, e se il sistema è utilizzato in un processo bancario regolato.
Un modello usato per produttività interna può richiedere un percorso di governance. Un modello usato per segmentazione clienti può richiederne un altro. Un modello usato per merito creditizio, collections, fraud detection, prioritarizzazione di alert AML o reporting regolamentare può richiedere uno standard di evidenza molto più alto. La tecnologia può sembrare simile. L’obbligo di governance non lo è.
L’AI Act rafforza requisiti che banche serie dovrebbero già riconoscere: risk management, data governance, documentazione tecnica, record-keeping, trasparenza, human oversight, accuratezza, robustezza e cybersecurity. Non sono concetti legali astratti. Si mappano direttamente sulle discipline di controllo bancario. Il risk management si collega al risk appetite e al control assessment. La data governance si collega a lineage, qualità e uso autorizzato. La documentazione si collega all’auditability. Il record-keeping si collega all’evidenza. L’human oversight si collega all’accountability. Robustezza e cybersecurity si collegano alla resilienza tecnologica.
Per questo l’AI Act non dovrebbe essere implementato come silo di compliance separato. Se una banca crea un progetto AI Act autonomo, scollegato da technology governance, data governance, model risk management, DORA, GDPR e outsourcing oversight, creerà duplicazione e confusione. L’approccio più strategico è usare l’AI Act come meccanismo di pressione per rafforzare il modello di enterprise AI governance della banca.
Il lavoro di mapping dell’EBA sull’AI Act è rilevante perché ha valutato le implicazioni dell’AI Act per il settore bancario e dei pagamenti dell’UE, con particolare attenzione ai sistemi AI ad alto rischio come merito creditizio e credit scoring. Il messaggio importante per le banche è che l’AI Act readiness non deve essere trattata come universo parallelo. Deve essere mappata rispetto agli obblighi settoriali esistenti e alle aspettative di vigilanza.
In termini pratici, ogni banca dovrebbe costruire un inventario dei use case AI che faccia più che elencare strumenti. Dovrebbe classificare finalità, gruppo utenti, popolazione impattata, impatto decisionale, categoria dati, tipo modello, fonte di sviluppo, dipendenza da terze parti, criticità operativa, rilevanza regolamentare e stato dei controlli. Senza quell’inventario, il senior management non può sapere dove si trova il rischio AI. Senza sapere dove si trova il rischio AI, non può governarlo.
Digital Omnibus Update: la timeline è cambiata, la responsabilità no
Al 29 giugno 2026, il Consiglio dell’Unione europea ha dato approvazione finale a misure mirate di semplificazione dell’AI Act. Secondo la comunicazione del Consiglio, l’applicazione degli obblighi ad alto rischio passa al 2 dicembre 2027 per i sistemi AI stand-alone ad alto rischio e al 2 agosto 2028 per i sistemi AI integrati in prodotti. Non posso confermare, sulla base delle fonti disponibili qui, se il regolamento modificativo finale sia già stato pubblicato nella Gazzetta ufficiale dell’Unione europea.
Per le banche, questo cambia la pianificazione di implementazione, ma non la logica di governance.
Il tempo aggiuntivo non dovrebbe essere usato per rinviare l’AI governance. Dovrebbe essere usato per costruire inventario, logica di classificazione, controlli sui dati, approccio model risk, third-party oversight e board reporting che l’AI scalabile richiede comunque. La deadline può muoversi. L’accountability no.
Questo conta perché l’adozione dell’AI non aspetta le scadenze legali. Le banche stanno già implementando AI in interazione cliente, fraud detection, processi di credito, produttività interna, sviluppo software e risk analytics. Se la governance attende fino all’ultima data legale possibile, la banca accumulerà per anni esposizione AI non classificata, non documentata e mal controllata.
Una banca seria dovrebbe quindi usare la timeline modificata come vantaggio di pianificazione, non come scusa per il ritardo. La domanda giusta non è: “Quanto tardi possiamo essere compliant?” La domanda giusta è: “Quanto presto possiamo costruire un modello di governance riutilizzabile che renda più semplice scalare in modo compliant?”
Questa è la differenza strategica tra gestione delle scadenze ed esecuzione controllata.
DORA: AI governance e resilienza operativa
Le discussioni sull’AI governance si concentrano spesso su fairness, explainability e model risk. Questi temi contano. Ma per le banche non bastano.
DORA rende inevitabile la realtà tecnologica. Il Regolamento (UE) 2022/2554 stabilisce un quadro europeo per la resilienza operativa digitale nel settore finanziario, includendo ICT risk management, incident reporting, operational resilience testing e ICT third-party risk. Questo è direttamente rilevante per l’AI, perché i sistemi AI dipendono sempre più da infrastruttura cloud, API, model services, data provider esterni, sviluppo esternalizzato e vendor tecnologici.
Una banca può pensare di implementare un chatbot per il servizio clienti. Dal punto di vista della governance, potrebbe introdurre un nuovo flusso dati, una nuova dipendenza vendor, un nuovo problema di access control, un nuovo requisito di monitoring, un nuovo scenario di rischio operativo e un nuovo percorso di incident management. Se il chatbot usa AI generativa, la banca deve anche considerare hallucination risk, prompt injection, leakage di dati confidenziali, logging inadeguato, scarsa explainability, model drift e dipendenza dagli aggiornamenti del modello del provider.
Per questo l’AI governance non può stare fuori dalla resilienza operativa.
Un framework serio di AI governance nel banking deve porre domande di tipo DORA fin dall’inizio. Il sistema AI supporta un servizio business importante? Dipende da un critical ICT third-party provider? Cosa succede se il model service non è disponibile? Cosa succede se gli output degradano? Cosa succede se il vendor cambia il modello? Cosa succede se il sistema produce output dannosi o fuorvianti su larga scala? Cosa succede se dati sensibili vengono esposti attraverso prompt, embeddings, log o output? Chi lo rileva? Chi decide se si tratta di un ICT incident, data incident, model issue, conduct issue o tutto insieme?
Queste domande definiscono se l’AI è pronta per la produzione.
DORA cambia anche il rapporto tra innovazione AI e third-party risk. Molte capacità AI non saranno costruite interamente dentro la banca. Arriveranno da cloud provider, AI platforms, software vendor, data provider, analytics tools e specialist model services. Non è automaticamente un problema. Ma significa che l’AI governance deve essere integrata in procurement, outsourcing assessment, ICT risk classification, clausole contrattuali, exit planning, service monitoring e analisi del concentration risk.
Una banca che tratta la selezione di vendor AI come un normale acquisto software manca il punto. Il tema non è solo se lo strumento funziona. Il tema è se la banca può controllare, monitorare, spiegare, challenge, uscire e dimostrare l’uso di quello strumento in un ambiente regolato.
Qui la governance diventa pratica. Il processo di approvazione AI non dovrebbe iniziare dopo che Procurement ha selezionato il vendor. Dovrebbe iniziare prima che la banca si impegni su un’architettura, un modello di data-sharing o una dipendenza contrattuale che poi diventa impossibile da disfare.
GDPR e decisioni automatizzate
L’AI governance nel banking è impossibile senza data protection governance.
Il GDPR rimane centrale perché molti use case AI bancari coinvolgono dati personali, profilazione o decisioni che possono incidere significativamente sugli individui. L’articolo 22 del GDPR dà agli individui il diritto di non essere sottoposti a una decisione basata esclusivamente su trattamento automatizzato, inclusa la profilazione, quando tale decisione produce effetti legali o similmente significativi, soggetta a specifiche eccezioni e garanzie. Questo è direttamente rilevante quando l’AI viene usata in credito, pricing, collections, customer vulnerability, fraud controls o altri processi decisionali che impattano i clienti.
Ma il GDPR non riguarda solo le decisioni automatizzate. Riguarda anche base giuridica, limitazione della finalità, minimizzazione dei dati, trasparenza, accuratezza, limitazione della conservazione, integrità, confidenzialità e accountability. Questi principi non sono ostacoli all’AI governance. Ne fanno parte.
L’Opinion 28/2024 dell’EDPB è importante perché affronta aspetti di protezione dati relativi ai modelli AI, inclusi quando e come un modello AI può essere considerato anonimo, come il legitimate interest può essere valutato come base giuridica nello sviluppo e nel deployment, e quali conseguenze possono derivare dal trattamento illecito nella fase di sviluppo. Per le banche, questo è particolarmente rilevante perché data lineage e uso lecito dei dati non sono domande astratte di privacy. Determinano se la banca può difendere il ciclo di vita del modello.
L’implicazione pratica è chiara: l’AI governance deve collegare l’approvazione del modello all’approvazione dei dati.
Un modello non dovrebbe essere approvato semplicemente perché performa bene statisticamente. Deve anche essere chiaro quali dati sono stati utilizzati, se la banca ha il diritto di usarli per la finalità prevista, se sono coinvolti dati personali, se caratteristiche sensibili o protette sono presenti direttamente o indirettamente, se proxy possono creare bias, se la qualità dati è sufficiente, se sono definiti periodi di retention e se l’uso degli output è trasparente verso gli interessati quando richiesto.
Questo è particolarmente importante per AI generativa e large language models. Molte banche hanno iniziato con use case di produttività interna perché apparivano a rischio minore. Ma anche strumenti interni possono processare informazioni confidenziali, dati personali, dati cliente, codice, incident record, materiale HR, report di rischio o documenti supervisory. Se i dipendenti inseriscono informazioni sensibili in uno strumento AI senza controlli appropriati, la banca può creare problemi di privacy, confidenzialità, proprietà intellettuale, sicurezza e regolamentazione prima ancora che esista un use case cliente esterno.
Per questo le acceptable-use policies non bastano. Le banche hanno bisogno di technical guardrails, logging, access controls, data-loss prevention, training, monitoring e conseguenze chiare per l’uso improprio. Ancora più importante, hanno bisogno di alternative approvate e utilizzabili. Se l’ambiente AI ufficiale è troppo lento, troppo restrittivo o troppo scollegato dal modo in cui i dipendenti lavorano, emergerà shadow AI.
Shadow AI non è una strategia di innovazione. È un fallimento di controllo.
Model Risk Management e AI generativa
L’AI governance nel banking deve essere costruita sul model risk management, ma non può essere limitata al model risk management tradizionale.
Le banche comprendono già la governance dei modelli in aree come credit risk, market risk, liquidity risk, capital models, stress testing e IFRS 9. Conoscono l’importanza di validation, documentation, monitoring, limitations, change control e independent challenge. Ma l’AI introduce complessità aggiuntiva: comportamento non lineare del modello, dipendenza dai dati, ridotta interpretabilità, possibilità di continuous learning, dipendenza da provider esterni di modelli e nuove forme di output risk.
Il follow-up report dell’EBA sul machine learning per modelli IRB è utile perché mostra come requisiti prudenziali, GDPR e AI Act si intersecano quando il machine learning viene usato in modelli di rischio di credito. La guida rivista della BCE sui modelli interni chiarisce inoltre le aspettative di vigilanza sull’uso di tecniche di machine learning nei modelli interni. Non sono documenti generici di etica AI. Sono materiali supervisory specifici per il banking e rilevanti per una governance AI seria.
La lezione pratica è che le banche hanno bisogno di un approccio tiered alla model governance. Non ogni sistema AI dovrebbe passare attraverso lo stesso processo di validazione di un modello IRB. Sarebbe impraticabile. Ma non ogni sistema AI può essere trattato come una semplice feature software. Il framework di governance deve classificare i modelli in base a materialità, use case, rilevanza regolamentare, impatto decisionale, complessità, sensibilità dei dati, esigenze di explainability, dipendenza operativa e danno potenziale.
Uno strumento interno low-risk di summarisation può richiedere accesso controllato, restrizioni sui dati, logging e acceptable-use monitoring. Un modello usato per prioritarizzare alert AML può richiedere validazione più forte, explainability, bias assessment, performance monitoring e operational back-testing. Un modello di merito creditizio può richiedere un percorso di governance molto più formale perché può influenzare direttamente l’accesso a risorse finanziarie e può rientrare in una categoria AI ad alto rischio.
Il model risk management deve evolvere anche per l’AI generativa. La validazione tradizionale chiede se il modello performa rispetto a metriche definite su dati definiti. L’AI generativa aggiunge domande più difficili da ridurre a un singolo score. Il sistema hallucina? Produce output plausibili ma sbagliati? Perde informazioni confidenziali? È vulnerabile al prompt injection? Genera risposte discriminatorie o fuorvianti? Si comporta diversamente tra lingue? Degrada quando il provider aggiorna il modello? La banca può riprodurre gli output? Può spiegare perché una risposta è stata generata? Il use case richiede comportamento deterministico o output probabilistico è accettabile?
Queste domande devono essere risposte prima del deployment, non dopo un incidente.
L’AI governance deve definire cosa significa “good enough” per ogni classe di use case AI. Se la banca non può definire criteri di accettazione, non può governare il sistema. Se non può governare il sistema, non dovrebbe scalarlo.
L’inventario AI: lo strumento di governance più sottovalutato
L’artefatto più importante di AI governance in una banca non è la policy. È l’inventario.
Senza inventario AI, la banca non conosce la sua esposizione. Senza conoscere l’esposizione, non può classificare il rischio. Senza classificazione del rischio, non può applicare controlli proporzionati. Senza controlli proporzionati, sovra-controlla i use case a basso rischio o sotto-controlla quelli materiali.
Un inventario AI serio dovrebbe includere almeno queste dimensioni: use-case owner, processo business, legal entity, giurisdizione, gruppo utenti, popolazione impattata, tipo modello, provider, fonti dati, coinvolgimento di dati personali, impatto decisionale, materialità, classificazione AI Act, rilevanza GDPR, rilevanza DORA, rilevanza outsourcing, classificazione model risk, stato validazione, metriche di monitoring, incidenti, limitazioni, residual risk e retirement status.
L’inventario deve anche catturare AI incorporata nei prodotti vendor. Questo è facile da perdere. Le banche possono non pensare di implementare AI quando acquistano software con funzionalità AI integrate. Ma dal punto di vista della governance, l’embedded AI può comunque influenzare processi, decisioni, data flow e dipendenze operative. La vendor AI non è fuori dalla responsabilità della banca solo perché il modello sta dentro un prodotto terzo.
L’inventario dovrebbe anche distinguere sperimentazione da produzione. Un proof of concept in sandbox non è la stessa cosa di uno strumento usato da centinaia di dipendenti o di un modello che influenza risultati cliente. Ma anche i piloti hanno bisogno di governance. Hanno bisogno di confini: dati approvati, ambienti approvati, limiti temporali, exit criteria e regole per passare in produzione.
Il passaggio da pilota a produzione è uno dei momenti di rischio più alto nell’AI governance. Molti fallimenti avvengono perché un use case iniziato informalmente diventa operativo senza passare attraverso un control gate appropriato. Una demo diventa workflow. Un workflow diventa dipendenza. Una dipendenza diventa problema di controllo.
L’AI governance deve rendere visibile questa transizione.
Human Oversight oltre la checkbox
Human oversight è uno dei concetti più ripetuti nell’AI governance. È anche uno dei più fraintesi.
Una banca non dovrebbe rivendicare meaningful human oversight semplicemente perché una persona è da qualche parte nel processo. Human oversight deve essere progettato. Il reviewer umano deve comprendere la finalità del sistema AI, le limitazioni del modello, il contesto decisionale, i criteri di escalation e le circostanze in cui l’output AI dovrebbe essere challenge o overridden.
Questo è particolarmente importante nel banking perché i dipendenti possono fidarsi troppo degli output AI quando questi appaiono precisi, tecnici o sicuri. Una raccomandazione di credito, un fraud score, una prioritarizzazione AML, un customer-risk summary o un’anomalia di reporting regolamentare può sembrare oggettiva perché generata da un modello. Ma l’output del modello non è verità. È una stima strutturata prodotta sotto assunzioni, limitazioni dati e scelte di design.
Human oversight deve quindi essere collegato a training, process design, decision rights e accountability. Chi può overrulare il sistema AI? Quando deve farlo? Quale evidenza è richiesta? Gli override sono monitorati? I pattern di override sono rivisti? Il reviewer umano è sufficientemente indipendente? C’è rischio di automation bias? Il processo consente tempo sufficiente per una vera review, o l’umano si limita a timbrare l’output del modello?
È facile scrivere “human in the loop” in una policy. È molto più difficile progettare un processo in cui l’umano abbia davvero competenza, autorità e tempo per challenge la macchina.
Per use case bancari high-impact, questa differenza è decisiva.
Explainability: non ogni modello richiede la stessa spiegazione
Explainability è un’altra area in cui le banche hanno bisogno di disciplina pratica.
Non ogni sistema AI richiede lo stesso livello di spiegazione. Un modello usato per instradare ticket interni non richiede la stessa explainability di un modello usato per supportare la valutazione del merito creditizio. Un assistente AI generativo che riassume policy interne non richiede lo stesso standard di spiegazione di un modello usato nella classificazione del rischio. Ma ogni sistema AI materiale ha bisogno di uno standard di spiegazione appropriato al suo uso.
Explainability dovrebbe essere definita per audience e finalità. Un data scientist può avere bisogno di spiegazione tecnica. Un model validator può avere bisogno di performance drivers, limitazioni e sensitivity analysis. Un business user può avere bisogno di reason codes e logica decisionale. Un cliente può avere bisogno di informazioni comprensibili su come una decisione che lo riguarda è stata presa. Un supervisor può avere bisogno di evidenza che la banca comprende, controlla e monitora il sistema.
Un singolo metodo di spiegazione non soddisferà tutti questi bisogni.
Per le banche, explainability deve collegarsi all’accountability. Se nessuno può spiegare il modello abbastanza bene da challenge, la banca dovrebbe essere cauta nel deployarlo in processi decisionali materiali. Questo non significa che possano essere usati solo modelli semplici. Significa che la banca deve poter giustificare perché un modello è appropriato per il use case, come le sue limitazioni sono controllate, come gli output sono monitorati e come gli stakeholder impattati sono protetti.
Il BIS Financial Stability Institute ha identificato la regolazione dell’AI nei servizi finanziari come area attiva di sviluppo supervisory, includendo model risk, data privacy, explainability e rischi specifici dell’AI generativa come hallucination.
La domanda giusta non è: “Possiamo spiegare perfettamente il modello?” La domanda giusta è: “Possiamo spiegarlo sufficientemente per la decisione che supporta e il rischio che crea?”
Third-Party AI ed Embedded Vendor AI
La third-party AI sarà una delle sfide di governance più difficili per le banche.
Molte banche si affideranno a provider esterni per foundation models, cloud infrastructure, AI platforms, vendor applications, data services, monitoring tools e analytics specialistici. È razionale. Nessuna banca dovrebbe presumere di poter costruire internamente ogni capacità AI. Ma l’uso di terze parti non trasferisce accountability fuori dalla banca.
Il Financial Stability Board ha identificato third-party dependencies, market correlations, cyber risks e sfide in model risk e governance come vulnerabilità legate all’AI con potenziali implicazioni per la stabilità finanziaria. Questo è altamente rilevante per le banche perché l’adozione dell’AI può concentrare dipendenze su pochi provider tecnologici e cloud.
Dal punto di vista della governance, la third-party AI crea varie domande.
La banca sa se il prodotto vendor include AI? Il contratto permette alla banca di comprendere ruolo, limitazioni e ciclo di aggiornamento del modello? La banca può limitare l’uso dei dati? Può impedire al vendor di usare dati bancari per training? I log sono disponibili? La banca può testare gli output? Il vendor fornisce documentazione sufficiente? Cosa succede quando il vendor cambia il modello? Cosa succede se il provider ritira il servizio? Esiste un exit plan? Ci sono concentration risks a livello di banca? Più processi critici dipendono dallo stesso provider?
Queste domande non dovrebbero essere poste solo per critical outsourcing arrangements. Dovrebbero far parte della AI vendor governance più ampia, con proporzionalità basata sulla materialità.
I team Procurement hanno bisogno di AI literacy. I team Legal hanno bisogno di posizioni contrattuali specifiche per l’AI. I team Technology hanno bisogno di standard architetturali. I team Risk hanno bisogno di classificazione vendor risk. I team business devono capire che comprare AI non è lo stesso che comprare software ordinario.
Il rischio AI vendor più pericoloso non è sempre quello più visibile. A volte è la funzionalità AI nascosta in una piattaforma che la banca usa già. Un vendor introduce una nuova funzionalità AI. Un team business la attiva. I dati iniziano a muoversi. Gli output entrano in un workflow. Nessuno aggiorna l’inventario. Nessuno valuta il rischio. Nessuno informa il board.
È così che shadow AI diventa rischio istituzionale.
Business Value e kill mechanism
L’AI governance non dovrebbe essere disegnata solo intorno al rischio. Sarebbe incompleta.
Le banche hanno bisogno di AI perché hanno bisogno di migliore produttività, migliore customer experience, più forte fraud detection, sviluppo software più rapido, risk analytics migliorata, controlli più efficienti e migliore uso dei dati. Un modello di governance che blocca soltanto l’AI fallirà. Spingerà l’innovazione in canali informali o renderà la banca strategicamente più lenta.
Il giusto modello di governance deve collegare controllo del rischio e creazione di valore.
Ogni use case AI materiale dovrebbe avere un business case. Quale problema risolve? Quale processo migliora? Quale costo riduce? Quale rischio mitiga? Quale risultato cliente migliora? Quale control weakness affronta? Quale metrica proverà che il use case funziona?
Senza questa disciplina, l’AI diventa teatro.
Le banche sono particolarmente vulnerabili all’AI theatre perché la pressione executive è alta. Ogni istituzione vuole mostrare che è attiva sull’AI. Ogni funzione vuole un use case. Ogni vendor rivendica capacità AI. Ogni presentazione strategica include una slide sull’AI generativa. Ma attività non significa trasformazione.
Una banca con cinquanta piloti e nessun modello di controllo scalabile non è avanti. È esposta.
Una banca con meno use case, ma una piattaforma chiara, data pipeline governate, approval path riutilizzabili, benefici misurabili e deployment in produzione controllato può essere in una posizione molto più forte. L’obiettivo non è massimizzare il numero di esperimenti AI. L’obiettivo è operationalise AI dove crea valore e può essere controllata.
Per questo l’AI governance dovrebbe includere un kill mechanism. Non ogni use case AI dovrebbe sopravvivere. Se un use case non crea valore misurabile, non può essere controllato, duplica capacità esistenti, aumenta complessità o crea rischio sproporzionato, dovrebbe essere fermato. La governance matura non riguarda solo l’approvazione. Riguarda anche la terminazione.
AI governance come enterprise capability
Le banche che scaleranno l’AI con successo tratteranno l’AI governance come enterprise capability.
Significa che la banca ha una tassonomia AI comune. Sa cosa conta come AI, cosa conta come AI generativa, cosa conta come modello, cosa conta come high impact, cosa conta come production use e cosa conta come uso proibito o limitato.
Significa che la banca ha un inventario controllato. Non dieci spreadsheet. Non registri sparsi tra Risk, Technology, Data e Compliance. Una vista affidabile dell’adozione AI e del rischio.
Significa che la banca ha approval pathways basati sul rischio. Gli strumenti di produttività low-risk seguono un processo proporzionato. I sistemi decisionali high-impact ricevono review più profonda. La third-party AI viene valutata prima dell’adozione. Modifiche materiali attivano re-approval.
Significa che la banca ha una AI control library. Data controls, access controls, logging, monitoring, bias testing, explainability, cyber testing, vendor controls, incident triggers e human oversight non vengono reinventati per ogni use case.
Significa che la banca ha AI literacy a più livelli. I membri del board devono capire abbastanza per challenge il management. I senior executive devono capire abbastanza per owning le decisioni. Le funzioni di controllo devono capire abbastanza per valutare il rischio. I dipendenti devono capire abbastanza per usare gli strumenti in sicurezza.
Significa che la banca ha metriche. AI governance senza metriche diventa narrativa. La banca dovrebbe tracciare use case AI per status, classe di rischio, business line, legal entity, provider, control maturity, issue, incidenti, value delivered e audit finding.
Significa che la banca ha assurance. Internal audit non dovrebbe aspettare che l’AI sia già scalata informalmente. Dovrebbe testare governance framework, completezza dell’inventario, control design, evidenza di approvazione, monitoring e issue remediation.
Significa che la banca ha un management rhythm. L’AI governance dovrebbe essere rivista regolarmente dal forum executive appropriato, escalata al board quando materiale, e collegata a strategia, investimenti tecnologici e risk appetite.
Framework esterni possono supportare questo lavoro. ISO/IEC 42001:2023 specifica requisiti e linee guida per stabilire, implementare, mantenere e migliorare continuamente un AI management system. Il NIST AI Risk Management Framework e il Generative AI Profile forniscono un riferimento strutturato per AI risk management, inclusi i rischi dell’AI generativa.
Ma una banca non dovrebbe confondere framework alignment con regulatory readiness. ISO e NIST possono supportare il sistema di gestione, ma non sostituiscono EU AI Act, DORA, GDPR, aspettative EBA, supervisione ECB, obblighi di internal governance o requisiti regolamentari locali.
L’approccio migliore è usare i framework esterni come impalcatura, non come edificio.
Cosa dovrebbero chiedere ora i board
Board e senior executive non dovrebbero aspettare un framework di AI governance perfetto prima di porre domande migliori. Possono iniziare ora.
- Dovrebbero chiedere: abbiamo un inventario AI completo, inclusa third-party ed embedded AI?
- Dovrebbero chiedere: quali use case AI potrebbero incidere materialmente su clienti, dipendenti, decisioni di rischio, financial crime controls, reporting regolamentare, capitale o resilienza operativa?
- Dovrebbero chiedere: quali sistemi AI potrebbero rientrare nelle categorie high-risk dell’EU AI Act, e quale evidenza supporta quella classificazione?
- Dovrebbero chiedere: come si collega l’AI governance a DORA, GDPR, outsourcing, model risk management e internal governance?
- Dovrebbero chiedere: chi possiede end to end ogni sistema AI materiale?
- Dovrebbero chiedere: il management può evidenziare qualità dei dati, uso lecito dei dati, performance del modello, human oversight, monitoring e issue management?
- Dovrebbero chiedere: quali dipendenze AI da terze parti stanno emergendo, e dove potrebbe nascere concentration risk?
- Dovrebbero chiedere: dove l’AI generativa è già usata dai dipendenti, e come viene prevenuta la shadow AI?
- Dovrebbero chiedere: quale valore misurabile ha prodotto l’AI, e quali use case dovrebbero essere fermati?
- Dovrebbero chiedere: quando internal audit rivedrà il framework di AI governance?
Queste domande non sono progettate per rallentare l’AI. Sono progettate per renderla reale.
Conclusione
L’AI governance nel banking è spesso fraintesa. Viene trattata come peso regolamentare, checklist di compliance o livello di controllo difensivo. Questa visione è troppo limitata.
In una banca europea, l’AI governance è il meccanismo che consente all’AI di scalare senza compromettere accountability, resilienza, protezione dei dati, controllo dei modelli o fiducia del supervisore.
Le istituzioni che falliranno non saranno necessariamente quelle che si muovono lentamente. Alcune si muoveranno velocemente, ma senza controllo. Altre costruiranno complessi documenti di governance che non cambiano il processo decisionale. Entrambi gli approcci si bloccheranno.
Le istituzioni che avranno successo faranno qualcosa di più difficile. Collegheranno la strategia AI al modello operativo della banca. Sapranno dove l’AI viene usata. Classificheranno il rischio in modo coerente. Governeranno dati e modelli insieme. Controlleranno le dipendenze da terze parti. Renderanno significativo l’human oversight. Forniranno ai board evidenze, non slogan. Fermeranno i use case deboli e scaleranno quelli forti.
Questa è la differenza tra sperimentazione AI e trasformazione AI.
Una banca può comprare strumenti AI. Può comprare cloud platform. Può comprare accesso ai modelli. Può comprare supporto consulenziale. Ma non può comprare accountability. Non può esternalizzare il giudizio. Non può delegare la fiducia.
L’AI governance nel banking non è quindi il lato amministrativo dell’AI. È la disciplina di leadership che determina se l’AI diventa una controlled enterprise capability o un ulteriore strato di complessità non gestita.
La prossima linea competitiva nel banking europeo non sarà tra banche che usano AI e banche che non la usano. Quasi tutte le istituzioni serie la useranno. La linea sarà tra banche capaci di governare l’AI su scala e banche intrappolate tra innovation theatre e disagio supervisory.
L’AI governance è dove quella linea diventerà visibile.
Fonti
La base fattuale e regolamentare di questo articolo include: EU AI Act e la sua logica di classificazione high-risk, incluso Annex III; la comunicazione del Consiglio del 29 giugno 2026 sulla semplificazione dell’AI Act e le timeline high-risk modificate; DORA e il suo framework per ICT risk e third-party risk; GDPR, incluse le decisioni automatizzate ai sensi dell’articolo 22; EDPB Opinion 28/2024 sui modelli AI e i dati personali; materiali EBA sull’adozione AI e sulle implicazioni dell’AI Act per banking e payments; materiali ECB su modelli interni e machine learning; materiali FSB sulle vulnerabilità AI per la stabilità finanziaria; lavori BIS/FSI sulla regolazione dell’AI nei servizi finanziari; ISO/IEC 42001:2023; e il NIST AI Risk Management Framework con il Generative AI Profile.
