IA agentica vs IA generativa: cosa cambia per la governance

In sintesi

• L’IA generativa produce un esito che voi rileggete. L’IA agentica produce un atto già compiuto nel momento in cui lo osservate. Da questo solo spostamento discende tutto il resto.
• Gli agenti non costituiscono una categoria giuridica nuova: l’articolo 3, paragrafo 1 del regolamento europeo già contempla sistemi dotati di livelli di autonomia variabili.
• Il confine tra IA agentica e IA generativa è una gradazione, non un interruttore. Va governato per grado di agentività: accesso agli strumenti, memoria, pianificazione autonoma, effetto non rivisto, passaggio di consegne tra agenti.
• Il registro dei rischi non cambia di intensità, cambia di categoria. L’iniezione di prompt cessa di essere un problema di testo e diventa un problema di transazione non autorizzata.
• Cambia anche il fascicolo probatorio: i log dei prompt non bastano più, perché il revisore chiederà i log delle azioni, l’identità con cui l’agente ha operato e la prova che il meccanismo di arresto funzioni davvero.

IA agentica vs IA generativa: la differenza che sposta gli obblighi

Se chiedete a un fornitore di spiegare l’IA agentica, otterrete ovunque la medesima frase: l’IA generativa crea contenuti, l’IA agentica compie azioni. La formula è corretta e risulta del tutto inservibile a chi deve autorizzare una messa in produzione. La versione utile è più stretta. L’IA generativa depone una bozza davanti a una persona, ed è quella persona a stabilire se diventerà reale. L’IA agentica chiude proprio quell’intervallo: pianifica una sequenza, richiama uno strumento, scrive in un sistema gestionale e infine rendiconta. Esito ed effetto arrivano insieme. In quell’intervallo si collocava però tutto ciò su cui la governance ha silenziosamente contato: il passaggio di revisione, la traccia di approvazione, la possibilità di intercettare una risposta errata prima che costi qualcosa. Eliminato l’intervallo, i controlli non falliscono in modo rumoroso. Semplicemente smettono di trovarsi dove si trova il rischio. Il legislatore europeo non lo ha ignorato. L’articolo 3, paragrafo 1 definisce un sistema di IA come un sistema automatizzato che opera con livelli di autonomia variabili e che deduce output capaci di influenzare ambienti fisici o virtuali. L’autonomia è già dentro la definizione. Un agente non costituisce dunque un oggetto giuridico inedito, ma il medesimo oggetto con il regolatore spinto più avanti, ragione per cui gli obblighi non mutano identità bensì peso.

La pila di capacità da cui nasce il divario

L’Agentic Security Initiative di OWASP descrive un agente attraverso quattro capacità: pianificazione e ragionamento, memoria e persistenza dello stato, uso di strumenti e azione. Ciascuna rappresenta una superficie di governance non meno che una superficie tecnica.

• La pianificazione comporta che il sistema abbia scelto passaggi che non avevate elencato, sicché una valutazione dei rischi costruita su un elenco esaustivo di comportamenti attesi non regge più.
• La memoria comporta che lo stato persista tra un’esecuzione e l’altra, per cui un input contaminato può modificare il comportamento molto dopo la chiusura della sessione che lo ha introdotto.
• L’uso di strumenti comporta che il raggio d’azione coincida con quanto consentono le credenziali, non con quanto consente la casella di testo.
• L’azione comporta che l’effetto sia reale prima di essere rivisto.

Un modello di IA generativa possiede la prima capacità in forma debole e nessuna delle altre tre. In questo consiste per intero il divario, e ogni sezione che segue non ne è che una conseguenza.

Il test delle cinque domande: il vostro sistema ha già varcato il confine?

Sono rare le squadre che decidono di costruire un agente. Aggiungono una chiamata a strumento a un assistente conversazionale, poi un ciclo di ripetizione, poi uno schedulatore, e uno sprint più tardi la cosa scrive in produzione. Il passaggio raramente costituisce una decisione, il che spiega perché raramente attivi una revisione di governance. Sottoponete ogni sistema di cui rispondete a queste cinque domande.

