Come capire se un progetto pilota AI ha funzionato.

Cosa deve dimostrare un progetto pilota

Un progetto pilota è una prova limitata di un sistema di intelligenza artificiale su un’attività reale, con un perimetro definito, una durata stabilita e una decisione da prendere alla fine. Risponde a una domanda precisa: su questa attività, in questa azienda e con queste persone, il sistema fa risparmiare abbastanza tempo o migliora abbastanza il risultato da giustificare costi e rischi?

Una dimostrazione del fornitore mostra che lo strumento sa fare qualcosa in condizioni favorevoli. Il pilota lavora invece sui casi di tutti i giorni, compresi quelli difficili, insieme alle persone che poi dovranno usarlo.

Il NIST, l’istituto statunitense per gli standard e la tecnologia, nel suo AI Risk Management Framework indica tra gli esiti della gestione del rischio una decisione esplicita: stabilire se il sistema raggiunge gli scopi e gli obiettivi dichiarati e se il suo sviluppo o la sua adozione devono proseguire. Il framework è volontario e pensato per organizzazioni di ogni dimensione, e il principio vale anche per una PMI di dieci persone. Un pilota che finisce senza una decisione scritta tende a continuare per inerzia, con costi che nessuno ha approvato.

Per arrivare alla decisione servono una misura di partenza, il tempo totale per caso, la qualità, le eccezioni, il costo d’uso, l’adozione da parte delle persone e criteri fissati prima di cominciare. I criteri vengono per primi, perché vanno scritti quando i risultati ancora non si conoscono.

Perché i criteri vanno decisi prima

Alla fine di una prova, con il lavoro già fatto e l’entusiasmo o la delusione del momento, è facile trovare buone ragioni per qualsiasi decisione. Scrivere i criteri in anticipo protegge da questo rischio e rende la valutazione comprensibile anche a chi non ha seguito il progetto.

Un criterio utile dice cosa si misura, come lo si misura, quale soglia rende il risultato accettabile e chi decide. La soglia la fissa l’azienda, partendo dai propri costi e dai propri rischi; nessuna regola generale può dirla al posto suo. Una formulazione tipica suona così: il tempo totale per caso, controlli compresi, deve scendere sotto un valore stabilito; gli errori che arrivano al cliente non devono aumentare rispetto a oggi; il costo per caso a regime deve restare sotto il costo attuale.

Conviene distinguere i criteri che bastano da soli per fermare la prova da quelli che si possono compensare. Un errore grave su un dato personale, o un preventivo sbagliato inviato a un cliente, può essere un motivo sufficiente per fermarsi anche se il resto va bene. Un risparmio di tempo più basso del previsto, a qualità invariata, porta più spesso a una correzione.

Vanno decisi prima anche il perimetro e la durata: quali casi entrano nella prova, quali restano fuori, per quanto tempo. La durata deve coprire un ciclo normale dell’attività, con scadenze e picchi compresi; se la prova cade in un periodo tranquillo, misura solo quello.

La baseline: misurare come si lavora oggi

La baseline è la misura del processo attuale, senza AI, sugli stessi tipi di casi che entreranno nel pilota. Senza baseline qualsiasi risultato sembra buono, perché manca il termine di confronto. Il NIST lo scrive in modo esplicito: la gestione dei rischi di sistemi che affiancano o sostituiscono attività umane richiede una qualche misura di riferimento con cui confrontarli. Anche lo studio sperimentale di Dell’Acqua e colleghi sull’uso di GPT-4 da parte dei consulenti di Boston Consulting Group, pubblicato su Organization Science, ha misurato le prestazioni di partenza dei partecipanti prima di assegnarli ai gruppi con e senza AI.

In una PMI la baseline si costruisce con mezzi semplici. Si prende un campione di casi recenti e rappresentativi, compresi quelli difficili, e si registra per ciascuno il tempo di lavoro, le correzioni, gli errori emersi in seguito e i passaggi ad altre persone. Se questi dati non esistono, si raccolgono per un periodo prima di avviare la prova, con un foglio condiviso e un po’ di disciplina. Le stime a memoria, del tipo «ci vuole circa mezz’ora», tendono a ricordare il caso medio e a dimenticare quelli complicati.

