Le imprese stanno sperimentando sistemi capaci di cercare informazioni, compilare documenti, aggiornare applicativi e avviare flussi di lavoro. Chiamarli semplicemente “assistenti” può però essere fuorviante: quando un sistema riceve strumenti, credenziali e la facoltà di compiere azioni, il tema non è più solo la qualità della risposta. È il governo dell’azione.
La questione è diventata più concreta anche nel dibattito istituzionale. Il NIST ha dedicato nel 2026 un’iniziativa agli standard per gli agenti AI e una sintesi delle consultazioni sulla loro sicurezza. Nell’Unione europea, l’AI Act non crea una categoria normativa separata per gli agenti, ma le regole applicabili dipendono dall’uso, dal ruolo nella catena del valore e dalle funzionalità effettivamente offerte. Per un’impresa, questa è una ragione in più per non trattare un agente come una semplice chat con un’interfaccia più elegante.
Un agente non è un nuovo utente amministratore
Un agente può essere utile proprio perché collega più sistemi: legge una casella condivisa, interroga un ERP, propone un ordine, apre un ticket o prepara una risposta al cliente. Ma la catena aumenta il perimetro di rischio. Un’istruzione ostile contenuta in un allegato o in una pagina web, un’autorizzazione troppo ampia o una registrazione incompleta possono trasformare un’automazione ordinaria in un problema di sicurezza, privacy o controllo interno.
Il punto non è negare l’autonomia. È renderla proporzionata. Il NIST, nel materiale sull’identità e l’autorizzazione di agenti software e AI, richiama precisamente identificazione, autenticazione, autorizzazione, auditabilità e non ripudio come temi da affrontare. Sono concetti noti alla cybersecurity, ma vanno adattati a un software che pianifica passaggi e usa strumenti in base al contesto.
Le tre identità da distinguere
La domanda pratica non è “l’agente ha accesso?”. È: per conto di chi agisce, con quale identità e entro quali limiti?
La prima identità è quella della persona o dell’unità organizzativa che attiva il processo. La seconda è quella tecnica dell’agente, separata da account personali e riconoscibile nei log. La terza riguarda lo strumento chiamato dall’agente: CRM, ERP, repository, piattaforma di assistenza o servizio esterno.
Separare questi livelli evita due errori frequenti. Il primo è usare credenziali condivise “per far funzionare la prova”. Il secondo è attribuire all’agente diritti ereditati senza capire se servono davvero. Un agente che prepara una bozza di ordine non deve poter modificare anagrafiche, pagamenti o ruoli utente. Un agente che analizza contratti può ricevere documenti selezionati senza poterli inoltrare automaticamente fuori dal perimetro aziendale.
Permessi minimi, azioni reversibili
Il principio del minimo privilegio resta una buona base, ma per gli agenti va tradotto anche nel disegno delle azioni. Conviene cominciare con capacità di sola lettura, bozze e simulazioni; le azioni irreversibili o con impatto economico devono passare da una conferma umana o da regole di approvazione esplicite.
Una matrice essenziale può aiutare:
- consultazione: l’agente legge fonti definite e conserva la provenienza;
- proposta: genera una bozza, ma non la invia o registra da solo;
- esecuzione limitata: compie azioni predefinite, con soglie e registrazione;
- esecuzione con approvazione: richiede un via libera per eccezioni, dati sensibili o effetti verso l’esterno.
Questa progressione è più utile di una scelta binaria tra “manuale” e “completamente autonomo”. Permette di testare il valore del caso d’uso senza concedere in anticipo ogni autorizzazione disponibile.
L’audit deve raccontare una decisione
Un log che dice solo “workflow completato” non basta. Quando un agente entra nei processi, occorre poter ricostruire almeno il contesto dell’azione: richiesta iniziale, fonti o dati consultati, strumenti utilizzati, identità coinvolte, autorizzazioni applicate, output prodotto e approvazioni ricevute.
Non significa conservare indiscriminatamente ogni conversazione o dato personale. Significa progettare evidenze adeguate allo scopo, con tempi di conservazione, accessi e minimizzazione coerenti con le regole aziendali e con il GDPR. Per alcune attività sarà sufficiente il riferimento al documento e alla versione; per altre, come la modifica di dati o l’invio di comunicazioni, servirà una traccia più puntuale.
La stessa tracciabilità serve alla gestione degli incidenti. La sintesi NIST sulle risposte alla consultazione dedicata alla sicurezza degli agenti segnala rischi come l’interazione con dati avversari, inclusa l’indirect prompt injection, e la necessità di adattare le pratiche cyber tradizionali. Per l’impresa questo vuol dire predisporre revoca rapida dei token, interruttori di arresto, limiti di chiamata e una procedura per isolare un’integrazione senza bloccare tutta l’operatività.
Cosa richiede l’AI Act, e cosa richiede il buon governo
L’AI Act non usa “agente AI” come etichetta normativa autonoma. La Commissione europea chiarisce che un agente può rientrare nelle definizioni di sistema AI o di modello di AI per finalità generali, mentre gli obblighi specifici dipendono dal caso. Dal 2 agosto 2026 sono applicabili, tra l’altro, le regole di trasparenza dell’articolo 50 quando il sistema è destinato a interagire con persone fisiche o a generare contenuti; per eventuali sistemi ad alto rischio le tempistiche e i requisiti sono diversi.
È importante non trasformare questa precisazione in una scorciatoia: non ogni agente aziendale è automaticamente ad alto rischio, né ogni progetto richiede lo stesso apparato. Tuttavia, anche quando non scatta un obbligo specifico, identità separate, autorizzazioni granulari e audit trail sono scelte di controllo ragionevoli. Rendono più semplice dimostrare cosa è stato progettato, testato e autorizzato.
Una checklist prima di collegare il primo strumento
Prima del pilota, responsabili IT, sicurezza, processo e compliance dovrebbero condividere poche risposte verificabili:
- qual è l’obiettivo operativo e quale azione l’agente può davvero compiere;
- quali dati legge, scrive o trasferisce e con quali basi di accesso;
- quale identità tecnica usa e come sono separati ambiente di test e produzione;
- quali azioni richiedono approvazione umana, soglie o doppio controllo;
- dove sono raccolte le evidenze e chi può consultarle;
- come si revoca l’accesso e come si gestisce un comportamento inatteso.
La tecnologia degli agenti sta rendendo accessibili automazioni che fino a poco tempo fa richiedevano integrazioni su misura. La velocità è interessante, ma il vantaggio durevole non nasce dal collegare più strumenti possibile. Nasce dal sapere chi può agire, con quale mandato, e dal poterlo dimostrare dopo.
Nota di trasparenza: questo articolo e le immagini collegate sono stati realizzati in parte con l’utilizzo dell’intelligenza artificiale, con supervisione e responsabilità editoriale umana.