Vai al contenuto
SwankyForge
SwankyForge
Tutti gli insights
Articolo9 min di lettura

Secondo un conteggio, il 95% dei pilot di IA non ha impatto sul conto economico. Concordate la metrica prima di costruire il modello.

Quattro studi del 2025 e di inizio 2026 concordano sul fatto che la maggior parte delle aziende vede un ritorno misurabile minimo dall'IA, e il fallimento tipico sta sul lato business: la soluzione è una metrica, una baseline e una regola di decisione scritte prima di costruire qualsiasi cosa.

Nel luglio 2025 il progetto NANDA del MIT ha pubblicato un rapporto secondo cui il 95% delle organizzazioni otteneva un ritorno nullo dall'IA generativa, nonostante 30–40 miliardi di $ di investimenti aziendali. Fortune ha messo il numero in un titolo nell'agosto 2025, e da lì ha fatto il giro.

Il numero è più debole della sua fama. Si basa su interviste a 52 organizzazioni, un sondaggio su 153 dirigenti raccolto in quattro conferenze di settore e un'analisi di oltre 300 iniziative di IA pubbliche. I critici hanno giudicato troppo ristretta la definizione di successo. Ma altri tre studi con metodi diversi vanno nella stessa direzione: la maggior parte delle aziende che usano l'IA non riesce ancora a ritrovarla nei propri risultati finanziari.

La nostra lettura è che la maggior parte di questi pilot era già decisa prima che un modello venisse addestrato. Nessuno ha misurato una baseline, nessuno ha concordato una metrica, nessuno nel business era responsabile del risultato e nessuno ha pianificato come l'output sarebbe entrato nel processo quotidiano. Sono lacune di business, e colmarle costa giorni di lavoro, non mesi.

Quattro studi, una direzione

Fonte Campione Cosa è stato misurato Risultato principale
MIT NANDA, luglio 2025 52 organizzazioni intervistate, 153 dirigenti sondati, oltre 300 iniziative pubbliche analizzate, gennaio–giugno 2025 Ritorno dall'IA generativa dichiarato dagli interessati Il 95% delle organizzazioni ottiene un ritorno nullo; il 5% dei pilot integrati ricava milioni in valore
BCG, settembre 2025 1.250 alti dirigenti e decisori sull'IA Valore dell'IA nell'intera azienda Il 5% genera valore sostanziale su larga scala; il 60% riporta guadagni minimi su ricavi e costi
McKinsey, novembre 2025 Sondaggio globale su organizzazioni Impatto sull'EBIT a livello aziendale L'88% usa l'IA in almeno una funzione; il 39% riporta un qualche impatto sull'EBIT, e la maggior parte di questi lo colloca sotto il 5% dell'EBIT
Working paper NBER, febbraio 2026 Quasi 6.000 dirigenti di aziende in quattro paesi Effetto su occupazione e produttività negli ultimi tre anni Il 69% delle aziende usa l'IA; nove su dieci non riportano alcun impatto su occupazione o produttività

Le definizioni differiscono. Il MIT chiede se un deployment ha prodotto un ritorno misurabile, BCG classifica le aziende in gruppi di maturità, McKinsey chiede dell'EBIT e il sondaggio NBER chiede di produttività e organico. Nessuno è una misurazione pulita dell'effetto dell'IA. Presi insieme, dicono che l'adozione è ampia e il ritorno misurato è raro.

Quanto fidarsi del 95%

Meno di quanto suggeriscano i titoli, e lo dice il rapporto stesso. La sua sezione sui limiti afferma che i dati sono "corretti nella direzione" e provengono da interviste individuali anziché da rendicontazioni ufficiali delle aziende, che le definizioni di successo variano tra organizzazioni e che una finestra di osservazione di sei mesi può sottostimare il successo dei sistemi complessi. Il successo è stato definito come deployment oltre la fase pilota con KPI misurabili, con il ritorno valutato sei mesi dopo il pilot. Per gli strumenti dedicati a compiti specifici, un'implementazione riuscita era quella che utenti o dirigenti descrivevano come dotata di un effetto marcato e duraturo su produttività o conto economico.

La critica del Marketing AI Institute aggiunge che la definizione ignora guadagni di efficienza, retention ed effetti sulla pipeline commerciale, e che 52 interviste non possono reggere un'affermazione sull'intero mercato. Entrambi i punti sono corretti. Il 95% va trattato come un dato rumoroso, non come un tasso di fallimento.

Due parti del rapporto reggono meglio del titolo. La prima è la diagnosi. Gli autori scrivono che il divario non sembra dipendere dalla qualità dei modelli o dalla regolamentazione, e che la maggior parte dei deployment fallisce per workflow fragili, mancanza di apprendimento contestuale e disallineamento con le operazioni quotidiane. La seconda è ciò che hanno fatto gli acquirenti che ci sono riusciti: hanno giudicato gli strumenti sui risultati operativi anziché sui benchmark dei modelli, e hanno lasciato che fossero i titolari di budget e i manager di dominio a scegliere i problemi e guidare i rollout.

Il rapporto ha anche rilevato che le collaborazioni esterne arrivavano al deployment in circa il 67% dei casi, contro circa il 33% degli sviluppi interni. Siamo un fornitore, quindi abbiamo un interesse in quel dato, e va letto con l'avvertenza del rapporto stesso: i numeri sono dichiarati dagli interessati, e le aziende che scelgono un partner possono differire per altri aspetti da quelle che sviluppano internamente. È una correlazione.

Perché i pilot si bloccano

