La demo funziona. Il problema viene dopo.
Creare un agente AI è la parte più semplice. La vera sfida — quella che decide il successo del progetto — arriva quando lo devi mettere in produzione.
Ho perso il conto delle demo di agenti AI che funzionano benissimo in fase di presentazione e poi si inceppano non appena qualcuno le porta in un contesto reale.
Non è un problema di intelligenza artificiale. È un problema di approccio.
La sindrome del proof of concept
Esiste un pattern che si ripete quasi sempre quando un'organizzazione inizia a costruire sistemi AI: il team concentra tutto sulla demo. L'obiettivo diventa "far girare l'agente", mostrare che risponde bene, che è intelligente, che supera le aspettative del cliente o del dirigente che deve approvare.
La demo riesce. Tutti sono entusiasti. Si procede.
E poi arriva il momento in cui lo stesso sistema deve girare in autonomia su dati reali, gestire volumi che in demo erano simulati, funzionare senza qualcuno che tiene d'occhio il prompt.
È qui che la maggior parte dei progetti si blocca.
Chiamo questo fenomeno "sindrome del proof of concept": l'energia e la competenza vengono investite nella fase più visibile — la dimostrazione — e quasi nulla nel percorso che trasforma quella dimostrazione in un sistema affidabile.
Il vero lavoro: progettare il layer applicativo
Costruire un agente richiede ore. Farlo funzionare in produzione richiede settimane o mesi, e richiede competenze completamente diverse.
Il salto non è tecnico nel senso del modello AI — Claude, GPT-4, Gemini fanno tutti bene il loro lavoro nella sandbox. Il salto è ingegneristico nel senso del sistema che ci sta intorno.
Cosa vuol dire concretamente?
- Come entrano i dati. Un agente in demo riceve input puliti, ben formattati, scritti da chi lo sta testando. In produzione i dati arrivano da database, email, PDF scannerizzati, export da software gestionali. La pulizia, la validazione e l'orchestrazione di questi input è già metà del progetto.
- Come si integrano i flussi. L'agente non lavora mai da solo: si connette ad altri sistemi, scrive su database, invia notifiche, consulta API. Progettare queste integrazioni in modo che siano stabili — e che falliscano in modo prevedibile quando c'è un errore — è un lavoro di architettura che non ha nulla a che fare con la qualità del modello.
- Come si controllano i costi. Una chiamata API in demo è quasi invisibile in termini di costo. Quando l'agente elabora migliaia di richieste al giorno, le stesse scelte di design che funzionavano bene in demo diventano un problema economico serio. La progettazione della scalabilità e del controllo dei costi deve avvenire prima, non dopo.
Cosa cambia nella pratica
Se stai accompagnando un'organizzazione nell'adozione di un agente AI — come formatore, consulente, o responsabile interno — questo è il punto in cui devi orientare l'attenzione.
Non chiedere "l'agente risponde bene?". Chiedere: chi lo monitora in produzione? Cosa succede se un dato entra malformato? Quanto costa se il volume raddoppia?
Queste domande sembrano banali finché non ci si trova a rispondere a un dirigente che chiede perché il sistema — che in demo era perfetto — ora si blocca a giorni alterni.
La pianificazione attenta e l'esecuzione precisa sono le vere competenze richieste per passare da un proof of concept a un'applicazione che funziona davvero. Non sono skill dell'AI — sono skill di progettazione, di ingegneria del software, di gestione del rischio.
L'entusiasmo per la demo è necessario. Ma non è sufficiente.
Il lavoro vero inizia quando la demo è finita.