Misurare il ritorno dell'AI in azienda senza illudersi

Pubblicato il • Generato e revisionato

Misurare il ritorno dell'AI in azienda senza illudersi

Un cliente mi ha mostrato, qualche mese fa, un report interno sul loro primo progetto AI. Avevano integrato un assistente per la gestione delle email commerciali. Nel report c'era scritto: "stimiamo un risparmio di 2 ore al giorno per commerciale". Cinque commerciali, duecento giorni lavorativi, un bel numero annuale. Tutto molto convincente. Quando ho chiesto come avevano misurato quel dato, mi hanno risposto: "è una stima dei commerciali stessi".

Ecco il problema. Non con l'AI, ma con il modo in cui la maggior parte delle aziende valuta l'AI. Si parte da stime ottimistiche, si moltiplicano per numeri grandi, si arriva a ROI che sembrano giustificare qualsiasi investimento. Poi, sei mesi dopo, nessuno sa dire se il progetto ha funzionato davvero.

Il peccato originale: misurare ciò che è facile, non ciò che conta

La metrica più comune nei progetti AI è il tempo risparmiato. È intuitiva, si comunica bene agli stakeholder, e sembra oggettiva. In realtà, è quasi sempre sbagliata per due motivi.

Primo: il tempo risparmiato non è valore creato automaticamente. Se un commerciale risparmia un'ora al giorno grazie all'AI, quell'ora diventa valore solo se viene reimpiegata in attività a maggior rendimento: più chiamate, più offerte, più relazioni. Se invece viene assorbita da riunioni o micro-task, il risparmio esiste sulla carta, non nel conto economico.

Secondo: le stime self-report sono sistematicamente distorte verso l'alto. Le persone tendono a sopravvalutare il tempo speso in attività ripetitive e a sottovalutare quanto siano già efficienti. Questo non è un problema di onestà, è un bias cognitivo documentato.

La domanda giusta non è "quanto tempo risparmia questa soluzione", ma "che cosa succede concretamente con il tempo risparmiato, e come lo vedo nel dato".

Le metriche che sembrano solide ma ingannano

Oltre al tempo risparmiato, esistono altre metriche superficialmente convincenti che circolano nei pitch e nei report aziendali.

Numero di task automatizzati. Un KPI che misura quantità, non qualità. Automatizzare mille task irrilevanti non vale quanto automatizzare dieci task critici. Peggio ancora: un task "automatizzato" che richiede comunque revisione umana costante non è davvero automatizzato.

Tasso di adozione dello strumento. Molte aziende celebrano l'adozione come successo. Ma adozione non significa utilizzo efficace. Gli utenti possono aprire uno strumento ogni giorno senza che questo produca valore misurabile.

Soddisfazione degli utenti. Utile come indicatore di usabilità, inutile come proxy di business impact. Uno strumento può piacere moltissimo e non spostare nessun numero che conta.

Queste metriche non sono inutili in assoluto: servono a diagnosticare problemi di processo o di adozione. Il guaio è usarle come prova del ROI.

Le metriche che contano davvero

Misurare il ritorno reale di un progetto AI richiede di collegare l'intervento a outcome di business misurabili e preesistenti al progetto. Questo significa stabilire la metrica obiettivo prima di partire, non dopo.

Ecco i criteri che uso per valutare se una metrica è seria:

  • Esiste un dato storico di riferimento (baseline) misurato prima dell'AI?
  • La metrica è influenzata direttamente dall'attività automatizzata, senza troppi passaggi intermedi?
  • È verificabile da una fonte oggettiva, non da stime degli utenti?
  • L'effetto è isolabile rispetto ad altri cambiamenti avvenuti nello stesso periodo?

In pratica, per un progetto di AI applicata al customer service, le metriche serie sono: tempo medio di risoluzione ticket, tasso di riapertura dei ticket, costo per ticket gestito. Non "quante risposte ha generato l'AI".

Per un progetto di AI applicata alla generazione di contenuti: tempo dal briefing alla versione approvata, numero di revisioni per contenuto, costo per contenuto pubblicato. Non "quanti contenuti abbiamo generato".

Il principio è sempre lo stesso: misura l'output di business, non l'attività dell'AI.

Costo per task: un indicatore utile se usato bene

Il costo per task è una delle metriche più oneste disponibili, ma va costruita con attenzione. L'errore frequente è includere solo i costi diretti della soluzione AI (licenza, API, infrastruttura) dimenticando i costi nascosti.

I costi nascosti che vedo quasi sempre sottostimati:

  • Tempo del team interno per implementazione, testing e manutenzione
  • Supervisione umana necessaria per validare gli output (mai zero, spesso sottovalutata)
  • Costo degli errori: un output AI sbagliato che arriva al cliente o entra in un processo critico ha un costo reale
  • Formazione e change management

Quando si calcola il costo per task includendo tutto questo, spesso il vantaggio economico si riduce rispetto alle stime iniziali. Ma questo non è necessariamente un problema: significa che si sta valutando con onestà, e si possono prendere decisioni migliori su dove scalare e dove no.

Un costo per task realistico permette anche di confrontare scenari: vale la pena ottimizzare questo processo con AI, o è più efficiente assumere una persona part-time, o ristrutturare il processo in altro modo?

Qualità dell'output: il problema più difficile da misurare

La qualità è la variabile che quasi tutti ignorano nelle valutazioni AI, perché è scomoda da misurare. Eppure è spesso quella determinante.

Un sistema AI che produce output al 70% di qualità rispetto allo standard umano, e che richiede revisione nel 40% dei casi, non ha lo stesso valore di uno che produce output al 90% di qualità con revisione nel 10% dei casi. Eppure nei report aziendali i due scenari vengono presentati allo stesso modo.

Come si misura la qualità in modo pratico? Dipende dal contesto, ma alcune strade funzionano.

Per output che vanno a cliente (email, offerte, contenuti): tasso di conversione, feedback diretto, tasso di rimbalzo su contenuti digitali. Metriche che il mercato fornisce in modo abbastanza oggettivo.

Per output interni (report, sintesi, analisi): si può usare una rubrica di valutazione condivisa tra gli utenti, con criteri definiti prima del progetto. Non è perfetto, ma è meglio del "sembra buono".

La cosa importante è definire un benchmark di qualità baseline prima di introdurre l'AI, in modo da avere un confronto reale.

La mossa concreta che puoi fare domani mattina

Se stai valutando un progetto AI o ne stai già gestendo uno, prendi il documento di valutazione che hai (presentazione, report, foglio di calcolo) e cancella ogni riga che contiene stime self-report, numeri proiettati senza baseline storica, o metriche di attività AI invece di outcome di business. Quello che rimane è la tua valutazione reale. Se rimane poco, è il momento di costruire le basi di misurazione prima di andare avanti, non dopo.

Fonti

Torna al blog