Per capire se l’IA migliora il lavoro, scegli un risultato aziendale rilevante, fissane il valore di partenza e confronta attività equivalenti svolte con e senza IA, quando è possibile. Il numero di prompt, token o righe di codice descrive l’attività: da solo non dimostra un vantaggio per l’impresa.
Misurare i risultati, non l’uso degli strumenti
Colleen Aubrey, vicepresidente senior di Applied AI Solutions in Amazon Web Services (AWS), sostiene che l’IA vada valutata con metriche aziendali già significative per l’organizzazione. La sua posizione è stata riportata da SiliconANGLE in un’intervista pubblicata il 6 novembre 2026; non è una direttiva generale di AWS.
La misura dipende dal problema: se il progetto punta a migliorare la gestione delle scorte, per esempio, ha senso osservare l’inventario. Per valutare il lavoro di un team, possono essere più pertinenti tempi, qualità o costi. La metrica va scelta prima di osservare il risultato, così da poterla confrontare con una base di partenza. Un semplice confronto prima-dopo, però, può risentire anche di altri cambiamenti avvenuti nel frattempo.
Parti da un risultato che conta per l’azienda. Poi verifica se cambia insieme al lavoro svolto, includendo anche la qualità e le attività successive.
Confrontare attività equivalenti
Per distinguere meglio il contributo dell’IA da quello di altri fattori, IBM descrive un confronto tra gruppi simili che svolgono lo stesso progetto: un gruppo usa l’IA, l’altro lavora con metodi tradizionali. IBM considera velocità, qualità, costo e accuratezza. È una modalità di confronto descritta da IBM, non il metodo attribuito ai casi AWS.
Il confronto è più utile se tiene conto anche del tipo di attività e delle competenze specifiche di chi la svolge. IBM consiglia inoltre di osservare come le persone si adattano agli strumenti e quanto questi si integrano con quelli già usati dal team. Se un gruppo conosce già bene il compito o gli strumenti, una media complessiva può nascondere differenze importanti.
Che cosa raccontano gli esempi AWS
Nel resoconto dell’intervista, SiliconANGLE attribuisce ad AWS una riduzione del 7% dell’inventario di Wells Vehicle Electronics nell’arco di tre mesi, mentre le referenze monitorate attivamente passavano da 20 a 2.000. Il dato mette insieme un risultato aziendale e un cambiamento nella quantità di prodotti seguiti.
Aubrey ha anche riferito che il ritmo delle messe in produzione del suo gruppo è raddoppiato dopo interventi sulla copertura dei test e sulle pipeline. Sono due esempi riportati, con misure diverse: uno riguarda le scorte, l’altro il rilascio del software. Per interpretarli, conviene mantenere ciascun indicatore legato al suo obiettivo e al suo contesto.
Per il software, seguire l’intero ciclo di sviluppo
Per i team software, GitLab raccomanda di valutare l’intero ciclo di vita dello sviluppo, dall’ideazione alla produzione. La quantità di codice generato o la velocità di una prima attività possono non riflettere il tempo speso poi in revisione, test e manutenzione. Anche qualità e sicurezza fanno parte del quadro: il codice generato può richiedere controlli o correzioni aggiuntivi.
| Ambito | Misure da considerare | A cosa si riferiscono |
| Attività aziendali comparabili | Velocità, qualità, costo e accuratezza | Confronto tra gruppi simili impegnati nello stesso progetto, con e senza IA, come descritto da IBM |
| Sviluppo software | Frequenza dei rilasci, tempo di consegna delle modifiche, tempo medio di ripristino, tasso di modifiche non riuscite e affidabilità | Indicatori DORA citati da GitLab per la distribuzione del software, da valutare insieme a qualità, sicurezza e lavoro successivo |
Gli indicatori DORA riguardano la consegna del software, non ogni progetto di IA. Usarli insieme a qualità, sicurezza e attività successive aiuta un team di sviluppo a valutare il flusso di lavoro nel suo complesso, invece di fermarsi alla velocità iniziale o al volume di codice prodotto.
