Perché i progetti AI si fermano al pilota: il gap non è tecnologico, è architetturale

Un numero per aprire, e non è quello del titolo.

Nel 2025 il mercato italiano dell'intelligenza artificiale ha raggiunto 1,8 miliardi di euro, in crescita del 50% sull'anno precedente. Nello stesso anno il 71% delle grandi imprese italiane aveva avviato almeno un progetto di AI. Tra le piccole e medie realtà la percentuale scende all'8%: nel dettaglio, il 15% delle medie imprese e il 7% delle piccole. Sono dati dell'Osservatorio Artificial Intelligence del Politecnico di Milano, rilevazione 2025.

C'è un altro dato della stessa ricerca che conta più dei precedenti, e che quasi nessuno cita: solo una grande impresa su cinque ha una buona pervasività dell'AI in diverse funzioni aziendali. Tradotto: quattro aziende su cinque tra quelle che hanno già avviato progetti li tengono confinati in un angolo. Un reparto, un caso d'uso, una demo che gira quando qualcuno la lancia a mano.

Il punto è questo. La distanza che conta non è tra chi ha avviato un progetto AI e chi no. È tra chi ha un sistema che gira da solo e chi ha un pilota che ha bisogno di una persona per partire.

Il numero del titolo, spiegato onestamente

Il "75% dei progetti AI che non arriva in produzione" circola da anni in decine di varianti. L'ho scritto anch'io. Vale la pena essere precisi su cosa è verificabile e cosa no, perché la differenza cambia le decisioni che prendi.

Quello che posso citare alla fonte è quanto sopra: 71% di adozione tra le grandi imprese, 8% tra le PMI, una su cinque con pervasività reale. Se il denominatore sono le grandi imprese che hanno avviato qualcosa, l'80% non ha portato l'AI dentro più funzioni. È un numero vicino al 75%, misura una cosa leggermente diversa, ed è quello che ho controllato di persona.

Sul fronte internazionale il riferimento più citato è la ricerca The GenAI Divide di MIT Project NANDA del 2025: su circa 300 deployment analizzati, il 95% dei pilot di AI generativa non ha prodotto un impatto misurabile sul conto economico. Anche qui attenzione a cosa dice davvero. Non dice che il 95% dei progetti si rompe. Dice che non lascia traccia nei numeri dell'azienda, che è una forma di fallimento molto più silenziosa e molto più comune.

La conclusione operativa è la stessa in entrambi i casi: il collo di bottiglia non è far funzionare il modello. È far sopravvivere il progetto al giorno dopo la demo.

Dove si blocca davvero: tre colli di bottiglia, con i numeri

Il report State of AI in the Enterprise 2026 di Deloitte, nella lettura italiana, mette in fila le barriere dichiarate dalle aziende. Sono tre, e nessuna è "il modello non è all'altezza".

Competenze, prima barriera. Il 39% indica la carenza di talenti e competenze come primo ostacolo all'adozione. Se si guarda specificamente all'AI agentica, cioè ai sistemi che agiscono e non solo rispondono, la percentuale sale al 49%. Il 41% cita costi e risorse necessarie, il 36% problemi di tecnologia o disponibilità dei dati.

Casi d'uso e dati, a pari merito. Il 27% fatica a identificare i casi d'uso, un altro 27% ha problemi di tecnologia o disponibilità dei dati.

Governance, il terzo 27%. Chi decide cosa automatizzare, chi valida l'output, chi risponde se sbaglia. Senza un framework decisionale ogni progetto AI resta un esperimento permanente, e un esperimento permanente per definizione non entra mai in produzione.

C'è un contrasto che vale la pena tenere insieme. Sempre da Deloitte, il 70% delle aziende italiane dichiara di usare già AI agentica e il 91% prevede di usarla entro due anni, l'82% aumenterà gli investimenti, il 92% si aspetta un guadagno di produttività. Ma solo il 35% ha calcolato un ritorno sull'investimento. Aspettativa altissima, misurazione bassa. È esattamente il terreno su cui i pilot muoiono senza che nessuno lo noti.

Il salto non è dal prompt alla risposta. È dal prompt al sistema

Quando un imprenditore mi dice "abbiamo provato l'AI e non è servita a molto", nel 90% dei casi quello che ha provato è un prompt. Qualcuno apre una chat, incolla del testo, ottiene un output decente, lo copia in un altro programma. Funziona, fa risparmiare qualche minuto, e resta legato alla presenza di quella persona davanti a quello schermo.

Un sistema è un'altra cosa. Ha cinque pezzi, e se ne manca uno non è un sistema:

1. Un trigger che parte da solo. Un orario, un evento, un webhook, una riga nuova in un database. Se serve un umano che clicchi, quello che hai è uno strumento, non un'automazione.
2. Un input strutturato. Il sistema sa dove andare a prendere i dati e in che forma aspettarseli. Non riceve "quello che gli incolli".
3. Un'elaborazione senza intervento. Il modello lavora dentro un perimetro definito, con istruzioni versionate e una lista di strumenti che può chiamare.
4. Un output nel formato giusto, nel posto giusto. Non un blocco di testo in chat. Una riga nel CRM, un PDF nella cartella condivisa, un messaggio su Slack, un record nel gestionale.
5. Una prova che è successo. Log, stato, esito. Se non sai dire se stanotte è andata bene, il sistema non esiste ancora.

