I tuoi agenti IA hanno bisogno di descrizioni delle mansioni, non di prompt migliori

Chiedete a un’azienda quali attività può svolgere una nuova analista della contabilità fornitori e otterrete una risposta precisa. Lavora con questi sistemi e questi fornitori; qualsiasi importo superiore a una soglia di approvazione, diciamo 10.000 $, deve essere sottoposto al suo responsabile per la firma. È in prova per i primi mesi. Di solito tutto questo è riportato in una tabella delle deleghe di autorità, che l’audit interno verifica ogni anno.

Chiedete alla stessa azienda quali attività può svolgere il suo nuovo agente per la gestione delle fatture e spesso vi mostrerà uno screenshot di un prompt.

Questa disparità mi preoccupa più di qualsiasi benchmark dei modelli. Stiamo assumendo una forza lavoro digitale senza il sistema di gestione che abbiamo impiegato un secolo a costruire per le persone: nessuno mette per iscritto i suoi poteri, nessuno ne verifica il giudizio prima che inizi a lavorare e nessuno ha fatto pratica a disattivarla.

Perché un prompt non basta

Un prompt descrive le intenzioni. Spiega a cosa serve l’agente. Raramente specifica cosa non deve mai fare, quali sono i suoi limiti o quando deve fermarsi e lasciare la decisione a una persona.

E quando un prompt specifica queste cose, non c’è nulla che le faccia rispettare. Una frase che dice a un agente di non emettere rimborsi superiori a 500 $ è solo una richiesta rivolta a un sistema probabilistico. Nessun revisore approverebbe come controllo per una persona «abbiamo chiesto gentilmente all’analista di farlo», quindi non capisco perché lo accettiamo per il software.

Chi si occupa di sicurezza ha già un nome per questo risultato. L’OWASP Top 10 per le applicazioni basate su LLM indica l’eccessiva autonomia come rischio fondamentale, dovuto a funzionalità, autorizzazioni o autonomia eccessive. In parole povere, è come affidare a un dipendente le chiavi di tutto fin dal primo giorno. Le indicazioni di OWASP sembrano la lista di controllo di un buon responsabile: dare all’agente solo gli strumenti di cui ha bisogno, circoscriverne le autorizzazioni, richiedere l’approvazione di una persona per le azioni ad alto impatto e far rispettare le autorizzazioni nei sistemi a valle, anziché fidarsi del modello e lasciare che controlli da sé il proprio operato.

Sottolineerei quest’ultimo punto. Le autorizzazioni devono essere applicate nel luogo in cui avviene l’azione: nell’identità di servizio dell’agente, nelle autorizzazioni dei suoi strumenti e nel limite di spesa al gateway API. Usare un account di servizio condiviso per gli agenti è come far condividere un solo badge a cinque persone. Quando qualcosa va storto, il registro di audit indica che è stato l’account di servizio a compiere l’azione, e non resta che indovinare quale agente sia stato.

Le cancellazioni sembrano un problema di gestione

Gartner prevede che oltre il 40% dei progetti di IA agentica sarà cancellato entro la fine del 2027, citando l’aumento dei costi, il valore aziendale poco chiaro e l’inadeguatezza dei controlli sui rischi.

L’entusiasmo e l’immaturità dei prodotti contribuiscono a spiegare il fenomeno. Provate, però, a leggere le tre cause dal punto di vista di un direttore operativo. I costi aumentano quando nessuno ha fissato un budget. Il valore resta poco chiaro quando nessuno ha messo per iscritto i risultati attesi dal lavoro. I controlli sui rischi sono insufficienti quando non ci sono limiti, verifiche né persone chiaramente responsabili. Gartner non la mette in questi termini: è la mia interpretazione. È ciò che succede quando si lascia che le persone agiscano senza un sistema di gestione, e il problema esiste da molto prima dell’IA.

I framework individuano la stessa lacuna. Il framework NIST per la gestione dei rischi dell’IA considera la funzione Governare come quella che attraversa Mappare, Misurare e Gestire; il suo profilo per l’IA generativa applica questo approccio anche ai sistemi generativi. Ciò che i framework non possono fornire è il meccanismo operativo: le autorizzazioni, i test e le verifiche che un team svolge concretamente, in un qualsiasi martedì. Senza questi elementi, la governance resta un PDF in una cartella condivisa.

Applicare agli agenti i vecchi strumenti di gestione

Si parte dalla descrizione della mansione, che nel caso di un agente diventa un’autorizzazione formale. Prima che un agente acceda a un sistema operativo, qualcuno dovrebbe poter redigere un documento di una pagina che specifichi cosa può fare, cosa non deve mai fare, le soglie di approvazione, la persona responsabile e chi può ampliarne i limiti. Nella matrice RACI, il responsabile ultimo è una persona. Se non si riesce a scrivere quel documento, il ruolo non è pronto per essere assegnato; direste lo stesso anche di una persona da assumere.

