Come condurre un progetto pilota di IA che produce una vera decisione

Una demo dimostra che il modello sa svolgere il compito una volta. Un pilota dimostra che all'azienda conviene pagarlo ogni giorno.

Tre cose vengono chiamate pilota e una sola lo è. La demo mostra una capacità su dati scelti, di solito per creare interesse interno, e per quello è davvero utile. La prova di concetto risponde a una domanda tecnica di fattibilità: questo modello, sui nostri dati, raggiunge una qualità accettabile. Il pilota risponde a una domanda commerciale: a volume reale, con utenti reali, il guadagno rispetto al processo attuale giustifica il costo di gestirlo. Confondere le tre è il modo più comune di spendere sei settimane di budget senza produrre nulla su cui agire.

Il segnale è cosa succede alla fine. Se il risultato è una riunione in cui si dice che sembra promettente, hai fatto una demo. Se il risultato è un numero accanto a una soglia concordata in anticipo, e una persona il cui compito è dire sì o no, hai fatto un pilota. La seconda versione può finire con un no ed essere valsa ogni ora, perché un no documentato ferma una spesa molto più grande.

Questa impostazione risolve anche la questione del budget. Durante un pilota non stai comprando software. Stai comprando l'informazione necessaria per decidere se comprarlo. Questo cambia cosa significa costoso: un pilota che costa una frazione dello sviluppo finale e impedisce in modo affidabile una costruzione sbagliata è economico, mentre uno che costa meno ma produce un risultato ambiguo è uno spreco a qualsiasi prezzo.

Il servizio clienti è un tema. Redigere la prima risposta alle email di garanzia in entrata è un processo.

Un pilota ha bisogno di un compito con confini netti. La prova pratica è riuscire a dire chi lo svolge oggi, quante volte a settimana accade, quanto dura una singola occorrenza e dove finisce il risultato. Se una di queste quattro risposte resta vaga, il perimetro è ancora un tema e il pilota passerà le prime tre settimane a scoprire cosa doveva essere.

Oltre ai confini servono quattro proprietà. Il volume, perché un compito che accade undici volte al mese non può generare un segnale in sei settimane. La tolleranza all'errore, perché la prima versione sbaglierà a volte e conviene che finisca in un punto recuperabile invece che davanti a un cliente o a un regolatore. Un riferimento misurabile, perché un miglioramento non significa nulla senza una base di cui ti fidi già. E dati che esistono già, perché un pilota che parte da un cantiere di raccolta dati è un progetto dati travestito da pilota.

C'è anche una proprietà politica che conta più di quanto i team immaginino: qualcuno in azienda deve volerlo davvero. Un processo scelto perché stava bene in una presentazione strategica, affidato a un team che non se ne era mai lamentato, ottiene cortese collaborazione e nessuna adozione, e il pilota finisce per misurare l'entusiasmo invece della tecnologia. Scegli il compito che una persona precisa è visibilmente stanca di fare.

I candidati migliori sono raramente spettacolari: estrazione da documenti in formati irregolari, prime bozze di risposta in una coda dove un umano approva ancora, smistamento e instradamento, riconciliazione tra due sistemi che non concordano. Condividono una forma: volume alto, posta in gioco unitaria bassa, un punto di controllo umano, e un numero che esiste già da qualche parte in una dashboard.

La regola che evita quasi tutti i fallimenti: se i criteri di successo non possono essere scritti in anticipo, il progetto non è pronto per diventare un pilota.

Un criterio di successo utilizzabile ha quattro parti: la metrica, il riferimento con cui la confronti, la soglia che vale come successo e la persona responsabile della misurazione. Per esempio: la redazione della prima risposta richiede oggi in media nove minuti a un operatore, su circa 400 ticket a settimana, misurata dal responsabile del supporto sull'esportazione del sistema di ticketing. Il pilota riesce se il tempo mediano di gestione scende sotto i cinque minuti mantenendo il tasso di approvazione al livello attuale o superiore. È una frase noiosa, ed è tutta la differenza tra una decisione e una discussione.

