Perché i progetti AI si fermano al prototipo (e cosa hanno in comune quelli che arrivano in produzione)

Quasi tutte le aziende con cui parlo hanno già un prototipo di AI. In demo rispondeva bene, è piaciuto alla direzione, e sei mesi dopo gira ancora sul portatile di qualcuno o in un ambiente di test che nessuno apre più. Il modello quasi mai c'entra: il prototipo si ferma per decisioni che andavano prese prima di scrivere il primo prompt, e che dopo una demo riuscita, con tutti che chiedono la data di partenza, diventano molto più difficili da prendere.

Quanti progetti AI si fermano dopo il proof of concept?

Abbastanza da finire nelle previsioni degli analisti. A luglio 2024 Gartner ha previsto che almeno il 30% dei progetti di AI generativa sarebbe stato abbandonato dopo il proof of concept entro la fine del 2025, per scarsa qualità dei dati, controlli sui rischi inadeguati, costi in crescita o valore di business poco chiaro (Gartner, luglio 2024). A giugno 2025 ha previsto che oltre il 40% dei progetti di agentic AI verrà cancellato entro la fine del 2027, per costi in crescita, valore poco chiaro o controlli sui rischi inadeguati (Gartner, giugno 2025).

Sono previsioni e non tassi di fallimento misurati, quindi non le userei come statistiche. Serve l'elenco dei motivi: costi, valore, controlli sui rischi e qualità dei dati si possono verificare prima che il pilota parta, e per la mia esperienza è lì che si decide quasi tutto.

Perché un prototipo AI che funziona in demo non va in produzione?

La demo dimostra che il modello sa fare il compito su esempi scelti da qualcuno. La produzione fa altre domande: meglio di cosa, su quali casi, cosa succede quando sbaglia, dove finiscono i dati, quanto costa a pieno volume. Un prototipo costruito senza queste risposte non ha niente da mostrare a chi deve autorizzare il rilascio. In tabella i blocchi che vedo più spesso, con il segnale che li rivela.

Cosa hanno in comune i progetti AI che arrivano in produzione?

Ho portato in produzione sistemi AI molto diversi tra loro: un agente LLM che smista oltre 1 milione di ticket l'anno dell'help desk di una grande banca italiana, le verifiche automatiche sulle pratiche di successione, una pipeline che estrae dati da oltre 2.500 bilanci al giorno, un agente vocale real-time per la segreteria di un poliambulatorio e le pipeline AI di una piattaforma finanziaria consumer. Avevano in comune poche decisioni prese presto, e ciascuna delle prossime cinque sezioni ne descrive una.

Perché misurare il processo attuale prima di costruire l'AI?

Senza un riferimento nessuno può dire se il sistema funziona. Con un riferimento, la riunione con il comitato diventa un confronto tra numeri. Nell'help desk della banca, le persone che smistavano i ticket a mano azzeccavano la categoria il 75% delle volte, su oltre 400 categorie. L'agente LLM è arrivato all'81% e il tempo medio di risoluzione è sceso da 5-6 giorni a 2-3, perché meno ticket rimbalzavano tra i team sbagliati. Sono questi numeri che hanno fatto superare al progetto la fase pilota. I dettagli sono nel caso studio sullo smistamento dei ticket.

Se il riferimento non esiste, misurarlo è il primo lavoro. Di solito basta un campione di qualche centinaio di casi reali e una persona che segna quanto tempo ci vuole e quante volte si sbaglia. È un lavoro noioso, e decide se un 81% verrà letto come un successo o come un sistema che sbaglia una volta su cinque.

Quanto deve essere stretto il perimetro del primo progetto AI?

Più stretto di quanto sembri ragionevole. L'agente vocale di IGEA, che ho co-fondato e di cui sono CTO, risponde alle chiamate della segreteria di un poliambulatorio e gestisce prenotazioni, spostamenti e disdette. Non fa triage medico, per scelta. Quella scelta lo ha reso prevedibile, ed è il motivo per cui era pienamente operativo, con il personale formato, in 2 settimane in un centro con oltre 40 medici. Nel primo mese ha perso 0 chiamate con un punteggio di successo del 96,7%.

Con un perimetro più largo avremmo passato mesi sui casi limite, e la discussione sui rischi con la struttura sarebbe stata molto più difficile. Quando un perimetro stretto funziona con continuità, aggiungere il compito successivo è un progetto più piccolo che partire larghi.

Cosa deve succedere quando l'AI sbaglia un caso?

