L’email è datata aprile e arriva dagli uffici dell’OSFI, l’autorità di vigilanza bancaria canadese. Il destinatario: i responsabili tecnicici delle banche. Il contenuto, reso pubblico grazie alle norme sull’accesso agli atti, rompe una regola non scritta del mondo regolamentare: non si fanno nomi. E invece l’OSFI cita esplicitamente il modello Claude di Anthropic — lo definisce un motivo concreto per cui la finestra utile a correggere vulnerabilità si sta chiudendo. Niente più “tecnicie emergenti” o “capacità avanzate”. Stavolta il bersaglio ha un nome ed è un modello di frontiera già in produzione in diversi settori. Il messaggio per le banche è inequivocabile: l’adozione indiscriminata degli LLM, se non governata con strumenti che garantiscano controllo e residenza dei dati, sta diventando un rischio sistemico in tempo reale.

La mossa dell’OSFI segnala un cambio di passo strutturale. I regolatori hanno sempre evitato di citare prodotti specifici per non alterare il mercato, per non dare l’impressione di endorsement o condanna e perché, in teoria, i principi devono essere agnostici rispetto al fornitore. Ma quando il ritmo dell’innovazione supera la capacità degli istituti di fare due diligence, il linguaggio generico diventa un lusso che non ci si può più permettere. L’effetto immediato è che le banche canadesi dovranno rendicontare come gestiscono l’esposizione a Claude — e per estensione a qualunque LLM che tratti dati sensibili — con la stessa granularità con cui tracciano le vulnerabilità del software tradizionale. Questo sposta l’ago della bilancia verso architetture che diano piena sovranità operativa: deployment on-premise, modelli self-hosted e pipeline di inference interne, dove il dato non lascia mai il perimetro aziendale.

Chi guadagna da questa pressione normativa? Innanzitutto l’ecosistema hardware: GPU e acceleratori che consentono di eseguire LLM quantizzati in locale senza dipendere da API cloud. I framework di serving come vLLM, TGI e Ollama diventano mattoni essenziali per costruire ambienti bancari conformi. Le software house specializzate in MLOps on-premise vedono crescere la domanda di strumenti per versionare, monitorare e mettere in sicurezza i modelli esattamente come si fa con i container e le librerie critiche. Chi perde quota sono i servizi cloud-only che non offrono garanzie vincolanti sulla residenza dei dati o che rendono difficile l’audit in ambienti multi-tenant. Non è un caso che le grandi banche stiano già investendo in cluster privati con GPU NVIDIA H100 o equivalenti, progettati per fine-tuning e inference di LLM senza uscire dalla propria rete.

C’è anche un effetto di secondo ordine che riguarda la velocità stessa dell’adozione. Dire “la finestra per correggere le falle si sta chiudendo” significa che ogni giorno di ritardo nell’integrare un LLM senza le dovute protezioni aumenta la superficie d’attacco. Le banche sono così incentivate ad accelerare la migrazione verso ambienti controllati, magari sacrificando qualche punto percentuale di performance del modello in cambio di auditing completo e isolamento. Qui entra in gioco il trade-off che chi valuta l’on-premise conosce bene: modelli con quantization aggressiva (INT8 o FP16) riducono il footprint di VRAM ma possono incidere sulla qualità delle risposte. AI-RADAR ha analizzato questi bilanciamenti in diverse architetture: la scelta non è mai binaria ma dipende dal carico di lavoro e dai requisiti di latenza.

La decisione dell’OSFI, infine, potrebbe fare scuola. Se altri regolatori — BCE, Bank of England, autorità europee — iniziassero a nominare modelli specifici nei propri alert, l’on-premise diventerebbe la configurazione di default per l’AI nel settore finanziario, non più una nicchia per i più cauti. La conformità, in altre parole, smette di essere un vincolo a posteriori e diventa il driver primario della progettazione infrastrutturale. Ed è proprio questo il punto di svolta che l’email canadese, con la sua secca concretezza, ha messo nero su bianco.