A un distributore industriale da 40 persone è bastata una settimana per avere un agente AI che preparava i preventivi. Leggeva una richiesta d’acquisto in arrivo, abbinava le righe d’ordine a un listino e buttava giù un preventivo che sembrava pronto da inviare. Il direttore commerciale si era convinto all’istante. Otto mesi dopo, l’agente era ancora fermo in una cartella di test e il team preparava i preventivi come li preparava da dieci anni.
Il modello non aveva niente che non andasse. Il ragionamento reggeva, e ogni richiesta di prova che lo sviluppatore gli dava tornava indietro pulita. Quello che non aveva ancora fatto era sopravvivere al contatto con l’azienda vera: l’ERP da interrogare, le eccezioni di prezzo che nessuno aveva mai messo per iscritto e un team commerciale che non aveva alcuna intenzione di mandare a un cliente un numero di cui non poteva rispondere.
Quel divario ormai ha un nome: il problema dell’ultimo miglio dell’AI. È la distanza tra un modello che rende in una demo e un sistema che un’azienda fa girare, senza supervisione, sul lavoro vero. La maggior parte dei progetti AI che finiscono in un binario morto ha un modello che fa il suo mestiere. Falliscono su tutto quello che deve succedere dopo.
Il numero che citano tutti, e cosa misura davvero
Un citatissimo studio del MIT ha dato una cifra a questo pattern: circa il 95% dei pilot aziendali di AI generativa non mostrava alcun impatto misurabile sul conto economico. Il rapporto attribuiva il divario a un “learning gap” nel modo in cui gli strumenti venivano adottati e integrati, non alla debolezza dei modelli.
Il numero si è diffuso in fretta, e con lui le critiche. Quasi tutte puntavano alla metodologia: la ricerca si basava su qualche centinaio di interviste e su una rassegna di deployment pubblici, termini come “pilot” e “impatto sul conto economico” non sono mai stati definiti con rigore, e uno studio che misura solo il ritorno finanziario immediato sottostima i progressi nei flussi di lavoro dove il beneficio arriva prima come meno errori o cicli più rapidi, e solo dopo si vede a bilancio. Tratta il 95% come un segnale approssimativo su dove i progetti AI si incagliano, non come un fatto assodato da citare in consiglio di amministrazione.
Quello che sopravvive alle critiche è la direzione del risultato, che coincide con ciò che si vede di continuo nella pratica. Il collo di bottiglia raramente riguarda la capacità del modello di svolgere il compito in linea di principio. Riguarda quasi sempre tutto ciò che serve perché il modello svolga quel compito in modo sicuro e ripetibile, dentro sistemi che esistevano molto prima che qualcuno comprasse una licenza AI.
Chiudere quel divario, di norma, è lavoro di ingegneria continuativo, calato nel modo in cui l’azienda opera, non un singolo evento di deployment. È la premessa dietro un servizio di ingegneria AI embedded: una presenza tecnica che resta dentro il flusso di lavoro finché il sistema non si guadagna il suo posto, invece di una consegna una tantum.
Cosa non ti dice “il modello funziona”
Una demo risponde a una sola domanda: il modello produce un buon output quando riceve input puliti e ben formati? È un segnale reale e utile. È anche una piccola frazione di quello che la produzione richiede.
Ecco cosa sta tra una demo funzionante e un software a cui un’azienda affida il lavoro senza presidio:
- I sistemi che fanno fede. Il modello ha bisogno di un accesso vivo e autenticato a ciò che contiene la verità: l’ERP, il CRM, il database dei prezzi, l’archivio documentale. Gran parte di questi sistemi espone API, ma la copertura è disomogenea, i rate limit sono reali e “ha un’API” non è la stessa cosa di “un agente può leggere e scrivere in modo affidabile i dati che gli servono”.
- La coda disordinata delle richieste reali. Chiamala pure il 20 per cento disordinato, più una scorciatoia verbale che una cifra misurata: gli input malformati, le righe d’ordine ambigue e i casi limite che un set di demo curato non fa mai emergere, ma che si presentano di continuo appena arrivano i volumi veri.
- Una suite di valutazione. Un modo documentato e ripetibile di rispondere a “sta ancora funzionando?”, che vada oltre la sensazione a pelle di qualcuno dopo un paio di controlli a campione.
- Permessi e sicurezza. Un service account con l’accesso che serve per fare il lavoro e niente di più, rivisto da chi è responsabile della sicurezza, con una risposta chiara su cosa succede se l’agente tocca dati che non dovrebbe.
- L’aderenza al flusso di lavoro. L’agente deve inserirsi nel modo in cui le persone lavorano oggi: chi rivede il suo output, in quale punto del processo, e cosa succede quando sbaglia.
- La fiducia del personale. La più difficile da mettere a piano. Chi si è già scottato con un numero sbagliato o con uno strumento che prometteva troppo non cederà le decisioni di merito solo perché l’ingegneria dice che la metrica di accuratezza è buona.
Ognuno di questi punti può bloccare un progetto da solo. In pratica si sommano: sistemare l’integrazione con l’ERP fa emergere problemi di qualità dei dati, che cambiano cosa deve verificare la suite di valutazione, che a sua volta cambia cosa il team commerciale è disposto ad accettare senza revisione.
Perché i chatbot generici e i copilot preconfezionati si fermano qui
Ecco anche perché comprare una licenza di un chatbot generalista o un copilot preconfezionato raramente chiude il divario da solo. Quegli strumenti risolvono la metà dell’equazione che riguarda il modello e ti lasciano l’altra metà per intero.
| Chatbot generico / copilot | Un sistema che ha chiuso l’ultimo miglio | |
|---|---|---|
| Accesso ai sistemi che fanno fede | Di solito nessuno, o un plugin superficiale | Accesso autenticato e delimitato, costruito per quel flusso di lavoro |
| Gestione dei casi limite | Ripiega su un’ipotesi che suona plausibile | Segnala ciò che non sa e fa escalation |
| Valutazione | Benchmark del fornitore su compiti generici | Una suite di test costruita sui tuoi casi storici |
| Sicurezza e permessi | Permessi ampi e generici di default | Accesso a privilegio minimo rivisto dal tuo team IT |
| Fiducia del personale | Non guadagnata da nessuna parte | Guadagnata sui tuoi dati prima del go-live |
Un assistente generalista può scrivere un preventivo che suona plausibile. Non ha modo di verificarlo contro il tuo listino, la tua giacenza attuale o lo sconto che il tuo ufficio finanza ha approvato il trimestre scorso per quel cliente specifico. Non sa dirti quando sta tirando a indovinare. Il divario sta in ciò per cui un prodotto generico è costruito; la qualità del ragionamento c’entra poco.
Un distributore da 40 persone impara la differenza a sue spese
Torniamo all’agente per i preventivi dell’apertura. L’azienda è un composito, costruito su pattern che ricorrono tra distributori di dimensioni simili che automatizzano la gestione dei preventivi in entrata, e mostra come la lista di sei punti qui sopra si gioca su un progetto vivo.
La demo ha richiesto a uno sviluppatore circa una settimana, ed era buona: estrazione pulita delle specifiche dall’email del cliente, una bozza formattata correttamente, prezzi plausibili sulla manciata di richieste campione usate per costruirla.
Poi il progetto ha incontrato l’azienda vera, in quattro modi distinti.
Il listino aveva eccezioni che nessuno aveva documentato. Circa un quinto delle richieste reali riguardava uno SKU fuori produzione con un sostituto informale, un sovrapprezzo di trasporto regionale applicato in modo incoerente a seconda di chi elaborava l’ordine, o uno sconto bundle che un commerciale ricordava e un altro no. Niente di tutto questo viveva nel listino master su cui la demo era stata costruita.
L’integrazione con l’ERP era il vero progetto. Prezzi correnti e giacenze vivevano in un sistema ERP, non nel foglio di calcolo esportato usato per la demo. Collegarsi voleva dire mappare i campi, fare i conti con i rate limit delle API e gestire il fatto che un prezzo in cache poteva scostarsi in silenzio da quello che l’ERP mostrava un minuto dopo.
Il team commerciale non si fidava, e aveva le sue ragioni. I commerciali si erano già scottati con uno strumento di pricing che aveva mandato un numero sbagliato a un cliente. Volevano vedere e approvare ogni bozza prima che arrivasse al destinatario, e volevano un modo semplice per correggere qualsiasi cosa sembrasse storta. Il design doveva trattare quella richiesta come un controllo legittimo, non come un attrito da automatizzare via.
Il set di valutazione è nato da 200 preventivi storici. Invece di fidarsi di “a me sembra a posto”, il team ha ripescato 200 preventivi reali del passato, ha oscurato i dati dei clienti e li ha usati come baseline: l’agente riproduce la stessa logica di prezzo, coglie le stesse eccezioni, segnala le stesse voci che un umano avrebbe segnalato? È quel test set, più della demo originale, che alla fine ha permesso al direttore commerciale di approvare l’uso dell’agente senza passaggio di revisione per la categoria di preventivi più semplice.
L’agente andato finalmente in produzione, mesi dopo, girava sullo stesso modello della demo della prima settimana. La differenza era tutto ciò che gli stava intorno: una connessione all’ERP, un elenco di eccezioni documentato, un flusso di approvazione chiesto dal team commerciale e una suite di test costruita sulla storia dell’azienda. La demo non è mai stata la parte difficile.
Cosa serve davvero per chiudere l’ultimo miglio
Alcune pratiche ricorrono con costanza nei progetti che superano questo divario.
Sviluppo eval-first. Costruisci il test prima della funzionalità. Hamel Husain sostiene che i team che saltano questo passaggio finiscono per non riuscire più a dire se una modifica ha migliorato o peggiorato il sistema, e ogni decisione successiva diventa una scommessa. Estrarre un campione rappresentativo di casi storici reali e definire com’è fatta una risposta corretta, prima di scrivere la logica dell’agente, cambia l’intero processo di costruzione: costruisci verso un obiettivo misurabile, non verso una demo che si limita a sembrare convincente.
Context engineering sui dati reali dell’azienda. Anthropic descrive il context engineering come la cura dell’insieme di informazioni disponibili al modello al momento dell’inferenza, cosa diversa dallo scrivere un buon prompt. Applicato a un sistema aziendale, significa ancorare il modello ai tuoi listini, alla corrispondenza passata e allo storico dei clienti invece che alla sua conoscenza generale di addestramento, e scegliere con criterio cosa deve vedere e cosa lo confonderebbe soltanto.
Architetture ibride. I sistemi più affidabili non chiedono a un modello linguistico di far rispettare le regole di business rigide. Un prezzo minimo, una soglia di approvazione, un requisito di conformità: quelli appartengono a codice deterministico che passa o fallisce, senza spazio di interpretazione. Il compito del modello è la parte che richiede davvero giudizio, come leggere una richiesta ambigua o preparare un testo che un umano rivedrà. Separare le due cose con chiarezza è ciò che rende il comportamento di un agente abbastanza prevedibile da poterci contare sui grandi volumi.
Qualcuno organizzativamente vicino al lavoro. Le specifiche si perdono dei pezzi. La persona che elabora i sovrapprezzi di trasporto ogni giorno conosce un’eccezione che il documento dei requisiti non ha mai menzionato, e scoprirla alla seconda settimana costa molto meno che scoprirla dopo il go-live. I progetti che riescono di solito hanno qualcuno, che sia personale interno o un ingegnere del fornitore che lavora on-site con il team, abbastanza vicino al flusso di lavoro da cogliere quel tipo di lacuna prima che diventi un incidente in produzione.
Niente di tutto questo è esotico. Somiglia più a una pratica disciplinata di ingegneria del software che a qualcosa di specifico dei modelli linguistici. La differenza è che i progetti AI spesso la saltano, perché la demo sembrava già così convincente che saltarla pareva sicuro.
Perché tutto questo continua a produrre lo stesso modello di delivery
Guarda dove hanno messo i soldi i vendor con più esperienza di deployment AI in azienda, e un pattern emerge. A giugno 2026 AWS ha impegnato un miliardo di dollari in un programma di forward deployed engineering, inserendo ingegneri direttamente presso i clienti e i partner che li servono, per chiudere gap di integrazione come quelli descritti sopra. Salesforce si è impegnata a costruire un team di 1.000 ingegneri dedicati per la sua linea Agentforce, per la stessa ragione. OpenAI ha formalizzato una funzione simile al proprio interno nel 2025.
Non è una coincidenza. Se la parte difficile di un progetto AI è l’integrazione con i sistemi, la gestione dei casi limite e la fiducia del personale, più che la qualità del modello, allora il modello di delivery deve tenere gli ingegneri vicini all’azienda finché quella fiducia non è guadagnata, e questo richiede molto più tempo che consegnare una demo. È un accordo commerciale diverso dal comprare software a scaffale, e vale la pena capirlo nei suoi termini: Cos’è un forward deployed engineer? spiega come funzionano davvero quel ruolo e quel modello di delivery.
Questa diagnosi è anche più stretta della domanda più ampia sul perché i progetti con agenti AI falliscono in partenza. Molti progetti non arrivano nemmeno a mettere un modello funzionante in una demo vera, per ragioni che con l’ultimo miglio non c’entrano nulla: scope indefinito, nessun responsabile lato business, nessun modo concordato di misurare il successo prima di costruire. Perché i progetti con agenti AI falliscono copre quel rischio di progetto e una checklist per evitarlo. Questo articolo dà per superata quella soglia e pone la domanda successiva: il tuo modello funziona, quindi perché non sta ancora facendo girare l’azienda? La risposta, quasi ogni volta, sono le sei cose che stanno tra una demo e la produzione, e quel lavoro qualcuno lo deve fare davvero.
Domande frequenti
Cos'è il problema dell'ultimo miglio dell'AI?
È la distanza tra un modello AI che rende bene in una demo o in un proof of concept e un sistema che gira in modo affidabile dentro i flussi di lavoro reali di un'azienda. Il ragionamento del modello, quando la demo è pronta, di solito va già bene; quello che manca è l'integrazione con i sistemi reali, la gestione dei casi limite disordinati, una suite di valutazione, i permessi giusti, l'aderenza al flusso di lavoro e la fiducia del personale. Colmare quel divario è un progetto software e organizzativo, non un problema di modellazione.
È vero che il 95% dei pilot AI fallisce?
Un citatissimo studio del MIT ha riportato che circa il 95% dei pilot aziendali di AI generativa non mostrava alcun impatto misurabile sul conto economico, e ha attribuito il divario soprattutto ai gap di integrazione più che alla qualità dei modelli. Il campione e le definizioni dello studio sono stati messi in discussione da altri ricercatori, quindi trattalo come un segnale direzionale su dove i progetti AI si arenano, non come un benchmark di settore preciso.
Perché i chatbot AI generici o i copilot preconfezionati rendono poco in azienda?
Arrivano senza sapere nulla dei listini, dei sistemi che fanno fede, della gestione delle eccezioni o delle regole di approvazione di una specifica azienda. Un assistente generico può scrivere un testo che suona plausibile, ma non può verificare un numero contro il tuo ERP, segnalare una richiesta fuori dalla tua politica di sconti o guadagnarsi la fiducia di un team già scottato da una risposta sbagliata.
Cosa serve davvero per chiudere l'ultimo miglio dell'AI?
In pratica: una suite di valutazione costruita su casi storici reali prima di affidare all'agente quelli nuovi, context engineering che ancora il modello ai tuoi dati invece che alla conoscenza generica, un'architettura ibrida in cui il codice deterministico applica le regole rigide e il modello gestisce le valutazioni di merito, e qualcuno abbastanza vicino al lavoro quotidiano da cogliere ciò che un documento di specifiche non dice.
In cosa il problema dell'ultimo miglio è diverso da un progetto AI con uno scope mal definito?
Si sovrappongono, ma non sono lo stesso fallimento. Uno scope mal definito è un rischio organizzativo che può affondare un progetto prima che venga scritta una sola riga di codice. Il problema dell'ultimo miglio dà per buoni sia lo scope sia il modello e pone una domanda più stretta: perché un modello che tecnicamente funziona impiega comunque mesi a diventare software che l'azienda fa girare senza supervisione.