Il quinto punto è quello che si salta sempre, ed è quello che decide se il progetto è vivo tra sei mesi. Su come si arriva a questi cinque pezzi partendo da un processo manuale ho scritto una guida separata: come mappare un processo prima di automatizzarlo.

I sei pezzi che separano un pilota da un sistema in produzione

Questa è la parte che nei preventivi non compare quasi mai, e che è il grosso del lavoro reale.

Idempotenza. Un'automazione schedulata prima o poi girerà due volte sullo stesso input. Rete che cade a metà, retry automatico, qualcuno che rilancia il job a mano. Se il secondo giro produce un secondo effetto (una seconda email, un secondo record, un secondo addebito) hai costruito una macchina che sbaglia in proporzione a quanto la usi. La regola che applico ovunque: uno script deve poter girare più volte senza effetti cumulativi.

Error handling esplicito, con cinque livelli. Per ogni automazione scrivo la catena completa prima del codice: errore, rilevamento, risposta, fallback, alert. Cosa può rompersi. Come me ne accorgo. Cosa fa il sistema quando succede. Cosa fa se anche quella strada è chiusa. Chi viene avvisato e su quale canale. Quattro righe su cinque non bastano: se manca l'alert, il guasto diventa invisibile.

Osservabilità dal punto giusto. Questo è il punto dove ho sbagliato io, e vale più di qualsiasi teoria. Il mio sistema di health check controllava che i job cloud fossero stati lanciati, non che fossero riusciti. La riga di stato la scriveva chi accendeva il job, non chi lo portava a termine. Risultato: tra il 3 e il 9 luglio 2026 tre esecuzioni sono fallite senza che partisse un solo alert, e un job di raccolta contenuti è rimasto morto circa tre settimane per un errore di validazione prima che me ne accorgessi. Il cruscotto era verde tutto il tempo. Ho riscritto il check l'11 luglio: adesso valuta le esecuzioni, e verde significa "c'è stato un successo dentro la finestra prevista". La lezione è generale. Un monitor che guarda l'intenzione invece del risultato è peggio di nessun monitor, perché ti fa dormire.

Ownership dello stato. Chi possiede il dato di verità. Se due componenti scrivono nello stesso posto senza un lock, prima o poi si sovrascrivono. Se lo stato vive solo nella memoria di una sessione, al riavvio sparisce. Nel mio setup ogni pezzo di stato ha un proprietario dichiarato, e i componenti che non lo possiedono lo leggono e basta.

Gate di qualità automatici. Se un sistema genera contenuto o decisioni che escono a nome tuo, serve un controllo deterministico prima della pubblicazione, non una revisione a campione. Nel mio caso è una suite di test che deve essere verde prima e dopo ogni modifica ai file che governano lo stile e i fatti dichiarabili. Non è eleganza: è quello che evita che un errore di prompt diventi un errore pubblicato.

Teardown. Ogni risorsa temporanea che crei (un job una tantum, un flag, una credenziale di prova, un noindex) va spenta nella stessa sessione che ne verifica l'esito, oppure deve nascere auto terminante. Altrimenti la ritrovi accesa mesi dopo, quando non ricordi più perché esiste. Questa regola l'ho scritta dopo aver trovato un trigger di prova ancora attivo alla scadenza.

Il quadro completo di come questi pezzi stanno insieme su un sistema vero, con i numeri, è nel caso studio dell'ecosistema di 21 automazioni che gestisco.

Come si sceglie il primo processo (e perché quasi sempre si sceglie male)

L'errore tipico è partire dal processo più visibile. Quello di cui si lamentano tutti in riunione. Quasi sempre è anche il più intrecciato con le eccezioni, le persone e le abitudini, quindi è il candidato peggiore per un primo intervento.

I quattro criteri che uso, in ordine:

1. Frequenza. Un processo che gira ogni giorno vale più di uno che gira una volta al mese, anche se il secondo brucia più ore per singola esecuzione. La frequenza è quello che trasforma un risparmio in un'abitudine.
2. Struttura dell'input. Se i dati in ingresso arrivano già in una forma prevedibile, il progetto dura settimane. Se ogni volta arrivano diversi, prima dell'AI serve lavoro sui dati, e va detto prima di firmare.
3. Costo dell'errore. Un errore recuperabile permette di partire in fretta e correggere. Un errore che tocca un cliente, un pagamento o un adempimento richiede supervisione umana esplicita, e va progettata dall'inizio.
4. KPI già esistente. Se non c'è già un numero che qualcuno guarda, non saprai dire se l'automazione ha funzionato. Il KPI si sceglie prima, non dopo.

Aggiungo un passaggio che pochi consulenti propongono, perché toglie lavoro a chi lo propone: prima di automatizzare, prova a cancellare. Molti processi esistono per inerzia. Un report che nessuno legge non va automatizzato, va spento. Un'approvazione che è sempre positiva non va velocizzata, va rimossa. Automatizzare uno spreco significa produrlo più in fretta.