1. Può richiamare uno strumento, un’API o una base dati senza che una persona approvi quella specifica chiamata? In tal caso il vostro punto di controllo si è spostato dall’output all’autorizzazione.
2. Conserva uno stato tra passaggi o sessioni capace di modificarne il comportamento successivo? In tal caso possedete un bene corruttibile, che richiede controlli di integrità e non soltanto controlli di accesso.
3. Ha scomposto l’obiettivo in passaggi che non avevate definito? In tal caso la valutazione dei rischi non può più procedere comportamento per comportamento, ma deve procedere confine per confine.
4. Il suo output può produrre effetti senza che qualcuno lo riveda prima? In tal caso la sorveglianza diventa un problema di progettazione e non più di processo.
5. Trasferisce lavoro a un altro agente, oppure ne riceve? In tal caso state governando un sistema, e i guasti interessanti si annidano nell’interazione anziché in un singolo componente.

Un sì non rappresenta un allarme. Cinque sì descrivono un sistema diverso da quello che la vostra documentazione raffigura. L’impostazione più solida proviene dal Center for Long-Term Cybersecurity dell’università di Berkeley, il cui Agentic AI Risk-Management Standards Profile sostiene che la governance debba crescere con il grado di agentività, anziché trattare l’autonomia come attributo binario. Registrate il punteggio delle cinque risposte nell’inventario e lasciate che sia esso a determinare quanto pesanti debbano risultare i controlli. Un campo che riporti soltanto « autonomo: sì o no » non sopravvive all’incontro con un portafoglio reale. È anche il punto in cui la shadow AI smette di essere un problema di scoperta per diventare un problema di classificazione. Una squadra che diciotto mesi fa ha censito il proprio strumento come assistente di scrittura non ne rifarà la scheda soltanto perché qualcuno ha attivato le chiamate a funzione.

Che cosa cambia nella classificazione

È qui che la distinzione produce la sua prima conseguenza giuridica concreta, e lo fa su due assi contemporaneamente. L’analisi di The Future Society dedicata al modo in cui il regolamento raggiunge gli agenti, Ahead of the Curve (Oueslati e Staes-Polet, 2025), li espone entrambi. Il capo V raggiunge il modello per finalità generali che sta sotto l’agente: i fornitori di modelli con rischio sistemico devono valutare e mitigare i rischi derivanti dall’integrazione di tali modelli in sistemi agentici. Il capo III raggiunge invece il sistema agentico in quanto tale, attraverso la classificazione ad alto rischio. Ne discendono tre conseguenze, e ciascuna coglie qualcuno di sorpresa. In primo luogo, la qualificazione ad alto rischio di un agente polivalente resta effettivamente incerta. L’allegato III è stato redatto prima che i rischi agentici fossero ben compresi, e un agente che può essere orientato verso molti compiti rischia di rientrare nell’ambito per difetto, salvo esclusione deliberata degli usi ad alto rischio da parte del fornitore. Deliberata significa documentata e tecnicamente imposta, non una riga in una politica d’uso. Chi affronta il punto parte dal metodo di classificazione dei sistemi ad alto rischio e lo applica all’uso più ampio che l’agente può raggiungere, non a quello previsto. In secondo luogo, l’impalcatura che aggiungete può mutare la vostra qualifica. Avvolgere un modello di IA per finalità generali in un livello di recupero documentale, in un framework di orchestrazione e in un insieme di strumenti può configurare una modifica sostanziale, che trasferisce obblighi da fornitore su una squadra che aveva preventivato obblighi da deployer. Il conto della conformità risulta allora sensibilmente diverso, e di norma ricade su un gruppo di ingegneria che il capo V non lo ha mai aperto. In terzo luogo, la classificazione va rifatta. Una capacità agentica aggiunta a un sistema generativo esistente non è un avanzamento di versione: ai fini della classificazione si tratta di un sistema nuovo, e il lavoro di conformità riparte dalla valutazione dei rischi anziché riprendere dall’ultimo visto.

Che cosa cambia nella sorveglianza umana

