Portare un assistente AI da 300.000 utenti all’intera base clienti entro pochi mesi non è un problema di prompt. È un problema di architettura, controllo e rilascio. Il caso Itaú mostra una sequenza utile anche a una PMI: partire da un compito delimitato, separare i dati dal modello, misurare ogni passaggio e ampliare l’autonomia solo quando gli errori sono osservabili e reversibili.

Il 16 ottobre 2026 OpenAI ha raccontato come la banca brasiliana stia costruendo ia.i, un’interfaccia conversazionale per servizi finanziari, insieme a IARA, la piattaforma interna che governa accesso ai modelli, costi e policy. È un caso enterprise, non un modello da copiare alla lettera. La parte trasferibile è il metodo: non acquistare “l’AI”, ma costruire un percorso controllato fra bisogno, contesto, modello, azione e verifica.

La scala arriva dopo il perimetro

Itaú ha iniziato il rilascio di ia.i con circa 300.000 clienti. Nel comunicato di luglio indicava come passaggi successivi circa 3 milioni di clienti entro settembre e l’intera base entro la fine del 2026. L’interfaccia accetta testo e voce e deve coprire ambiti diversi, dal conto corrente alle carte, dal credito agli investimenti. Quando serve, il flusso passa a un supporto umano specializzato.

Il dato importante non è il numero di utenti. È il fatto che la scala sia stata preceduta da una prima fase circoscritta. Un chatbot aperto a tutti dal primo giorno moltiplica contemporaneamente richieste impreviste, costi, casi limite e danni possibili. Un gruppo iniziale consente invece di osservare intenzioni reali, risposte deboli, tempi di latenza ed escalation prima che diventino un problema di massa.

Per una PMI il primo perimetro può essere molto più piccolo: un solo team, un solo tipo di documento e un’azione che resta confermabile da una persona. Per esempio, preparare una bozza di risposta a una richiesta commerciale usando listino e condizioni aggiornate. L’AI legge e propone; l’operatore verifica e invia. In questa fase non deve modificare il CRM, promettere uno sconto o spedire un messaggio in autonomia.

Il modello non deve possedere il processo

OpenAI descrive il Customer DNA di Itaú come una rappresentazione del contesto finanziario di circa 70 milioni di clienti. I modelli GPT sono uno dei componenti che possono mantenerla e arricchirla, non il luogo in cui vive l’intero processo. Questa distinzione evita un errore frequente: trasformare il modello in database, motore di regole e interfaccia nello stesso momento.

In un’architettura più semplice, adatta a un’azienda piccola, le responsabilità restano separate:

  • il gestionale, il CRM o WordPress conservano il dato ufficiale;
  • un livello applicativo decide quali record può leggere l’AI;
  • il modello interpreta la richiesta e produce una proposta strutturata;
  • regole deterministiche validano formato, permessi e limiti;
  • l’azione finale viene registrata e, nei casi sensibili, approvata da una persona.

Il modello può essere sostituito senza migrare il processo, perché identità, autorizzazioni, fonti e log non dipendono dal suo prompt. È una scelta tecnica, ma anche economica: permette di usare modelli diversi in base a costo, latenza e complessità. Itaú dichiara di aver scelto uno spettro di modelli proprio per coprire richieste semplici ed economiche e casi che richiedono più ragionamento.

Costruire una IARA in formato PMI

IARA è la piattaforma di governance e orchestrazione con cui Itaú rende disponibili più modelli alle proprie squadre. Secondo il caso pubblicato da OpenAI, questa infrastruttura controlla tre variabili: costo per token, accuratezza delle risposte e applicazione delle policy di AI responsabile. Nel dipartimento legale opera su una base superiore a 90 milioni di documenti ed esegue oltre 2 milioni di attività al mese; i miglioramenti di efficienza dichiarati variano dal 20% all’80% nelle diverse fasi dei processi.

Una PMI non ha bisogno di replicare quella piattaforma. Ha bisogno degli stessi confini in una forma più leggera. Il componente centrale può essere un gateway applicativo o un workflow che riceve la richiesta e applica cinque controlli prima di chiamare il modello:

  1. identifica utente, ruolo e finalità della richiesta;
  2. seleziona soltanto i dati necessari per quel compito;
  3. sceglie modello e budget massimo;
  4. valida l’output con uno schema atteso;
  5. registra versione, fonti, esito, costo ed eventuale approvazione.

Questa è la mia take tecnica sul caso: il primo investimento non dovrebbe essere un prompt più raffinato, ma un punto unico da cui passano provider, autenticazione, routing, limiti e log. Senza quel punto, ogni integrazione diventa un’eccezione difficile da aggiornare. Con quel punto, cambiare provider o abbassare il budget non richiede di riscrivere tutti i flussi.

Rilasciare l’autonomia in quattro fasi

Il percorso più sicuro non distingue fra “AI presente” e “AI assente”. Distingue quanta autonomia riceve il sistema e quanto costa correggerlo. Una sequenza pratica è questa.

1. Valutazione offline