Quanto costa arrivare davvero in produzione

Numeri miei, quelli che trovi sulla pagina prezzi, così non devi indovinare.

La diagnosi si separa dall'implementazione, sempre. Una call di scoping da 30 minuti costa 97 euro e serve a scegliere il primo perimetro; se poi partiamo, l'importo viene scalato dal preventivo. Un audit da 90 minuti costa 297 euro e produce una mappa dei processi con priorità e roadmap. L'implementazione parte da 997 euro per un system setup su processi prioritari e arriva a 2.000 euro per un sistema end to end con deploy e monitoraggio. Se preferisci vedere il risultato prima di impegnarti su un progetto, l'AI Build Day è una giornata singola da 290 euro con una regola secca: se a fine giornata non gira niente, rimborso pieno.

Il range di mercato per progetti di automazione più ampi lo trovi nell'articolo dedicato a quanto costa l'automazione AI per una PMI, diviso per livello di complessità dello stack.

Una nota sul finanziamento, perché cambia la matematica più di qualsiasi sconto. Nel 2026 il MIMIT ha stanziato risorse per un voucher digitalizzazione con contributo a fondo perduto, e molte Camere di Commercio hanno bandi propri su software e automazione. Il perimetro delle spese ammissibili cambia da bando a bando e va letto caso per caso: alcuni coprono la consulenza specialistica, altri solo licenze e cloud. Vale la pena verificare l'ammissibilità prima di definire il progetto, non dopo.

La produzione ha anche un costo di conformità

Dal 2 agosto 2026 scattano gli obblighi del Regolamento UE 2024/1689, l'AI Act, per chi usa sistemi di AI nella propria attività. Non riguarda solo chi sviluppa modelli: riguarda anche il deployer, cioè l'azienda che li mette al lavoro sui propri processi.

Questo cambia il conto di un progetto che va in produzione, e in modo asimmetrico rispetto a un pilota. Un esperimento interno ha obblighi limitati. Un sistema che manda comunicazioni ai clienti, che seleziona candidati o che entra in decisioni che toccano persone porta con sé registro dei sistemi in uso, informazione agli interessati, tracciabilità delle decisioni e formazione del personale. Chi progetta l'automazione senza tenerne conto costruisce un debito che si paga tutto insieme, di solito nel momento peggiore.

Ho scritto cosa cambia concretamente, senza allarmismi, in AI Act: cosa cambia davvero dal 2 agosto 2026. Se vuoi solo capire in due minuti dove sei esposto, c'è un self check gratuito.

Cosa farei se dovessi ripartire da zero

Se domani mi trovassi a costruire l'automazione di una PMI da capo, con budget limitato e nessun progetto pregresso, farei questo, in questo ordine.

Prima cosa, sceglierei un solo processo. Non tre, non "una roadmap a fasi". Uno. Con un KPI già esistente e un errore recuperabile.

Seconda cosa, scriverei i criteri di accettazione prima del codice. Cosa deve produrre, in quanto tempo, con quale tasso di errore accettabile, e chi decide se ha funzionato. Se non riesco a scriverli, significa che il processo non è ancora chiaro, e nessuna tecnologia risolve un processo poco chiaro.

Terza cosa, costruirei la catena di errore prima della funzionalità. Alert compreso. Il primo messaggio che deve funzionare non è quello di successo: è quello di guasto.

Quarta cosa, lo farei girare per due settimane in parallelo al processo manuale, confrontando gli output. Non è tempo perso: è l'unico modo per sapere se il sistema sbaglia, e come.

Quinta cosa, spegnerei il processo manuale. Se non lo spegni, non hai automatizzato niente. Hai aggiunto un secondo processo da mantenere.

Sesta cosa, misurerei per un mese e deciderei se il secondo processo vale il progetto. La decisione sul secondo si prende con i dati del primo, mai insieme al primo.

Il costo dell'attesa non è teorico

Il divario tra chi ha sistemi che girano e chi ha esperimenti non si sta chiudendo. I dati Deloitte lo dicono in modo netto: chi ha già l'AI agentica in casa aumenta gli investimenti, chi non ce l'ha vede allargarsi la distanza sul fronte delle competenze, che è la barriera più difficile da colmare in fretta perché non si compra con una licenza.

Per una PMI l'attesa si misura in cose concrete. Ore che restano dentro attività ripetitive invece che dentro attività commerciali. Clienti che scelgono chi risponde in due ore invece che in due giorni. Persone che si dimettono perché passano metà giornata a copiare dati tra due programmi.

Non serve un piano di trasformazione. Serve un processo scelto bene, portato fino in fondo, con un numero attaccato che dica se ha funzionato. Poi il secondo.

Se vuoi partire da lì, il modo più veloce è mettere un processo concreto al centro di una call di scoping: prenota qui, 30 minuti, si esce con una priorità e un perimetro. Se preferisci prima farti un'idea di come lavoro, il caso studio delle 21 automazioni è pubblico e contiene i numeri veri, guasti inclusi.