Lo schema si ripete con una regolarità quasi noiosa. Un'azienda lancia un progetto pilota AI. La demo è impressionante. Tutti annuiscono. Sei mesi dopo il progetto finisce in silenzio in un cassetto, la voce di budget sparisce e l'organizzazione conclude che «l'AI non è ancora pronta per il nostro settore». Il modello, quasi mai, era il problema. Lo era il modo in cui il pilota era stato progettato.
Le indagini di settore continuano a collocare tra il settanta e il novanta per cento la quota di progetti pilota AI che non arrivano mai in produzione, e la nostra esperienza con i progetti arenati che ci troviamo a ereditare dice che le indagini hanno all'incirca ragione. Quello che le indagini non dicono è che queste morti sono prevedibili. Gli stessi tre difetti di progettazione spiegano la maggior parte del cimitero - e tutti e tre sono visibili nella prima settimana, molto prima che un modello abbia avuto occasione di rendere meno del previsto.
I tre modi in cui muoiono i progetti pilota
Morte per metrica assente. Il progetto nasceva per «esplorare le capacità dell'AI», il che significa che nessuno ha definito il numero che doveva muovere. Senza una metrica non esiste una linea d'arrivo; senza una linea d'arrivo, la revisione di budget lo uccide per impostazione predefinita. Un progetto pilota dovrebbe essere un esperimento con un'ipotesi: «questo modello può dimezzare il tempo di revisione di primo passaggio a parità di accuratezza». Che passi o che non passi, si impara qualcosa che si può mettere a budget.
L'indizio sta nel linguaggio del mandato. «Esplorare», «valutare il potenziale di», «costruire competenza in»: sono formule che non possono fallire, e tutto ciò che non può fallire non può nemmeno riuscire. Si confronti con questa: «ridurre il tempo mediano di gestione delle eccezioni da 40 minuti a meno di 15, misurato sul volume reale, entro la fine del secondo trimestre». Quella frase può perdere. Ed è esattamente ciò che la rende finanziabile quando vince.
Morte per dati da demo. Il progetto girava su esempi puliti e selezionati. La produzione gira su fax scansionati, catene di email inoltrate e quell'unico fornitore che manda ancora i TIFF. Il divario tra accuratezza in demo e accuratezza in produzione è il punto in cui muore la fiducia - e quando gli operatori smettono di fidarsi dello strumento, nessun miglioramento di accuratezza li riporta indietro. Il rimedio non è affascinante: costruire il set di valutazione partendo dai casi reali più ostici.
C'è una ragione più profonda per cui questo uccide i progetti pilota: il divario dei dati da demo non si manifesta come un singolo fallimento, si manifesta come un'erosione. Lo strumento ha ragione sui casi facili - che il team saprebbe comunque gestire - e torto su quelli difficili, che sono esattamente quelli su cui si voleva aiuto. Gli operatori fanno il conto in fretta. Nel giro di un mese lo strumento ha un soprannome, e il soprannome non è affettuoso.
Morte per responsabile assente. Il progetto apparteneva a un team di innovazione; il flusso di lavoro apparteneva alle operations. Quando il pilota è finito, nessuno il cui bonus dipendesse da quel processo era responsabile di adottarlo. I progetti pilota sopravvivono quando è il responsabile del processo - non lo sponsor - a chiederli.
Altri due modi di fallire meritano una menzione d'onore. Morte per involucro: il progetto vive in una scheda separata, con un login separato, in una finestra separata - e ogni cambio di contesto che impone è un piccolo pedaggio sull'adozione. Se l'output del modello non compare dentro lo strumento in cui si prende la decisione, verrà consultato per una settimana e poi dimenticato. E morte per governance tardiva: sicurezza, ufficio legale e compliance sentono parlare del pilota al quarto mese, e a quel punto l'unica mossa che resta loro è fermarlo. Porti loro lo schema dei flussi di dati nella prima settimana e diventano collaboratori; li colga di sorpresa e diventano, giustamente, un muro.
Un progetto pilota non è una piccola demo. È un piccolo sistema di produzione - con una metrica, dati reali e un responsabile.
Scegliere un flusso di lavoro che possa reggere un progetto pilota
Metà del successo di un progetto pilota si decide prima ancora che venga chiamato un fornitore, nella scelta del flusso di lavoro. I buoni candidati condividono quattro proprietà. Volume: l'attività si ripete centinaia di volte al mese, così i guadagni sono misurabili e il segnale di apprendimento si accumula. Tolleranza alla revisione: una persona può verificare l'output a basso costo - riassumere, classificare, estrarre, preparare una bozza - a differenza delle attività in cui verificare costa quanto farle. Dati già esistenti: i casi storici che servono per un set di valutazione sono già dentro un sistema da qualche parte, non nella testa di due veterani. Dolore: chi svolge oggi quell'attività ne detesta la parte peggiore, perché quella motivazione è il motore di adozione che nessun piano di rollout può sostituire.
I candidati sbagliati sono altrettanto riconoscibili. Tutto ciò che è critico per la sicurezza o per la compliance come primo progetto - non perché l'AI non possa aiutare lì, ma perché il primo progetto fissa il budget di fiducia dell'organizzazione, e un fallimento visibile all'inizio in un flusso ad alto rischio lo consuma tutto. Tutto ciò che ha meno di cento casi al mese, dove la statistica non riuscirà mai a separare il segnale dalla fortuna. E la demo preferita dell'amministratore delegato vista a una conferenza, che ha lo sponsor ma raramente il volume, i dati o il responsabile. Scelga ogni volta il flusso di lavoro noioso, ad alto volume e detestato.
Lo sprint di fattibilità, passo per passo
Le due settimane di sprint che aprono ogni collaborazione AI che gestiamo hanno una forma fissa, e ogni passaggio esiste perché saltarlo ha già bruciato qualcuno. Primo e secondo giorno: raccogliere il set di valutazione - da cento a duecento casi reali, campionati sul volume in produzione, con gli operatori che indicano quali sono difficili e perché. Non i casi che inoltra lo sponsor: i casi che il team teme. Terzo e quarto giorno: misurare la linea di base umana. Quanto dura oggi l'attività, quanto costa, qual è il tasso di errore attuale? Senza questo numero il pilota non potrà dimostrare nulla in seguito.
La settimana centrale: far girare i modelli candidati sul set di valutazione e costruire la tassonomia degli errori - non solo «accurato all'87%», ma quale 13% sbaglia, e se gli errori si concentrano in un punto poco costoso (tipi di documento rari che si possono instradare alle persone) oppure in un punto fatale (i casi di maggior valore). Gli ultimi giorni: mettere un prezzo all'economia unitaria - costo per caso ai volumi di produzione, inclusa la revisione umana che l'instradamento per confidenza farà scattare - e scrivere il memo di go/no-go. Circa un terzo dei nostri sprint finisce in «no-go», e quei memo hanno fatto risparmiare ai clienti più soldi di alcuni dei sistemi che abbiamo consegnato.
Tre che ce l'hanno fatta
Revisione contrattuale in uno studio legale. Il mandato dichiarava un solo numero: il tempo di revisione di primo passaggio. Il set di valutazione è stato costruito sui contratti passati dello studio, compresi quelli disordinati, e valutato rispetto alle correzioni che i soci avevano fatto in passato. Gli avvocati vedevano la confidenza del modello su ogni clausola e potevano rifiutare i suggerimenti con un clic - e i rifiuti rientravano nella valutazione. L'adozione non è stata imposta: è avvenuta perché lo strumento rendeva più breve la parte fastidiosa del lavoro.
Triage delle eccezioni in un retailer. Invece di puntare il modello sull'intero flusso ordini, è stato puntato solo sulle eccezioni: il 4% degli ordini che consumava il 60% del tempo del team. L'instradamento basato sulla confidenza faceva sì che il modello gestisse le eccezioni di routine e passasse in escalation quelle strane. Il lavoro di nessuno è cambiato, tranne la sua ora peggiore.
Previsione della domanda dentro la pianificazione. La precedente «dashboard AI» era stata ignorata per un anno. La versione ricostruita ha messo la previsione dentro lo strumento di pianificazione, nel momento in cui si decide l'impegno, mostrando onestamente il margine di errore del modello. Chi stava al banco la sovrascriveva liberamente - e il tasso di sovrascrittura è diventato esso stesso la metrica di adozione. È sceso mese dopo mese.
Si noti che cosa hanno in comune i tre sopravvissuti. Nessuno puntava l'AI su un intero mestiere: ognuno la puntava sulla fetta peggiore di uno. Tutti e tre mostravano la propria incertezza invece di nasconderla, ed è questo che ha permesso alle persone di calibrare la fiducia invece di perderla. E in tutti e tre la metrica apparteneva a chi faceva il lavoro, non a una slide. Lo schema è quasi imbarazzante nella sua semplicità; solo che viene seguito di rado, perché «trasformare la funzione» fa una riunione di avvio migliore di «sistemare l'ora peggiore del martedì».
L'instradamento per confidenza, lo schema che rende l'AI rilasciabile
Se c'è uno schema ingegneristico che separa i sistemi consegnati da quelli finiti nel cassetto, è questo. Ogni output del modello porta con sé un segnale di confidenza; il sistema instrada in base a quello. Confidenza alta: passa dritto, con log. Media: in una coda di revisione umana, precompilata, un tasto per approvare. Bassa, oppure un tipo di caso che il set di valutazione non ha mai visto: escalation completa, e segnalazione della lacuna. Le soglie sono decisioni di business, non tecniche - codificano quanto costa un errore, e sono diverse tra una bozza di marketing e un'istruzione di pagamento.
L'instradamento fa tre lavori insieme. Limita il raggio d'azione degli errori del modello, ed è questo che rende il sistema difendibile davanti a un comitato rischi. Genera dati di addestramento etichettati come sottoprodotto del lavoro normale: ogni approvazione o correzione umana affina il ciclo di valutazione successivo. E dà all'adozione una pendenza: il team guarda la macchina guadagnarsi la fiducia caso per caso, invece di doverla concedere in anticipo. I sistemi introdotti così diventano più autonomi nel tempo, con prove a ogni passo. I sistemi introdotti come «completamente automatici» vengono spenti al primo errore visibile.
Quanto dovrebbe costare un progetto pilota
Un progetto pilota che non può fallire a basso costo non sarà lasciato fallire affatto: verrà dichiarato un successo e messo in silenzio da parte, il che è peggio. La struttura dei costi dovrebbe rispecchiare la struttura della decisione: uno sprint di fattibilità con un prezzo in settimane, una realizzazione in produzione con un prezzo per milestone che consegnano ognuna qualcosa di verificabile, e costi di esercizio modellati per caso prima del go-live, non scoperti sulla prima fattura. L'uso dei modelli è un costo variabile, e i flussi di lavoro con documenti pesanti o contesti lunghi possono riservare sorprese ai volumi di produzione; il passaggio dello sprint dedicato all'economia unitaria esiste proprio perché la sorpresa avvenga su un foglio di calcolo.
Attenzione anche al fallimento opposto: il progetto pilota troppo piccolo per dimostrare qualcosa. Un prototipo di un fine settimana su dieci casi scelti a mano produce esattamente un artefatto: una demo ingannevole. Se il flusso di lavoro conta abbastanza da meritare un pilota, conta abbastanza da meritare una linea di base seria e una valutazione su volume reale. Il pilota onesto minimo è più piccolo di quanto la maggior parte delle aziende tema e più grande di un hackathon: settimane, non giorni; centinaia di casi, non dieci.
Che cosa misurare dopo il go-live
La metrica del pilota risponde alla domanda «ha funzionato al primo mese». La produzione ha bisogno di una dashboard che risponda a «sta ancora funzionando al dodicesimo», e i numeri interessanti sono comportamentali. Tasso di sovrascrittura: se scende è salute, se sale è deriva - nei dati, nel modello o nella fiducia del team. Composizione delle escalation: se la coda umana cresce, o è cambiato il volume o il modello ha smesso di coprirlo. Costo unitario per caso, perché sia i prezzi dei modelli sia i profili d'uso si muovono. E l'accuratezza su una fetta a rotazione di casi reali, rivalutata con il sistema di valutazione, perché il mondo su cui il modello è stato misurato l'anno scorso non è il mondo in cui gira adesso.
È anche la risposta onesta alla domanda «quando finisce il progetto AI»: non finisce mai del tutto - ma il costo ricorrente è piccolo, mettibile a budget e noioso, esattamente come la manutenzione di qualsiasi altro sistema in produzione. Ciò che non è accettabile è l'alternativa scelta da quasi tutti i rilasci falliti: consegnare, smettere di misurare e scoprire da un cliente arrabbiato che il modello sbaglia in silenzio da marzo.
Dia ai numeri un rituale, altrimenti non sopravvivranno al trimestre. Basta una revisione mensile di trenta minuti - il responsabile del processo, un ingegnere, la dashboard: che cosa si è mosso, che cosa è andato alla deriva, quali escalation erano nuove e un miglioramento scelto per il mese successivo. Il rituale conta più degli strumenti, perché una dashboard che nessuno ha in calendario è solo uno screenshot con dei costi di hosting. E metta per iscritto che cosa si è deciso a ogni revisione: alla terza volta che si cambia un modello o si sposta una soglia, quel registro è la differenza tra un'organizzazione che impara e un team che tira a indovinare due volte.
La lista di controllo
Una metrica, dichiarata nel mandato, che possa fallire in modo visibile. Un set di valutazione costruito sui casi reali più ostici, non sui più belli. Un responsabile del processo che lo vuole, non uno sponsor che lo finanzia. Output consegnato dentro lo strumento in cui si prende la decisione, mai in una scheda in più. Sicurezza e compliance nella stanza già dalla prima settimana. Instradamento per confidenza verso le persone dal primo giorno, con soglie fissate in base a quanto costa sbagliare. Uno sprint di fattibilità prima della realizzazione, così che la decisione go/no-go costi settimane e non trimestri. E una dashboard post-lancio che qualcuno presidia davvero. È tutta qui la differenza tra un progetto pilota e un comunicato stampa.