La tassonomia dei rischi degli agenti IA: 12 rischi che ogni azienda dovrebbe monitorare

19 aprile 2026 · 11 min di lettura

Gli agenti IA hanno bisogno di una tassonomia dei rischi per un motivo semplice:
non generano solo testo. Possono usare strumenti, accedere a dati, ricordare
contesto, chiamare API, delegare lavoro e attivare processi aziendali.

La domanda di governance passa quindi da:

L'output del modello e accettabile?

A:

Che cosa era autorizzato a fare l'agente, che cosa ha fatto davvero, quale
controllo ha fallito, chi ha approvato il rischio, e possiamo provarlo?

Questo articolo parte da una tassonomia pratica di 12 rischi. Poi amplia la
lista in una visione enterprise piu completa, organizzata per controllo degli
accessi, uso improprio degli strumenti, governance, privacy, qualita dell'output,
comportamento degli agenti, affidabilita e osservabilita.

La cosa cruciale e la disciplina delle fonti. Alcuni rischi derivano
direttamente da framework, leggi, regolamenti o standard riconosciuti. Altri sono
indicatori tratti da ricerca di sicurezza, letteratura sulla sicurezza dell'IA o
pattern di incidenti. Sono utili, ma non devono essere presentati come obblighi
legali se una legge, un regolamento o uno standard non lo dice davvero.

La versione breve

Ogni azienda che distribuisce agenti IA dovrebbe monitorare questi 12 rischi:

Questa lista e volutamente pratica. E la checklist che business owner, security
lead, team compliance e architetti IA possono usare prima della produzione.

Ma la tassonomia enterprise completa e piu ampia.

La tassonomia enterprise piu ampia

Una tassonomia piu completa raggruppa i rischi dell'IA agentica in sette domini.

Questa struttura si mappa meglio sul modo in cui le aziende governano davvero i
sistemi. I team security riconoscono access control e tool misuse. I team privacy
riconoscono data exposure e retention. I team compliance riconoscono
accountability ed evidenze. I team engineering riconoscono affidabilita e
osservabilita.

La tassonomia non e utile perche crea caselle perfette. E utile perche permette
ai team di fare la stessa domanda operativa:

Quale controllo aziendale fallisce se questo agente si comporta male?

Fonti di riferimento

La tassonomia seguente si basa su queste fonti:

• OWASP Agentic AI - Threats and Mitigations, Version 1.1, dicembre 2025. E la fonte diretta piu forte per minacce specifiche degli agenti come memory poisoning, tool misuse, goal manipulation, untraceability, identity compromise, rischi multi-agente e human manipulation. La guida attuale elenca T1-T17; sintesi piu vecchie possono citare T1-T15.
• OWASP Top 10 for Large Language Model Applications 2025, in particolare Prompt Injection, Sensitive Information Disclosure, Supply Chain Vulnerabilities, Excessive Agency, Overreliance e Unbounded Consumption.
• NIST AI Risk Management Framework 1.0, che struttura la governance del rischio IA attraverso Govern, Map, Measure e Manage.
• NIST AI RMF Generative AI Profile, NIST AI 600-1, che nomina rischi come confabulation, harmful bias, data privacy, information integrity, human-AI configuration e integrazione nella value chain.
• MITRE ATLAS, knowledge base di tattiche e tecniche avversarie contro sistemi abilitati dall'IA.
• EU AI Act, Regulation (EU) 2024/1689, in particolare requisiti per sistemi high-risk: risk management, data governance, documentazione tecnica, logging, trasparenza, human oversight, accuratezza, robustezza, cybersecurity, post-market monitoring e obblighi dei deployer.
• GDPR, Regulation (EU) 2016/679, in particolare articoli 5, 32, 33 e 35 quando gli agenti trattano dati personali.
• ISO/IEC 42001:2023, standard di AI management system, utile per governance, responsabilita, policy, risk management e miglioramento continuo.
• NIST Cybersecurity Framework 2.0, soprattutto risultati Govern e Protect per identita, accesso, supply chain, monitoraggio e risk management.

Quando questo articolo cita temi frontier come self-replication, resistenza allo
shutdown o acquisizione autonoma di risorse, trattali come indicatori di rischio
da ricerca sulla sicurezza dell'IA e valutazioni di sistemi avanzati, salvo che
il tuo sistema concreto abbia davvero quelle capacita.

1. Rischio di autonomia

Il rischio di autonomia e il rischio che un agente agisca senza sufficiente
supervisione umana rispetto al livello di impatto.

Questa e la differenza fondamentale tra un assistente IA e un agente IA. Un
chatbot puo dare una risposta sbagliata. Un agente di workflow autonomo puo dare
una risposta sbagliata e poi agire su quella risposta.

Da monitorare:

• L'agente puo agire da trigger o eventi in background?
• Puo completare task multi-step senza approvazione step-by-step?
• Puo influenzare clienti, dipendenti, dati finanziari, contratti,
  infrastruttura, sicurezza o processi regolati?
• Un umano puo interrompere, mettere in pausa, sovrascrivere o invertire l'azione?

Fonti:

• L'EU AI Act richiede human oversight per sistemi IA high-risk all'articolo 14.
• Il NIST AI RMF richiede di governare, mappare, misurare e gestire i rischi IA nel contesto.
• OWASP Agentic AI discute autonomia, pianificazione, misalignment e overload
  del human-in-the-loop come pattern di minaccia agentici.

2. Rischio degli strumenti

Il rischio degli strumenti e il rischio che un agente usi male strumenti interni
o esterni.

Gli strumenti includono API, database, browser, email, esecuzione di codice,
azioni CRM, workflow automation, ticketing, file store, sistemi di pagamento e
strumenti di sicurezza.

Da monitorare:

• Quali strumenti puo chiamare l'agente?
• Le chiamate sono read-only o write-capable?
• Il modello puo scegliere i parametri degli strumenti?
• L'output di uno strumento puo diventare nuovo contesto di istruzione?
• Gli strumenti ad alto impatto sono protetti da policy e approvazione umana?

Fonti:

• OWASP Agentic AI include direttamente tool misuse, code execution attacks e
  insecure inter-agent protocol abuse.
• OWASP LLM Top 10 include Excessive Agency e Insecure Output Handling.
• NIST CSF 2.0 fornisce il linguaggio dei controlli per accesso, protezione,
  detection, response e recovery.

3. Rischio di permessi

Il rischio di permessi e il rischio che l'agente possa accedere o fare piu di
quanto dovrebbe.

Gli agenti spesso usano permessi ereditati dall'utente, scope OAuth delegati,
service account, identita di connettori o permessi di piattaforma. Questo crea
un classico rischio di access control in una forma nuova.

Da monitorare:

• L'agente usa un'identita nominativa?
• Ha accesso least-privilege?
• Usa credenziali condivise o service account ampi?
• Puo eseguire azioni che l'utente richiedente non potrebbe eseguire direttamente?
• Puo attraversare tenant, dipartimenti, ambienti o trust boundary?

Minacce specifiche includono privilege escalation, credential theft e confused deputy.

Fonti:

• OWASP Agentic AI copre identity compromise, spoofing, confused deputy e rischi di autorizzazione.
• NIST CSF PR.AA copre identity management, authentication e access control.
• GDPR articolo 32 conta quando permessi eccessivi espongono dati personali.

4. Rischio di prompt injection

Il rischio di prompt injection e il rischio che l'agente segua istruzioni
malevole, nascoste, contraddittorie o non fidate.

Per gli agenti, la prompt injection e piu pericolosa di una risposta sbagliata
perche l'agente puo trasformare l'istruzione malevola in un'azione.

Da monitorare:

• L'agente legge email, pagine web, ticket, PDF, documenti o chat non fidati?
• I documenti recuperati sono mescolati allo stesso contesto delle istruzioni di sistema?
• Un utente, cliente, fornitore o attaccante puo influenzare gli argomenti degli strumenti?
• Le chiamate agli strumenti sono vincolate da policy esterne al modello?