Secondo noi quattro lacune spiegano la maggior parte dei pilot bloccati, e nessuna è tecnica.

  1. Nessuna baseline. "Il tempo di gestione è sceso del 20%" non significa nulla se nessuno ha misurato il tempo di gestione prima del pilot, con la stessa definizione, su un periodo comparabile.
  2. Nessuna metrica concordata. Il team dati riporta l'accuratezza del modello, la finanza chiede dei costi, le operations chiedono del throughput. Ogni parte sceglie il proprio numero a posteriori, e il pilot finisce in una discussione invece che in una decisione.
  3. Nessun responsabile nel business. Un pilot gestito da un team centrale, senza nessuno sul lato business che controlli il budget o il processo, non ha nessuno che lo porti in produzione quando funziona.
  4. Nessun percorso nel processo. Il modello funziona in una sandbox, ma nessuno ha cambiato la schermata che le persone usano, l'ordine dei passaggi o gli obiettivi su cui vengono valutate. Un output che arriva fuori dal workflow viene ignorato.

Per chi ha il budget: una pagina prima di costruire qualsiasi cosa

Prima di spostare qualsiasi dato o scegliere qualsiasi modello, scrivete una pagina con sei righe.

  • Metrica. Un numero a cui il business tiene già, con una definizione esatta.
  • Baseline. Il suo valore attuale, su una finestra dichiarata, calcolato con la query che userà il pilot.
  • Regola di decisione. Quale risultato significa rollout e quale significa stop.
  • Guardrail. Cosa non deve peggiorare mentre la metrica migliora.
  • Responsabile. La persona nel business che cambierà il processo se il pilot funziona.
  • Data di decisione. Il giorno in cui si decide, qualunque sia il risultato.

Un esempio illustrativo per un copilot di supporto che scrive bozze di risposta ai ticket di primo livello:

Riga Voce illustrativa
Metrica Tempo di gestione mediano per ticket di primo livello
Baseline Misurata nelle quattro settimane precedenti il pilot, stesse categorie di ticket
Regola di decisione Rollout se la mediana scende del 10% o più; stop se scende di meno del 3%
Guardrail Tasso di riapertura e soddisfazione dei clienti entro un punto dalla baseline
Responsabile Responsabile del supporto
Data di decisione Sei settimane dopo il lancio

Se concordare questa pagina richiede più di una settimana, il problema non è pronto per l'IA. A volte scriverla mostra che la metrica si può spostare con una regola o un report, e allora la risposta più economica è quella giusta.

Per gli ingegneri: far reggere la metrica

Randomizzate all'unità in cui avviene l'effetto. Per un copilot di supporto è l'operatore o il team, non il ticket, se altrimenti gli operatori imparerebbero dal copilot e cambierebbero il modo di gestire i ticket di controllo. Per i processi operativi che non si possono dividere nello stesso momento, alternate i periodi con un disegno switchback. Tenete un piccolo holdout dopo il rollout per vedere se l'effetto si attenua.

Misurate la baseline con la pipeline del pilot stesso. Stessa query, stessi filtri, stessa durata della finestra. Eseguite prima un confronto A/A, dividendo il traffico senza applicare alcuna modifica, per vedere quanto si muove la metrica da sola. Le metriche stagionali richiedono un gruppo di controllo contemporaneo; un confronto prima e dopo mescolerà il pilot con il calendario.

Dimensionate il test prima di iniziare. Per due gruppi con potenza dell'80% e significatività del 5%, una regola pratica comune è n per gruppo ≈ 16·σ²/δ², dove σ è la deviazione standard della metrica e δ è il più piccolo effetto che valga la pena rilevare. Numeri illustrativi: se il tempo di gestione ha una deviazione standard di 6 minuti e l'effetto che conta è 0,6 minuti, n ≈ 16 × 36 / 0,36 = 1.600 ticket per gruppo. Un team che gestisce 200 ticket di questo tipo a settimana ha bisogno di 16 settimane per raccoglierne 3.200. È il momento di scegliere un effetto più grande, un pilot più lungo o una metrica meno rumorosa, per esempio correggendo per il tempo di gestione di ciascun operatore nel periodo precedente. I tempi di gestione sono asimmetrici, quindi confrontate le mediane o i valori trasformati in logaritmo, oppure stimate l'intervallo con il bootstrap.

Mettete la metrica nel contratto. Definizione, fonte dei dati, query, finestra e soglia entrano nello statement of work come criterio di accettazione della milestone. L'accettazione allora significa eseguire la query concordata, non discutere se il sistema sembri utile.

Scrivete il criterio di stop prima del lancio. Se l'effetto alla data di decisione è sotto la soglia, il pilot si ferma. Controllare il risultato ogni giorno e fermarsi quando sembra buono gonfia i falsi positivi; se le occhiate anticipate sono inevitabili, usate un test sequenziale progettato per quello.

Come lavoriamo con questo

Concordiamo la metrica prima di addestrare qualsiasi modello, ed entra nel contratto come criterio di accettazione. Le milestone vengono fatturate solo dopo l'accettazione, quindi è la metrica a decidere la fattura. Un ingegnere nominato resta sul progetto dall'inizio alla fine, il che impedisce alla definizione della metrica di slittare tra un passaggio di consegne e l'altro. Quando il documento di una pagina mostra che una regola o un report sposterebbero la metrica a un costo minore, lo diciamo e sconsigliamo di acquistare ML.

Nel nostro listino un incarico di discovery costa 6k–14k € in 2–3 settimane, ed è la fase in cui scriviamo il documento descritto sopra insieme a chi ha il budget. Un teardown mostra come sono prezzati discovery, proof of concept e produzione, e la pagina dei contatti è il modo per avviarne uno.

Fonti

Ha un processo che costa troppo?

Ce ne parli. La prima call è gratuita e, se l'AI non è la risposta, glielo diciamo.

Parliamo del suo caso