AI Governance del capex per i consigli di amministrazione: dal portafoglio di esperimenti a business case di livello investment-grade

1. Considerare la spesa per AI come un portafoglio governato

Un portafoglio AI contiene più che progetti. Di solito include casi d'uso che dovrebbero modificare ricavi, costi, rischio o servizio; capacità condivise di dati e integrazione; abbonamenti a modelli e applicazioni; capacità cloud o di data center; team specialistici; funzioni di controllo; e attività di cambiamento necessarie per modificare il modo in cui viene svolto il lavoro. Ogni categoria ha una diversa vita economica, un diverso profilo di dipendenze e un diverso grado di reversibilità. Un unico budget per l'innovazione può nascondere queste differenze.

Il consiglio di amministrazione necessita di una visione che concili gli impegni tra le diverse classificazioni contabili. Parte della spesa può essere infrastruttura capitalizzata, parte può essere spesa operativa e parte può essere incorporata nelle retribuzioni della business unit o nei contratti con i fornitori. La questione economica è la liquidità e la capacità incrementali totali impegnate nel portafoglio, inclusi i costi operativi successivi al lancio. Un'iniziativa può sembrare sostenibile durante un progetto pilota perché integrazione aziendale, sicurezza, bonifica dei dati, ridisegno dei processi, formazione, monitoraggio e costi di esercizio restano al di fuori del perimetro contabile del pilota.

Le comunicazioni ufficiali mostrano perché la disciplina degli impegni è importante. Alphabet ha riportato USD 91.4 billion di spese in conto capitale per il 2025, principalmente infrastruttura tecnica, e ha dichiarato di attendersi un aumento significativo nel 2026 degli investimenti in server, apparecchiature di rete e data center.[4] La relazione annuale 2026 di Microsoft afferma che gli investimenti AI vengono effettuati su scala significativa e in anticipo rispetto a flussi di ricavi pienamente sviluppati.[5] Meta ha riportato USD 72.22 billion di spese in conto capitale per il 2025, inclusi i pagamenti del capitale dei leasing finanziari, e prevedeva USD 115 billion-USD 135 billion di spese in conto capitale nel 2026 per sostenere gli sforzi AI e il proprio core business.[6] Amazon ha riportato USD 96.3 billion di spese in conto capitale per cassa nei primi sei mesi del 2026, principalmente infrastruttura tecnologica a supporto della crescita di AWS e della capacità di evasione degli ordini.[7] Queste cifre hanno definizioni diverse e finalità aziendali miste. La loro rilevanza sta nell'entità, nei lunghi tempi di realizzazione e nell'incertezza della domanda descritti nei documenti depositati.

Il portafoglio dovrebbe quindi rendere noti cinque totali: spesa cumulata approvata; impegni contrattuali e di leasing; run rate annuo corrente; costo operativo previsto a regime; e richieste di capacità non ancora impegnata. Dovrebbe inoltre identificare quali casi d'uso assorbono ciascuna capacità condivisa. Ciò impedisce che una piattaforma venga approvata come necessità strategica mentre i benefici da essa dipendenti restano senza un responsabile.

2. Attribuire al consiglio di amministrazione un mandato di governance definito

La supervisione del consiglio di amministrazione dovrebbe concentrarsi sull'esposizione rilevante, sulla coerenza del portafoglio, sull'appetito al rischio e sulla qualità delle evidenze. Non dovrebbe richiedere ai consiglieri di scegliere i modelli o di gestire gli sprint di realizzazione. La direzione resta responsabile di proporre ed eseguire gli investimenti. Il consiglio stabilisce quali impegni richiedono approvazione, quali evidenze devono accompagnarli, come si esercita la verifica indipendente e cosa accade quando un caso d'uso non soddisfa le proprie condizioni.

Le soglie di approvazione dovrebbero combinare rilevanza finanziaria, rischio e reversibilità. Un'applicazione a basso costo che incide su occupazione, credito, salute, sicurezza, infrastrutture critiche o dati personali sensibili può meritare una supervisione maggiore rispetto a uno strumento di produttività più rilevante. Una prenotazione di capacità pluriennale può richiedere l'attenzione del consiglio perché riduce la flessibilità strategica anche se la liquidità di breve periodo è modesta. Le soglie dovrebbero quindi considerare la spesa cumulata, gli impegni non cancellabili, le decisioni e gli utenti interessati, la sensibilità dei dati, l'autonomia, la portata geografica e il costo di uscita.

Il consiglio ha inoltre bisogno di un dirigente responsabile. Un amministratore delegato, un direttore finanziario o uno sponsor della trasformazione designato dovrebbe essere titolare del valore del portafoglio. I leader tecnologici sono titolari dell'architettura e delle evidenze di realizzazione. I responsabili di business sono titolari della baseline operativa, dell'adozione e dei benefici realizzati. I leader di rischio, sicurezza, privacy, legale e compliance sono titolari di standard indipendenti nell'ambito dei loro mandati. L'audit interno può verificare il design e l'operatività senza diventare un approvatore di prima linea.

Tabella 1. AI Diritti decisionali e titolarità delle evidenze del portafoglio

L'allocazione è un modello. Le responsabilità e le deleghe effettive devono seguire lo statuto, la normativa e il quadro di rischio dell'organizzazione.

3. Rendere il caso d'uso l'unità di valore

Un modello, una piattaforma o un data lake raramente rappresentano l'unità diretta di valore aziendale. Il valore emerge quando un gruppo definito di utenti modifica una decisione o un flusso di lavoro e la modifica produce un esito misurabile. Il caso d'uso dovrebbe quindi specificare l'utente, il processo operativo, la decisione o l'attività, il contributo di AI, la responsabilità umana, la baseline, l'esito target e i controlli interessati. Questa definizione crea un collegamento tra tecnologia e flusso di cassa, servizio o rischio.

