La demo è filata liscia. Il modello ha letto l'email, capito la richiesta, redatto una risposta impeccabile, e la sala ha applaudito. Tre mesi dopo, quel pilota è ancora esattamente quello: una demo che qualcuno accende quando passa un dirigente. Non è mai andato in produzione. Non è sfortuna né mancanza di budget per «più IA»: è lo schema più comune del settore. La demo impressiona perché mostra la parte facile. La produzione è tutto ciò che la demo, per progetto, ha saltato.
Perché i piloti di IA falliscono (e quasi mai è il modello)
I numeri dell'ultimo anno sono scomodi. L'indagine Voice of the Enterprise di S&P Global Market Intelligence (2025) ha trovato che il 42% delle aziende ha abbandonato la maggior parte delle proprie iniziative di IA nel 2025 — contro il 17% dell'anno prima —, scartando quasi metà delle proof of concept prima che arrivassero in produzione. IDC, dal canto suo, ha calcolato che l'88% dei piloti di IA non supera il salto al dispiegamento ampio: solo 4 proof of concept su 33 sono passate in produzione. Non è che il modello non fosse capace nella demo. È che «capace nella demo» e «in produzione» sono due cose diverse — e la seconda non è stata comprata.
Conviene separare due domande che la demo confonde apposta. La prima — «il modello può farlo?» — riceve quasi sempre un sì. La seconda — «la tua azienda può gestirlo ogni giorno, con i tuoi dati, i tuoi sistemi, i tuoi permessi e le tue eccezioni?» — è quella che decide se c'è un progetto. La demo risponde alla prima e nasconde la seconda. Per questo una demo brillante è un segnale tanto brutto quanto buono: dimostra ciò che non fallisce quasi mai e tace su ciò che fallisce sempre.
Il 70% che la demo salta
BCG lo riassume in un principio che invecchia benissimo: il successo di un progetto di IA è 10% algoritmi, 20% dati e tecnologia, e 70% persone, processi e cambiamento culturale. La demo vive interamente in quel primo 10%. Il fossato tra il pilota e la produzione è quel 70% — più il 20% di idraulica dei dati — che nessuna presentazione di vendita mostra, perché non fa un bel video.
Quel 70–90% invisibile, in concreto, è questo:
- Dati veri, non da laboratorio. La demo gira su tre esempi puliti. La produzione riceve PDF storti, campi vuoti, duplicati e l'email che non segue nessun modello. Senza dati affidabili e accessibili, lo stesso modello che brillava nella demo comincia a inventare.
- Integrazioni. Il risultato deve entrare e uscire dai tuoi sistemi — CRM, ERP, email, database — con autenticazione, permessi e tracciabilità. Quel cablaggio è l'80% del lavoro vero e lo 0% della demo.
- Casi limite e gestione degli errori. La demo non ha casi limite; il martedì sì. Cosa succede quando il modello non è sicuro, quando l'API cade, quando il dato arriva a metà? Un sistema in produzione ha una risposta. Una demo no.
- Osservabilità e costo. In produzione devi vedere cosa fa il sistema, quando sbaglia e quanto costa ogni esecuzione su scala. Un pilota senza strumentazione non si governa: si spegne al primo spavento.
- Proprietà e adozione. Qualcuno deve essere proprietario del sistema, mantenerlo e far sì che il team lo usi davvero invece di tornare al solito foglio di calcolo. Senza proprietario e senza adozione, anche il miglior sistema muore da solo.
Demo vs produzione: non è lo stesso progetto
| Dimensione | Nella demo | In produzione |
|---|---|---|
| Dati | Tre esempi puliti e scelti | Tutto ciò che entra, sporco e a qualsiasi ora |
| Errori | Non compaiono | Sono metà del design |
| Integrazione | Copia e incolla il risultato | Entra ed esce dai tuoi sistemi con permessi |
| Costo | Irrilevante (una esecuzione) | Misurato per esecuzione, su scala |
| Proprietario | Chi ha fatto la demo | Qualcuno che lo mantiene ogni giorno |
| Successo | Impressionare la sala | Funzionare senza che nessuno guardi |
C'è una versione di questo fallimento che è di operatività — il 70% qui sopra — e un'altra che è di progettazione: promettere un sistema che si governa da solo e consegnarlo senza la persona che lo governa. La seconda la sviluppiamo a parte in il mito dell'agente 100% autonomo. E a volte la conclusione onesta è che quel processo non andava automatizzato per intero: lo trattiamo in quando NON automatizzare un processo con l'IA. Qui il focus è un altro: anche se il processo è un buon candidato e l'umano è ben posizionato, il pilota muore lo stesso se nessuno costruisce il 70% noioso.
Come si attraversa il fossato
L'ordine che funziona ribalta quello della demo. La demo parte dal modello e spera che il resto si incastri da solo. Un sistema parte dal processo e tratta il modello come un pezzo in più:
- Parti dal processo, non dal modello. Mappa come si fa il lavoro oggi — dove si inceppa, quali eccezioni compaiono, chi decide cosa. È ciò che separa automatizzare processi con l'IA dal comprare uno strumento e pregare.
- Metti a budget il 70% dal primo giorno. Dati, integrazioni, gestione degli errori e adozione non sono una «fase due»: sono il progetto. Se il piano copre solo la demo, sai già come finisce.
- Strumenta prima di scalare. Misura la precisione, il costo per esecuzione e cosa viene escalato a un umano. Un sistema che non puoi misurare è un sistema che non puoi governare.
- Metti un proprietario e un umano nel loop. Qualcuno mantiene il sistema, e una persona rivede proprio dove il giudizio pesa più della velocità. È la logica di montare processi interni con agenti: l'IA fa il grosso, l'umano decide ciò che conta.
Niente di tutto questo compare in un video di novanta secondi, ed è esattamente per questo che il settore preferisce venderti la demo. Noi facciamo il contrario: costruiamo il 70% noioso, lo cabliamo ai tuoi sistemi, lo strumentiamo e lo lasciamo girare un martedì qualunque senza che nessuno guardi. Si chiama automazione delle operazioni, e si fattura per ciò che funziona in produzione, non per ciò che impressiona la sala.