Scrivi la condizione di fallimento con la stessa cura, perché è la parte che tutti saltano. Definisci in anticipo quale risultato significherebbe fermarsi, e fallo accettare da chi decide mentre nessuno è ancora coinvolto emotivamente. Senza questo, un esito mediocre viene sempre letto con indulgenza, e un progetto che doveva chiudersi alla sesta settimana scivola in una fase due sostenuta dal solo entusiasmo. Buona parte degli abbandoni rilevati da S&P Global è questa deriva che prima o poi sbatte contro un muro, più tardi e più costosamente del necessario.

Due elementi accompagnano la soglia. Un tetto di costo, espresso per unità di lavoro invece che come totale mensile, perché è l'unitario a dirti se l'economia regge a dieci volte il volume. E un livello minimo di qualità separato dall'obiettivo di velocità, dato che quasi qualsiasi numero di latenza o costo si può raggiungere degradando l'output: un pilota che ottimizza la metrica scritta rovinando in silenzio quella non scritta è un esito classico ed evitabile.

È anche il test onesto per capire se avviare un pilota. Non riuscire a scrivere il riferimento di solito significa che il processo non è strumentato, e il primo cantiere corretto è la strumentazione. Non riuscire a indicare chi decide di solito significa che nessuno ha davvero accettato di cambiare il modo in cui si lavora, e nessun risultato di pilota lo sistemerà.

Un pilota che gira su un estratto ripulito dentro un notebook non ti dice quasi nulla sul sistema che dovresti gestire.

Condizioni di produzione significa i dati reali con i loro buchi reali, gli utenti reali nel loro lavoro reale, e i punti di integrazione che esisteranno dopo. La ragione non è il rigore fine a se stesso: i guasti interessanti vivono esattamente lì. Il record malformato, il caso limite che vale il quattro per cento del volume e l'ottanta per cento della difficoltà, il passaggio di consegne che richiede un permesso che nessuno ha. Un pilota su dati puliti non ne trova nessuno e produce un numero su cui non puoi contare.

Quattro cose devono esistere alla fine, e costruirle durante il pilota è il punto, non un costo accessorio. Un banco di valutazione che gira nella tua integrazione continua, perché la qualità sia un test e non un'impressione, e perché il numero resti riproducibile dopo un cambio di modello o di prompt. Guardrail in ingresso e in uscita. Un tetto di costo rigido, perché un ciclo fuori controllo non diventi una fattura a sorpresa. E un ripiego documentato verso il processo precedente, che è ciò che rende accettabile mettere la cosa davanti a utenti veri.

Sei settimane è la forma che abbiamo adottato per una singola funzionalità di produzione: abbastanza lunga da incontrare casi limite reali e ottenere una misura stabile, abbastanza corta perché la decisione resti davanti a chi l'ha autorizzata. Gli incarichi più lunghi tendono a perdere il proprio decisore in una riorganizzazione o in un ciclo di budget, che è un modo silenzioso di fallire.

Tieni il codice nei tuoi repository dal primo commit. Durante il pilota non costa nulla e determina quanto vale un sì: se il lavoro resta nell'ambiente di un fornitore fino a una consegna di fine incarico, un risultato positivo ti compra una dipendenza invece di un sistema, e una consegna puntuale fallisce molto più spesso di un processo di trasferimento.

La misura di un pilota non è se ha funzionato. È se il risultato era abbastanza chiaro da poterci agire, in un senso o nell'altro.

Alla fine devi poter dire quattro cose in un paragrafo: qual era il riferimento, cosa ha ottenuto il sistema rispetto a quello, quanto costa per unità a volume reale e cosa si rompe se tripli quel volume. Un pilota che produce queste quattro frasi ha fatto il suo lavoro, che il verdetto sia costruire, comprare o fermarsi.

Un no netto è un buon esito e va trattato come tale internamente, perché l'alternativa era scoprirlo dopo lo sviluppo completo. Quello che resta da un pilota negativo è reale: un riferimento strumentato che prima non avevi, un banco di valutazione che sopravvive al tentativo, e una ragione documentata per cui questo processo resiste all'automazione, il che evita che la stessa idea torni ogni due trimestri.

Il vero rischio non è né il sì né il no. È un risultato che ognuno può interpretare a proprio favore, cosa che accade ogni volta che la soglia è stata scritta a posteriori o non è stata scritta affatto. Quell'ambiguità è ciò che alimenta le statistiche sugli abbandoni: non un progetto fallito, ma un progetto che non è mai riuscito a dire a nessuno di aver funzionato.