Perché l’AI governance conta adesso: le policy stabiliscono l’intento, gli agenti agiscono a velocità computazionale
L’AI governance conta adesso perché le policy scritte non riescono a tenere il passo con la velocità degli agenti. Di norma, la governance si basa su policy, formazione e revisioni periodiche. Le policy definiscono ciò che dovrebbe accadere, ma non possono verificare ciò che accade mentre un agente AI è in esecuzione. È in quel divario tra regole scritte e comportamento in esecuzione che si producono più danni.
Gli agenti AI eseguono workflow a più passaggi, richiamano strumenti e modificano lo stato dei sistemi. Il loro ragionamento è probabilistico, quindi lo stesso task può seguire un percorso diverso e costare ogni volta una cifra diversa. In sostanza, una policy scritta non basta a impedire nemmeno a un singolo agente di commettere un errore significativo.
L’analisi di Gartner di settembre 2026 quantifica questa esposizione. Gartner prevede che, entro il 2029, almeno il 70% delle organizzazioni con AI agentica in produzione in ambito infrastruttura e operations subirà un incidente rilevante di servizio, sicurezza o costi, legato in parte a controlli runtime insufficienti. Spesso è proprio la spesa il primo segnale di una governance debole: un agente in loop o una finestra di contesto sovradimensionata lascia traccia in fattura molto prima che qualcuno si accorga di un evento di sicurezza.
Gartner converge su un’unica idea: la governance deve essere integrata, continua e applicabile. In pratica significa avere un inventario di agenti e owner, guardrail e circuit breaker a runtime, osservabilità su ciò che un agente ha deciso e perché, controlli finanziari che interrompono l’esecuzione al raggiungimento di soglie prestabilite e approvazione umana per le azioni ad alto impatto.
Ma i controlli privi di contesto sono strumenti di poco conto.
Perché l’AI governance fallisce senza contesto di business?
L’AI governance fallisce senza contesto di business perché un agente, e le persone che lo supervisionano, non possono valutare una situazione che non comprendono. Una regola come “limita la spesa” o “attiva l’escalation per le azioni rischiose” non significa nulla finché il sistema non sa che cosa significa rischioso, che cosa è costoso e che cosa conta di più per il business.
Il più delle volte, gli agenti AI si comportano come un bravo neoassunto al primo giorno: veloce e pieno di idee, ma senza onboarding, senza policy e senza nessuno che spieghi come funzionano i sistemi legacy. Non comprende fino in fondo le metriche, il modo in cui i dati si collegano tra loro, né come trasformare quelle informazioni in valore di business concreto. La governance trova in questa immagine una corrispondenza precisa:
- L’onboarding è il contesto di business: quali sistemi e asset esistono, come si collegano, chi ne è responsabile, quali definizioni usa l’azienda.
- La supervisione è il controllo a runtime: che cosa l’agente può fare, toccare e spendere.
- La valutazione delle performance è l’osservabilità: evidenza di ciò che l’agente ha fatto e di ciò che ha prodotto.
Un approccio basato solo sulle policy copre la supervisione sulla carta, con poco onboarding e nessuna valutazione delle performance.
Che cosa significa davvero contesto di business?
Con contesto di business intendiamo la comprensione semantica e governata di ciò che esiste nell’organizzazione (sistemi, dati, metriche, regole, priorità e relazioni tra questi elementi), insieme ai template e ai workflow che la mettono al lavoro per gli agenti. Persone e agenti la condividono in modo uniforme, e svolge tre compiti:
- Informa l’agente. Un agente che sa che un servizio è tier-1, chi ne è responsabile e da che cosa dipende ottiene questi fatti in modo deterministico, invece di doverli dedurre ogni volta. Uno che deve ricostruire il quadro a ogni chiamata spreca turni e token.
- Dà senso alle policy. Budget, limiti e livelli di autonomia hanno senso solo in relazione alla criticità. Un loop fuori controllo su un servizio di pagamento e uno su un bot interno della wiki sono incidenti molto diversi.
- Dà un prezzo al risultato. Il valore è il downtime evitato e le ore risparmiate al costo reale del team. Senza di esso, il ROI dell’AI resta una slide.
La supervisione umana segue la stessa logica. Più revisori senza un contesto condiviso moltiplicano le interpretazioni invece di ridurre il rischio, perché ciascuno porta con sé le proprie definizioni. L’approvazione umana continua ad avere senso per le azioni irreversibili e ad alto impatto, a patto che chi approva veda ciò che ha visto l’agente: il servizio coinvolto, le sue dipendenze e il suo owner.
Token o valore: che cosa dovrebbe misurare un CTO?
Un CTO dovrebbe misurare il valore netto che una sessione di un agente crea rispetto a quanto costa, e non soltanto il volume di token consumati. Il conteggio dei token descrive l’attività. Il valore netto, con il tempo risparmiato e il downtime evitato convertiti in denaro, descrive il ROI. Per questo, in un contesto enterprise, governare l’AI significa anche osservare il consumo e il ritorno procurato da ogni agente.
È la legge di Goodhart all’opera: quando una misura diventa un obiettivo, smette di essere una buona misura. Una volta approvata l’adozione, il KPI di successo diventa silenziosamente “quanti token stiamo consumando”. Ma spendere token non significa sempre generare valore, e confondere le due cose è un errore costoso.
Sta già succedendo, e alla luce del sole. Secondo Fortune, Uber avrebbe bruciato l’intero budget 2026 per l’AI coding in quattro mesi, dopo aver incentivato l’adozione con una classifica interna che ordinava i team in base all’uso degli strumenti AI. Il suo presidente e COO, Andrew Macdonald, ha poi dichiarato in un podcast che il legame tra quell’utilizzo e funzionalità più utili per i clienti “non c’è ancora”.
L’immagine speculare è fuorviante allo stesso modo. Una sessione che consuma molti token sembra uno spreco finché non si scopre che ha risolto un incidente critico in pochi minuti. Una sessione economica che gira in tondo senza risolvere nulla è puro spreco, per quanto il suo ragionamento sembrasse ponderato. Tagliare la fattura dei token punirebbe la prima e premierebbe la seconda. Poiché il solo numero inganna in entrambe le direzioni, solo il contesto lo rende interpretabile.
Lo spreco, poi, si nasconde bene. Dietro una risposta finale pulita può esserci un processo che ha bruciato molte volte i token di cui aveva bisogno, trascinandosi dietro contesto ridondante a ogni turno. Il costo si concentra spesso in pochi passaggi, ma lo vedi solo se osservi il processo e non soltanto l’output. È qui che l’LLMOps comincia ad assomigliare al FinOps: i modelli si confrontano su costo e valore generato, come si farebbe con diversi cloud provider, invece di scegliere per abitudine.
C’è poi il lungo periodo. Gli agenti cambiano ogni volta che un modello viene aggiornato, un’istruzione viene rivista o viene aggiunto un tool. Una revisione al momento dell’approvazione dice poco sul comportamento sei mesi dopo. La governance deve funzionare come per qualsiasi servizio in produzione: misurazione continua rispetto a una baseline, in modo che ogni modifica si dimostri un miglioramento o una regressione. Così il miglioramento non è più una speculazione ma una prova di fatto.
4 domande a cui l’AI governance a runtime deve rispondere
L’AI governance a runtime si riduce a quattro domande a cui ogni CTO dovrebbe saper rispondere, in qualsiasi momento, per qualsiasi agente in produzione:
