Rischio degli agenti IA: perché gli agenti hanno bisogno di un nuovo modello di governance
12 aprile 2026 · 8 min di lettura
Gli agenti IA stanno rapidamente diventando la nuova narrativa dominante dell’AI enterprise. I vendor stanno aggiungendo agenti a suite di produttività, piattaforme di customer service, strumenti per sviluppatori, sistemi di workflow e ambienti low-code. Microsoft Copilot Studio, per esempio, oggi si presenta come una piattaforma per creare, personalizzare, distribuire e gestire agenti IA che possono connettersi ai dati aziendali, usare strumenti e essere pubblicati in canali come Microsoft 365 Copilot, Teams, SharePoint e siti web.
Questo cambiamento conta. Ma crea anche un problema di linguaggio.
Non tutti i prodotti chiamati "agenti" portano con sé lo stesso rischio.
Un semplice assistente prompt-response basato su pochi documenti non è la stessa cosa di un agente di workflow autonomo che monitora eventi, decide cosa fare, richiama strumenti, aggiorna record, invia messaggi, scala casi o attiva processi aziendali in background. Entrambi possono essere venduti come agenti. Ma non hanno bisogno dello stesso modello di governance.
Idea chiave: un agente è una categoria di prodotto, ma il comportamento agentico è una proprietà di rischio.
Dall’IA che risponde all’IA che agisce
La governance tradizionale dell’IA spesso parte da domande come:
- Il modello è accurato?
- L’output è distorto?
- Il sistema spiega il proprio risultato?
- I dati personali vengono trattati in modo lecito?
- Gli utenti possono fidarsi della risposta?
Queste domande restano importanti. Ma i sistemi agentici aggiungono un nuovo livello: l’azione.
Con gli agenti, la domanda di governance cambia da:
Che cosa ha detto il modello?
A:
Cosa era autorizzato a fare l’agente, cosa ha fatto davvero, perché lo ha fatto, chi lo ha approvato e possiamo dimostrarlo?
Si tratta di un problema di controllo molto diverso.
Un chatbot può dare una risposta sbagliata. Un agente può dare una risposta sbagliata e poi agire sulla base di quella risposta. Può chiamare un’API, aggiornare un ticket, inviare un’e-mail a un cliente, modificare un record, recuperare dati sensibili, avviare un rimborso, creare un task o passare il lavoro a un altro agente.
Nel momento in cui un sistema IA può influenzare un altro sistema, la governance dell’IA diventa governance operativa.
L’etichetta “agente” è troppo ampia
La documentazione di Microsoft stessa rende visibile lo spettro. Microsoft 365 Copilot descrive agenti che vanno da semplici agenti prompt-response fino ad agenti pienamente autonomi. Copilot Studio aggiunge poi capacità autonome in cui gli agenti possono agire sulla base di trigger, istruzioni e guardrail, operando in background anziché limitarsi a rispondere in una conversazione.
Questo spettro è utile. Ma crea anche confusione.
Molte organizzazioni sentono la parola “agente” e pensano di avere davanti una sola categoria. In pratica, esistono diversi livelli di comportamento agentico.
Livello 1: assistente di conoscenza
Si tratta di uno strumento poco agentico. Risponde a domande usando istruzioni e fonti di conoscenza selezionate.
Esempio:
- Un assistente HR interno che risponde a domande sulle policy usando documenti approvati.
- Un agente Copilot Studio che risponde in una chat Teams usando topic e conoscenza configurati.
Rischi principali:
- Risposte errate
- Conoscenza obsoleta
- Divulgazione inappropriata
- Eccessivo affidamento dell’utente
Focus di governance:
- Qualità dei contenuti
- Accesso alle fonti di conoscenza
- Disclaimer ed escalation
- Logging di base
Livello 2: assistente di workflow guidato
Questo strumento aiuta un utente a completare un compito, ma la guida resta all’essere umano.
Esempio:
- Un assistente di supporto che prepara una risposta e suggerisce il passo successivo.
- Un assistente sales che riassume le informazioni su un account e propone un’e-mail di follow-up.
Rischi principali:
- Raccomandazioni deboli
- Contesto incompleto
- Riassunti fuorvianti
- Approvazione automatica senza vera revisione
Focus di governance:
- Revisione umana
- Trasparenza delle fonti
- Confini del workflow
- Formazione degli utenti
Livello 3: agente che usa strumenti
Qui il rischio inizia a cambiare in modo materiale. L’agente può chiamare strumenti, API, flow o connettori.
Esempio:
- Un agente di supporto IT che crea ticket e controlla lo stato del dispositivo.
- Un agente di customer service che cerca ordini e avvia azioni approvate.
- Un agente Copilot Studio connesso a flow Power Automate o ad API di sistemi aziendali.
Rischi principali:
- Uso non autorizzato degli strumenti
- Permessi eccessivi
- Prompt injection che porta a tool misuse
- Perdita di dati tramite input o output degli strumenti
- Auditabilità incompleta
Focus di governance:
- Tool permission matrix
- Accesso least privilege
- Regole di approvazione
- Audit log
- Runtime policy enforcement
Livello 4: agente di workflow autonomo
L’agente può monitorare eventi, prendere decisioni ed eseguire task senza aspettare un prompt utente.
Esempio:
- Un agente che monitora e-mail di fornitori, estrae modifiche contrattuali, classifica il rischio e instrada le approvazioni.
- Un agente finance che monitora eccezioni di riconciliazione e avvia workflow di correzione.
- Un agente security che osserva alert, arricchisce casi e prende misure di contenimento.
Rischi principali:
- Azione non approvata
- Decisione sbagliata su larga scala
- Errore silenzioso
- Fallimento dell’escalation
- Interruzione del processo aziendale
- Lacune nella prova di compliance
Focus di governance:
- Validazione dei trigger
- Confini decisionali
- Approvazione umana per azioni critiche
- Monitoring e alerting
- Incident response
- Kill switch
Livello 5: orchestrazione multi-agente
Più agenti si coordinano, delegano o si passano il lavoro.
Esempio:
- Un processo di customer onboarding in cui un agente raccoglie documenti, un altro verifica la compliance, un altro aggiorna i sistemi e un altro ancora comunica con il cliente.
Rischi principali:
- Vuoti di accountability
- Istruzioni in conflitto
- Propagazione degli errori
- Delega nascosta
- Analisi della causa radice difficile
Focus di governance:
- Identità degli agenti
- Regole di delega
- Tracciabilità end-to-end
- Test di sistema
- Modello di ownership
Regola pratica: non governare l’etichetta, ma il comportamento.
Esempi di casi d’uso per livello di agente
I livelli non vogliono essere scatole perfette. Sono un modo pratico per chiedersi: quanta agency ha davvero questo sistema?
| Livello di agente | Casi d’uso tipici | Cosa lo rende agentico | Focus di governance |
|---|---|---|---|
| Livello 1: assistente di conoscenza | Q&A su policy HR, ricerca di conoscenza per helpdesk IT, FAQ di compliance interna, assistente per documentazione prodotto, assistente onboarding | Risponde da fonti approvate ma non esegue azioni | Qualità della conoscenza, controllo accessi, aggiornamento delle fonti, disclaimer, percorsi di escalation |
| Livello 2: assistente di workflow guidato | Bozze di risposte ai clienti, sintesi di account sales, preparazione di brief per meeting, suggerimenti next-best-action, prime bozze di note di rischio | Guida un essere umano in un compito mentre la decisione finale resta umana | Revisione umana, trasparenza delle fonti, confini del workflow, training, approvazione dell’output finale |
| Livello 3: agente che usa strumenti | Creazione di ticket di supporto, verifica dello stato ordini, interrogazione di record CRM, apertura di service request IT, invocazione di flow Power Automate | Chiama strumenti o connettori, di solito dentro una sessione avviata dall’utente | Tool permission matrix, least privilege, audit logging, regole di approvazione, test di prompt injection |
| Livello 4: agente di workflow autonomo | Monitoraggio di e-mail fornitori, routing di eccezioni contrattuali, triage di alert di sicurezza, riconciliazione di eccezioni finance, escalation di casi cliente | Agisce tramite trigger ed esegue parti di processo senza attendere ogni singolo prompt utente | Validazione dei trigger, confini di azione, monitoring, kill switch, approvazione umana per azioni ad alto impatto |
| Livello 5: orchestrazione multi-agente | Customer onboarding tra KYC, legal, CRM e supporto; incident response con agenti di investigazione e remediation; workflow enterprise di procurement | Più agenti si coordinano, delegano o si passano il lavoro tra sistemi e team | Identità degli agenti, regole di delega, tracciabilità end-to-end, test di sistema, ownership e accountability |
Anche gli strumenti poco agentici hanno bisogno di governance
Sarebbe un errore considerare le piattaforme poco agentiche come innocue. Un semplice agente Copilot Studio può comunque esporre informazioni sensibili, fornire risposte fuorvianti, basarsi su conoscenza obsoleta o creare un falso senso di autorevolezza.
Ma gli strumenti poco agentici di solito rientrano in un modello di governance più leggero, perché il sistema soprattutto risponde e non agisce in modo indipendente.
Per gli strumenti poco agentici, le domande più importanti sono:
- A quali fonti di conoscenza può accedere l’agente?
- I permessi vengono ereditati correttamente da Microsoft 365, SharePoint o altri sistemi?
- Le risposte sono ancorate a contenuti approvati?
- L’utente sa quando verificare o fare escalation?
- Le conversazioni vengono loggate in modo appropriato?
- Chi possiede l’agente dopo il rilascio?
È governance, ma è soprattutto governance di contenuto, accesso, qualità e ownership.
Il rischio più pesante inizia quando l’agente acquisisce strumenti, autonomia, memoria, trigger o la capacità di influenzare sistemi aziendali.
A quel punto, il modello di governance deve includere control design, non soltanto content review.
Perché la governance IA esistente non basta
Molti programmi di AI governance sono stati progettati intorno a modelli e use case. Chiedono ai team di documentare il modello, classificare il caso d’uso, valutare l’impatto privacy, testare il bias e approvare il deployment.
È un buon inizio. Ma gli agenti introducono rischi che non sono completamente coperti da una governance model-centric.
1. Gli agenti hanno permessi
I modelli generano output. Gli agenti spesso hanno permessi.
Possono accedere a file, interrogare database, chiamare API, inviare e-mail, creare record o invocare workflow. Questo significa che la agent governance deve prendere in prestito elementi dall’identity and access management.
La domanda chiave diventa:
Cosa è autorizzato a fare questo agente, in quali condizioni, e chi ha approvato quei permessi?
2. Gli agenti hanno strumenti
Gli strumenti creano una nuova superficie di attacco. Un’istruzione malevola nascosta in un documento, in una e-mail, in una pagina web, in un ticket o in una fonte di conoscenza recuperata può tentare di manipolare l’agente affinché usi i suoi strumenti nel modo sbagliato.
Per gli agenti, la prompt injection non riguarda solo l’influenza sul testo. Può riguardare l’influenza sull’azione.
3. Gli agenti hanno comportamento a runtime
Una valutazione del modello prima del lancio non basta. Gli agenti possono comportarsi in modo diverso a seconda di trigger, contesto, risposte degli strumenti, dati recuperati, istruzioni dell’utente e stato del workflow.
La governance deve quindi continuare a runtime tramite logging, monitoring, alert e incident response.
4. Gli agenti hanno bisogno di confini d’azione
Una risposta accettabile non è la stessa cosa di un’azione accettabile.
Per esempio, un agente può essere autorizzato a preparare una raccomandazione di rimborso ma non a emettere il rimborso. Può essere autorizzato a creare un ticket ma non a chiuderlo. Può riassumere un rischio contrattuale ma non inviare il contratto rivisto alla controparte.
Questi confini devono essere espliciti.
5. Gli agenti creano requisiti di evidenza
Quando qualcosa va storto, l’organizzazione deve poter ricostruire la sequenza:
- Che cosa ha attivato l’agente?
- Quali dati ha visto?
- Quale istruzione ha seguito?
- Quali strumenti ha chiamato?
- Quale decisione di policy è stata presa?
- Era richiesta approvazione umana?
- Chi ha approvato o respinto l’azione?
- Che cosa è cambiato nel sistema aziendale?
Se non si riesce a rispondere a queste domande, non si ha agent governance. Si ha agent hope.
Un modello pratico di governance per gli agenti IA
Un modello utile di governance per agenti dovrebbe includere almeno otto livelli di controllo.
1. Inventario degli agenti
Non si possono governare agenti che non si vedono.
Tracciare ogni agente con:
- Owner
- Scopo
- Gruppo utenti
- Modello o piattaforma
- Fonti dati
- Strumenti e connettori
- Livello di autonomia
- Livello di rischio
- Stato di approvazione
- Data di review
- Responsabile del monitoring
2. Tiering del rischio agentico
Classificare gli agenti in base al comportamento, non al label del vendor.
Dimensioni utili:
- Può accedere a dati sensibili?
- Può chiamare strumenti?
- Può scrivere in sistemi?
- Può agire senza un prompt utente?
- Può attivare comunicazione esterna?
- Può prendere o influenzare decisioni ad alto impatto?
- Può delegare ad altri agenti?
3. Tool Permission Matrix
Ogni strumento dovrebbe avere una policy esplicita.
Per ogni strumento, definire:
- Consentito o bloccato
- Solo lettura o con capacità di scrittura
- Approvazione richiesta o meno
- Soglie massime
- Classi di dati consentite
- Gruppi utente consentiti
- Requisiti di logging
Uno strumento di rimborso, per esempio, potrebbe consentire raccomandazioni in bozza senza approvazione, richiedere approvazione sotto una certa soglia e bloccare rimborsi autonomi sopra quella soglia.
4. Punti di approvazione umana
Human-in-the-loop non deve essere uno slogan. Deve essere progettato nel workflow.
L’approvazione dovrebbe essere richiesta per:
- Impegni legali
- Transazioni finanziarie
- Decisioni HR
- Azioni che impattano il cliente
- Cambiamenti sensibili lato sicurezza
- Azioni irreversibili
- Decisioni automatizzate ad alto volume
L’approvazione deve diventare parte dell’audit trail.
5. Test su prompt injection e tool misuse
Gli agenti devono essere testati contro scenari avversariali prima della produzione.
Testare:
- Documenti recuperati malevoli
- Istruzioni in conflitto
- Tentativi di esfiltrare dati
- Tentativi di bypassare l’approvazione
- Tentativi di usare strumenti non autorizzati
- Tentativi di sovrascrivere le istruzioni di sistema
- Tentativi di attivare azioni da input non affidabili
6. Runtime audit logging
I log devono catturare più della risposta finale.
Al minimo:
- Trigger utente o evento
- ID agente
- Versione del prompt o delle istruzioni
- Versione del modello
- Contesto recuperato
- Chiamate agli strumenti
- Input e output degli strumenti
- Decisioni di policy
- Approvazioni umane
- Azione finale
- Trace ID
7. Monitoring e kill switch
Gli agenti hanno bisogno di controlli operativi.
Monitorare:
- Uso inatteso di strumenti
- Accesso insolito ai dati
- Errori ripetuti
- Picchi di escalation
- Anomalie di costo
- Comportamenti in loop
- Azioni fuori dai pattern normali
Un agente ad alto rischio dovrebbe avere una chiara procedura di pausa, revoca o kill switch.
8. Lifecycle review
Gli agenti evolvono. I loro strumenti, prompt, fonti dati, modelli, utenti e contesti di business cambiano.
Fare review degli agenti quando:
- Viene aggiunto un nuovo strumento
- Viene connessa una nuova fonte dati
- Aumenta l’autonomia
- Cambia il modello
- L’agente viene pubblicato in un nuovo canale
- Cambia il processo di business
- Si verifica un incidente
La lezione di Microsoft Copilot Studio
L’approccio di Microsoft è utile perché mostra il pattern enterprise emergente. Copilot Studio mette insieme creazione low-code di agenti, grounding su dati di business, strumenti, flow, API, canali di pubblicazione, capacità di management, analytics e feature di governance.
Ma mostra anche perché le organizzazioni hanno bisogno di un proprio linguaggio del rischio agentico.
Un semplice agente dichiarativo o prompt-response può essere un’estensione gestibile del knowledge management. Un agente Copilot Studio autonomo collegato a workflow aziendali è più vicino a un attore di processo digitale. Un sistema multi-agente che coordina strumenti e reparti è più vicino a un sistema operativo distribuito.
Questi sistemi non dovrebbero passare attraverso la stessa checklist di approvazione.
La domanda di rischio non è:
È stato costruito con Copilot Studio, Azure AI Foundry, LangGraph, OpenAI, CrewAI o un altro framework?
La domanda migliore è:
Quale grado di agency ha questo sistema, e quali controlli corrispondono a quel grado di agency?
Questo framing aiuta anche a evitare blind spot specifici del vendor. Una piattaforma low-code può offrire guardrail utili, controlli admin e integrazione con strumenti di governance enterprise. Tutto questo è prezioso. Ma l’organizzazione deve comunque decidere quali azioni sono accettabili, quali approvazioni sono richieste, quali evidenze vanno conservate e chi possiede l’agente dopo il deployment.
Una semplice regola pratica
Più un sistema IA può agire, più la governance deve spostarsi dalla documentazione al controllo.
Usare questa regola:
- Se risponde soltanto, governare contenuto, accesso e accuratezza.
- Se raccomanda, governare decision support e revisione umana.
- Se usa strumenti, governare permessi e tool-call policy.
- Se agisce autonomamente, governare trigger, approvazioni, monitoring e incident response.
- Se coordina altri agenti, governare identità, delega e tracciabilità end-to-end.
Questa è la base di AI Agent Risk.
Cosa fare adesso
Per le organizzazioni che iniziano ora, i primi passi sono pratici:
- Creare un inventario di tutti gli agenti e sistemi agent-like.
- Classificarli per livello di agency, non per nome del prodotto.
- Identificare quali agenti possono accedere a dati, chiamare strumenti o attivare azioni.
- Definire una tool permission matrix per ogni agente che usa strumenti.
- Richiedere approvazione umana per azioni sensibili o irreversibili.
- Loggare le azioni degli agenti in modo da supportare audit e incident response.
- Testare gli agenti contro prompt injection, data leakage e approval bypass.
- Riesaminare gli agenti ogni volta che autonomia, strumenti o accesso ai dati si espandono.
Il futuro della governance dell’IA non riguarderà solo i modelli. Riguarderà sistemi che percepiscono, decidono e agiscono dentro i processi aziendali.
Per questo gli agenti hanno bisogno di un nuovo modello di governance.