Due vecchie regole sulle deleghe di autorità si applicano anche in questo caso. Non si può delegare un’autorità che non si possiede, quindi un sottoagente non dovrebbe mai ricevere poteri più ampi di quelli dell’agente che lo ha generato. Vale anche il principio della separazione dei compiti. Un agente che può sia creare un fornitore sia pagarlo darebbe luogo alla stessa constatazione di audit che si avrebbe nel caso di una persona.

C’è poi la prova di selezione. Per lo più valutiamo gli agenti come faremmo con una calcolatrice, controllando se la risposta è corretta. Una prova per un lavoratore verificherebbe invece se ha rispettato i limiti delle proprie autorizzazioni, chiesto l’approvazione quando previsto, sottoposto il caso a un livello superiore quando la situazione esulava dal suo mandato e si fermato quando avrebbe dovuto farlo.

Nelle mie ricerche sto costruendo un benchmark composto da 50 scenari che riguardano proprio questi tipi di errore: superare le soglie di approvazione, agire sulla base di dati obsoleti, seguire istruzioni iniettate che ampliano il proprio ambito operativo e mantenere l’accesso dopo un cambio di ruolo. Finora l’ho eseguito solo su agenti basati su script, per verificare che gli scenari funzionino come previsto, quindi non ho risultati sui modelli da riferire. Mentre li scrivevo, mi ha sorpreso quanto fossero comuni. Sono i normali modi in cui i dipendenti escono dai binari, riscritti per il software. La maggior parte delle classifiche pubbliche valuta ancora il completamento delle attività, e pochissime verificano se l’agente ha rispettato i limiti della propria autorità.

Il periodo di prova e l’avanzamento di carriera si traducono in modo abbastanza diretto. Con le persone, iniziamo assegnando loro un ambito ristretto e lo ampliamo man mano che dimostrano di saper valutare le situazioni. Gli agenti possono guadagnarsi gli stessi limiti, dimostrando nel tempo di rispettarli, di segnalare correttamente i problemi e di fermarsi senza intoppi; quel comportamento può giustificare altrettanto facilmente una riduzione delle autorizzazioni.

Gli agenti introducono una complicazione che non riguarda le persone. Quando un fornitore aggiorna il modello sottostante, di fatto ci si ritrova con un nuovo assunto che porta il vecchio badge. Lo considererei un evento di modifica e ripeterei i test prima di trasferire l’autorizzazione.

La cessazione dell’incarico va simulata prima che se ne presenti la necessità. Se dovessi fermare questo agente e revocargli l’accesso entro la prossima ora, potresti farlo? Chi ha l’autorità di prendere questa decisione alle 2 di notte? Che cosa si bloccherebbe a valle e quali impegni in corso qualcuno dovrebbe annullare manualmente? Se nessuno ha mai fatto questa prova, non resta che sperare che l’interruttore di emergenza funzioni.

Puoi ritenere un dipendente responsabile. Non puoi ritenere un agente responsabile di nulla, ed è qui che il paragone smette di funzionare. È anche per questo che l’autorizzazione deve essere applicata nei sistemi e che ogni agente deve avere una persona designata come responsabile. In ogni caso, qualcuno finisce per risponderne. Di solito è chi ha dato il via libera, che sapesse o meno di stare approvando qualcosa.

Cosa chiederà l’analisi dell’incidente

Prima o poi, alcuni di questi agenti faranno qualcosa che non dovrebbero fare. Quando accadrà, l’analisi successiva all’incidente porrà le stesse domande che pone già per le persone. Che cosa era autorizzato a fare e dove è scritto? Chi ha approvato l’ampliamento dei suoi accessi? Quanto tempo ci è voluto per fermarlo? Chi ne era responsabile?

Se le risposte sincere sono «un prompt», «nessuno se lo ricorda», «ore» e «non è chiaro», un modello migliore non ti avrebbe salvato.

Dove finisce per concentrarsi il vantaggio

I modelli stanno diventando risorse a noleggio, sostituite e aggiornate secondo i tempi del fornitore. Due aziende possono usare lo stesso modello e ritrovarsi in situazioni molto diverse. Una dispone di agenti con budget, limiti, responsabili e una traccia di audit per ogni azione rilevante; l’altra ha un costoso progetto pilota destinato a finire nelle statistiche di cancellazione di qualcuno.

La differenza sta nel sistema di gestione che circonda il modello. Quel sistema si costruisce lentamente, perlopiù grazie a persone che hanno già diretto organizzazioni.

Se domani il tuo agente più recente superasse i limiti della propria autorità, qualcuno nella tua azienda se ne accorgerebbe? E sapresti mostrare per iscritto a un revisore dove si trovava il limite?