Si raccoglie un set di casi reali già risolti, rimuovendo i dati non necessari. Il sistema produce risposte che nessun cliente vede. Un revisore confronta risultato atteso, fonti utilizzate, errori e omissioni. Il test serve anche a definire quando il sistema deve rispondere “non so” o passare la richiesta a una persona.

2. Modalità sola lettura

L’AI può cercare, riassumere e preparare una bozza, ma non scrive nei sistemi. Ogni output mostra le fonti e resta modificabile. È la fase giusta per misurare tempo risparmiato e tasso di accettazione senza introdurre un rischio operativo elevato.

3. Azioni vincolate

Il sistema può compilare un campo o predisporre un’operazione entro limiti espliciti. Prima dell’esecuzione, un controllo deterministico verifica permessi, valori ammessi e destinazione. Invii, pagamenti, cancellazioni e modifiche irreversibili richiedono ancora conferma umana tramite un outbox.

4. Espansione misurata

Si allargano utenti, documenti o azioni soltanto se le metriche restano entro soglia per un periodo definito. Ogni nuova funzione riapre la valutazione: un assistente affidabile nel recupero di informazioni non è automaticamente pronto a prendere decisioni o agire per conto dell’utente.

Le metriche che decidono il go-live

“La risposta sembra buona” non è un criterio di produzione. Prima del pilot bisogna definire un registro con un responsabile, una soglia e un’azione correttiva per ciascuna misura. Le metriche minime sono sei:

  • correttezza: percentuale di risposte accettate rispetto a un set valutato;
  • fondatezza: presenza di una fonte valida per i claim verificabili;
  • escalation: quota di casi passati correttamente a una persona;
  • latenza: tempo al risultato utile, non soltanto tempo di risposta del modello;
  • costo: spesa per attività completata, inclusa la revisione umana;
  • impatto: tempo risparmiato, errori evitati o aumento di conversione nel processo scelto.

Conviene aggiungere due indicatori negativi: azioni bloccate dai controlli e incidenti sfuggiti ai controlli. Il primo segnala quanto spesso il sistema tenta di uscire dal perimetro; il secondo misura il rischio residuo. Se cresce il volume ma peggiorano escalation o fondatezza, il rollout va fermato anche se il costo per chiamata scende.

I numeri pubblicati da Itaú sono risultati dichiarati dall’azienda, non benchmark universali. Un miglioramento del 20% in una fase documentale non autorizza a promettere lo stesso risultato a un’altra organizzazione. Il baseline della PMI deve essere misurato prima del pilot: tempo medio, errori, rilavorazioni e costo del processo attuale.

Sicurezza e trasparenza prima dell’automazione

Il profilo NIST per l’AI generativa organizza la gestione del rischio lungo quattro funzioni: governare, mappare, misurare e gestire. OWASP indica fra i rischi principali delle applicazioni con modelli linguistici la prompt injection, la divulgazione di informazioni sensibili, la gestione impropria dell’output e l’eccesso di autonomia. Questi rischi diventano concreti quando il modello legge documenti esterni o può chiamare strumenti.

Per ridurli, i contenuti recuperati da email, pagine web o allegati vanno trattati come dati non fidati, non come istruzioni. Le credenziali non devono entrare nel prompt. L’output deve essere sanificato e validato prima di essere mostrato in WordPress, inviato via email o passato a un’API. Gli strumenti devono avere permessi minimi e un elenco chiuso di operazioni. Infine serve un circuit breaker che disattivi il flusso senza spegnere l’intero servizio.

Per le aziende europee la trasparenza non è più soltanto una buona pratica. Dal 2 agosto 2026 l’articolo 50 dell’AI Act applica specifici obblighi di trasparenza: quando una persona interagisce direttamente con un sistema AI deve esserne informata, salvo eccezioni previste. La classificazione giuridica dipende però dal caso d’uso; prima di usare l’AI in ambiti come lavoro, credito o servizi essenziali serve una valutazione legale specifica, non una checklist generica.

Il piano operativo da portare in riunione

Il caso Itaú non dice a una PMI di iniziare da milioni di utenti. Dice di costruire il controllo prima della scala. In una riunione di 45 minuti si può definire il primo esperimento rispondendo a sette domande:

  1. Quale singolo compito ripetitivo vogliamo migliorare?
  2. Qual è il dato ufficiale e chi può leggerlo?
  3. Quale output strutturato deve produrre il modello?
  4. Quali azioni restano vietate o richiedono approvazione?
  5. Quali casi reali useremo per il test offline?
  6. Quali soglie bloccano il rilascio?
  7. Chi controlla log, costi e incidenti dopo il go-live?

Se manca una risposta, non manca un dettaglio tecnico: manca un pezzo del prodotto. Il primo obiettivo non è automatizzare tutto, ma rendere verificabile una decisione alla volta. Solo dopo si estendono utenti, fonti e autonomia. È così che una piattaforma enterprise come IARA diventa una lezione concreta anche per chi lavora con un CRM, WordPress e pochi workflow.

Fonti