Il confine del caso d'uso richiede disciplina. Un'affermazione come «migliorare il servizio clienti con AI» è troppo ampia per l'approvazione dell'investimento. Un caso governato potrebbe definire l'assistenza per un tipo di contatto, una popolazione di utenti e un canale specifici; misurare il tempo di gestione, la risoluzione al primo contatto, la qualità, i reclami e l'escalation; identificare le fonti di dati e conoscenza approvate; e mantenere l'autorità umana per eccezioni definite. L'ambito diventa verificabile e i costi diventano attribuibili.

Le capacità condivise dovrebbero essere allocate in modo trasparente. Se dieci casi d'uso richiedono un livello di recupero delle informazioni, controlli di identità e monitoraggio, il caso della piattaforma dovrebbe mostrare capacità condivisa minima, capacità incrementale per caso d'uso e capacità inutilizzata. Allocare ogni costo condiviso al primo caso d'uso può far apparire antieconomica una capacità sostenibile. Trattare tutti i costi condivisi come costi generali strategici può far apparire ogni caso d'uso artificialmente attraente. Il portafoglio dovrebbe mostrare la convenienza economica sia prima sia dopo un metodo di allocazione coerente.

Anche i casi d'uso necessitano di identificatori stabili e controllo delle versioni. Un progetto pilota che inizia come assistenza alla redazione può in seguito generare comunicazioni ai clienti o formulare raccomandazioni. I suoi profili di rischio, dati e benefici sono cambiati. Il registro di approvazione dovrebbe mostrare il nuovo perimetro, l'impegno cumulativo e l'impatto sui controlli, invece di consentire all'iniziativa di mantenere la sua classificazione originaria di basso rischio.

4. Richiedere un business case di livello investment grade

Un business case di livello investment grade è un documento decisionale in grado di resistere alle contestazioni in ambito finanziario, operativo, tecnologico e di rischio. Parte dal problema operativo e dal controfattuale business as usual. Confronta poi le opzioni, individua il percorso preferito, quantifica il costo e il beneficio sull'intero ciclo di vita, dimostra la realizzazione e l'adozione e indica i controlli necessari per l'utilizzo. La sua profondità dovrebbe essere proporzionata all'impegno e alle conseguenze.

Il Green Book 2026 di HM Treasury descrive cinque dimensioni interconnesse: strategica, economica, commerciale, finanziaria e gestionale. Richiede inoltre la valutazione delle opzioni e la proporzionalità.[17] Le linee guida correlate sul business case sviluppano le proposte attraverso business case di indirizzo strategico, business case preliminari e business case completi.[18] Questi quadri di riferimento del settore pubblico non sono regole di approvazione aziendali. Il loro valore per i consigli di amministrazione consiste nel separare la motivazione strategica, il valore, gli accordi con i fornitori, la sostenibilità economica e le evidenze di realizzazione.

Il controfattuale merita particolare attenzione. Il business case dovrebbe confrontare l'opzione AI preferita con il business as usual, la riprogettazione dei processi senza AI, un'opzione analytics basata su regole o convenzionale, l'esternalizzazione, l'acquisto e lo sviluppo interno. Se le performance di baseline stanno peggiorando, mantenere il risultato attuale può esso stesso richiedere investimenti. Se una trasformazione esistente cattura già parte del beneficio, il business case AI dovrebbe considerare solo l'effetto incrementale.

Il business case deve dichiarare l'incertezza senza nasconderla in una singola stima puntuale. Gli intervalli di costo dovrebbero riflettere la maturità della stima. Gli intervalli dei benefici dovrebbero riflettere l'affidabilità della misurazione e l'adozione. L'analisi degli scenari dovrebbe mostrare i risultati in termini di domanda, prezzo, utilizzo, qualità, produttività e controllo. Le dipendenze dalla disponibilità dei fornitori, dall'energia, dai diritti sui dati, dalle competenze specialistiche e dal cambiamento dei processi devono restare esplicite.

Tabella 2. Evidenze minime per un business case AI

Le evidenze dovrebbero maturare con l'impegno. Una proposta di discovery può utilizzare intervalli delimitati; le decisioni di produzione e di scala richiedono input controllati, tracciabili e aggiornati.

5. Segmentare il portafoglio prima di classificarlo

Il confronto di portafoglio funziona solo quando vengono identificati investimenti non omogenei. Un segmento può contenere casi d'uso di ricavo, un altro casi di capacità lavorativa o di costo, un altro applicazioni di rischio e controllo, e un altro ancora capacità strategica i cui benefici diretti si generano attraverso diversi casi a valle. Il lavoro su infrastrutture e conformità obbligatoria dovrebbe restare visibile come livelli separati anziché competere su una misura di rendimento comune non supportata.

Il portafoglio può anche essere segmentato per maturità. La discovery convalida il problema e i dati disponibili. L'esperimento verifica la fattibilità tecnica in un ambiente delimitato. Il pilota collauda il processo end-to-end, il comportamento degli utenti e i controlli. La produzione stabilisce un servizio controllato. La scala aumenta utenti, volume, geografia o autonomia. La revisione dei benefici verifica i risultati realizzati e determina se la capacità debba essere ampliata, corretta, mantenuta o dismessa.

La segmentazione dei rischi dovrebbe influenzare il percorso di approvazione. Il Risk Management Framework AI del NIST organizza l'attività attorno a governare, mappare, misurare e gestire, con la governance che opera lungo l'intero ciclo di vita AI.[10] Il suo profilo AI generativo identifica azioni per rischi che possono essere nuovi o amplificati da sistemi generativi.[11] Il framework di responsabilità della GAO raggruppa pratiche attorno a governance, dati, prestazioni e monitoraggio.[12] Questi framework supportano un inventario comune consentendo ai controlli di variare in base al caso d'uso, al contesto e alle conseguenze.

