Come valutare il rischio di un agente IA prima della produzione
10 maggio 2026 · 10 min di lettura
La valutazione del rischio di un agente IA dovrebbe avvenire prima della produzione, non dopo il primo incidente, la prima richiesta di audit o una escalation confusa.
Non deve essere un processo pesante. Se diventa troppo pesante, i team lo aggireranno. La versione utile è una raccolta strutturata di informazioni che aiuta prodotto, compliance, sicurezza, architettura e business owner a rispondere a una domanda:
Che cosa potrebbe fare questo agente, chi potrebbe essere impattato e quali controlli devono essere presenti prima che possa operare?
Questo articolo propone un modello pratico per valutare gli agenti IA in azienda, nel momento in cui esistono un caso d’uso reale, una bozza di architettura e un percorso verso la produzione, ma non ancora l’approvazione finale.
Versione breve
Prima della produzione, valuta sette dimensioni:
| Dimensione | Cosa determinare |
|---|---|
| Intake del caso d’uso | Scopo, utenti, owner, processo e contesto di deploy |
| Autonomia | Se l’agente risponde, raccomanda, agisce o opera tramite trigger |
| Accesso agli strumenti | Quali sistemi può chiamare e se le chiamate sono in sola lettura o in scrittura |
| Sensibilità dei dati | Quali dati personali, confidenziali, regolati o privilegiati può usare |
| Supervisione umana | Dove una persona rivede, approva, interrompe o annulla |
| Impatto business | Quale danno può verificarsi se l’agente sbaglia, viene manipolato, non è disponibile o è troppo sicuro |
| Livello finale di rischio | Se il rischio è basso, medio, alto o inaccettabile senza redesign |
L’output dovrebbe essere un livello di rischio sintetico, una checklist di controlli, owner nominati e prove riutilizzabili per revisioni di sicurezza, privacy, compliance e architettura.
Perché la valutazione degli agenti è diversa
Le revisioni IA tradizionali guardano spesso a modello, dataset, uso previsto, qualità dell’output, bias, spiegabilità e privacy. Sono ancora importanti.
Gli agenti aggiungono rischio operativo.
Un agente può:
- Chiamare strumenti o API.
- Recuperare documenti o record di database.
- Usare permessi delegati.
- Salvare memoria.
- Eseguire piani multi-step.
- Operare da trigger in background.
- Inviare messaggi, aggiornare record, aprire ticket, approvare step di workflow o avviare processi in customer service, HR, finanza, legale, sicurezza o infrastruttura.
Quindi la domanda non è solo "la risposta è accurata?" ma anche "che cosa può fare il sistema con quella risposta?"
Il modello deve valutare il comportamento, non l’etichetta. Un chatbot chiamato agente può essere a basso rischio. Un assistente di workflow con accesso agli strumenti può essere ad alto rischio anche se usa un modello noto.
Step 1: iniziare dall’intake del caso d’uso
L’intake definisce i confini. Senza confini, il resto della valutazione diventa astratto.
Raccogli:
- Nome dell’agente e business owner.
- Scopo previsto.
- Utenti principali.
- Clienti, dipendenti, fornitori o terze parti impattati.
- Processo business supportato.
- Canale di deploy: sito, Teams, Slack, portale interno, API o workflow in background.
- Trigger di produzione: prompt utente, creazione ticket, e-mail in arrivo, job schedulato, webhook o evento in coda.
- Ambito di lancio: pilota, produzione interna, customer-facing o enterprise-wide.
- Owner del supporto e degli incidenti.
Il punto critico è la responsabilità. Se l’agente non ha business owner, percorso di supporto e incident owner, non è pronto per la produzione.
Step 2: valutare l’autonomia
L’autonomia misura quanto l’agente può decidere e agire senza che una persona guidi ogni passaggio.
| Score | Livello di autonomia | Descrizione |
|---|---|---|
| 0 | Solo risposta | L’agente risponde a domande e non agisce |
| 1 | Raccomanda | L’agente suggerisce azioni, ma un umano le esegue |
| 2 | Agisce con approvazione | L’agente prepara o svolge azioni dopo approvazione esplicita |
| 3 | Agisce autonomamente | L’agente opera da trigger o completa step senza approvazione caso per caso |
Domande:
- Può operare senza un messaggio utente?
- Può completare più step prima di tornare a una persona?
- Può scegliere quale strumento chiamare?
- Può decidere quando un task è completo?
- Può ritentare, escalare, delegare o cambiare piano?
- Può influenzare record business, comunicazioni cliente, pagamenti, decisioni HR, contratti, controlli di sicurezza o configurazioni infrastrutturali?
Alta autonomia non è automaticamente inaccettabile. Richiede però confini più chiari, logging più forte, approvazioni per azioni ad alto impatto, monitoraggio e un modo rapido per fermare l’agente.
Step 3: valutare l’accesso agli strumenti
L’accesso agli strumenti rende il rischio concreto. Gli strumenti includono API, database, browser, e-mail, sistemi di ticketing, CRM, ERP, HR, workflow automation, esecuzione di codice, file store, pagamenti e strumenti di sicurezza.
| Score | Accesso agli strumenti | Descrizione |
|---|---|---|
| 0 | Nessuno strumento | L’agente genera solo risposte |
| 1 | Sola lettura | L’agente recupera dati ma non modifica sistemi |
| 2 | Scrittura limitata | L’agente crea bozze, ticket, note o record a basso impatto |
| 3 | Strumenti ad alto impatto | L’agente modifica stato cliente, finanza, HR, legale, sicurezza o infrastruttura |
Per ogni strumento, documenta nome, scopo business, lettura o scrittura, autenticazione, identità usata, scope, limiti, scelta degli argomenti da parte del modello, influenza degli output sugli step successivi e necessità di approvazione.
Qui si applica il least privilege. Se serve solo lo stato ordine, non dare permessi di rimborso. Se serve solo una bozza, non permettere l’invio. Se servono dati di test, non collegare dati di produzione.
Step 4: valutare la sensibilità dei dati
Gli agenti possono esporre dati direttamente o indirettamente, sintetizzandoli, trasformandoli, combinandoli o inviandoli altrove.
| Score | Livello dati | Descrizione |
|---|---|---|
| 0 | Pubblico | Solo informazioni pubbliche |
| 1 | Interno | Informazioni aziendali non pubbliche a bassa sensibilità |
| 2 | Confidenziale o personale | Dati cliente, dipendente, commerciali, contrattuali o operativi |
| 3 | Ristretto o regolato | Dati personali sensibili, credenziali, segreti, pagamenti, privilegio legale, record regolati o informazioni di sicurezza |
Chiedi:
- Quali fonti dati può usare l’agente?
- Può combinare dati da più sistemi?
- Può accedere a dati personali?
- Può vedere contratti confidenziali, file HR, finanza, codice sorgente, credenziali, log di sicurezza o materiale legale?
- Può spostare dati in canali meno protetti?
- Può memorizzare dati?
- Retention e cancellazione sono definite?
- Minimizzazione e limitazione dello scopo sono coperte?
Quando ci sono dati personali, collega la valutazione alla privacy review. In contesto europeo, il GDPR è rilevante per base giuridica, minimizzazione, sicurezza, gestione breach e DPIA quando richiesta.
Step 5: definire la supervisione umana
Supervisione umana non significa avere una persona genericamente vicina al processo. Deve essere abbastanza concreta da cambiare il risultato.
Per ogni azione significativa, definisci chi rivede, cosa vede, quale decisione può prendere, se può rifiutare, modificare, escalare o mettere in pausa, se l’approvazione viene loggata, cosa succede se il revisore non è disponibile e se una persona può fermare l’agente.
L’approvazione serve quando un’azione è difficile da annullare, cambia diritti o accessi, muove denaro, modifica stato HR, invia comunicazioni esterne, cambia record legali o contrattuali, modifica postura di sicurezza o impatta infrastruttura di produzione.
Supervisione debole:
Un umano è nel loop.
Supervisione utile:
Un supervisore support deve approvare rimborsi sopra CHF 100. La schermata mostra richiesta cliente, policy recuperata, importo proposto, ragione, ordine sorgente, flag di rischio e trace ID. Approvazione o rifiuto sono loggati prima della chiamata all’API di rimborso.
Questo livello di dettaglio regge in produzione.
Step 6: valutare l’impatto business
L’impatto business descrive cosa accade se l’agente fallisce.
| Score | Impatto | Descrizione |
|---|---|---|
| 0 | Minimo | Piccolo disagio o output facilmente correggibile |
| 1 | Basso | Rework interno, confusione limitata o piccolo costo operativo |
| 2 | Moderato | Impatto cliente, gap di evidenza compliance, perdita finanziaria, esposizione dati o interruzione processo |
| 3 | Severo | Danno legale, finanziario, sicurezza, diritti, regolatorio o reputazionale materiale |
Considera se l’agente sbaglia, è troppo sicuro, segue prompt injection, chiama lo strumento giusto con argomenti sbagliati, espone dati, salta approvazioni, agisce su larga scala, fallisce silenziosamente, non spiega l’accaduto o crea record che sistemi downstream considerano affidabili.
La scala conta. Una bozza sbagliata non è uguale a 10.000 e-mail cliente sbagliate. Una raccomandazione errata non è uguale a un trigger autonomo che si ripete ogni pochi minuti.
Step 7: assegnare il livello finale
Un approccio pratico è assegnare score da 0 a 3 ad autonomia, strumenti, dati e impatto, poi usare il punteggio più alto e le red flag.
| Livello | Profilo tipico | Postura di produzione |
|---|---|---|
| Basso | Solo risposte o raccomandazioni, bassa sensibilità, basso impatto | Review standard, owner assegnato, logging base |
| Medio | Strumenti in lettura, dati interni o confidenziali, impatto limitato | Review sicurezza/privacy, controlli accesso, monitoraggio, istruzioni utente |
| Alto | Strumenti in scrittura, alta autonomia, dati ristretti, impatto cliente o regolatorio | Review architettura, workflow di approvazione, audit log, test, piano incident, accettazione rischio |
| Inaccettabile senza redesign | Azioni irreversibili ad alto impatto, permessi eccessivi, nessun owner, nessun logging, nessuna supervisione reale o base legale incerta | Non lanciare prima del redesign |
La formula aiuta, ma non sostituisce il giudizio. Un agente con bassa autonomia e accesso payroll merita comunque attenzione. Un agente senza dati sensibili ma con permessi firewall non è basso rischio.
Checklist per il gate di produzione
Prima del lancio, richiedi evidenze per i controlli adeguati:
- Business owner e technical owner.
- Intake approvato.
- Voce di inventario.
- Matrice permessi strumenti.
- Classificazione dati e privacy review dove necessaria.
- Design della supervisione umana.
- Piano di logging e tracciabilità.
- Test di prompt injection e misuse per agenti con strumenti.
- Piano di monitoring e alerting.
- Incident owner e percorso di escalation.
- Data di review e trigger di rivalutazione.
Per agenti ad alto rischio servono anche review architetturale, accettazione esplicita del rischio, test dei workflow di approvazione, scenari red team, rollback o kill switch, change control per prompt, strumenti, fonti di retrieval e policy, e regole di retention delle evidenze.
Esempio: agente support per rimborsi
Un agente support può leggere storico ordini, riassumere messaggi cliente, verificare policy di rimborso e preparare rimborsi.
| Dimensione | Score | Razionale |
|---|---|---|
| Autonomia | 2 | Propone e prepara azioni, ma i rimborsi richiedono approvazione |
| Accesso strumenti | 3 | L’API di rimborso modifica record finanziari |
| Sensibilità dati | 2 | Dati cliente e storico ordini sono in scope |
| Impatto business | 2 | Rimborsi o rifiuti errati generano impatto cliente, finanziario e compliance |
Livello finale: Alto.
Controlli richiesti:
- Strumento rimborso limitato allo scope minimo.
- Soglia di importo.
- Approvazione umana sopra un importo definito.
- Blocco automatico di pattern anomali.
- Test di prompt injection con messaggi e allegati cliente.
- Audit log per richiesta, policy recuperata, decisione proposta, approvazione, tool call e risultato.
- Owner support e percorso incident chiari.
Lo scopo della valutazione non è bloccare sistemi utili, ma rendere visibili i controlli prima che il sistema tocchi clienti e denaro reali.
Esempio: assistente policy HR
Un assistente HR risponde a domande dei dipendenti da documenti approvati. Non ha strumenti di scrittura e non accede ai fascicoli personali.
| Dimensione | Score | Razionale |
|---|---|---|
| Autonomia | 0 | Risponde solo a domande |
| Accesso strumenti | 1 | Recupera contenuto policy approvato |
| Sensibilità dati | 1 | Usa policy interne, non fascicoli dipendenti |
| Impatto business | 1 | Risposte errate possono creare confusione, ma devono escalare a HR |
Livello finale: Basso o medio, secondo audience e temi.
Controlli richiesti: fonti approvate, owner per aggiornamento policy, link alle fonti, escalation per temi lavoro, legale, benefit o dati sensibili, e logging d’uso.
Base di riferimento
Questo modello si allinea a NIST AI Risk Management Framework 1.0, NIST AI RMF Generative AI Profile, NIST AI 600-1, OWASP Top 10 for LLM Applications 2025, OWASP Agentic AI - Threats and Mitigations, EU AI Act, Regulation (EU) 2024/1689 e GDPR, Regulation (EU) 2016/679.
La lezione pratica è semplice: la valutazione di un agente non deve essere documentazione di modello con un nuovo titolo. Deve collegare le capacità reali dell’agente all’impatto business e ai controlli di produzione.
Regola pratica
Se un agente può solo rispondere, valuta qualità e accesso ai dati.
Se può agire, valuta il percorso dell’azione.
Se può agire senza aspettare una persona, valuta il modello operativo.
E se nessuno può spiegare chi possiede l’agente, cosa può fare, cosa ha fatto e come fermarlo, non è pronto per la produzione.