Una dimostrazione di intelligenza artificiale può essere impressionante.
Una richiesta complessa viene interpretata correttamente. Una risposta che avrebbe richiesto mezz’ora arriva in pochi secondi. Un documento viene analizzato, un testo viene prodotto, un agente riesce a utilizzare diversi strumenti.
È facile guardare tutto questo e concludere che il progetto funziona.
Ma una demo dimostra soprattutto che una tecnologia è capace di fare qualcosa.
Non dimostra ancora che quell’attività abbia prodotto valore per l’azienda.
Tra le due cose c’è una distanza importante.
Un progetto AI può funzionare tecnicamente e non modificare quasi nulla nel lavoro reale.
Può generare ottimi contenuti che devono poi essere completamente ricontrollati.
Può far risparmiare cinque minuti in un’attività che rappresenta una parte irrilevante del processo.
Può essere utilizzato molto e produrre comunque risultati poco utili.
Può persino velocizzare una fase creando più lavoro nella fase successiva.
Per questo, quando l’AI entra davvero in azienda, la domanda cambia.
Non è più:
“Quanto è bravo il modello?”
Diventa:
“Che cosa è migliorato da quando lo utilizziamo?”
Prima di misurare l’AI bisogna misurare il lavoro
Se non sappiamo come funzionava un processo prima dell’introduzione dell’AI, diventa difficile stabilire quanto sia migliorato dopo.
Serve una baseline.
Quanto tempo richiede oggi l’attività?
Quante persone intervengono?
Quanti passaggi manuali esistono?
Quante eccezioni vengono gestite?
Quanti errori richiedono correzioni?
Quanto tempo passa tra l’inizio e la conclusione?
Qual è il livello qualitativo del risultato?
Queste misure non devono necessariamente trasformarsi in un progetto analitico complesso.
Devono però permetterci di descrivere il punto di partenza.
Altrimenti rischiamo di attribuire all’intelligenza artificiale miglioramenti che non abbiamo realmente verificato.
E soprattutto non possiamo capire se il costo necessario per introdurla è proporzionato al beneficio ottenuto.
Output e risultato non sono la stessa cosa
Uno dei problemi più comuni nella valutazione dell’AI è misurare ciò che il sistema produce invece di ciò che il processo ottiene.
Numero di prompt.
Numero di conversazioni.
Documenti generati.
Richieste processate.
Token consumati.
Utenti attivi.
Sono dati utili.
Ma descrivono soprattutto l’utilizzo del sistema.
Non necessariamente il suo valore.
Se cento persone utilizzano ogni giorno uno strumento AI, sappiamo che lo strumento viene utilizzato.
Non sappiamo ancora se stanno lavorando meglio.
La misura interessante arriva un livello dopo.
Quanto tempo viene realmente eliminato?
Quanti errori vengono evitati?
Quante attività aggiuntive possono essere gestite?
Quanto diminuisce il tempo di risposta?
Quanta rilavorazione viene eliminata?
Quanto migliora il risultato consegnato al cliente?
Il passaggio fondamentale è quindi:
Output → Cambiamento operativo → Valore
Saltare il passaggio centrale rende molto facile confondere attività con risultato.
Il tempo risparmiato non è automaticamente valore
“Abbiamo risparmiato cento ore.”
È una frase che sembra già esprimere un risultato economico.
Non sempre è così.
Se quelle cento ore liberate vengono assorbite da altre attività poco utili, il beneficio economico può essere minimo.
Se invece permettono allo stesso gruppo di persone di gestire più clienti, ridurre arretrati, accelerare consegne o concentrarsi su attività ad alto valore, il risultato cambia completamente.
Il tempo liberato è quindi una capacità potenziale.
Il valore nasce da ciò che l’organizzazione riesce a fare con quella capacità.
Questa distinzione è particolarmente importante con l’intelligenza artificiale perché molti benefici iniziali vengono descritti in termini di produttività individuale.
Scrivere più velocemente.
Riassumere più velocemente.
Cercare più velocemente.
Preparare documenti più velocemente.
Sono miglioramenti reali.
Ma per trasformarsi in valore aziendale devono produrre un effetto nel processo complessivo.
Non misurare soltanto la velocità
L’AI rende naturale concentrarsi sul tempo perché è uno degli effetti più facili da osservare.
Ma un sistema più veloce non è necessariamente un sistema migliore.
Una risposta prodotta in trenta secondi ma controllata per venti minuti potrebbe non essere più efficiente della procedura precedente.
Una classificazione automatica rapidissima ma poco affidabile può creare lavoro aggiuntivo.
Un agente che completa molte attività ma genera eccezioni frequenti può spostare il problema invece di eliminarlo.
Per questo la misura deve essere multidimensionale.
A seconda del processo possiamo osservare almeno:
Tempo Quanto cambia il tempo necessario per completare il lavoro?
Qualità Il risultato è migliore, equivalente o peggiore?
Errori Quante correzioni o rilavorazioni servono?
Capacità Quanto lavoro aggiuntivo può essere gestito con le stesse risorse?
Costo Quanto costa ottenere il risultato completo, compresa la supervisione?
Esperienza Il cambiamento migliora realmente il lavoro di chi utilizza il sistema o di chi riceve il servizio?
Non tutte queste dimensioni devono essere utilizzate contemporaneamente.
Devono essere scelte quelle che rappresentano davvero il valore del processo.
Anche la supervisione ha un costo
Uno dei rischi più facili da sottovalutare è misurare soltanto ciò che l’AI automatizza.
Un sistema genera un documento in un minuto invece di venti.
Ottimo.
Ma cosa succede dopo?
Se una persona deve impiegare quindici minuti per verificarlo, correggerlo e assicurarsi che non abbia introdotto errori, il vantaggio reale è molto diverso.
Lo stesso vale per gli agenti.
Un agente può completare automaticamente dieci passaggi ma richiedere un controllo costante sulle eccezioni.
Può ridurre il lavoro operativo e contemporaneamente aumentare quello di supervisione.
Può eliminare attività manuali e introdurre nuovi costi di integrazione, monitoraggio e manutenzione.
Questi elementi non dimostrano che il progetto non funzioni.
Significano semplicemente che dobbiamo misurare il processo completo, non il singolo passaggio automatizzato.
La qualità tecnica e il valore aziendale hanno bisogno di misure diverse
Un sistema AI deve essere valutato anche tecnicamente.
Accuratezza.
Affidabilità.
Rispetto delle istruzioni.
Qualità delle risposte.
Capacità di utilizzare correttamente gli strumenti.
Gestione delle eccezioni.
Queste valutazioni sono indispensabili.
Ma rispondono a una domanda:
“Il sistema fa bene ciò che abbiamo progettato?”
La misura aziendale risponde a una domanda diversa:
“Ciò che abbiamo progettato produce un risultato utile?”
Servono entrambe.
Un sistema tecnicamente affidabile che risolve un problema irrilevante non genera molto valore.
Un sistema potenzialmente molto utile ma tecnicamente inaffidabile non è pronto per essere utilizzato.
Solo quando le due dimensioni si incontrano abbiamo un progetto realmente solido.
Definire il successo prima del progetto
Il momento peggiore per decidere come misurare un progetto AI è quando il progetto è già terminato.
A quel punto è facile scegliere indicatori che confermano ciò che abbiamo costruito.
È molto più utile stabilire prima cosa dovrebbe cambiare.
Ad esempio:
ridurre il tempo medio di gestione di una richiesta mantenendo lo stesso livello qualitativo;
ridurre le attività manuali necessarie per preparare un report;
aumentare il numero di richieste gestibili senza aumentare proporzionalmente il carico operativo;
ridurre errori e rilavorazioni in una specifica fase;
accorciare il tempo necessario per recuperare informazioni distribuite tra sistemi diversi.
In questo modo il progetto nasce già con un criterio di successo.
E soprattutto diventa possibile decidere anche di fermarlo.
Questa è una possibilità importante.
L’obiettivo di un progetto AI non dovrebbe essere dimostrare che l’AI funziona.
Dovrebbe essere capire se funziona abbastanza bene da meritare di essere utilizzata in quel processo.
Un pilot serve a imparare, non a confermare
Un proof of concept può dimostrare che una tecnologia è tecnicamente possibile.
Un pilot dovrebbe andare oltre.
Dovrebbe permettere di osservare il sistema dentro una parte reale del lavoro.
Con persone reali.
Dati reali.
Eccezioni reali.
Vincoli reali.
È lì che emergono le informazioni più importanti.
Quanto viene utilizzato.
Dove fallisce.
Quando serve l’intervento umano.
Quale parte del beneficio previsto si manifesta veramente.
Quali nuovi costi o problemi compaiono.
Il pilot non dovrebbe essere progettato per ottenere un “sì”.
Dovrebbe essere progettato per prendere una decisione migliore.
Estendere. Modificare. Limitare. Oppure fermare.
Sono tutti risultati validi se derivano da una misura corretta.
Il ROI arriva dopo il processo
Naturalmente prima o poi entra anche la dimensione economica.
Costi evitati.
Capacità aggiuntiva.
Incremento dei ricavi.
Riduzione del rischio.
Migliore utilizzo delle persone.
Ma cercare di trasformare immediatamente ogni secondo risparmiato in euro può produrre una precisione soltanto apparente.
Prima dobbiamo capire se il cambiamento operativo è reale e stabile.
Solo dopo possiamo attribuirgli un valore economico credibile.
Il percorso più utile è quindi:
- Baseline
- Cambiamento
- Misura
- Valore
- Decisione
Non:
AI → ROI
L’AI non deve dimostrare di essere intelligente
Questa è forse la conseguenza più interessante.
Quando smettiamo di valutare l’intelligenza artificiale osservando soltanto ciò che genera, iniziamo a trattarla come qualsiasi altro investimento aziendale.
Non deve stupirci.
Deve funzionare.
Non deve produrre la risposta più elegante.
Deve contribuire a un risultato.
Non deve essere utilizzata ovunque.
Deve essere utilizzata dove produce un miglioramento che possiamo osservare e sostenere nel tempo.
E questo cambia anche il modo in cui scegliamo i progetti.
La domanda non è più:
“Dove possiamo utilizzare l’AI?”
Ma:
“Quale risultato aziendale vogliamo migliorare e possiamo dimostrare che l’AI ci aiuta realmente a farlo?”
È una domanda meno spettacolare.
Ma è quella che trasforma una tecnologia interessante in uno strumento di lavoro.