La mappa risultante dovrebbe mostrare sia l'esposizione strategica sia quella finanziaria. Un piccolo esperimento può restare nel pool di scoperta. Un servizio in produzione con costi ricorrenti di modello e cloud appartiene al portafoglio vincolato. Una piattaforma condivisa dovrebbe mostrare i casi d'uso e la domanda che la giustificano. Un investimento obbligatorio in controlli dovrebbe mostrare l'esposizione che mitiga e le conseguenze operative del ritardo.

6. Costruire una mappa del portafoglio di casi d'uso

La mappa del portafoglio confronta il valore economico atteso con la confidenza nell'esecuzione. Il valore economico può combinare flusso di cassa incrementale, costo monetario evitato, capacità utilizzabile, miglioramento del servizio e riduzione del rischio, con etichette separate dove la conversione monetaria è debole. La confidenza nell'esecuzione combina chiarezza del problema, evidenza dei benefici, prontezza dei dati, progettazione dei controlli, adozione e capacità di realizzazione. La dimensione della bolla può rappresentare il costo annuale a regime o l'impegno cumulativo.

La mappa guida l'azione. I casi ad alto valore e alta confidenza sono candidati a una scalabilità controllata. I casi ad alto valore e bassa confidenza meritano un investimento mirato in evidenze, non un impegno automatico. I casi a valore inferiore e alta confidenza possono restare utili quando abilitano capacità strategica, soddisfano un obbligo o offrono una via rapida all'adozione. I casi a valore inferiore e bassa confidenza dovrebbero normalmente essere interrotti, accorpati o riportati alla definizione del problema.

Un ufficio di portafoglio dovrebbe impedire che la mappa diventi una gara di bellezza. I punteggi necessitano di definizioni ancorate, date delle fonti e responsabili. Il comitato dovrebbe vedere intervalli di confidenza e violazioni delle linee rosse. Dovrebbe inoltre visualizzare la concentrazione per fornitore, modello, provider cloud, dominio dati, processo aziendale e funzione di controllo. Dieci casi d'uso singolarmente attraenti possono creare una dipendenza condivisa significativa.

I casi d'uso, i punteggi e i costi annuali a regime sono assunzioni ipotetiche di modellazione. La dimensione della bolla rappresenta il costo annuale; la mappa supporta la governance e non stabilisce una previsione o una raccomandazione.

[/FIGURE]

7. Far progredire i benefici lungo una scala di confidenza

La confidenza nei benefici dovrebbe essere guadagnata attraverso le evidenze. Un'ipotesi gestionale può giustificare una spesa di scoperta. Non dovrebbe sostenere un ampio impegno in produzione. Un progetto pilota controllato può stabilire se la tecnologia modifica le prestazioni delle attività in condizioni definite. Le evidenze dalla produzione possono mostrare se il processo più ampio, gli utenti e i controlli sostengono il risultato. La verifica finanziaria può confermare se il cambiamento ha creato esiti di cassa, capacità, servizio o rischio dopo i costi e gli effetti di spiazzamento.

La scala evita una falsa precisione. Un beneficio può avere un importo stimato elevato e una bassa confidenza. Un altro può avere un importo inferiore e evidenze più solide. Il portafoglio dovrebbe riportare entrambi. La confidenza dovrebbe diminuire quando il caso d'uso cambia popolazione, dati, modello, processo o scala, perché le evidenze precedenti potrebbero non essere trasferibili.

La ricerca OCSE sull'adozione di AI riporta che l'incertezza sul ritorno sull'investimento e una maturità dei dati insufficiente sono barriere importanti, e che i manager possono sottovalutare le implicazioni di processo e culturali a livello aziendale.[8] Una revisione OCSE separata della ricerca sperimentale rileva che le prestazioni dipendono dal compito e dall'esperienza utente, mentre le evidenze organizzative di lungo periodo restano limitate.[9] Questi risultati supportano un trasferimento cauto dagli esperimenti su singoli compiti alle affermazioni sul flusso di cassa aziendale.

La funzione finanziaria dovrebbe definire le evidenze richieste a ciascun livello. Il tempo risparmiato non equivale automaticamente a denaro risparmiato. Può creare capacità, migliorare il servizio, ridurre gli straordinari, evitare assunzioni o consentire una riduzione dell'organico; ciascuna via ha evidenze e conseguenze diverse. L'aumento dei ricavi richiede un gruppo di controllo credibile o un altro metodo di attribuzione. La riduzione del rischio può richiedere un'analisi delle perdite attese o dei costi di controllo e dovrebbe preservare esiti non finanziari gravi che non si prestano a una semplice monetizzazione.

La scala definisce la maturità delle evidenze. Non attribuisce a un livello di affidabilità una probabilità universale né una maggiorazione di valutazione.

[/FIGURE]

8. Stabilire la baseline e il controfattuale

La baseline dovrebbe registrare le prestazioni prima dell'intervento AI. A seconda del caso d'uso, può includere volume delle transazioni, tempo di gestione, rilavorazioni, errori, difetti, perdite, conversione, margine, reclami, tempo ciclo, livello di servizio, eccezioni di controllo e impegno dei dipendenti. I sistemi di origine, il periodo di misurazione, le esclusioni e la stagionalità dovrebbero essere documentati. Una baseline costruita dopo un pilota di successo può introdurre un bias di selezione.

Il controfattuale definisce ciò che accadrebbe senza l'investimento proposto. Il business as usual può includere tendenze di produttività esistenti, variazioni contrattuali dei prezzi, piani di organico, miglioramenti dei processi e altre release tecnologiche. Il business case dovrebbe evitare di rivendicare benefici già attesi da questi fattori. Quando un controllo randomizzato non è praticabile, un'implementazione graduale, un gruppo appaiato, una serie temporale interrotta o un confronto pre-post definito possono fornire evidenze utili, purché le limitazioni siano dichiarate.