L’articolo 14 impone che i sistemi ad alto rischio siano progettati in modo da poter essere efficacemente sorvegliati da persone fisiche, con misure proporzionate ai rischi, al grado di autonomia e al contesto d’uso. Letta pensando a un agente, la disposizione rivela subito la propria difficoltà: la norma accresce le proprie pretese esattamente al crescere della proprietà che rende quelle pretese ardue da soddisfare. La sorveglianza di un sistema generativo costa poco perché è sincrona: qualcuno legge, poi agisce. La sorveglianza di un sistema agentico costa molto perché l’azione ha già avuto luogo, e va quindi progettata dentro il percorso di esecuzione anziché sovrapposta a valle. Ne derivano tre mutamenti concreti per la sorveglianza umana ai sensi dell’articolo 14. Il punto di controllo sostituisce la rilettura. La sorveglianza passa dal leggere un esito all’autorizzare in anticipo classi di azioni e all’interrompere azioni determinate mentre si svolgono. Si tratta di un modello di autorizzazioni, che merita la stessa cura progettuale riservata al prompt. La modalità di sorveglianza si sposta, ma non ovunque. Passare dall’human-in-the-loop all’human-on-the-loop rappresenta la scelta giusta per lavorazioni ad alto volume e bassa conseguenza. Rappresenta la scelta sbagliata quando una decisione produce effetti giuridici o similmente rilevanti su una persona, poiché l’articolo 22 del GDPR continua a limitare la decisione interamente automatizzata a prescindere da come il regolamento sull’IA classifichi il sistema. Il Garante per la protezione dei dati personali ha peraltro più volte ribadito che l’intervento umano invocato debba risultare effettivo e dotato di reale potere di modifica. La sorveglianza deve sopravvivere al proprio volume. OWASP cataloga il punto come T10, Overwhelming Human-in-the-Loop, ed è il più sottovalutato dell’elenco. Una coda di approvazione che un revisore smaltisce al ritmo di quattrocento elementi l’ora non è sorveglianza: è un timbro corredato di pista di controllo. Quando un presidio dipende da un’attenzione che la cadenza rende impossibile, il presidio ha già fallito, e le vostre evidenze documenteranno quel fallimento.

Che cosa cambia nel registro dei rischi

È la sezione che la maggior parte dei confronti salta, ed è quella in cui la differenza smette di essere concettuale. I modi di guasto non peggiorano: cambiano categoria. Un registro generativo riguarda soprattutto ciò che il sistema dice: allucinazione, perdita di riservatezza, output discriminatorio o tossico, iniezione di prompt come problema di contenuto. Un registro agentico riguarda ciò che il sistema fa. La tassonomia OWASP elenca quindici minacce agentiche, tra cui l’avvelenamento della memoria, l’abuso di strumenti, la compromissione dei privilegi, l’allucinazione a cascata, la manipolazione dell’obiettivo, il ripudio e la mancata tracciabilità, nonché gli agenti fuori controllo all’interno di sistemi multi-agente. La frase da portare al vostro comitato rischi sta in una riga: l’iniezione di prompt smette di essere un problema di frase sbagliata e diventa un problema di transazione non autorizzata. Stesso attacco, diversa classe di conseguenze, diverso titolare. <table header-row=”true”> <tr> <td>Modo di guasto</td> <td>Nell’IA generativa</td> <td>Nell’IA agentica</td> <td>Che cosa diventa il controllo</td> </tr> <tr> <td>Iniezione di prompt</td> <td>Testo difforme dalle policy o imbarazzante</td> <td>Chiamata a strumento non autorizzata, esfiltrazione, esecuzione di codice</td> <td>Confini di fiducia in ingresso e privilegio minimo sugli strumenti</td> </tr> <tr> <td>Allucinazione</td> <td>Un’affermazione errata che un revisore intercetta</td> <td>Un’azione errata già compiuta, su cui si innestano i passaggi seguenti</td> <td>Validazione dell’azione e reversibilità, non sola rilettura</td> </tr> <tr> <td>Fuga di dati</td> <td>Testo sensibile in una risposta</td> <td>Dati spostati tra sistemi dall’agente stesso</td> <td>Controllo dei flussi in uscita a livello di strumento</td> </tr> <tr> <td>Corruzione della memoria</td> <td>Non pertinente</td> <td>Uno stato avvelenato orienta il comportamento tra sessioni</td> <td>Validazione della memoria e isolamento delle sessioni</td> </tr> <tr> <td>Identità</td> <td>Un’utenza di servizio, uno schema di chiamata</td> <td>Un’identità non umana che opera di continuo su più sistemi</td> <td>Identità dell’agente, credenziali circoscritte, piena imputabilità</td> </tr> <tr> <td>Cumulo</td> <td>Confinato a una risposta</td> <td>Guasto a cascata tra passaggi o tra agenti</td> <td>Valutazione a livello di sistema, interruttori, contenimento</td> </tr> </table> Il profilo di Berkeley aggiunge i rischi di coda che contano ai gradi di agentività elevati: perdita di controllo, elusione della sorveglianza, disallineamento ingannevole e guasti multi-agente a cascata. Formula inoltre un principio che merita di entrare nelle vostre revisioni progettuali: un sistema multi-agente va valutato sia per singolo agente sia collettivamente, perché gli effetti emergenti dell’interazione non compaiono nei test di componente. La sua raccomandazione più netta consiste nel trattare un agente sufficientemente capace come non affidabile e nel contenerlo di conseguenza. Due conseguenze pratiche per i programmi già avviati. La vostra metodologia di gestione del rischio IA deve valutare a livello di sistema, altrimenti l’esame agente per agente manca i guasti di interazione. E il red teaming per l’IA deve prendere di mira il confine degli strumenti e l’archivio di memoria, non soltanto il prompt, poiché è di lì che un agente si rompe davvero.

