Come si costruisce il business case di un progetto AI?

Il business case dell'AI è la stima strutturata di costi e benefici di un progetto di intelligenza artificiale, costruita per reggere alla domanda del direttore finanziario prima ancora che al collaudo tecnico. Il calcolo classico del ritorno si rompe su questo terreno perché tratta l'AI come un progetto software a costo fisso, mentre il costo reale varia con l'uso, con la qualità dei dati di partenza e con quanta supervisione umana resta necessaria dopo il go-live. Il metodo distintivo è costruire tre scenari espliciti (prudente, realistico, ottimistico) al posto di un numero unico che nessun decisore crede davvero, e mettere in colonna le voci che i business case improvvisati dimenticano: il costo per token e la sua variabilità (vedi AI tokenomics), la preparazione dei dati, la supervisione umana residua, la manutenzione di prompt e valutazioni, il costo del cambiamento organizzativo. Un pilota che non arriva in produzione, in questo schema, non è automaticamente denaro perso.

Perché il calcolo classico non regge

Un progetto software tradizionale ha un costo di sviluppo che si ammortizza e un costo di esercizio quasi piatto. Un sistema AI ha invece una componente di costo variabile e imprevedibile: il consumo di token cresce con l'uso reale, che è difficile da stimare prima del lancio, e i prezzi dei modelli cambiano nel tempo. A questo si aggiunge una voce che raramente compare nei fogli di calcolo iniziali, cioè il lavoro di preparazione e pulizia dei dati, che spesso assorbe più tempo dello sviluppo del modello stesso. Serve poi mettere in conto che l'automazione raramente elimina del tutto la supervisione umana: sposta le persone dall'eseguire al controllare la qualità, e quel controllo costa, e quel controllo ha un costo ricorrente. Infine i prompt e le valutazioni automatiche che misurano se il sistema funziona ancora bene richiedono manutenzione continua, non una tantum, perché i modelli cambiano versione e il comportamento del sistema si sposta con loro.

Il metodo dei tre scenari

Invece di presentare una stima puntuale del ritorno, che chiunque abbia visto un progetto slittare sa essere poco più di un auspicio, il metodo costruisce tre colonne parallele con le stesse voci di costo e beneficio, fatte variare su ipotesi esplicite e dichiarate: adozione da parte degli utenti, tasso di errore accettato, volume reale di utilizzo. Lo scenario prudente assume adozione lenta, supervisione alta e benefici tardivi; quello realistico usa i dati del pilota, quando esiste; quello ottimistico assume che le curve di apprendimento e di adozione funzionino come da manuale. La decisione utile non è "l'AI conviene o no", ma se il progetto regge anche nello scenario prudente, e quanto è distante lo scenario realistico da quello ottimistico: una forbice stretta segnala un business case solido, una forbice larga segnala che servono più dati prima di impegnare budget.

Il pilota che produce un asset, non solo un risultato

Un pilota che non arriva in produzione ha comunque potuto generare valore riutilizzabile: dati puliti e documentati che serviranno al prossimo tentativo, un caso d'uso chiarito con precisione (cosa deve fare davvero il sistema, non l'idea vaga di partenza), competenze interne che restano in azienda anche se quel progetto specifico si ferma. Questo non è un modo per giustificare ogni fallimento: un pilota che non produce nessuno di questi tre asset, e non arriva in produzione, è semplicemente un pilota fallito. Ma trattare ogni pilota interrotto come spreco puro spinge i team a forzare in produzione sistemi non pronti pur di non ammettere un costo affondato, il che è peggio del pilota interrotto stesso.

Perché conta per chi decide

Chi firma il budget di un progetto AI vuole sapere due cose: quanto costa se le cose vanno storto, e cosa resta in azienda se il progetto non arriva a regime. Un business case con tre scenari e le voci di costo nascoste in colonna risponde a entrambe, e sposta la conversazione dal pitch ottimistico a una decisione di rischio informata, la stessa disciplina che il FinOps applica alla spesa cloud. Il business case cambia però a seconda di cosa si sta finanziando: proof of concept, prototipo e MVP non sono sinonimi, ed è l'equivoco che si paga quando si discute il budget.