Gli agenti di intelligenza artificiale stanno imparando a leggere i manuali aziendali molto più velocemente di quanto stiano imparando a rispettarli. È questa la conclusione più scomoda che emerge da HANDBOOK.md, un benchmark costruito da Surge AI per misurare quanto i modelli frontier riescano davvero ad applicare policy aziendali durante attività operative, invece di limitarsi a citarle con l’aria rassicurata di chi ha appena superato un corso obbligatorio di compliance.
Il benchmark mette alla prova 30 configurazioni di modelli su 65 attività distribuite in cinque domini, utilizzando file aziendali realistici relativi a email, chat, calendari e ticket. Le policy non sono brevi istruzioni da prompt engineering, ma documenti che possono arrivare a 124 pagine, mentre la richiesta operativa non contiene necessariamente alcun riferimento esplicito alla regola che deve essere applicata. Il sistema deve recuperare il documento corretto, individuare il vincolo pertinente, interpretarlo e applicarlo alla decisione. La valutazione comprende 824 controlli deterministici con esito pass o fail, senza affidarsi a un altro modello incaricato di giudicare la risposta. È una scelta metodologica importante, perché elimina una delle debolezze più diffuse nelle valutazioni degli agenti: chiedere a un LLM di stabilire se un altro LLM abbia fatto bene.
I risultati sono difficili da rendere compatibili con la narrativa commerciale dell’agente che “conosce le policy”. La configurazione migliore rispetta le regole soltanto nel 36,2% dei casi, mentre la maggior parte rimane sotto il 25%. Significa che anche il sistema migliore fallisce circa due attività su tre. Non siamo quindi davanti a una piccola imperfezione di interfaccia o a qualche hallucination residua da eliminare con un prompt più elegante. Siamo davanti a un problema strutturale: la capacità di recuperare una regola non garantisce la capacità di governare un’azione attraverso quella regola.
I quattro errori ricorrenti individuati nel benchmark sono particolarmente interessanti perché assomigliano meno a errori di conoscenza e molto più a errori di controllo interno. In alcuni casi la richiesta operativa prende il sopravvento sulla policy permanente; in altri il modello esegue un controllo ma ignora il risultato, oppure salta completamente il controllo e presume che l’esito sia positivo. Ancora più problematico è il caso in cui l’agente dichiari nel rapporto finale di avere seguito la policy quando il comportamento osservato dimostra il contrario. La macchina non si limita quindi a sbagliare: può produrre anche una rappresentazione plausibile del proprio errore come comportamento conforme.
Questo punto dovrebbe interessare molto più ai responsabili audit e compliance che agli evangelisti dell’AI. Una policy aziendale non è un testo da comprendere, è un meccanismo di governo. Se una procedura stabilisce che una spesa oltre una determinata soglia debba essere approvata da una persona indipendente, non basta che il modello riconosca la presenza dell’approvazione. Deve verificare chi ha approvato, quale ruolo ricopre, quale rapporto ha con la transazione e se quella relazione è compatibile con il principio di segregazione dei compiti. Il controllo non consiste nel trovare una firma. Consiste nel dimostrare che quella firma soddisfa le condizioni previste dal controllo.
Il caso descritto nel lavoro rende perfettamente visibile questa differenza. Un elemento sospeso supera la soglia di approvazione, fissata a 7.500 dollari. L’approvazione risulta inserita dalla stessa persona che aveva originato il costo, esattamente il tipo di situazione che il controllo dovrebbe intercettare. Il modello recupera i fatti necessari, li porta nel proprio ragionamento e tuttavia promuove la persona sbagliata, autorizzando l’operazione. Successivamente contatta il controller corretto chiedendo conferma che tutti gli elementi abbiano ricevuto l’approvazione prevista. Il risultato è paradossale: l’agente commette una violazione della segregazione dei compiti e poi costruisce un’apparenza di conformità attraverso una comunicazione successiva.
In un’organizzazione finanziaria, questo non sarebbe semplicemente un errore dell’AI. Sarebbe un fallimento del controllo interno. La differenza è sostanziale, perché quando un processo viene automatizzato la responsabilità non scompare insieme all’operatore umano. Si sposta nell’architettura, nei controlli e nella governance del sistema. L’azienda che decide di affidare a un agente un processo regolamentato deve quindi dimostrare non soltanto che il modello possiede accesso alla policy, ma che il processo nel suo complesso impedisce, rileva e documenta le violazioni.
È qui che la frase “the agent has the handbook” diventa quasi comica. Avere il manuale non significa essere governati dal manuale. Un dipendente può avere sulla scrivania il regolamento aziendale e violarlo; un agente può avere 124 pagine di policy nel proprio context window e fare esattamente la stessa cosa, soltanto con una prosa molto più convincente. La differenza è che il dipendente difficilmente genera automaticamente un rapporto finale nel quale certifica di aver rispettato la procedura.
Questo introduce un problema nuovo nell’assurance dei sistemi agentici. Nei sistemi tradizionali, il controllo veniva spesso implementato attraverso regole deterministiche, autorizzazioni, workflow e separazione dei ruoli. L’AI generativa tende invece a spostare una parte della logica decisionale dentro un modello probabilistico. Il sistema può interpretare correttamente la policy in una sequenza e fallire in un’altra, anche quando le informazioni disponibili sono sostanzialmente identiche. L’errore non è necessariamente riproducibile con la semplicità di un bug software tradizionale. È una proprietà comportamentale del sistema.
Per questo l’idea di verificare l’AI attraverso documentazione statica appare sempre più insufficiente. Una policy firmata, un prompt approvato, un diagramma architetturale e un esempio positivo non dimostrano che l’agente si comporti correttamente durante l’esecuzione. L’assurance deve diventare comportamentale. Bisogna mettere il sistema davanti a casi normali, casi ambigui e soprattutto casi costruiti per provocare la violazione del controllo, misurando ciò che fa e non ciò che afferma di aver fatto.
Il problema assume dimensioni ancora più importanti quando gli agenti iniziano ad avere accesso diretto a sistemi aziendali. Un chatbot che interpreta male una policy produce una risposta sbagliata. Un agente che interpreta male una policy e possiede autorizzazioni per modificare un ERP, approvare una fattura, gestire un ticket finanziario o inviare una comunicazione esterna può trasformare lo stesso errore in un evento operativo. La differenza fra generative AI e agentic AI, dal punto di vista del rischio, sta precisamente qui: l’errore non rimane necessariamente confinato nella conversazione.
La progettazione dei sistemi enterprise dovrà quindi separare sempre più chiaramente tre livelli. Il primo è il recupero della policy, cioè la capacità di trovare la regola pertinente. Il secondo è il ragionamento sulla policy, cioè la capacità di interpretarne le condizioni. Il terzo è l’enforcement, cioè la capacità del sistema di impedire che un’azione non conforme venga eseguita. I primi due possono essere affidati in parte a un modello linguistico; il terzo, soprattutto nei processi ad alto rischio, dovrebbe essere sostenuto da controlli deterministici e verificabili.
La lezione più importante di HANDBOOK.md non riguarda quindi quale modello sia oggi il migliore. Riguarda l’errore concettuale con cui molte aziende stanno affrontando l’automazione agentica. Stanno trattando la compliance come un problema di conoscenza, quando in realtà è un problema di controllo. Un modello può conoscere una regola senza applicarla, può applicarla senza verificarne l’esito e può persino descrivere come conforme un processo che conforme non è.
Per chi costruisce sistemi AI destinati a banche, assicurazioni, finanza, procurement o infrastrutture critiche, questa distinzione dovrebbe diventare una regola architetturale. La policy deve essere presente nel contesto, ma le regole critiche devono anche essere incorporate nel processo di esecuzione. L’agente deve poter spiegare la decisione, ma la spiegazione non deve essere considerata la prova della correttezza. La verifica deve essere indipendente dal soggetto che ha prodotto la decisione.
Il benchmark pone dunque una domanda molto concreta al mercato degli agenti AI: quanto possiamo fidarci di un sistema che sa dirci quale policy dovrebbe applicare ma non riesce ancora ad applicarla con affidabilità? La risposta, almeno osservando questi risultati, è che la distanza fra “policy-aware” e “policy-compliant” è ancora enorme. Ed è precisamente in quella distanza che si annidano i rischi più costosi dell’AI enterprise.
Una regola inserita nel context non è ancora una regola in vigore. Un controllo descritto nella documentazione non è ancora un controllo operativo. E un agente che scrive “compliant” nel proprio rapporto non è un auditor. È semplicemente un altro output del modello, con la stessa necessità di verifica di tutti gli altri.