La maggior parte dei progetti con agenti AI non muore in produzione. Muore nei tre mesi che separano una demo promettente da un business owner che smette silenziosamente di rispondere alle email del fornitore.
La demo ha funzionato. Il concept era solido. Tra il kickoff e il lancio, il progetto si è semplicemente… bloccato. Se stai pianificando un progetto con agenti AI — o cercando di salvarne uno che ha già perso slancio — capire perché i progetti con agenti AI falliscono è più utile di qualsiasi guida tecnologica. I problemi non sono quasi mai tecnici.
I quattro pattern di fallimento che vediamo ripetutamente
Dopo aver costruito e distribuito agenti AI personalizzati per PMI in tutta la Svizzera e in Europa, gli stessi quattro punti critici emergono con una regolarità scomoda.
1. Uno scope che nessuno riusciva davvero a definire
Il più comune. Un progetto parte con un brief del tipo: “Vogliamo un agente AI per gestire le richieste dei clienti.” Nessun dato sui volumi in entrata, nessuna definizione di cosa significhi “gestire”, nessun elenco di casi limite, nessun accordo su cosa debba fare l’agente quando non riesce ad aiutare.
Senza uno scope preciso, ogni conversazione riparte da zero. Il fornitore interpreta “gestire” come deflettere; il cliente intende risolvere. Alla quarta settimana, entrambe le parti stanno costruendo cose diverse. Il progetto si espande per coprire ogni scenario possibile, le stime di costo quadruplicano e qualcuno alla fine stacca la spina.
Come dovrebbe essere: un documento di scope che nomina gli esatti eventi scatenanti, le fonti di dati che l’agente è autorizzato a utilizzare, le condizioni di escalation e la definizione di un risultato positivo — tutto concordato e firmato prima che venga scritto una sola riga di codice.
2. Nessun process owner lato business
I fornitori tecnicamente capaci possono costruire esattamente ciò che specifichi, ma non possono sostituire la conoscenza interna. Ogni progetto con agenti AI ha bisogno di qualcuno lato cliente che conosca il flusso di lavoro reale, possa rispondere a domande sui casi limite e abbia l’autorità di prendere decisioni quando i requisiti confliggono.
Quando questa persona non esiste — o esiste sulla carta ma è troppo occupata — il progetto deriva. Gli sviluppatori fanno ipotesi. Le ipotesi si accumulano. Quando qualcuno di senior esamina il risultato, l’agente gestisce correttamente il 60% dei casi e nessuno sa se questo sia accettabile o no.
La responsabilità di processo non è un compito part-time. Per un progetto di una certa portata, aspettati di dedicare da due a quattro ore settimanali da parte di chi gestisce davvero il processo che stai automatizzando.
3. Nessun framework di valutazione prima dello sviluppo
Come sai che l’agente funziona? Se non riesci a rispondere a questa domanda prima che il progetto inizi, non ci riuscirai nemmeno dopo il lancio.
I team che saltano la progettazione della valutazione finiscono per avere agenti in produzione che nessuno si fida, nessuno monitora e alla fine nessuno usa. “Sembrava a posto nei test” non è uno standard di qualità. Nemmeno “gli utenti non si sono ancora lamentati.”
Un framework di valutazione minimo risponde a tre domande: come appare il comportamento corretto su un campione rappresentativo di input reali, chi esamina i casi limite e come si riconosce una regressione? Vedi Testare gli agenti AI: come le valutazioni mantengono l’automazione affidabile per un approfondimento su come funziona nella pratica.
4. Confondere il successo del pilot con la prontezza in produzione
Un pilot che funziona su 50 casi di test selezionati non è un agente pronto a gestire 5.000 interazioni live. Il divario tra i due è dove la maggior parte dei progetti si scontra con un muro inaspettato.
La produzione reale introduce: input che nessuno aveva pensato di testare, guasti alle integrazioni sotto carico, latenze che erano accettabili con traffico ridotto, e utenti che interagiscono con il sistema in modi che il team di design non aveva mai anticipato. Un agente che ha performato perfettamente in un ambiente controllato può diventare un problema il lunedì mattina.
La transizione da pilot a produzione ha bisogno di una propria fase di progetto, di un proprio budget e di propri criteri di successo. I team che trattano il go-live come il traguardo finale tendono a scoprire perché si tratta di un errore.
Perché questi fallimenti si concentrano insieme
Nessuno dei quattro pattern descritti sopra riguarda il modello AI, il framework o l’infrastruttura. Sono problemi organizzativi e di processo che indossano un costume tecnologico.
Questo è importante perché sposta dove il rischio si trova davvero. La domanda “quale framework AI dovremmo usare?” è molto meno importante di “abbiamo definito come appare il risultato finale?” Un progetto costruito sul framework giusto con uno scope vago fallirà. Un progetto costruito su uno stack più semplice ma con uno scope rigoroso e un process owner solido verrà consegnato.
Detto questo, le scelte tecniche sbagliate possono amplificare i fallimenti organizzativi. Un agente costruito su una piattaforma no-code — dove i limiti mensili di esecuzione o il pricing per interazione possono diventare vincolanti al volume di produzione — non ti dà il margine per correggere i problemi di processo in corsa. Se stai valutando decisioni di build vs. buy, Implementare gli agenti AI nella tua azienda: una roadmap per fasi e Misurare il ROI degli agenti AI: un framework per le PMI coprono la logica di valutazione che dovrebbe precedere qualsiasi scelta tecnica.
Una checklist per ridurre il rischio — per chi acquista
Scorri questa lista prima di approvare qualsiasi progetto con agenti AI. Se non riesci a rispondere a una domanda, quella è una lacuna da colmare — non un dettaglio da gestire in seguito.
Scope e requisiti
- La condizione scatenante dell’agente è inequivocabile? (Cosa avvia l’interazione?)
- Esiste un elenco scritto di cosa l’agente può e non può fare?
- Le condizioni di escalation sono definite? (Quando subentra un essere umano, e come?)
- La definizione di successo è concordata per iscritto — non “funziona bene” ma misurabile?
Responsabilità di processo
- C’è un process owner lato business nominato con autorità decisionale?
- Questa persona si è impegnata a dedicare un numero realistico di ore settimanali al progetto?
- Ha accesso ai dati del flusso di lavoro reale — non a una versione demo ripulita?
Valutazione
- Hai un set rappresentativo di input reali su cui testare prima del lancio?
- C’è una soglia concordata su cosa significhi buona performance?
- Chi esamina i casi di fallimento, e con quale frequenza?
Pianificazione da pilot a produzione
- Esiste un budget e una timeline separati per il consolidamento post-pilot?
- L’agente è stato testato con volumi di input realistici, non solo campioni selezionati?
- C’è un piano di rollback se il comportamento in produzione degrada?
Responsabilità del fornitore
- Il fornitore è responsabile della consegna di risultati definiti, o solo di ore di lavoro?
- C’è un periodo di supporto post-lancio definito?
- I processi di pricing e di modifica dello scope sono chiari?
Se vuoi valutare quanto è preparata la tua organizzazione prima di iniziare, La tua azienda è pronta per gli agenti AI? copre le dimensioni della preparazione in modo più dettagliato.
Il lato fornitore dell’equazione
Una checklist di de-risking ti aiuta come acquirente, ma funziona solo se il fornitore che scegli è disposto ad affrontarla con onestà. I segnali d’allarme lato fornitore includono:
- Impegnarsi su un prezzo fisso prima che lo scope sia definito
- Mostrarti una demo prima di aver capito il tuo flusso di lavoro reale
- Nessuna discussione sulla metodologia di valutazione o testing
- Un modello di handoff in cui “costruiscono e ti formano” invece di restare responsabili della performance in produzione
Il fornitore giusto rallenta prima che lo scope sia chiaro. Pone domande scomode sulla responsabilità di processo. Propone un framework di valutazione e lo inserisce nel contratto. Quella frizione all’inizio del processo è ciò che previene il blocco silenzioso tre mesi dopo.
Il nostro servizio di AI Strategy esiste precisamente per questa fase pre-sviluppo — aiutando le organizzazioni a definire lo scope, stabilire i criteri di valutazione e identificare dove un agente creerà davvero valore prima che inizi qualsiasi sviluppo.
Esiste una versione di ogni progetto con agenti AI fallito in cui un’unica conversazione onesta — due settimane prima che il lavoro iniziasse — avrebbe cambiato tutto. La tecnologia non ha quasi mai bisogno di essere difesa. Il processo sì.
Se hai un progetto che stai cercando di definire, o uno che si è già bloccato, prenota una chiamata di 30 minuti con il team di Orange ITS. Ti diremo onestamente se le basi sono a posto — e cosa deve cambiare se non lo sono.
Domande frequenti
Qual è la causa più comune di fallimento dei progetti con agenti AI?
Uno scope che nessuno ha davvero definito: brief come vogliamo un agente per gestire le richieste, senza dati sui volumi, senza definizione di gestire e senza condizioni di escalation. Il fornitore interpreta in un modo, il cliente in un altro, i costi quadruplicano e qualcuno stacca la spina.
I fallimenti dei progetti di agenti AI sono problemi tecnici?
Quasi mai: i quattro pattern ricorrenti (scope vago, assenza di process owner, nessun framework di valutazione, confusione tra pilot e produzione) sono problemi organizzativi e di processo con un costume tecnologico. Un progetto sul framework giusto ma con scope vago fallisce; uno su stack più semplice con scope rigoroso viene consegnato.
Che ruolo ha il process owner lato business e quanto tempo richiede?
Serve qualcuno lato cliente che conosca il flusso di lavoro reale, risponda alle domande sui casi limite e abbia autorità decisionale quando i requisiti confliggono. Per un progetto di una certa portata, va previsto un impegno di due-quattro ore settimanali da parte di chi gestisce davvero il processo.
Perché un pilot riuscito non significa prontezza per la produzione?
Un pilot su 50 casi di test selezionati non è un agente pronto per 5.000 interazioni live: la produzione introduce input imprevisti, guasti alle integrazioni sotto carico, latenze e comportamenti degli utenti mai anticipati. La transizione richiede una fase di progetto dedicata, con proprio budget, timeline e piano di rollback.
Quali segnali d'allarme indicano un fornitore inaffidabile?
Un prezzo fisso promesso prima che lo scope sia definito, una demo mostrata prima di aver capito il flusso di lavoro reale, nessuna discussione sulla metodologia di valutazione e un modello di handoff dove il fornitore costruisce e forma senza restare responsabile della performance in produzione. Il fornitore giusto rallenta finché lo scope non è chiaro.