Governance degli agenti AI in azienda: controllo, contesto e regole per scalare

Un agente che deve scegliere tra centinaia di strumenti non lavora, si blocca. È ciò che accade quando si espone un’operazione API come singolo strumento del Model Context Protocol. Nelle aziende con migliaia di API e sistemi come CRM o ERP con centinaia di operazioni, questo approccio crolla. La tesi: per scalare servono meno superfici da manovrare e più regole dure. Si vedono tre mosse convergenti: ridurre il mapping uno a uno, esporre i permessi come funzioni richiamabili, rendere deterministiche le metriche, affiancare guardrail verificabili. Così gli agenti smettono di essere scatole nere e diventano componenti governati dell’infrastruttura^1,2,3,4.

1. Perché esporre ogni endpoint come strumento MCP non scala

Molte organizzazioni hanno programmi API completi. Gestiscono migliaia di API interne, ognuna con un owner e uno schema di autenticazione. Quei sistemi custodiscono il contesto che serve agli agenti in produzione: anagrafiche clienti, inventario, ticket di supporto¹. La pratica corrente, quando si usa MCP, è creare uno strumento per ogni operazione. Funziona con pochi endpoint. Non regge su un patrimonio enterprise.

CRM o ERP tipici espongono centinaia di operazioni. Un agente che deve combinarle si ritrova davanti centinaia di definizioni di strumenti. Il carico cognitivo esplode già in partenza. Prima ancora di eseguire un task, l’agente deve orientarsi in un catalogo di strumenti sovrabbondante. La conseguenza è una perdita di efficacia e una complessità gestionale che non scala¹.

Il punto non è MCP. È il modello di esposizione. L’integrazione utile non moltiplica gli strumenti a disposizione dell’agente quando il dominio reale ne conta già centinaia. Ridurre il numero di punti di contatto evita un sovraccarico iniziale che impedisce all’agente di lavorare in modo efficace¹.

2. Permessi e continuità delle pipeline: il ruolo degli helper IAM

Molte pipeline si fermano per un motivo banale: permessi mancanti. Partono ticket manuali. I rilasci si bloccano. Google Cloud introduce IAM Helper per rendere richiamabili le skill IAM da agenti, assistenti di codice e CI/CD, così i flussi non si interrompono sui controlli di accesso².

IAM Helper non è un nuovo motore di policy. Orchestra ed espone capacità IAM già esistenti come funzioni. Chi costruisce un agente, una pipeline di deployment o un assistente di codice può invocarle direttamente, dentro il processo automatizzato. L’obiettivo è eliminare passaggi ripetitivi legati all’accesso, mantenendo le stesse regole e controlli già in uso².

Google Cloud inquadra IAM Helper come estensione. Policy Intelligence e Privileged Access Manager restano al loro posto. Il nuovo layer li aumenta, non li sostituisce². Il messaggio è chiaro: non si scardina la governance per far correre gli agenti. Si rende programmabile ciò che già governa gli accessi².

3. Dati e semantica: indicizzare LookML per metriche deterministiche

Dare accesso ai dati non basta se un agente deve calcolare una metrica. Senza semantica deterministica, il rischio è una risposta ben scritta ma sbagliata. Google Cloud ha portato in disponibilità generale l’indicizzazione del linguaggio semantico LookML in Knowledge Catalog per Looker Core su Google Cloud³. Le definizioni esatte delle metriche entrano nel catalogo aziendale: formule SQL, join, filtri. In forma ricercabile e sfruttabile dagli strumenti che interrogano il catalogo³.

L’annuncio distingue due piani. Il contesto organizzativo: dove vivono i dati, come fluiscono, quali regole li governano. La semantica deterministica: come si definiscono e si calcolano le metriche a partire da quei dati. Il primo nasce da metadati eterogenei, spesso testuali. Il secondo vive in LookML, con specifiche tecniche che eliminano ambiguità³.

La lezione è concreta: gli agenti rispondono meglio quando possono interrogare definizioni che vincolano il calcolo. Chiedere a un modello di ricostruire metriche da testo libero espone ad ambiguità. Portare le definizioni in un catalogo interrogabile allinea le risposte ai numeri che l’azienda riconosce come corretti³.

4. Il trust bottleneck: perché servono guardrail deterministici

Dove gli agenti scrivono codice, la produzione corre e la verifica no. Il Faros AI Engineering Report di marzo 2026, su 22.000 sviluppatori, riporta tre segnali: il tempo di review delle pull request è cinque volte più lungo, gli incidenti per PR salgono del 242%, i bug in produzione per sviluppatore del 54%⁴. Un post tecnico propone una cura: guardrail deterministici per rendere affidabili i workflow agentici⁴.

Il quadro di partenza è netto. Gli agenti generano gran parte della logica applicativa e del test code. Gli sviluppatori dirigono, controllano, decidono cosa passa. Le code review diventano costose e stancanti. La giornata si spezza in continui cambi di contesto. La qualità cala⁴.

I guardrail puntano a trasformare pezzi del controllo umano in regole ripetibili e verificabili. Non eliminano la revisione. La rendono selettiva e misurabile. L’obiettivo è accelerare dove le regole coprono il rischio e concentrare il giudizio umano dove serve davvero. È una risposta diretta al collo di bottiglia della fiducia che oggi allunga i tempi e aumenta gli incidenti⁴.

5. Implicazioni pratiche per la governance degli agenti in azienda

Le quattro mosse si tengono tra loro. Ridurre il numero di strumenti MCP esposti all’agente limita il carico cognitivo iniziale e rende più gestibile l’uso degli strumenti. L’agente opera su pochi attrezzi con responsabilità chiare. La gestione degli owner e degli schemi di autenticazione resta nei domini d’origine, non si replica a livello di migliaia di strumenti¹.

Esporre le capacità IAM come funzioni crea un collegamento esplicito tra processo automatizzato e controllo di accesso. Un assistente di codice o una pipeline CI/CD non si fermano per chiedere un permesso a voce. Chiamano una funzione che applica le stesse regole di sempre. Così l’automazione evita passaggi manuali ripetitivi mantenendo i controlli in vigore².

Indicizzare LookML nel catalogo sposta il fulcro dalla scoperta generica al calcolo corretto. Un agente che risponde con metriche legge definizioni univoche, non interpreta note testuali. Questo riduce l’ambiguità e rende utilizzabili, da parte degli strumenti, le formule e i filtri ufficiali³.

Infine, i guardrail deterministici intervengono dove l’agente produce cambiamenti che toccano ambienti reali. Portano criteri verificabili nel flusso di validazione. Ridimensionano la parte manuale che oggi rallenta e genera fatica. E rispondono a numeri precisi, come il +242% di incidenti per PR riportato da Faros⁴.

Il filo è unico: meno superfici arbitrarie, più interfacce stabili, più semantica codificata, più controlli ripetibili. Non è una promessa astratta. È una serie di scelte già adottate: dal rifiuto del mapping uno a uno in MCP, all’uso di helper per i permessi, all’inserimento della semantica LookML nel catalogo, all’introduzione di guardrail che si possono verificare e misurare^1,2,3,4.

Chi guida piattaforme software trova qui una rotta operativa: mettere gli agenti dentro l’infrastruttura che c’è e pretendere che ogni decisione automatizzata resti allineata a regole e definizioni ufficiali, come già accade per API, accessi e metriche.