Un progetto AI non è riuscito quando l'agente risponde. È riuscito quando produce un risultato misurabile, in modo sicuro, adottato e sostenibile nel tempo.
La distanza fra le due cose è dove i progetti si fermano, e non è una questione di opinione. Salesforce rileva che l'ostacolo principale per chi vuole ottenere valore da dati e AI resta la qualità dei dati - incompleti, non aggiornati o inaffidabili - e che solo il 43% dei responsabili data & analytics ha framework e policy formali di data governance (State of Data and Analytics). Gartner, dal canto suo, collega l'abbandono dei progetti a quattro cause ricorrenti: qualità dei dati, controlli di rischio inadeguati, costi in crescita e valore di business poco chiaro.
Il problema non è solo tecnico
Un progetto AI mette insieme tecnologia, dati, processi, persone e responsabilità. La piattaforma scelta - Salesforce, Agentforce, Data 360, ChatGPT, Claude, Slack o un'architettura headless - è una parte della soluzione, non la soluzione. Deve inserirsi in un processo reale, usare dati affidabili, rispettare le autorizzazioni esistenti e produrre un risultato che l'azienda sappia misurare.
Quando uno di questi elementi manca, il progetto può arrivare al go-live senza diventare un sistema operativo. Sotto ci sono le sei cause che si ripetono più spesso, e cosa fare per ciascuna.
1. Nessuno possiede il risultato
L'IT gestisce la piattaforma, il business usa il processo, un team dati gestisce le fonti. Nessuna di queste funzioni, da sola, risponde del risultato complessivo.
Dopo il rilascio qualcuno deve decidere quali casi d'uso hanno priorità, quali dati sono affidabili per l'agente, quali utenti accedono a quali informazioni, quando correggere un comportamento, e quando estendere, modificare o fermare l'iniziativa.
Senza un owner con autorità su processo e priorità, la soluzione smette di evolvere: gli utenti incontrano eccezioni, i dati cambiano, emergono nuove esigenze e nessuno ha il mandato per intervenire.
Cosa fare: nominare un business owner prima del kickoff. Non la persona che raccoglie feedback e partecipa alle riunioni, ma qualcuno con autorità su priorità, processo, metriche e coinvolgimento degli stakeholder.
2. I dati non sono pronti per l'AI
Un agente può usare dati CRM, documenti, knowledge base, ERP, ticketing e fonti esterne. Se quelle fonti sono incomplete, duplicate, obsolete o in conflitto, il rischio non è solo una risposta imprecisa: è che gli utenti smettano di fidarsi della soluzione, e a quel punto il progetto è finito anche se il sistema funziona.
Su un campione di 1.203 responsabili della gestione dati, Gartner ha rilevato che il 63% delle organizzazioni non ha, o non sa di avere, pratiche di data management adeguate all'AI, e ha previsto che nel corso del 2026 il 60% dei progetti AI non supportati da dati pronti sarebbe stato abbandonato (Gartner, febbraio 2025).
Cosa fare: prima di progettare l'agente, verificate il caso d'uso su un campione di dati reali.
- Quali sono le fonti autorevoli?
- Quali campi sono indispensabili?
- Quanto sono completi e aggiornati?
- Esistono duplicati o valori incoerenti?
- Chi è responsabile della qualità?
- Quali dati non devono essere usati dall'agente?
La bonifica non deve coprire l'intero CRM. Deve coprire i dati indispensabili al primo caso d'uso.
3. Accessi e sicurezza arrivano troppo tardi
Una persona consulta il CRM dentro ruoli, profili e regole di condivisione già definite. Un agente recupera e combina informazioni da più oggetti, documenti e sistemi per rispondere a una richiesta: è un modo di leggere che il modello di visibilità esistente non è stato progettato per prevedere.
Le domande da porre durante l'analisi, non dopo:
- Quali dati può leggere l'agente, e in quale contesto?
- La risposta cambia in base all'utente che la richiede?
- Quali dati riservati vanno esclusi?
- Quali azioni può eseguire in autonomia, e quali richiedono approvazione?
- Come vengono registrate richieste, fonti e azioni?
Non è una preoccupazione teorica: nelle organizzazioni con maturità AI alta, il 48% dei responsabili indica le minacce di sicurezza fra le prime tre barriere all'implementazione (Gartner, giugno 2025). Sono le aziende più avanti, cioè quelle che ci sono già passate.
Cosa fare: costruire una matrice di accesso durante l'analisi, insieme a business owner, IT, security, privacy e legal, che per ogni caso d'uso e tipo di utente dica cosa può vedere, cosa può chiedere, cosa può modificare, cosa l'agente fa da solo, quando serve un'approvazione e quali dati vanno mascherati o esclusi.
4. Il caso d'uso non è abbastanza concreto
Molti progetti partono da "come usiamo l'AI?" invece che da un problema operativo preciso. In quel caso il partner può proporre un caso d'uso ragionevole e ben costruito, ma non prioritario per voi. Il rischio non è che la soluzione sia sbagliata: è che automatizzi un'attività marginale, con pochi utenti, il cui valore non giustifica costi e manutenzione.
Alla scelta del caso d'uso si aggiunge un problema di mercato. Gartner parla di "agent washing": prodotti esistenti - assistenti, RPA, chatbot - rimarchiati come agentici senza capacità agentiche sostanziali. La stima è che solo circa 130 dei migliaia di vendor che si presentano come agentic AI lo siano davvero (Gartner, giugno 2025). Molti casi d'uso presentati oggi come agentici non richiedono un'implementazione agentica.
Le organizzazioni con maturità AI più alta scelgono i progetti combinando valore di business e fattibilità tecnica, ed è una disciplina che si vede nei numeri: il 45% mantiene le iniziative in produzione per tre anni o più, contro il 20% di quelle a bassa maturità.
Cosa fare: valutate ogni caso d'uso su quattro dimensioni e scegliete il primo che va bene su tutte e quattro, non quello con la demo migliore.
| Criterio | Domanda |
|---|---|
| Volume | Quante volte al mese avviene questa attività? |
| Ripetitività | Il processo segue regole sufficientemente stabili? |
| Dati | Le informazioni necessarie sono disponibili e affidabili? |
| Valore | Quanto tempo, costo o rischio può ridurre? |
5. Il valore non è stato definito prima
Un progetto può essere usato e non produrre abbastanza valore. Senza una baseline presa prima dell'avvio, dopo il go-live è difficile dimostrare se tempi, ticket, costi, qualità o produttività siano migliorati davvero. Restano le testimonianze dei singoli: utili, insufficienti a difendere un investimento ricorrente davanti a chi tiene il budget.
Anche qui la differenza fra chi riesce e chi no è misurata: il 63% delle organizzazioni ad alta maturità AI adotta metriche formali, e il 57% dichiara che le funzioni di business si fidano delle nuove soluzioni AI e sono pronte a usarle - contro il 14% di quelle a bassa maturità.
Cosa fare: prima di partire, definite una metrica primaria, il suo valore iniziale, il risultato atteso, la data di misurazione, la fonte dati per calcolarla e chi verificherà. Per esempio:
Ridurre del 20% i ticket interni sulle richieste HR entro sei mesi dal go-live, misurando i ticket chiusi nel sistema di assistenza.
"Migliorare l'esperienza utente" è un obiettivo. Non è ancora un criterio di successo.
6. Non esiste un criterio per fermarsi
Un pilota non deve dimostrare che l'AI funziona in generale. Deve verificare se uno specifico caso d'uso è sostenibile nel vostro contesto.
Senza criteri stabiliti prima, un pilota si estende senza una decisione esplicita: non è abbastanza convincente per essere scalato, ma nessuno lo chiude. Consuma risorse e occupa il posto di un caso d'uso migliore. Nel luglio 2024 Gartner prevedeva che almeno il 30% dei progetti di AI generativa sarebbe stato abbandonato dopo il proof of concept entro fine 2025 (Gartner, luglio 2024); per i progetti agentici la previsione più recente parla di oltre il 40% cancellati entro fine 2027. Cambia il numero, non la causa: costi in crescita, valore poco chiaro, controlli di rischio inadeguati.
Cosa fare: definite prima dell'avvio quanto dura il pilota, quali utenti e dati coinvolge, quali metriche osserverete, quale soglia minima deve raggiungere, quali rischi impongono di sospendere e chi prende la decisione finale. Per esempio:
Dopo otto settimane estendiamo il pilota solo se l'agente risolve senza escalation almeno il 60% delle richieste nel perimetro, con feedback positivo degli utenti e senza incidenti di sicurezza rilevanti.
Il criterio di stop non è una previsione di fallimento. È il modo per sperimentare in modo controllato.
Il denominatore comune
Dati, governance, accessi, scelta del caso d'uso, misura del valore e criteri di stop non sono attività accessorie all'implementazione. Sono il progetto.
Il partner può fornire metodo, piattaforma, competenze tecniche e supporto. L'azienda deve mantenere la responsabilità delle decisioni su processo, dati, priorità, rischio e valore. Questa distribuzione va chiarita prima dell'avvio, ed è il tema di cosa chiedere a un partner prima di firmare.
Segnali precoci
State accumulando rischio se, a progetto avviato:
- nessuno sa indicare il business owner del caso d'uso;
- non esiste un elenco delle fonti dati con i relativi responsabili;
- il team non sa dire cosa può vedere o fare l'agente per ciascun tipo di utente;
- i test usano solo dati demo o un ambiente non rappresentativo;
- la metrica di successo non ha una baseline;
- consumo, costi ricorrenti e modello di supporto non sono stati discussi;
- molte decisioni critiche vengono rinviate al go-live.
Un segnale solo non vuol dire che il progetto fallirà. Più segnali insieme dicono che conviene fermarsi, chiarire il perimetro e aggiornare piano, responsabilità o architettura.
Domande frequenti
Il fornitore è responsabile se il progetto non genera valore?
Il partner risponde del perimetro, della qualità del delivery e degli impegni contrattuali concordati. Il cliente resta responsabile di priorità, process owner, disponibilità dei dati, decisioni sugli accessi, adozione e misurazione del valore. Per questo quegli elementi devono comparire nel piano di progetto e nella governance, non solo nelle conversazioni iniziali.
Si può recuperare un progetto già partito male?
Spesso sì. Il primo passo è capire se il problema è tecnico oppure se manca una decisione su processo, dati, accessi, responsabilità o metrica. Poi si restringe il perimetro a un caso d'uso gestibile, si nomina un owner, si stabilisce una baseline e si decide quali dati e integrazioni servono davvero. Non sempre serve una nuova piattaforma: a volte serve definire con precisione il problema.
Un progetto AI può essere piccolo?
Sì, e spesso dovrebbe iniziare così. Un caso d'uso limitato, con utenti reali, dati rappresentativi, autorizzazioni verificate e una metrica chiara produce più apprendimento di un programma ampio senza priorità. L'obiettivo iniziale è capire se la soluzione genera valore nel vostro contesto; solo dopo ha senso estenderla.
Approfondimenti
- Conviene Agentforce? - le quattro condizioni da verificare prima di partire.
- Cosa chiedere a un partner prima di firmare
- Readiness assessment - processo, dati, governance e valore atteso verificati sulla vostra situazione, in due giornate.