Che cosa cambia nelle prove da produrre

La conformità non coincide con ciò che credete del vostro sistema, bensì con ciò che sapete mostrare. Su questo terreno i due paradigmi divergono nettamente, e le squadre scoprono di regola il divario durante una verifica anziché prima. Per un sistema generativo il fascicolo risulta familiare: documentazione del modello, esiti delle valutazioni, log di prompt e output, traccia della revisione umana. Per un sistema agentico la tenuta dei registri prevista dall’articolo 12 deve reggere molto di più. Chi ricostruisce una singola decisione dell’agente ha bisogno dell’obiettivo assegnato, del piano prodotto, di ogni chiamata a strumento con parametri ed esito, dell’identità con cui si è operato, dell’autorizzazione che copriva la chiamata, del carattere reversibile dell’azione e dell’eventuale reversione, nonché della collocazione del punto di controllo umano. OWASP archivia l’impossibilità di produrre questa catena come T8, ripudio e mancata tracciabilità, e la tratta alla stregua di una minaccia di sicurezza. È altrettanto un fallimento di governance. Se non riuscite a ricondurre un’azione a un agente, a una versione e a un’autorizzazione, non potete rispondere né a un’autorità, né a un revisore, né a chi avanzi una pretesa, e sarà l’assenza del log a diventare il rilievo. Tre artefatti da aggiungere, di cui un sistema generativo non ha mai avuto bisogno:

• Una decisione documentata di procedere o non procedere prima del rilascio, che il profilo di Berkeley colloca in Manage 1.1. Messa per iscritto, con le condizioni che la ribalterebbero.
• La prova che il percorso di disinnesco funzioni, collaudata e non asserita. Un pulsante di arresto che nessuno ha mai azionato in un’esercitazione resta un’intenzione progettuale, non un controllo.
• Un inventario delle identità non umane, affinché ogni azione dell’agente si risolva in una credenziale, un perimetro e un responsabile.

È anche il momento in cui la vostra documentazione tecnica e la vostra procedura di segnalazione degli incidenti chiedono una riscrittura più che un’estensione, essendo state concepite entrambe attorno a un sistema che produce output e non effetti.

Che cosa cambia nella catena del valore

