PoC di agenti AI: come impostarle perché arrivino in produzione

Un agente che prenota, un agente che risponde ai clienti, un agente che riconcilia fatture. Nei board di cui faccio parte la domanda è sempre la stessa: facciamo una PoC? La risposta giusta esiste, ma dipende da come la PoC viene impostata, da cosa deve dimostrare e da chi decide cosa succede dopo.

Perché il problema non è partire. Il 71% delle grandi imprese italiane ha progetti AI attivi, solo il 9% ha una governance strutturata (Osservatorio Artificial Intelligence, Politecnico di Milano, febbraio 2026). Le PoC si fanno, tante. Poi restano lì, in quel limbo che chiamiamo pilot purgatory: dimostrazioni che hanno funzionato una volta, davanti alle persone giuste, e che nessuno ha mai portato oltre.

Il 40% dei progetti agentici verrà cancellato entro il 2027

La stima è di Gartner, giugno 2025: oltre il 40% dei progetti di agentic AI verrà cancellato entro fine 2027 per costi crescenti, valore di business poco chiaro o controlli di rischio inadeguati. Anushree Verma, analista di Gartner, dichiara che la maggior parte dei progetti agentici oggi sono esperimenti o proof of concept guidati dall'hype, spesso applicati male.

Il MIT, con il progetto NANDA, era arrivato a una conclusione ancora più dura nell'estate 2025: il 95% dei pilot di AI generativa non produce impatto misurabile sul conto economico.

Ecco, questi numeri raccontano una cosa precisa, che vediamo ogni settimana nei nostri assessment: le PoC falliscono quando nascono per impressionare qualcuno invece che per informare una decisione. E una PoC che non serve a decidere è un costo travestito da innovazione.

Una PoC senza criteri definiti a monte è una demo

La differenza tra una demo e una proof of concept sta tutta in un documento che quasi nessuno scrive: i criteri di successo, fissati prima di scrivere una riga di codice.

Per un agente AI i criteri non possono limitarsi a "funziona". Un agente prende decisioni in autonomia, tocca sistemi reali, produce output che qualcuno userà, e quindi va misurato su dimensioni che una demo non mostra mai: il tasso di completamento del task su casi reali e non su esempi selezionati, il comportamento sugli edge case, il costo per esecuzione (token, chiamate API, tempo di supervisione umana), la frequenza con cui serve l'intervento di una persona, cosa succede quando l'agente sbaglia.

Nel nostro modello lo formalizziamo così: la PoC parte con dati e contesto reali, con criteri di successo definiti a monte, e produce tre output possibili, scala, correggi, ferma. Il prototipo non è un fine, è uno strumento decisionale. Se alla fine della PoC non sapete cosa costerebbe portarla in produzione e quali condizioni la renderebbero sostenibile, la PoC vi ha regalato applausi e nessuna risposta.

C'è anche un test preliminare che consigliamo sempre, perché filtra metà delle richieste: questo caso d'uso ha davvero bisogno di un agente? Molti processi si risolvono con automazione tradizionale o con un assistente ben integrato, a costi e rischi molto più bassi. Gartner segnala che gran parte dei casi d'uso presentati come agentici non richiedono affatto implementazioni agentiche. Scegliere l'agente quando basta un workflow è il primo errore economico, e si commette prima ancora di iniziare.

L'errore economico: la PoC che diventa produzione per inerzia

La scena tipica: la PoC piace, lo sponsor vuole andare veloce, e il team porta in produzione la stessa architettura della PoC. Nessuno ha stimato i costi a regime, nessuno ha verificato l'integrazione con ERP e CRM, nessuno ha previsto il monitoraggio.

Sei mesi dopo i costi operativi sono il doppio o il triplo delle stime, perché una PoC ottimizza per la velocità di dimostrazione, non per l'efficienza di esercizio. Un agente che in demo costa pochi centesimi a esecuzione, in produzione, con retry, contesto ampio, orchestrazione di più modelli e supervisione umana, cambia ordine di grandezza.