Fonti:

• OWASP LLM Top 10 lista Prompt Injection come rischio centrale delle applicazioni LLM.
• OWASP Agentic AI estende il tema a tool misuse, goal manipulation e agent-communication poisoning.
• Molti avvisi sulla prompt injection vengono da ricerca security e casi sul campo:
  trattali come evidenza di rischio, non come obbligo legale autonomo.

5. Rischio di memoria

Il rischio di memoria e il rischio che un agente memorizzi, esponga, avveleni o
riutilizzi il contesto in modo inappropriato.

La memoria rende gli agenti piu utili, ma crea anche uno strato persistente che
attaccanti e incidenti possono sfruttare.

Da monitorare:

• Che cosa ricorda l'agente?
• Chi puo scrivere in memoria?
• Chi puo leggere la memoria?
• La memoria puo influenzare futuri tool call?
• La memoria viene cancellata quando lo scopo originale scade?
• Le informazioni sensibili sono filtrate prima dello storage?

Minacce specifiche includono memory poisoning e leakage a lungo termine di
contesto personale, confidenziale o privilegiato.

Fonti:

• OWASP Agentic AI include Memory Poisoning come minaccia nominata.
• NIST AI 600-1 copre rischi di data privacy e information integrity.
• GDPR articoli 5 e 32 si applicano quando dati personali sono archiviati,
  conservati o riutilizzati.

6. Rischio di esposizione dati

Il rischio di esposizione dati e il rischio che l'agente recuperi, riveli,
riassuma, trasformi o trasmetta dati sensibili in modo non sicuro.

L'agente potrebbe non esporre direttamente una tabella di database. Potrebbe
riassumere parti sensibili in una chat, una bozza email, un ticket support, un
file esportato o un payload API.

Da monitorare:

• A quali fonti dati puo accedere l'agente?
• Quali dati puo combinare?
• Puo spostare dati verso canali meno protetti?
• Puo inviare dati a tool di terze parti o utenti esterni?
• Sono in scope dati personali, credenziali, contratti, source code, dati HR,
  dati finanziari o log security?

Fonti:

• OWASP LLM Top 10 include Sensitive Information Disclosure.
• OWASP Agentic AI include scenari di esfiltrazione tramite strumenti, rogue agents e multi-agent systems.
• GDPR articoli 5, 32 e 33 si applicano dove dati personali sono trattati o violati.
• EU AI Act articolo 10 si applica alla data governance per sistemi IA high-risk.

7. Rischio di pianificazione

Il rischio di pianificazione e il rischio che un agente crei un piano multi-step
difettoso che sembra ragionevole localmente ma fallisce globalmente.

Non e solo hallucination. Un piano puo contenere step singolarmente plausibili e
comunque violare policy, mancare una dipendenza, creare costi, sovraccaricare un
team o attivare il processo sbagliato.

Da monitorare:

• L'agente puo decomporre obiettivi in sotto-obiettivi?
• Puo rivedere i piani sulla base di output intermedi?
• Ottimizza il completamento del task sopra policy, safety, budget o vincoli di business?
• I piani sono rivisti prima di esecuzioni ad alto impatto?

Fonti:

• OWASP Agentic AI include intent breaking, goal manipulation e comportamenti misaligned o deceptive.
• NIST AI 600-1 copre confabulation, information integrity e human-AI configuration.
• EU AI Act articoli 9, 13 e 14 contano per sistemi high-risk perche risk
  management, trasparenza e human oversight devono essere progettati nel sistema.

8. Rischio di delega

Il rischio di delega e il rischio che l'agente passi lavoro ad altri agenti,
task, strumenti o workflow senza controlli chiari.

I sistemi multi-agente rendono piu difficile l'accountability. Un agente
coordinatore puo creare un task, un agente specialista chiamare uno strumento,
un altro riassumere il risultato e un quarto comunicare con l'utente.

Da monitorare:

• Quali agenti possono comunicare?
• Le identita degli agenti sono autenticate?
• I messaggi sono firmati, scoped, loggati e filtrati?
• Un agente puo portare un altro agente oltre la sua autorita?
• Chi possiede il workflow end-to-end?

Fonti:

• OWASP Agentic AI include agent communication poisoning, rogue agents in
  multi-agent systems, human attacks on multi-agent systems e insecure inter-agent protocol abuse.
• EU AI Act articolo 25 e rilevante per responsabilita lungo la value chain IA.
• ISO/IEC 42001 e rilevante per responsabilita di management system e lifecycle controls.

9. Rischio di osservabilita

Il rischio di osservabilita e il rischio che l'organizzazione non possa
ricostruire cosa e successo.

Per gli agenti, i log dell'output finale non bastano. Serve la traccia operativa:
trigger, utente, versione delle istruzioni, retrieval, tool call, argomenti,
decisioni di policy, approvazioni, output, azioni, errori, retry e handoff.

Da monitorare:

• Gli incident responder possono ricostruire l'intera esecuzione?
• Tool call e argomenti sono loggati?
• Le approvazioni sono registrate?
• I dinieghi di policy sono registrati?
• Il comportamento anomalo puo essere rilevato?
• Esiste un kill switch o una procedura di pausa?

Fonti:

• OWASP Agentic AI include Repudiation and Untraceability.
• EU AI Act include logging, documentazione tecnica, monitoring, post-market
  monitoring e obblighi di azione correttiva per sistemi high-risk.
• NIST AI RMF e NIST CSF supportano measurement, monitoring, response e recovery.

10. Rischio di accountability

Il rischio di accountability e il rischio che nessuno possieda chiaramente
decisioni, approvazioni, operation, incident o remediation.

Questo rischio e facile da perdere perche un agente puo stare tra team diversi.
Product possiede il use case. IT possiede il connettore. Security possiede
l'access control. Legal possiede la policy. Un vendor possiede la piattaforma.
Il business possiede il risultato.

Da monitorare:

• Chi e il business owner?
• Chi e il technical owner?
• Chi approva l'uso in produzione?
• Chi approva categorie di azioni ad alto impatto?
• Chi gestisce gli incident?
• Chi accetta il rischio residuo?

Fonti:

• EU AI Act articoli 16-27 definiscono responsabilita tra provider, importer,
  distributor, deployer e altri ruoli della value chain.
• ISO/IEC 42001 richiede accountability di management system e miglioramento continuo.
• La funzione Govern del NIST AI RMF enfatizza ruoli, policy, processi e oversight.

11. Rischio di conformita

Il rischio di conformita e il rischio che l'agente violi requisiti legali,
regolatori, contrattuali, settoriali o di policy interna.

Non e solo una questione di AI Act. A seconda del use case, il rischio degli
agenti puo toccare privacy, diritto del lavoro, servizi finanziari, sanita,
consumer protection, cybersecurity, contratti, records retention, regolazione
settoriale e policy interne.

Da monitorare:

• Il use case e high-risk o regolato?
• L'agente tratta dati personali?
• Influenza diritti, accesso, occupazione, credito, educazione, sanita, safety,
  security o risultati legali?
• Esiste documentazione per risk management, test, monitoring, human oversight e incident response?
• Gli obblighi di trasparenza sono soddisfatti?

Fonti:

• EU AI Act articoli 9-15, 17-20, 26-27 e 50 sono particolarmente rilevanti per
  high-risk e transparency obligations.
• GDPR articoli 5, 32, 33 e 35 contano quando sono coinvolti dati personali.
• ISO/IEC 42001 e NIST AI RMF forniscono strutture di governance ed evidenza.

12. Rischio di processo aziendale

Il rischio di processo aziendale e il rischio che l'agente causi danno
operativo diretto.

Qui la governance degli agenti diventa reale. Una risposta sbagliata e un
problema. Una risposta sbagliata che chiude un caso cliente, approva un rimborso,
modifica un record dipendente, cambia infrastruttura, scrive a un regolatore o
aggiorna un workflow legale e un altro problema.