I benefici richiedono una catena che colleghi la metrica operativa al bilancio o a un risultato governato. I minuti risparmiati per attività diventano capacità annua solo dopo la moltiplicazione per volume idoneo, adozione, riduzione sostenuta dei tempi e riallocazione produttiva. La capacità diventa costo evitato solo quando cambia un piano di assunzioni approvato o viene eliminata una spesa di terzi. Il ricavo diventa margine di contribuzione al netto dei costi di erogazione, cannibalizzazione, scontistica, churn e imposte, ove pertinenti. Il consiglio di amministrazione dovrebbe vedere ciascun passaggio di raccordo.

Il framework UK Digital and Data Benefits è stato sviluppato per aiutare a quantificare i benefici dei programmi digitali e dei dati e deve essere utilizzato insieme alla guida del Green Book.[19] Anche il Government Efficiency Framework collega i risparmi identificati alla gestione dei benefici e agli assetti di governance più ampi.[20] Il loro contesto di settore pubblico differisce da un portafoglio aziendale. La disciplina generale resta utile: definire le tipologie di beneficio, i metodi di misurazione, la responsabilità e la relazione tra cambiamento operativo e valore.

9. Rendere la preparazione dei dati un criterio di accesso al capitale

La preparazione dei dati ha un valore economico diretto perché la bonifica consuma tempo, impegno specialistico e attenzione operativa. Influisce inoltre sui rischi di performance e di controllo. Un caso d'uso dovrebbe identificare i dati necessari, il titolare dei dati, la base giuridica o il diritto contrattuale, il percorso di accesso, la qualità, la completezza, il lineage, la rappresentatività, la conservazione, la classificazione di sicurezza, la resilienza e il monitoraggio. Le incognite dovrebbero comportare conseguenze in termini di costi e tempi.

La valutazione della preparazione dovrebbe distinguere l'esistenza di un dataset dall'accesso utilizzabile. I dati possono essere distribuiti tra sistemi, bloccati in contratti con fornitori, disponibili solo tramite estrazione manuale o non adatti alla frequenza richiesta. Le etichette possono essere incoerenti. Gli esiti storici possono riflettere politiche passate che sono cambiate. I dati di addestramento possono non rappresentare gli utenti attuali o i casi limite. Un'affermazione generica secondo cui l'organizzazione dispone di dati non risolve questi problemi.

La heatmap dovrebbe utilizzare punteggi ancorati. Un punteggio rosso significa che una condizione definita è assente o inaccettabile. Ambra significa che la bonifica è finanziata e circoscritta. Verde significa che le evidenze attuali soddisfano il gate. Grigio significa che la dimensione non è stata valutata. Le medie possono nascondere fallimenti sulle soglie invalicabili, per cui i problemi relativi a diritti, sicurezza o usi vietati dovrebbero restare visibili anche quando altre dimensioni sono mature.

L'economia del caso d'uso dovrebbe includere la bonifica dei dati e il controllo continuativo. Un prodotto dati può supportare diversi casi d'uso, consentendo l'allocazione condivisa dei costi. Il consiglio di amministrazione dovrebbe vedere i casi d'uso che giustificano l'investimento, la sequenza richiesta e il rischio che la domanda prevista non si materializzi.

I punteggi si basano su ipotetiche assunzioni di modellazione: 1 significa assente o inaccettabile, 3 significa bonifica circoscritta e 5 significa evidenze pronte per il gate.

[/FIGURE]

10. Riconciliare l'economia dell'intero ciclo di vita

Il modello di costo dovrebbe includere discovery, sviluppo, integrazione, dati, sicurezza, validazione, licenze, inferenza del modello, cloud o infrastruttura, gestione del cambiamento, formazione, supporto, monitoraggio e dismissione. Dovrebbe inoltre includere le persone interne laddove rappresentino capacità scarsa o assunzioni incrementali. Gli impegni relativi a volumi minimi, capacità riservata, contratti di locazione e contratti take-or-pay dovrebbero essere esposti separatamente rispetto all'utilizzo variabile.

Il modello dei benefici dovrebbe distinguere cassa, capacità, ricavi, servizio e rischio. Tali categorie non dovrebbero essere sommate in un unico totale monetario a meno che la base di conversione non sia credibile. Un caso può evidenziare un rendimento di cassa positivo e un esito distinto per il cliente o per i controlli. Un caso d'uso obbligatorio di conformità può avere un rendimento convenzionale limitato pur preservando il permesso di operare. Il suo costo compete comunque per capitale e capacità di erogazione.

L'esempio ipotetico seguente utilizza un modello nominale a cinque anni, un tasso di sconto dell'11 per cento, nessun valore terminale e un trattamento fiscale semplificato. Presuppone che i costi di implementazione si manifestino prima della scalabilità, che i benefici crescano con l'adozione e che il costo operativo annuo aumenti con i volumi. Esclude la struttura di finanziamento, il cambio estero, il capitale circolante, la capitalizzazione contabile e le interazioni con altri programmi. Si tratta di ipotesi di modellizzazione, non di input di mercato.

Tabella 3. Economia ipotetica di un caso d'uso dalla fase pilota alla scala

I valori sono ipotetici, in milioni di USD. Il VAN applica un tasso di sconto nominale dell'11 per cento su cinque anni, senza valore terminale; i totali sono arrotondati e non rappresentano una previsione.

La variazione dei valori migliora la decisione. Il caso dovrebbe mostrare il livello di adozione, il prezzo unitario, il tasso di errore, il beneficio per transazione o il volume in corrispondenza dei quali il VAN si azzera o raggiunge una soglia del consiglio di amministrazione. Dovrebbe inoltre mostrare la liquidità a rischio prima della successiva decisione reversibile. Ciò concentra il dibattito sulle ipotesi che determinano il valore.

La visione di portafoglio dovrebbe evitare il doppio conteggio. Una piattaforma dati condivisa non può attribuirsi il beneficio pieno di ogni caso d'uso dipendente mentre ciascun caso d'uso attribuisce a sua volta lo stesso valore. Un beneficio di produttività non può essere conteggiato come riduzione dei costi, evitamento di assunzioni e ricavi aggiuntivi a meno che l'organizzazione non disponga di un'allocazione credibile della capacità liberata. La funzione finance dovrebbe mantenere un registro dei benefici con un unico responsabile e un unico trattamento per ciascun risultato.