La PoC ben fatta contiene già l'antidoto: tra i criteri di successo c'è la stima realistica di costi e complessità di produzione. Se la PoC dimostra che il caso d'uso funziona ma costerebbe più del processo che sostituisce, è una PoC riuscita, con esito negativo. Ha evitato un investimento sbagliato, che è esattamente il suo lavoro. La nostra proposta di valore include il dire "stop", quando i numeri lo dicono.

L'errore normativo: la PoC come zona franca

Qui vediamo l'ingenuità più diffusa. "È solo una PoC" viene usato come esenzione implicita: dati reali dei clienti dentro un prototipo, nessun registro, nessuna valutazione del rischio, fornitori scelti senza verifiche.

Una PoC che usa dati personali reali è un trattamento a tutti gli effetti, e il GDPR non prevede sconti per gli esperimenti. E con l'AI Act la classificazione del rischio va fatta all'inizio, non alla fine: se il caso d'uso che state prototipando rientra tra i sistemi ad alto rischio (selezione del personale, credito, accesso a servizi essenziali), le scelte fatte in PoC, dai dataset alla supervisione umana, determinano quanto costerà la conformità dopo. Il calendario aggiornato dal regolamento 2026/1744 sposta gli obblighi per i sistemi ad alto rischio dell'Allegato III al 2 dicembre 2027, con i nuovi divieti in vigore dal 2 dicembre 2026: finestre di decisione, per chi sta prototipando adesso, più che scadenze amministrative.

Per gli agenti il tema si amplifica, perché un agente agisce: scrive su sistemi reali e prende micro-decisioni per conto vostro. La supervisione umana richiesta dalla normativa per i casi rilevanti va progettata nel prototipo, insieme a log delle azioni e possibilità di intervento, perché aggiungerla dopo significa riprogettare. Nel nostro AI Rating questa è la dimensione Risk, e contiene quelli che chiamiamo gate critici: parametri non compensabili, dove un'eccellenza tecnica altrove non ripaga una carenza su compliance o etica. Un'azienda con delivery da classe A e un registro dei sistemi AI inesistente resta in classe C, e la logica vale identica per le PoC.

Prima il rating, poi il prototipo

Tutto questo spiega la sequenza del nostro metodo, che a qualcuno all'inizio sembra lenta e poi si rivela il modo più rapido per arrivare in produzione davvero.

Prima si misura: l'AI Rating fotografa la maturità su quattro dimensioni (Readiness, Delivery, Risk, Confidence) e dice se l'organizzazione ha le condizioni per portare un agente oltre il prototipo. Una PoC di agente in un'azienda senza dati accessibili, senza ownership chiara e senza pratiche di monitoraggio produrrà una bella demo e nient'altro, e saperlo prima costa una frazione di quanto costa scoprirlo dopo.

Poi si decide: quale caso d'uso, con quali criteri di successo, con quale soglia di stop. Poi si valida, ed è il mestiere di protot.ai, la nostra unit di fast prototyping: prototipi in una-tre settimane, MVP in quattro-otto, su dati reali, con l'esplicito mandato di mettere alla prova l'ipotesi prima della produzione. protot.ai prova, ZeroFive costruisce in produzione e governa: la separazione è voluta, perché chi valida non deve avere interesse a vendere l'implementazione, altrimenti ogni PoC finisce miracolosamente per "funzionare".

Nei 34 e più assessment e progetti che abbiamo condotto, la correlazione più netta è questa: le PoC che arrivano in produzione sono quelle nate dentro un percorso di decisione, con uno sponsor executive che ha già stabilito cosa farà con l'esito, qualunque esso sia.

La domanda da farsi, prima di stanziare il budget per la prossima PoC di agenti, viene molto prima della scelta del modello o del vendor: se il prototipo funzionasse, sareste in grado di portarlo in produzione e di governarlo? Se la risposta è incerta, la PoC da fare per prima è quella sulla vostra organizzazione.