Come leggere un caso AI: baseline, osservazioni e stime prima di decidere

“Abbiamo risparmiato il 40%” è una stima finché non sai su quanti casi, misurato da chi e rispetto a quale baseline. Tre righe da tenere separate, le domande da fare a chi presenta un risultato e come raccontiamo i nostri casi.

Se devi valutare un risultato AI, tuo o di un fornitore, leggilo su tre righe separate: com’era il lavoro prima, cosa è successo nel test, cosa potrebbe succedere dopo. La prima è la baseline, la seconda sono le osservazioni, la terza sono le stime. Quasi tutte le decisioni sbagliate nascono da una stima presentata come osservazione.

Nel 2025 il 16,4% delle imprese italiane con almeno dieci addetti usava almeno una tecnologia di intelligenza artificiale, secondo Istat. Ognuna di quelle aziende ha visto, prima di decidere, almeno una presentazione con una percentuale in grande: meno 40% di tempo, più 30% di produttività, il 90% delle richieste gestite in automatico.

Alcune di quelle percentuali erano misurate. Molte erano stime. Il problema non è che esistano le stime: è che nella slide hanno lo stesso carattere, lo stesso colore e la stessa autorevolezza dei dati osservati.

“Abbiamo risparmiato il 40%” è una stima finché non sai su quanti casi, misurato da chi, rispetto a quale baseline.

Tre righe nello stesso registro

Un caso AI ben raccontato mette tre righe una accanto all’altra e non le mescola.

Il NIST AI Risk Management Framework dedica un’intera funzione, “Measure”, a questo tema: i sistemi vanno valutati con metriche definite prima, su dati rappresentativi, e i risultati vanno documentati insieme ai loro limiti. È la versione formale di una regola semplice: prima decidi cosa misuri, poi misuri, poi racconti.

1. La baseline: com’era prima

Senza baseline puoi dimostrare che il nuovo workflow funziona. Non puoi dire quanto abbia migliorato il processo, perché non sai da dove partivi.

Una baseline credibile ha un periodo definito, per esempio le ultime quattro settimane, un numero di casi, le stesse metriche che userai dopo e il nome di chi ha raccolto i dati. Se viene ricostruita a fine progetto chiedendo alle persone “quanto ci mettevate prima?”, è una stima travestita.

2. Le osservazioni: cosa è successo davvero

Le osservazioni descrivono il test: quanti casi, come sono stati scelti, in quali condizioni, con quale controllo sugli output, misurati da chi. Un test su venti casi rappresentativi, con criteri scritti e verifica di una persona diversa da chi ha costruito il workflow, produce osservazioni solide.

Un test su cinque casi scelti perché “funzionavano bene” produce una demo. Può essere utile per capire il potenziale, ma non è un risultato.

3. Le stime: cosa potrebbe succedere

Le stime sono legittime e necessarie: servono a decidere se estendere un progetto. Vanno però dichiarate come tali, con le assunzioni scritte. “Se il risparmio medio osservato su venti casi si confermasse sui circa duecento casi mensili, il tempo recuperato sarebbe di X ore al mese” è una stima onesta.

“Il progetto fa risparmiare X ore al mese” detto dopo venti casi è la stessa frase senza l’onestà.

4. Le domande da fare

Davanti a qualsiasi percentuale, quattro domande bastano quasi sempre.

1. 01Su quanti casi è stato misurato, e come sono stati scelti?
2. 02Chi ha raccolto i dati e con quali criteri?
3. 03Rispetto a quale baseline, raccolta quando?
4. 04Cosa cambierebbe nella decisione se il numero fosse la metà?

La quarta domanda è la più utile. Se la risposta è “niente, partiremmo comunque”, la percentuale non era il vero motivo della decisione. Se la risposta è “non partiremmo”, vale la pena verificare il numero prima di firmare.

5. Quanti casi servono

Non esiste un numero universale. Servono abbastanza casi da coprire le variazioni normali del processo: i casi tipici, quelli difficili, gli input incompleti, qualche eccezione. Per la maggior parte dei workflow aziendali si parla di alcune decine, raccolte in un periodo che contenga le oscillazioni abituali.

Meglio venti casi reali misurati bene che duecento stimati a tavolino. E meglio dichiarare “venti casi, quattro settimane, un valutatore” che lasciare il numero senza contesto.

Esempio: leggere “meno 40%”

Un fornitore presenta un caso: “il nuovo workflow ha ridotto del 40% il tempo di preparazione delle offerte”. Esempio dimostrativo.

Le quattro domande. Su quanti casi? Dodici, scelti dal team commerciale. Misurato da chi? Dal fornitore stesso, con un cronometro sulla fase di redazione. Rispetto a quale baseline? Al tempo medio dichiarato dai commerciali in un’intervista. Il tempo di verifica dell’ufficio tecnico? Non incluso.

Riscritto su tre righe: baseline stimata a memoria; osservazioni su dodici casi selezionati, misurate da chi ha costruito il sistema, senza il tempo di controllo; stima del 40% presentata come risultato. Il caso può essere comunque promettente. Ma la decisione va presa sapendo che il numero reale, verifica inclusa e su casi non scelti, sarà probabilmente diverso.

La richiesta ragionevole non è “dimostratemi il 40%”. È “misuriamo insieme venti casi non scelti, con la nostra baseline e il nostro tempo di verifica, e poi decidiamo”.

Come raccontiamo i nostri casi

Applichiamo la stessa regola a noi stessi. Quando pubblichiamo un caso dichiariamo il perimetro del test, il numero di casi e come sono stati scelti, chi ha misurato, la baseline e il periodo in cui è stata raccolta, il tempo di verifica umana incluso nei conti e i casi esclusi dal workflow. Le stime sono nella terza riga, con le assunzioni scritte accanto.

È una conseguenza diretta del metodo: ogni incarico parte da un risultato osservabile, ha un responsabile e prevede una verifica. Se il risultato non è osservabile, non lo raccontiamo come tale.

Un caso che dichiara i suoi limiti è più utile di un caso che promette il doppio.

Dalla lettura alla decisione

Leggere un caso su tre righe non serve a bocciarlo. Serve a decidere con le informazioni giuste: cosa è stato dimostrato, in quali condizioni, e cosa resta da verificare nel vostro contesto.

Se avete davanti più casi e proposte e volete capire quale merita un test, il nostro AI Readiness & Opportunity Assessment serve proprio a costruire la baseline, scegliere il perimetro e definire come misurare prima di partire.

Fonti utilizzate

• *Istat, Imprese e ICT – Anno 2025, pubblicato il 15 dicembre 2025.
• *National Institute of Standards and Technology, AI Risk Management Framework 1.0, funzione Measure.