11. Prezzare esplicitamente infrastruttura, capacità ed energia

L'economia di AI può cambiare in base alla scelta del modello, al consumo di token o di capacità di calcolo, alla latenza, alla lunghezza del contesto, alla memorizzazione in cache, all'utilizzo, alla capacità riservata, all'archiviazione, al trasferimento dati, all'ammortamento hardware e alla disponibilità di energia. Il consiglio di amministrazione non ha bisogno di un tariffario tecnico. Ha bisogno delle determinanti unitarie, degli impegni contrattuali, della sensibilità e delle azioni di mitigazione.

L'Agenzia internazionale dell'energia riferisce che i data center dedicati a AI sono cresciuti rapidamente e che il consumo energetico per una semplice attività di AI è migliorato in modo sostanziale, mentre utilizzi più intensivi di video, ragionamento e attività agentiche possono consumare molta più energia.[3] Riferisce inoltre una crescita ampia e incerta della capacità dei data center e della domanda di elettricità. L'implicazione per un caso d'uso aziendale è che il costo per attività dovrebbe essere misurato con il carico di lavoro effettivo anziché ipotizzato da una dimostrazione.

L'approvazione della capacità dovrebbe basarsi su evidenze della domanda. Un'impresa può riservare infrastrutture per ragioni strategiche, protezione dell'approvvigionamento o latenza, ma il caso dovrebbe dimostrare utilizzo impegnato, valore dell'opzione e scenario negativo. Attrezzature con tempi di consegna lunghi, contratti energetici e locazioni di data center possono ridurre la reversibilità. Il deposito di Alphabet, ad esempio, descrive progetti pluriennali di data center e impegni materiali relativi a infrastrutture tecniche.[4] Il quadro fattuale è specifico dell'azienda; illustra come l'economia delle infrastrutture si estenda oltre un breve progetto pilota software.

L'instradamento dei modelli può preservare valore. Modelli a costi inferiori possono gestire attività circoscritte, con modelli più grandi utilizzati per le eccezioni. Recupero, caching, progettazione dei prompt e vincoli di processo possono ridurre il consumo. Il portafoglio dovrebbe monitorare il costo per esito aziendale completato e accettato, non solo il costo per richiesta. Gli output falliti, ripetuti o corretti manualmente vanno inclusi nel denominatore.

12. Progettare i controlli come parte dell'investimento

I controlli sono requisiti di prodotto e operativi con costi, tempistiche e responsabilità. Dovrebbero essere progettati insieme al caso d'uso anziché aggiunti dopo il successo tecnico. L'insieme dei controlli può includere finalità approvata, accesso, minimizzazione dei dati, test, revisione umana, segregazione, restrizioni sugli output, logging, monitoraggio, risposta agli incidenti, supervisione dei fornitori, conservazione dei documenti, fallback e dismissione.

La proporzionalità dei controlli è importante. Il framework NIST è volontario e agnostico rispetto al caso d'uso, e sottolinea la gestione continua del rischio lungo il ciclo di vita.[10] ISO/IEC 42001 specifica un sistema di gestione AI per le organizzazioni che forniscono o utilizzano AI e utilizza una struttura di miglioramento continuo.[13] La guida riveduta del 2026 della Federal Reserve sul rischio di modello sottolinea un approccio basato sul rischio, adattato al profilo dei modelli, alle dimensioni e alla complessità di un'organizzazione bancaria.[14] La guida bancaria si applica nell'ambito del suo perimetro normativo dichiarato. La sua lezione di governance più ampia è che validazione, limitazioni, supervisione e controlli dovrebbero essere proporzionati all'uso rilevante.

Gli obblighi legali richiedono un'analisi specifica per giurisdizione. L'AI Act dell'UE utilizza una struttura basata sul rischio e si applica in modo progressivo; la Commissione europea ha riferito che i poteri di applicazione e taluni obblighi di trasparenza si applicavano da agosto 2026, mentre altre disposizioni ad alto rischio sono soggette a date successive.[15][16] Un documento per il consiglio dovrebbe indicare il ruolo dell'organizzazione, l'ubicazione, la classificazione del caso d'uso e il parere legale. Un'etichetta generica "conforme a AI" non è sufficiente.

Tabella 4. Progettazione dei controlli collegata alle evidenze dell'investimento

La tabella è un modello di governance e non sostituisce requisiti legali, regolamentari, di sicurezza, di privacy o specifici del settore.

13. Usare gate di controllo per allineare l'autorità all'impegno

I gate dovrebbero autorizzare un impegno successivo definito. Il Gate 0 accoglie il problema nella fase di discovery. Il Gate 1 approva un esperimento circoscritto dopo che baseline, accesso ai dati e piano di test sono chiari. Il Gate 2 approva un pilota quando processo, utenti, controlli e metodo di misurazione dei benefici sono pronti. Il Gate 3 approva il rilascio in produzione dopo che le evidenze end-to-end su prestazioni e controlli hanno esito positivo. Il Gate 4 approva la scalabilità dopo che adozione ed economia unitaria sono dimostrate. Il Gate 5 chiude i benefici e stabilisce se procedere con espansione, mantenimento o dismissione.

Ogni gate dovrebbe avere quattro esiti: avanzare; avanzare con condizioni vincolate nel tempo; sospendere in attesa di evidenze; oppure fermarsi. Le condizioni richiedono un responsabile, un elemento probatorio, una data di scadenza e una conseguenza. Le approvazioni condizionate ripetute dovrebbero essere segnalate perché possono trasformare evidenze mancanti in esposizione permanente.

L'autorità di approvazione dovrebbe aumentare con l'impegno e le conseguenze. Un team delegato può approvare un esperimento piccolo e isolato. Un comitato investimenti può approvare un rilascio in produzione. Il consiglio può approvare un importante impegno infrastrutturale, una modifica sostanziale dell'automazione o un caso d'uso con conseguenze elevate. Le azioni di emergenza restano possibili tramite un'eccezione definita e una revisione retrospettiva.