La difficoltà maggiore non è tecnica. The Future Society la chiama il problema delle molte mani: nel momento in cui l’agente agisce, tante parti hanno contribuito che la responsabilità si disperde, a meno che qualcuno non la assegni deliberatamente. Tre attori, con risorse, competenze e informazione contestuale asimmetriche. Il fornitore del modello costruisce la capacità sottostante e i mezzi che rendono la governance possibile. Il fornitore del sistema agentico la adatta a una finalità e ne fissa i confini corrispondenti. Il deployer la esegue su dati reali, utenti reali e conseguenze reali. Il monitoraggio ne offre l’illustrazione più limpida. Il fornitore del modello deve costruire un’infrastruttura di monitoraggio configurabile. Il fornitore del sistema deve fissare soglie di allerta adeguate al caso d’uso. Il deployer deve effettivamente leggere gli allarmi e darvi seguito. Uno solo dei tre che agisca da sé produce qualcosa che in uno schema somiglia a sorveglianza e nell’esercizio non lo è. Per la maggior parte delle organizzazioni la domanda pratica diventa: che cosa pretendere da un fornitore che vende un agente? Quattro punti appartengono al contratto: lo schema e la conservazione dei log che riceverete, la granularità con cui potete circoscrivere le autorizzazioni dell’agente, il meccanismo di disinnesco con la sua latenza misurata, e gli obblighi di notifica quando il modello o l’impalcatura mutano sotto di voi. Trattate questi elementi come voci di due diligence sui fornitori con lo stesso peso delle domande di sicurezza, perché un cambiamento di capacità rilasciato in silenzio è un cambiamento di classificazione che non avete deciso voi. Ciò che non si delega è l’obbligo del deployer. Il rischio legato al contesto, la posizione rispetto ai diritti fondamentali e la progettazione della sorveglianza restano in capo all’organizzazione che esercisce il sistema: è il filo conduttore della responsabilità in materia di IA non appena gli agenti entrano nel parco applicativo.

La lista di controllo del passaggio

Dieci azioni quando un sistema varca la linea. Ciascuna è verificabile, il che conta più di quanto risulti comoda.

1. Rifare la classificazione sull’uso più ampio raggiungibile, non su quello previsto.
2. Iscrivere nell’inventario un punteggio di grado di agentività e abbandonare l’indicatore binario di autonomia.
3. Ripetere la valutazione dei rischi a livello di sistema, interazioni tra agenti comprese.
4. Censire ogni agente come identità non umana con un responsabile nominato.
5. Circoscrivere le autorizzazioni sugli strumenti al privilegio minimo e fissare il raggio d’azione deliberatamente anziché ereditarlo.
6. Strumentare una registrazione per singola azione che riporti obiettivo, piano, chiamata a strumento, identità e reversibilità.
7. Definire e collaudare il percorso di disinnesco, conservando la traccia della prova.
8. Riprogettare il punto di controllo umano perché sopravviva alla cadenza di produzione.
9. Rinegoziare il contratto di fornitura su log, autorizzazioni, arresto di emergenza e notifica delle modifiche.
10. Estendere la procedura di incidente alle azioni compiute dall’agente, non ai soli output prodotti.

Chi oggi governa tutto questo in fogli di calcolo incontra proprio al passaggio agentico il limite del metodo, perché la prova diventa continua anziché periodica. È esattamente il problema per cui esiste una piattaforma di gestione del rischio IA.

Domande frequenti