Da monitorare:

• Quale processo puo influenzare l'agente?
• L'azione puo essere invertita?
• L'agente puo operare su scala?
• Puo agire fuori orario?
• Puo influenzare umani che prendono decisioni consequenziali?
• Il processo ha controlli esistenti che l'agente aggira?

Fonti:

• OWASP Agentic AI include human manipulation, overwhelming the human in the loop,
  misaligned behavior e tool misuse.
• NIST AI 600-1 copre human-AI configuration, confabulation, harmful bias e information integrity.
• EU AI Act articoli 14 e 26 contano quando l'agente fa parte di un deployment
  high-risk e si applicano human oversight o obblighi del deployer.

Minacce specifiche da includere nel registro

I 12 rischi sono il linguaggio enterprise semplice. Un risk register dovrebbe
anche tracciare la classe di minaccia piu specifica.

Cosa dovrebbero monitorare le aziende

La mossa pratica e tracciare entrambi:

1. La classe di minaccia.
2. Il controllo aziendale che fallisce.

Per esempio:

• "Prompt injection" e una classe di minaccia.
• "L'agente customer support puo emettere rimborsi senza validazione di policy" e
  un controllo aziendale fallito.

Questa seconda frase rende la tassonomia operativa.

Come minimo, ogni voce del risk register dovrebbe includere:

• Nome e owner dell'agente
• Processo aziendale
• Livello dell'agente e livello di autonomia
• Strumenti, fonti dati, memory store e agenti delegati
• Dominio di rischio e classe di minaccia specifica
• Fonte di riferimento
• Scenario di minaccia
• Controllo mancante o fallito
• Punteggi di probabilita, impatto, autonomia, sensibilita dati, criticita tool e osservabilita
• Punti di approvazione umana richiesti
• Posizione delle evidenze
• Owner del rischio residuo
• Trigger di review e prossima data di review

Osservare gli indicatori di sistema

La maggior parte degli agenti enterprise oggi non ha autonomia frontier. Tuttavia
alcuni indicatori di sistema vanno monitorati perche mostrano quando un normale
workflow agent puo spostarsi in una categoria piu pericolosa.

Osserva:

• Perseguimento non intenzionale di obiettivi
• Privilege escalation non autorizzata
• Acquisizione autonoma di risorse
• Tentativi di preservare accesso o resistere allo shutdown
• Self-replication o creazione non autorizzata di agenti
• Loop di misinformation multi-agente
• Retry storm, tool call ripetute, spike di costo o esaurimento quota
• Nuovi o inattesi canali di data exfiltration

Questi indicatori non derivano tutti da un unico quadro legale. Sono meglio
compresi come segnali di rischio da ricerca sulla sicurezza dell'IA, adversarial
testing e valutazioni di agenti avanzati. Se compaiono in un sistema enterprise
reale, dovrebbero attivare una review immediata.

La regola pratica

Non fermarti a "questo agente ha rischio di autonomia" o "questo agente ha
rischio di prompt injection".

Scrivi la versione operativa:

Questo agente puo leggere email dei fornitori, estrarre modifiche contrattuali
e instradare approvazioni. Una email malevola di un fornitore potrebbe
iniettare istruzioni che inducono l'agente a classificare male una modifica e
bypassare la review legale.

Ora puoi governarlo.

Puoi assegnare un owner. Puoi richiedere un controllo. Puoi testare il fallimento.
Puoi loggare l'evidenza. Puoi decidere se il rischio residuo e accettabile.

Questo e lo scopo di una tassonomia dei rischi degli agenti.

Asset pratico

Il framework GitHub companion include:

• AI Agent Risk Taxonomy
• Risk Scoring Model
• Risk Register Template CSV

Usa la tassonomia per dare un nome al rischio. Usa il registro per assegnare
ownership. Usa il modello di scoring per decidere quali controlli devono esistere
prima della produzione.