L'evidenza ai punti di controllo è cumulativa. L'autorità di approvazione dovrebbe riflettere l'impegno cumulativo, il rischio, la reversibilità e gli utenti interessati.

[/FIGURE]

14. Testare l'adozione prima di rivendicare valore su scala

L'accettazione tecnica dimostra che un sistema è in grado di funzionare. L'evidenza di adozione dimostra che le persone lo utilizzano nel processo previsto e che il risultato operativo persiste. Un caso di scaling dovrebbe definire utenti e transazioni ammissibili, utilizzo attivo, frequenza, completamento, accettazione, override, rilavorazione, fallback e supporto. Dovrebbe inoltre identificare il lavoro che si è spostato al di fuori del sistema misurato.

L'adozione dovrebbe essere misurata rispetto a un denominatore di processo. Il numero di utenti con licenza è un'evidenza debole se solo una piccola quota del lavoro ammissibile passa attraverso il sistema. Anche un utilizzo elevato può essere fuorviante se l'output viene scartato o corretto. Esiti accettati per transazione ammissibile forniscono un ponte più solido verso il valore.

La progettazione dei processi e gli incentivi contano. Gli utenti possono aggirare un controllo lento o inaffidabile. I manager possono incoraggiare l'utilizzo senza modificare carichi di lavoro o obiettivi. I dipendenti possono risparmiare tempo ma ricevere più lavoro, con effetti su qualità e retention. Un business case dovrebbe indicare come cambiano ruoli, misure di performance, formazione, supervisione, supporto e consultazione della forza lavoro. Laddove si applichino diritti dei lavoratori o accordi collettivi, è necessaria una consulenza specialistica.

Il pilota dovrebbe rappresentare la popolazione operativa prevista. Volontari entusiasti, dati puliti e volumi bassi possono sovrastimare le prestazioni su scala. Una prova in produzione dovrebbe includere utenti ordinari, periodi di picco, eccezioni e ripristino dopo guasti. Le soglie di adozione dovrebbero quindi essere abbinate a soglie di qualità e di controllo.

15. Rendere esplicite le decisioni di interrompere o scalare

Una revisione stop-or-scale combina fiducia nei benefici, economia unitaria, adozione, prontezza dei dati, efficacia dei controlli e capacità di erogazione. Dovrebbe avvenire a una data o a un volume prestabiliti e prima del successivo impegno rilevante. La decisione è un'azione di portafoglio, non un punteggio retrospettivo del progetto.

Lo scaling può significare più utenti, transazioni, paesi, unità di business, fonti dati, autonomia o capacità del modello. Ogni forma modifica rischio e costo in modo diverso. L'approvazione dovrebbe specificare la dimensione dello scaling e l'evidenza che resta valida. Un caso d'uso che si estende a una nuova giurisdizione legale o a una popolazione interessata può richiedere una riclassificazione e una nuova revisione dei controlli.

L'interruzione dovrebbe avere un piano operativo. Il team necessita dell'autorità per terminare un contratto, liberare capacità riservata, archiviare dati, rimuovere accessi, conservare i registri, notificare gli utenti, ripristinare il processo e registrare gli apprendimenti. Una narrazione sui costi irrecuperabili non dovrebbe mantenere in vita un caso d'uso antieconomico o non controllato.

Tabella 5. Matrice decisionale stop-or-scale

Le soglie sono esempi ipotetici. Ogni organizzazione dovrebbe definire soglie di materialità, rischio ed evidenza nell'ambito del proprio quadro di governance.

I valori e le soglie sono ipotetiche assunzioni di modellizzazione. I colori di stato riassumono le evidenze sottostanti e non stabiliscono autonomamente la prontezza o il valore.

[/FIGURE]

16. Controllare fornitori, concentrazione e uscita

La selezione dei fornitori può determinare costi, prestazioni, utilizzo dei dati, auditabilità, resilienza del servizio e uscita. Il business case dovrebbe distinguere tra fornitore del modello, fornitore dell'applicazione, fornitore cloud o di infrastruttura, integratore e fornitore di dati. Un singolo contratto può combinare più ruoli. La concentrazione dovrebbe essere valutata a livello di portafoglio, perché unità di business separate possono creare una grande esposizione condivisa senza una visione centrale.

La due diligence dovrebbe coprire l'ambito del servizio, i fattori che determinano il prezzo, i minimi, la capacità, la sicurezza, la privacy, la proprietà intellettuale, l'uso dei dati di addestramento, le modifiche a modelli e funzionalità, i subappaltatori, la notifica degli incidenti, l'ubicazione dei dati, l'audit, la cooperazione con le autorità di regolamentazione, la portabilità, la transizione e la cessazione. Le dichiarazioni dei fornitori dovrebbero essere verificate rispetto all'uso previsto e alle evidenze interne. Una certificazione o uno standard può supportare la due diligence ma resta insufficiente ai fini dell'accettazione del caso d'uso.

L'economia dell'uscita dovrebbe essere quantificata. L'esportazione dei dati, la ricostruzione dei flussi di lavoro, la riqualificazione degli utenti, l'operatività in parallelo e la conservazione dei registri possono essere rilevanti. Un cambio di modello può alterare le prestazioni senza un rilascio software convenzionale. I contratti e le operazioni dovrebbero quindi prevedere preavviso, test e rollback. Ove il doppio approvvigionamento non sia economicamente conveniente, il consiglio di amministrazione dovrebbe essere informato della dipendenza accettata e del piano di contingenza.

L'ufficio di portafoglio dovrebbe mantenere un calendario degli impegni. Dovrebbe indicare date di rinnovo, revisioni dei prezzi, scaglioni di volume minimo, prenotazioni di capacità e finestre di risoluzione. Una decisione di interruzione presa dopo un rinnovo automatico offre una protezione economica inferiore rispetto a una revisione programmata prima della data di impegno.

