Come si misura un progetto AI che non è un giocattolo

Senza il prima non esiste il dopo

Prima di toccare qualsiasi modello, misura il processo com’è oggi per due o tre settimane. Quanti casi entrano, quanto tempo passa dall’arrivo alla chiusura, quante volte un output torna indietro per essere rifatto. Non serve un data warehouse: serve un campione onesto, preso in un periodo normale.

La baseline è la prima cosa che salta quando c’è fretta, ed è la stessa che rende indifendibile il progetto sei mesi dopo. Senza il prima, ogni miglioramento diventa un’opinione: qualcuno dirà che si lavorava bene anche senza, e tu non avrai niente da mettere sul tavolo.

Registra la distribuzione, non solo la media. Un processo che chiude in due giorni di mediana ma trascina una coda di casi che ci mettono settimane ha un problema diverso da quello che sembra. Spesso è proprio la coda il posto dove l’AI serve.

La qualità si giudica su casi veri

La qualità dell’output non si valuta leggendo tre risposte e dicendo che suonano bene. Si valuta su un set di valutazione: casi reali presi dal tuo storico, con accanto la risposta che consideri corretta. Va costruito prima del prototipo, perché è anche il documento che mette per iscritto cosa significa «corretto» in questa azienda.

Un set fatto solo di casi facili dà sempre ragione al sistema. Serve una selezione che assomigli al lavoro vero, comprese le parti sgradevoli.

• Una quota consistente dei casi viene dalla parte difficile dello storico: eccezioni, richieste ambigue, documenti scritti male.
• La risposta di riferimento la scrive chi quel lavoro lo fa oggi, non chi costruisce il sistema.
• I criteri sono espliciti e verificabili: merito della risposta, fonte citata giusta, formato rispettato, nessuna informazione inventata.
• Il set resta congelato tra una versione e l’altra, altrimenti confronti due esami, non due sistemi.
• Una parte dei casi non la vede mai chi sviluppa, altrimenti il sistema finisce cucito su quelli.

Impatto sul processo

Il set di valutazione dice se il sistema risponde bene. Non dice se l’azienda lavora meglio. Per quello servono i numeri della baseline, ricalcolati con lo stesso metodo: tempo di attraversamento, casi gestiti nell’unità di tempo, quota di casi chiusi senza intervento umano.

Le rilavorazioni sono la voce più sottovalutata delle tre. Un sistema che produce in metà tempo output che tornano quasi sempre indietro non ha accelerato il processo: ha spostato il lavoro più avanti, dove è più difficile vederlo. Contale a parte, e distingui la correzione di forma da quella di sostanza.

Misura anche il tempo che il sistema aggiunge: revisione, controllo delle fonti, travaso dei dati nel gestionale. Un risparmio calcolato ignorando il tempo di controllo non è una misura, è una speranza messa in tabella.

Economia: il costo per operazione

La domanda economica è una sola: quanto costa gestire un caso, tutto compreso, prima e dopo. Il costo di inferenza è la voce più visibile e quasi mai la più grande: quello che conta è quante chiamate servono per chiudere un caso, tentativi inclusi, non il prezzo della singola risposta.

Il costo per operazione va letto insieme al volume, perché un sistema che costa poco su cento casi al mese può essere insostenibile su diecimila. E uno che costa più del lavoro che sostituisce è un esperimento, non un investimento, ed è meglio scoprirlo sul prototipo. Nello stesso conto vanno anche le voci che nella slide iniziale non compaiono mai.

• L’infrastruttura che regge il sistema: indicizzazione, aggiornamento delle fonti, monitoraggio, conservazione dei log.
• Il lavoro umano che resta: se ogni output passa da una revisione, quella revisione è un costo del nuovo sistema, non del vecchio processo.
• La manutenzione ordinaria: rimettere mano ai prompt, tenere aggiornati i documenti citati, rilanciare il set di valutazione quando cambia il modello.

Rischio: gli errori non si mediano

Non tutti gli errori pesano uguale. Una risposta generica costa un minuto. Una cifra sbagliata mandata a un cliente, o un dato personale finito dove non doveva, costa molto di più. Una percentuale media di accuratezza nasconde esattamente questa differenza.

Definisci prima cosa conta come errore grave nel tuo dominio e contalo separatamente. Poi misura il tasso di escalation, quante volte il sistema passa la mano a una persona, e leggilo come un numero a due facce: troppo alto e non stai risparmiando niente, troppo basso e probabilmente il sistema risponde anche quando non dovrebbe.

Tieni un registro degli incidenti dal primo giorno, anche quando sono due righe. Se il processo tocca le persone, non è solo buon senso: l’AI Act commisura gli obblighi all’impatto dell’uso e ti chiede di saper dire cosa il sistema fa, il GDPR di sapere quali dati personali entrano e con quale base giuridica. Le metriche che ti servono per governare il progetto sono le stesse che ti servono per documentarlo.

Prima del codice, una pagina

Le metriche le sceglie chi possiede il processo, non chi costruisce il sistema. È una regola pratica: il responsabile di quell’ufficio sa quali casi sono difficili e quale numero viene già guardato ogni lunedì mattina. Se scegli tu, sceglierai qualcosa che il sistema sa già fare bene.

L’accordo si chiude prima di scrivere codice e sta su una pagina: quali metriche, come si calcolano, chi le calcola, il valore di partenza, la soglia sotto la quale il progetto non continua. Mezz’ora all’inizio evita tre mesi di discussione su cosa volesse dire il risultato.

Sulla stessa pagina scrivi cosa non conta. Il numero di richieste cresce con la curiosità e con le domande rifatte perché la prima risposta era sbagliata. Il tempo risparmiato ottenuto moltiplicando i casi per un risparmio ipotetico è un’assunzione travestita da misura. Il punteggio che il modello dà a se stesso serve durante lo sviluppo, non in comitato.

La prossima mossa è piccola: prendi il progetto che hai in corso e compila quella pagina oggi, per tutte e quattro le famiglie. Se ci riesci, hai un progetto misurato. Se restano caselle vuote, hai trovato il primo lavoro da fare, e non richiede una riga di codice.