Ogni modello sbaglia qualche caso, quindi prima del pilota va deciso cosa fa il sistema con quei casi. Nei miei progetti sui documenti ha funzionato sempre lo stesso schema: i casi che superano tutti i controlli passano in automatico, gli altri vanno a una persona con il motivo preciso per cui il controllo è fallito.

Nelle verifiche sulle pratiche di successione per una grande banca italiana i documenti vengono confrontati con i dati che la banca ha già. Le pratiche standard procedono senza intervento umano, e quando un controllo fallisce la pratica arriva all'operatore con la discrepanza indicata: l'operatore verifica un punto invece di rileggere tutto. I tempi di gestione sono scesi dell'80%. Nella pipeline sui bilanci girano circa 30 controlli su ogni documento (per esempio totali che devono quadrare) e il lavoro manuale è sceso dell'84%. In entrambi i casi l'affidabilità viene dai controlli, ed è anche quello che permette a un comitato rischi di approvare il sistema.

Quando decidere dove girano i dati e i modelli?

Prima di scrivere codice. Nei miei progetti bancari i modelli giravano su Azure OpenAI nel cloud UE del cliente, nessun dato sensibile finiva nei log e ogni documento in produzione aveva il suo audit trail. Alcune pipeline giravano interamente sull'OpenShift della banca. Niente di tutto questo si aggiunge dopo una demo costruita su un'API pubblica con dati veri nei prompt, e per una PMI vale lo stesso discorso con il DPO e il GDPR: dove vanno i dati dei clienti va deciso all'inizio.

Le integrazioni con i sistemi di una grande azienda richiedono più tempo di un prototipo per via delle verifiche di sicurezza e compliance. Quel tempo fa parte del progetto e va messo in calendario. Un pilota progettato fin dall'inizio per il cloud approvato arriva alla security review con quasi tutte le risposte pronte.

Perché registrare il costo di ogni chiamata AI fin dalla prima versione?

Un prototipo che costa pochi centesimi a richiesta sembra economico finché non lo si moltiplica per il volume reale. Con 1 milione di ticket l'anno o 2.500 documenti al giorno, piccole inefficienze diventano una voce di budget che qualcuno metterà in discussione. Quando ho preso in mano le pipeline AI di una piattaforma finanziaria consumer, facevano più chiamate al modello del necessario, mandavano contesto sovradimensionato e non avevano un tetto di spesa. Eliminare le chiamate ridondanti, ridurre il contesto, mettere in cache le risposte ripetute e introdurre tetti di spesa e rate limit ha ridotto i costi AI di circa l'80% con le stesse funzionalità. Oggi ogni report generato registra il proprio costo.

Se il costo unitario è registrato dalla prima versione, il business case per la produzione è un conto che chiunque può rifare. Se manca, il costo diventa uno dei motivi per fermare il progetto. Cosa è cambiato è descritto nel caso studio sulla riduzione dei costi AI.

Quale primo progetto AI ha più probabilità di arrivare in produzione?

Un processo interno, con volumi alti e un riferimento misurabile: smistamento di richieste, verifiche documentali, estrazione di dati. Usa dati che sono già dentro il perimetro aziendale, gli errori arrivano a un collega prima che a un cliente e i risultati si confrontano facilmente con il processo precedente. Un progetto rivolto ai clienti può funzionare, come mostra l'agente vocale del poliambulatorio, ma solo con un perimetro abbastanza stretto da essere affidabile dal primo giorno.

Come primo passo eviterei la richiesta tipica di un assistente che sa tutto dell'azienda. Per un compito così generico non esiste un riferimento da misurare, e nessuno può dire quando il progetto è finito.

Cosa verificare prima di avviare un pilota AI?

Quali errori evitare nel passaggio da pilota a produzione?

Il primo è giudicare il pilota da una demo invece che da un campione di casi reali, compresi quelli scritti male. Il secondo è presentare l'accuratezza media senza dire che fine fanno gli errori: un comitato rischi chiederà dove va a finire il 19% sbagliato. Il terzo è far partire la security review a pilota finito, quando l'architettura è già decisa. Poi c'è il perimetro che si allarga durante il pilota perché i primi risultati sembrano buoni. L'ultimo è trattare i costi come un problema da affrontare dopo, quando il pilota è il momento più economico per misurarli.

Se lavorate in una banca o in una società finanziaria, la pagina sulla consulenza AI per banche e servizi finanziari descrive come scelgo e porto in produzione i primi casi d'uso. Per agenti in altri settori c'è la pagina sullo sviluppo di agenti AI.