17. Fornire al consiglio di amministrazione un cruscotto basato su evidenze

Il cruscotto del consiglio di amministrazione dovrebbe essere compatto e tracciabile. Deve riportare i totali di portafoglio, le variazioni rispetto alla riunione precedente, le decisioni richieste e le eccezioni rilevanti. Dovrebbe mostrare la spesa approvata, gli impegni, il run rate annuale, il costo previsto a regime, i benefici per livello di confidenza, l'adozione, le mancanze dei controlli critici, i gate sui dati, la concentrazione e i casi d'uso prossimi alla revisione stop-or-scale.

Le aggregazioni richiedono approfondimenti. Una media di portafoglio verde può nascondere un caso d'uso rosso ad alte conseguenze. Il consiglio di amministrazione dovrebbe vedere le eccezioni per impegno cumulato e rischio. Dovrebbe inoltre vedere condizioni che si protraggono, rinvii ripetuti dei gate e benefici rimasti a livello di ipotesi o pilota mentre la spesa proseguiva.

Valore previsto e valore realizzato dovrebbero restare separati. Il cruscotto può mostrare il beneficio atteso ponderato per la confidenza ai fini di scenario, ma questo non dovrebbe essere riportato come valore realizzato. I risultati di cassa, capacità, ricavi e servizio verificati dalla funzione finanziaria necessitano di righe dedicate. Il costo evitato dovrebbe identificare il piano o contratto approvato che è cambiato.

La documentazione del comitato dovrebbe indicare assunzioni e variazioni rilevanti. Un prezzo del modello inferiore, un volume utenti più elevato, una licenza dati rivista o una nuova regolamentazione possono modificare il caso. Il controllo di versione dovrebbe preservare la base approvata a ciascun gate e spiegare la variazione corrente. Ciò supporta la responsabilità senza creare un business case statico che diventa obsoleto dopo il lancio.

18. Mobilitare il sistema di governance in novanta giorni

Il primo mese dovrebbe stabilire l'inventario e il perimetro decisionale. Il management dovrebbe identificare tutti i casi d'uso AI, le piattaforme, gli impegni infrastrutturali, gli abbonamenti, i fornitori e i domini dati. Ogni voce riceve un responsabile, uno stadio di maturità, la spesa cumulata, il run rate, la data del prossimo impegno e la classificazione del rischio. La funzione finanziaria riconcilia il registro contabile e i contratti con l'inventario.

Il secondo mese dovrebbe stabilire lo standard comune di evidenza. I responsabili di business definiscono baseline e meccanismi di beneficio. I team tecnologici e dati valutano architettura e prontezza. Le funzioni di controllo definiscono gate proporzionati. La funzione acquisti identifica concentrazione ed esposizione ai rinnovi. L'ufficio di portafoglio mappa le dipendenze e identifica i casi il cui prossimo impegno dovrebbe essere sospeso in attesa di evidenze.

Il terzo mese dovrebbe avviare il primo ciclo stop-or-scale. Il management seleziona i casi con la maggiore esposizione e con l'impegno più vicino. Il comitato investimenti verifica business case, condizioni e percorsi di uscita. Il consiglio di amministrazione approva la dotazione complessiva del portafoglio, le eccezioni rilevanti e la cadenza di reporting futura. I team operano quindi il sistema come processo decisionale ricorrente.

Tabella 6. Mobilitazione della governance capex di AI in novanta giorni

La sequenza è indicativa. La tempistica dovrebbe riflettere la scala del portafoglio, gli obblighi normativi, la disponibilità dei dati e la maturità della governance esistente.

L'ufficio dovrebbe iniziare dalle decisioni rilevanti, non da una ricostruzione storica completa. Gli esperimenti di valore inferiore possono essere collocati su un percorso semplificato. Gli elementi ad alto impegno, ad elevate conseguenze o prossimi al rinnovo meritano attenzione immediata. L'inventario può maturare mentre il sistema di governance inizia a proteggere la prossima decisione.

Conclusione

La governance dei capex AI collega il progresso tecnologico alla disciplina del capitale. Il consiglio necessita di un portafoglio riconciliato di casi d'uso, capacità condivise e impegni. Ogni caso d'uso rilevante richiede un problema operativo definito, un controfattuale, l'economia sull'intero ciclo di vita, la prontezza dei dati, il disegno dei controlli, un piano di adozione e un responsabile dei benefici accountable. Le evidenze dovrebbero maturare attraverso gate prima che l'impegno aumenti.

Il sistema descritto in questo articolo utilizza cinque strumenti collegati: una mappa del portafoglio dei casi d'uso, una scala di fiducia nei benefici, una heatmap della prontezza dei dati, gate di controllo e una dashboard stop-or-scale. Insieme mostrano quali casi meritano finanziamenti per la fase di scoperta, quali necessitano di interventi mirati, quali sono pronti per una scalabilità controllata e quali dovrebbero essere chiusi. Rivelano inoltre esposizioni a infrastrutture condivise e a fornitori che non possono essere governate un esperimento alla volta.

Una buona governance preserva l'apprendimento proteggendo il capitale. Un caso interrotto può produrre evidenze utili quando gli impegni sono limitati e le lezioni vengono catturate. Un caso portato in scala acquisisce maggiore autorità attraverso prestazioni rappresentative, adozione da parte degli utenti, controlli efficaci e valore verificato dalla funzione finanziaria. Il ruolo del consiglio è rendere espliciti tali standard e assicurare che il management li applichi prima che il portafoglio diventi difficile da invertire.

Appendice A. Domande del consiglio per un impegno rilevante in AI