ChatGPT è IA generativa o IA agentica? Entrambe, a seconda della configurazione. Usato come interfaccia conversazionale che restituisce testo da leggere, il prodotto è generativo. Dotato di strumenti, navigazione, esecuzione di codice o connettori, e autorizzato a concatenare passaggi verso un obiettivo, lo stesso prodotto si comporta in modo agentico. Ecco perché la domanda non si risolve al livello di un nome commerciale, bensì al livello della vostra configurazione, degli strumenti abilitati e delle autorizzazioni concesse. Due imprese con il medesimo abbonamento possono così sopportare obblighi molto diversi. Che differenza c’è tra un agente IA e l’IA agentica? Il profilo di Berkeley traccia una linea utile. Un agente IA indica un singolo modello dotato di strumenti per portare a termine un compito ben delimitato dall’inizio alla fine. L’IA agentica indica invece un sistema di più agenti coordinati verso obiettivi più ampi. La distinzione governa la valutazione: un agente isolato si valuta in larga misura da solo, mentre un sistema multi-agente va valutato per singolo agente e collettivamente, poiché i guasti più gravi emergono dall’interazione anziché da un componente difettoso. Potete fare un esempio di IA agentica? Un assistente agli acquisti che legge una fattura in entrata, la riscontra con l’ordine, interroga l’anagrafica del fornitore, segnala uno scostamento e deposita un’istruzione di pagamento approvata nel sistema contabile. Ogni passaggio è ordinario. La combinazione è agentica perché il sistema ha pianificato la sequenza, impiegato più strumenti e prodotto un effetto finanziario senza che una persona abbia approvato quel pagamento determinato. La versione generativa del medesimo assistente avrebbe redatto una sintesi a beneficio di un contabile. L’IA agentica è ad alto rischio ai sensi del regolamento europeo? Non automaticamente, e non per il fatto di essere agentica. La qualificazione dipende dalla finalità, dall’essere componente di sicurezza oppure dal ricadere in un settore dell’allegato III. La complicazione sta nel fatto che un agente polivalente può raggiungere molte finalità, e le analisi pubblicate segnalano che un sistema simile potrebbe rientrare nell’ambito per difetto, salvo esclusione deliberata e dimostrabile degli usi ad alto rischio. Classificate rispetto a ciò che l’agente può raggiungere e trattate l’esclusione come un controllo tecnico documentabile anziché come una dichiarazione di intenti. Serve una valutazione dei rischi diversa da quella di un’IA generativa? Sì, e non semplicemente più lunga. Una valutazione generativa è in larga parte centrata sull’output e si chiede che cosa il sistema potrebbe dire e chi ne verrebbe danneggiato. Una valutazione agentica deve risultare centrata sull’azione e condotta a livello di sistema: che cosa l’agente può raggiungere, che cosa può modificare, che cosa accade quando un passaggio fallisce a metà percorso e come i guasti si sommano tra passaggi o tra agenti. Il profilo di Berkeley riconduce questo percorso alle funzioni del NIST AI RMF, il che consente alla maggioranza delle organizzazioni di estendere un metodo esistente anziché adottarne uno nuovo. Occorre una policy IA distinta per gli agenti? Di rado un documento separato, ma quello esistente reclama clausole nuove: chi possa concedere a un agente l’accesso a uno strumento e sotto quale approvazione, quali classi di azione impongano sempre un punto di controllo umano, quali obblighi di registrazione e di identità si applichino, e quale evento faccia scattare una riclassificazione all’attivazione di una capacità agentica. Incorporare tali clausole nella vostra policy sull’IA preserva un unico documento opponibile invece di due testi concorrenti.

Conclusione

Il confronto che tutti pubblicano è corretto e si ferma un gradino troppo presto. L’IA generativa crea, l’IA agentica agisce, e la domanda interessante riguarda quanto ciò vi costa. Costa una riclassificazione, perché l’insieme degli usi raggiungibili si è allargato. Costa una riprogettazione della sorveglianza, perché l’articolo 14 pretende di più proprio quando l’autonomia rende più arduo soddisfarlo. Costa un registro dei rischi nuovo, perché i modi di guasto hanno cambiato categoria. Costa un fascicolo probatorio più pesante, perché il revisore ora domanda che cosa il sistema abbia fatto e sotto quale autorità. Costa infine un rapporto di fornitura rinegoziato, perché la parte che modifica la capacità raramente coincide con quella che ne sopporta le conseguenze. Nulla di tutto ciò depone contro gli agenti. Tutto depone a favore del sapere con precisione quando ne avete acquisito uno. Sottoponete il vostro portafoglio alle cinque domande in questo trimestre e misurate quanta parte abbia già varcato la linea. Per tenere classificazione, progettazione della sorveglianza, registro dei rischi e catena probatoria in un unico luogo invece che in cinque fogli di calcolo, è la ragione per cui esiste AI Sigil.