Conviene anche tenere da parte una serie di casi già risolti, con il risultato corretto noto, da far elaborare anche al sistema. Così il confronto tra risultato atteso e risultato ottenuto avviene sugli stessi esempi e non dipende dai casi che capitano durante la prova. La stessa serie serve di nuovo dopo ogni correzione e ogni aggiornamento del sistema.

Il tempo che conta è quello totale

Il risparmio di tempo è la misura che si guarda per prima, e anche quella che si calcola male più spesso, perché si conta solo il tempo che il sistema impiega a produrre un risultato. Per chi lavora, il tempo di un caso comprende la preparazione dell’input, l’attesa del risultato, il controllo, la correzione, la gestione dei casi che il sistema non sa trattare e il lavoro per rimediare agli errori scoperti in seguito.

Il calcolo è semplice. Si sommano, per tutti i casi del periodo, il tempo di preparazione, di controllo, di correzione, di gestione delle eccezioni e di rimedio agli errori, e si divide per il numero di casi. Il risultato si confronta con la baseline calcolata nello stesso modo. Il risparmio del periodo è la differenza per caso moltiplicata per il numero di casi gestiti.

Il tempo di controllo merita un’attenzione particolare. La ricerca sui fattori umani studia da tempo la tendenza a fidarsi troppo dei sistemi automatici. Parasuraman e Manzey, in una rassegna pubblicata su Human Factors nel 2010, descrivono questa distorsione da automazione e osservano che riguarda sia i principianti sia gli esperti, e che istruzioni e formazione da sole non bastano a prevenirla.

In un pilota questo significa leggere con cautela un tempo di controllo che scende quasi a zero dopo pochi giorni. Può darsi che il sistema sia affidabile, oppure che le persone abbiano smesso di controllare. Per capirlo si ricontrolla a campione una parte dei risultati già approvati, e si confronta quello che il controllo ha lasciato passare con quello che una revisione attenta avrebbe corretto.

Qualità ed eccezioni, lette per tipo di caso

La qualità si misura confrontando il risultato del sistema con quello che una persona competente considera corretto. Gli errori vanno classificati per gravità: ci sono quelli che il controllo intercetta e costano qualche minuto, quelli che arrivano al cliente o in contabilità, quelli che toccano dati personali o decisioni importanti. Contare solo il numero totale degli errori mette sullo stesso piano un refuso e un prezzo sbagliato.

Le eccezioni sono i casi che il sistema non sa gestire e che tornano a una persona. La loro quota si ottiene dividendo i casi tornati indietro per i casi totali del periodo. Un’eccezione dichiarata è meno pericolosa di un errore silenzioso, quindi un sistema che riconosce i propri limiti e passa la mano può valere più di uno che risponde sempre. Una quota di eccezioni alta riduce però il risparmio, perché quei casi richiedono lo stesso lavoro di prima più il tempo perso a scoprirli.

Una media calcolata sull’intero pilota può nascondere differenze importanti. Lo studio di Dell’Acqua e colleghi descrive una frontiera frastagliata delle capacità dell’AI: nello stesso flusso di lavoro, e su compiti di difficoltà apparentemente simile, l’assistenza dell’AI migliorava le prestazioni su alcuni compiti e le peggiorava su altri. Per una PMI la conseguenza pratica è dividere i casi del pilota in gruppi, per esempio ordini standard, ordini con varianti e ordini con richieste insolite, e valutare ogni gruppo per conto suo.

Può succedere che il sistema vada bene sul primo gruppo e male sul terzo. In quel caso la scelta più sensata è spesso usarlo solo dove funziona e lasciare il resto alle persone, scrivendo con chiarezza dove passa il confine.

Il costo d’uso, compreso quello che non compare in fattura

Il costo del pilota raramente coincide con il costo dell’uso a regime. Durante la prova le licenze possono essere gratuite o scontate, i volumi bassi, l’assistenza del fornitore più presente. Per decidere serve una stima del costo per caso nelle condizioni reali.

Le voci da sommare sono le licenze o gli abbonamenti, i costi a consumo, che per molti servizi di AI dipendono dalla quantità di testo elaborata, l’integrazione con gestionale e posta, la manutenzione, il tempo del referente interno e la formazione delle persone. Dividendo il totale del periodo per il numero di casi gestiti si ottiene il costo per caso del sistema. Il costo per caso attuale si ricava dalla baseline: tempo totale per caso moltiplicato per il costo orario di chi svolge l’attività.