1. Quale problema operativo e quale processo interessato rientrano nell'ambito?
2. Cosa accade nello scenario business as usual e quali opzioni non-AI sono state testate?
3. Quali benefici si configurano come risultati di cassa, capacità, ricavi, servizio o rischio?
4. Qual è il livello di confidenza attuale per ciascun beneficio e quali evidenze lo accrescono?
5. Quali sono gli impegni di cassa, di capacità e contrattuali per l'intero ciclo di vita?
6. Quali condizioni relative a diritti sui dati, qualità, provenienza, sicurezza e monitoraggio restano aperte?
7. Quali decisioni umane, soggetti interessati e giurisdizioni sono coinvolti?
8. Quali controlli sono necessari prima della fase pilota, della produzione e della scalabilità?
9. Quali soglie di adozione e qualità determinano scalabilità, sospensione o interruzione?
10. Qual è il prossimo impegno irreversibile e qual è il piano di uscita prima di esso?

Appendice B. Pacchetto minimo di evidenze per la decisione di interruzione o scalabilità

1. Definizione attuale del caso d'uso e cronologia delle versioni.
2. Metodo di misurazione della baseline, del controfattuale e dei benefici.
3. Spesa effettiva e prevista, impegni e costo operativo annuo.
4. Risultati del pilota o della produzione su utenti e condizioni rappresentativi.
5. Evidenze relative ad adozione, accettazione, rilavorazione, override e fallback.
6. Stato di preparazione dei dati e azioni correttive aperte.
7. Risultati dei test sui controlli, incidenti, limitazioni e accettazione del rischio residuo.
8. Performance dei fornitori, concentrazione, rinnovo e posizione di uscita.
9. Economia di scenario, valori di commutazione e liquidità a rischio prima del prossimo gate decisionale.
10. Raccomandazione del management con condizioni, responsabile, data e conseguenza.

Riferimenti

1. Banca dei Regolamenti Internazionali, Finanziare il boom di AI: dai flussi di cassa al debito, Bollettino BRI n. 120, pubblicato il 7 gennaio 2026. https://www.bis.org/publ/bisbull120.htm
2. Banca dei Regolamenti Internazionali, La corsa agli investimenti in AI, articolo di ricerca BRI n. 1367, pubblicato il 14 luglio 2026. https://www.bis.org/publ/work1367.htm
3. Agenzia Internazionale dell'Energia, Questioni chiave su energia e AI, pubblicato nel 2026. https://www.iea.org/reports/key-questions-on-energy-and-ai
4. Alphabet Inc., Relazione annuale sul modulo 10-K per l'esercizio chiuso al 31 dicembre 2025, depositata il 5 febbraio 2026. https://www.sec.gov/Archives/edgar/data/1652044/000165204426000018/goog-20251231.htm
5. Microsoft Corporation, Relazione annuale sul modulo 10-K per l'esercizio chiuso al 30 giugno 2026, depositata il 30 luglio 2026. https://www.sec.gov/Archives/edgar/data/789019/000119312526323660/msft-20260630.htm
6. Meta Platforms, Inc., Relazione annuale sul modulo 10-K per l'esercizio chiuso al 31 dicembre 2025, depositata il 29 gennaio 2026. https://www.sec.gov/Archives/edgar/data/1326801/000162828026025534/meta-12312025x10kars.htm
7. Amazon.com, Inc., Relazione trimestrale sul modulo 10-Q per il trimestre chiuso al 30 giugno 2026, depositata il 31 luglio 2026. https://www.sec.gov/Archives/edgar/data/1018724/000101872426000026/amzn-20260630.htm
8. OCSE, Boston Consulting Group e INSEAD, L'adozione dell'intelligenza artificiale nelle imprese: nuove evidenze per l'elaborazione delle politiche, pubblicato il 2 maggio 2025. https://doi.org/10.1787/f9ef33c3-en
9. OCSE, Gli effetti della AI generativa su produttività, innovazione e imprenditorialità, Documenti OCSE sull'intelligenza artificiale n. 39, pubblicato il 20 giugno 2025. https://doi.org/10.1787/b21df222-en
10. Istituto Nazionale degli Standard e della Tecnologia, Quadro di gestione del rischio per l'intelligenza artificiale 1.0, pubblicato il 26 gennaio 2023. https://doi.org/10.6028/NIST.AI.100-1
11. Istituto Nazionale degli Standard e della Tecnologia, Quadro di gestione del rischio per l'intelligenza artificiale: profilo per l'intelligenza artificiale generativa, pubblicato il 26 luglio 2024. https://doi.org/10.6028/NIST.AI.600-1
12. Ufficio di responsabilità governativa degli Stati Uniti, Intelligenza artificiale: un quadro di responsabilità per le agenzie federali e altri enti, GAO-21-519SP, pubblicato il 30 giugno 2021. https://www.gao.gov/products/gao-21-519sp
13. Organizzazione internazionale per la normazione, ISO/IEC 42001:2023 Tecnologie dell'informazione - Intelligenza artificiale - Sistema di gestione, pubblicato a dicembre 2023. https://www.iso.org/standard/81230.html
14. Board of Governors of the Federal Reserve System, Guida riveduta sulla gestione del rischio di modello, SR 26-2, pubblicata il 17 aprile 2026. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
15. Commissione europea, AI Act: quadro normativo per l'intelligenza artificiale, aggiornato il 3 agosto 2026. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
16. Unione europea, Regolamento (UE) 2024/1689 che stabilisce norme armonizzate sull'intelligenza artificiale, pubblicato il 12 luglio 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
17. HM Treasury, The Green Book 2026, pubblicato il 5 febbraio 2026. https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026
18. HM Treasury, Guida allo sviluppo dei business case, aggiornata il 30 giugno 2026. https://www.gov.uk/government/publications/guidance-on-developing-business-cases
19. Department for Science, Innovation and Technology e Government Digital Service, Quadro dei benefici digitali e dei dati, pubblicato il 7 aprile 2026. https://www.gov.uk/government/publications/digital-and-data-benefits-framework
20. Cabinet Office e HM Treasury, Il quadro per l'efficienza del governo, pubblicato nel 2025. https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2