Il confronto tra i due valori dice se il sistema si ripaga con il lavoro risparmiato. Altri effetti non entrano facilmente nel conto e vanno descritti a parole: risposte più rapide ai clienti, meno dipendenza da una sola persona, ma anche nuove dipendenze da un fornitore e dal modello che usa.

I modelli di AI vengono aggiornati, e un aggiornamento può cambiare il comportamento del sistema anche quando nessuno in azienda ha toccato nulla. Per questo nel costo entra anche il tempo per riverificare i risultati, con la serie di casi di prova, ogni volta che succede.

L’adozione: le persone lo usano davvero?

Un sistema che funziona nei test ma che le persone aggirano non produce risparmi. L’adozione si misura con un rapporto semplice, i casi passati dal sistema divisi per i casi che avrebbero potuto passarci, e con l’osservazione di come si lavora: chi ricopia comunque i dati a mano, chi tiene un foglio parallelo «per sicurezza», chi usa il sistema solo quando c’è il referente.

Il parere di chi lo usa è un dato e va raccolto in modo ordinato. Il NIST AI RMF include tra le attività di misura processi che permettono agli utenti finali di segnalare problemi e contestare i risultati, integrati nelle metriche di valutazione. In una piccola azienda bastano un canale semplice per segnalare gli errori durante la prova e un breve colloquio finale con ogni persona coinvolta. Le domande utili sono concrete: in quali casi il sistema ti ha fatto risparmiare tempo, in quali te ne ha fatto perdere, cosa controlli sempre, cosa cambieresti.

Una bassa adozione ha cause diverse, e ognuna porta a una decisione diversa. Se le persone non si fidano perché il sistema sbaglia, il problema è la qualità. Se non lo usano perché richiede passaggi in più, il sistema non è ben inserito nel processo. Se non sanno come usarlo, o temono le conseguenze di un errore, mancano formazione e regole chiare su chi risponde di cosa.

Estendere, correggere o fermarsi

Con le misure raccolte, la decisione si prende confrontando i risultati con i criteri scritti all’inizio. Le strade possibili sono tre.

Si estende quando i criteri sono rispettati sui gruppi di casi che si vogliono coprire, le persone usano il sistema e il costo per caso a regime è sostenibile. L’estensione può essere graduale: prima i casi su cui il pilota ha funzionato, poi gli altri, continuando a misurare allo stesso modo.

Si corregge quando i risultati sono incompleti ma la causa è riconoscibile, per esempio input disordinati, istruzioni poco chiare, un passaggio del processo che il sistema non vedeva o una formazione insufficiente. Dopo la correzione serve una nuova misura con gli stessi criteri, per evitare di spostare l’asticella dopo aver visto i risultati.

Ci si ferma quando il sistema non raggiunge i criteri e non c’è una causa correggibile, quando il costo supera il risparmio, quando gli errori gravi restano sopra la soglia accettata, oppure quando la baseline era già buona e il margine di miglioramento è troppo piccolo. Tra le opzioni che il NIST elenca, accanto alla ricalibrazione e alla mitigazione degli impatti, c’è anche la rimozione del sistema dall’uso. Fermarsi dopo un pilota piccolo costa poco e lascia misure e casi di prova che servono alla valutazione successiva.

La decisione va scritta, con le misure che la motivano, da chi era stato indicato all’inizio come responsabile.

Cosa un pilota non può dimostrare

Un pilota misura un sistema in condizioni limitate, e i suoi risultati valgono per quelle condizioni. Il NIST chiede di documentare i limiti della generalizzazione oltre le condizioni in cui il sistema è stato provato, e il consiglio vale anche per una piccola impresa.

Il numero di casi può essere troppo piccolo per far emergere gli errori rari, che sono spesso i più costosi. Il periodo può non comprendere stagionalità, picchi o scadenze. Le persone coinvolte sono spesso le più motivate, e possono non rappresentare chi userà il sistema dopo l’estensione. Va considerato anche che sapere di essere osservati può cambiare il modo di lavorare, sia durante la baseline sia durante la prova.

Per questo la misura continua dopo la decisione di estendere. Le stesse metriche, raccolte con meno frequenza, servono a verificare che il sistema funzioni ancora quando cambiano i volumi, le persone o il modello. Anche il framework del NIST prevede che il comportamento del sistema sia monitorato quando è in produzione.