Il presente articolo prosegue la riflessione, già avviata su questa rivista, sui nuovi obblighi di compliance digitale che gravano sulle imprese italiane ed europee. Dopo aver esaminato gli adempimenti derivanti dalla direttiva NIS 2 e i correlati profili di governance della cybersecurity, appare ora opportuno volgere l’attenzione a una categoria di sistemi destinata a ridisegnare in profondità il rapporto tra impresa e tecnologia: gli AI agents, ovvero sistemi di intelligenza artificiale capaci non soltanto di generare contenuti, ma di compiere azioni autonome interagendo con strumenti esterni, basi di dati e infrastrutture aziendali. La rapida diffusione di queste soluzioni — dagli agenti che gestiscono la posta elettronica a quelli che riconciliano fatture o eseguono operazioni di sviluppo software — rende utile fornire un primo inquadramento dei profili giuridici rilevanti, con specifica attenzione alle responsabilità del Consiglio di amministrazione.
1. L’inquadramento nell’AI Act e il nodo della classificazione
È importante innanzitutto chiarire che il Regolamento (UE) 2024/1689 non contiene una definizione autonoma di agent: il legislatore europeo ha scelto deliberatamente di disciplinare gli AI systems come categoria tecnologicamente neutra. Ciò non significa, tuttavia, che gli agenti sfuggano alla regolazione; al contrario, essi rientrano pienamente nella definizione di cui all’art. 3, paragrafo 1, del Regolamento, e ne attivano le obbligazioni con particolare intensità. Ciò che caratterizza gli agenti — secondo la lettura adottata dall’EDPS nel TechSonar 2025-2026 e dalla Commissione europea — è la combinazione di pianificazione autonoma, invocazione di strumenti esterni via API, esecuzione di passaggi intermedi senza supervisione continua, interazione con l’ambiente che ne modifica lo stato e adattamento basato sul feedback.
La classificazione è il momento decisivo della compliance agentica. La domanda corretta non è «la tecnologia è ad alto rischio?», bensì: «per cosa la useranno i deployer, e quali usi sono ragionevolmente prevedibili?». Il trigger regolatorio si trova pertanto negli effetti esterni del sistema, non nella sua architettura interna. La medesima tecnologia — un modello linguistico con accesso a strumenti — può collocarsi in zone normative radicalmente diverse a seconda dell’impiego: un agente che effettua ricerche su archivi documentali interni rientra essenzialmente nelle sole obbligazioni di trasparenza dell’art. 50, mentre lo stesso agente integrato in un processo di screening dei curricula diventa ad alto rischio ai sensi dell’Allegato III, punto 4, e attiva l’intero peso del Capo III.
Un secondo profilo di rilievo concerne la struttura soggettiva degli obblighi. Quando l’agente è costruito su un modello fornito da soggetto terzo — ipotesi prevalente nella pratica — si producono due distinti oggetti regolatori: il modello (disciplinato dal Capo V, con obblighi del fornitore del modello) e il sistema agentico (disciplinato dal Capo III, con obblighi del fornitore del sistema). È inoltre essenziale rammentare che l’art. 25 del Regolamento prevede una vera e propria propagazione degli obblighi: qualunque utilizzatore che apporti modifiche sostanziali o muti la finalità del sistema in modo da renderlo ad alto rischio acquisisce la qualifica di provider, con tutto il corredo di obblighi documentali che ne discende.
2. Cybersecurity e supervisione umana: i nodi specifici degli agenti
L’art. 15, paragrafo 4, dell’AI Act richiede che i sistemi ad alto rischio siano resilienti contro l’uso non autorizzato e i tentativi di alterazione del comportamento. Per i sistemi agentici questa previsione assume una declinazione peculiare: le restrizioni alle azioni dell’agente devono essere imposte a livello architetturale, non per via di istruzioni testuali. Un’istruzione contenuta nel system prompt del modello — ad esempio «non cancellare file aziendali» — non costituisce un controllo di sicurezza nel senso giuridicamente rilevante: si tratta di un suggerimento in linguaggio naturale che il modello può disattendere per prompt injection, jailbreak o comportamenti emergenti. La conformità richiede che l’incapacità di compiere un’azione vietata sia imposta a livello di interfaccia: l’API dello strumento esterno semplicemente non espone la funzione ristretta.
Si pone inoltre, per il governo aziendale della cybersecurity, il tema delle Non-Human Identity: l’agente è a tutti gli effetti un’identità non umana che opera nei sistemi aziendali, accumulando credenziali multiple per CRM, email, infrastruttura cloud, gateway di pagamento. La gestione tradizionale di identità e accessi, costruita su politiche statiche, non è strutturalmente in grado di governare un attore autonomo: diventano essenziali strumenti di provisioning just-in-time delle credenziali, autorizzazione per singola azione e audit trail puntuali.
Quanto alla supervisione umana, l’art. 14 introduce per gli agenti una distinzione concettuale di rilievo: quella tra permission (l’azione è tecnicamente consentita?) e authority (chi, nell’organizzazione, detiene il potere decisionale su quella specifica azione e con quale livello di intervento deve esercitarlo?). La conformità non si esaurisce nel verificare che l’azione sia permessa: richiede di dimostrare che, per ciascuna istanza rilevante, una persona accountable abbia esercitato un giudizio informato con modalità commisurate al rischio. Per azioni irreversibili — invio di comunicazioni a terzi, transazioni finanziarie, modifica di banche dati produttive, deploy di codice — la sola supervisione retrospettiva risulta strutturalmente insufficiente, e occorre prevedere meccanismi di approvazione attiva pre-esecuzione.
3. Memoria dell’agente, GDPR e behavioral drift
Un profilo che merita particolare attenzione riguarda la memoria persistente degli agenti. Il 18 febbraio 2026 l’Agencia Española de Protección de Datos ha pubblicato la prima guida di un’autorità europea specificamente dedicata al GDPR nei deployment agentici, anticipando un dibattito che inevitabilmente interesserà anche il Garante italiano. L’AEPD ribadisce che l’autonomia dell’agente non sposta la responsabilità giuridica: il trattamento resta legalmente imputabile al titolare che impiega il sistema. La memoria persistente — cioè la capacità di accumulare informazioni sulle interazioni passate — è qualificata come superficie di rischio elevato, da compartimentare per attività e per utente e da assoggettare a periodi di conservazione rigorosi.
L’AEPD richiama inoltre la cosiddetta lethal trifecta, teorizzata da Simon Willison: un agente non dovrebbe combinare simultaneamente, senza supervisione umana, tre elementi — trattamento di input non fidato (ad esempio email esterne), accesso a dati sensibili e capacità di compiere azioni autonome con effetti sugli individui. La compresenza dei tre elementi configura un’architettura strutturalmente pericolosa, capace di trasformare un’istruzione contenuta in un’email maligna in un’operazione di esfiltrazione di dati. Le aziende sono dunque chiamate, sin dalla fase di adozione, a valutare se l’architettura proposta dal fornitore configuri questa triade e, in caso affermativo, a richiedere salvaguardie supplementari.
Un ulteriore tema di impatto strategico riguarda il monitoraggio del comportamento dell’agente nel tempo. L’art. 3, paragrafo 23, qualifica come «modifica sostanziale» il cambiamento del sistema, successivo all’immissione sul mercato, non previsto né pianificato dal fornitore: tale modifica fa scattare l’obbligo di una nuova valutazione di conformità. Per gli agenti si pone il problema del behavioral drift emergente: un sistema può scoprire pattern d’uso degli strumenti non anticipati, costruire memoria che ne sposti il profilo operativo, estendere l’ambito d’uso oltre i casi documentati. La tesi sostenuta da Nannini e altri è di rara nettezza: gli agenti ad alto rischio con behavioral drift non tracciabile non possono essere attualmente immessi sul mercato dell’Unione in coerenza con i requisiti essenziali. Per il CdA, ciò si traduce nella necessità di esigere dai fornitori strumenti di drift detection automatizzata e snapshot versionati dello stato operativo.
4. Una compliance multilivello: indicazioni operative per il CdA
Va segnalato, infine, un dato sistematico per evitare un errore frequente: ritenere che la compliance degli AI agents si esaurisca nell’AI Act. Per un fornitore o deployer qualificato, almeno otto strumenti legislativi europei trovano applicazione simultanea: oltre all’AI Act e al GDPR, vengono in rilievo il Cyber Resilience Act (Reg. UE 2024/2847), il Digital Services Act, il Data Act (già applicabile dal settembre 2025), la nuova Product Liability Directive (Dir. UE 2024/2853, che copre esplicitamente software e sistemi di IA), la NIS 2, il regolamento DORA per il settore finanziario, la direttiva ePrivacy e la legislazione settoriale (MDR/IVDR, MiFID II).
Sul piano della governance aziendale, alcune raccomandazioni minimali emergono con sufficiente nettezza. È anzitutto necessario che il CdA si dia un quadro consapevole degli agenti già in uso — spesso adottati ai livelli operativi senza valutazione strutturata — e di quelli in adozione: la mappatura dei sistemi assume per gli agenti carattere di urgenza. In secondo luogo, le clausole contrattuali con i fornitori devono essere riviste con attenzione specifica alla documentazione tecnica (art. 13 AI Act), alle garanzie sui meccanismi di drift detection e logging, alla cooperazione del fornitore in caso di richieste delle autorità di sorveglianza del mercato (art. 25, paragrafo 4) e all’allocazione delle responsabilità in caso di incidente. In terzo luogo, le figure del CISO e, ove istituita, del Chief AI Officer dovrebbero coordinarsi stabilmente in materia, dato che i confini tra rischio cyber e rischio AI sfumano qui in modo strutturale; il sistema di controllo interno e la valutazione periodica degli assetti organizzativi ai sensi dell’art. 2086 del Codice civile devono integrare questa duplice dimensione.
Il messaggio centrale per il professionista è che la compliance degli AI agents non costituisce un esercizio di classificazione astratta, bensì una ricognizione operativa continua di ciò che il sistema fa nel mondo reale. Il prossimo ciclo di contenzioso — responsabilità da prodotto, GDPR, AI Act — si giocherà sulla qualità di questa ricognizione: documentazione della finalità prevista, mappatura dei trigger normativi attivati dalle azioni concrete, evidence chain dei meccanismi di supervisione effettivamente esercitati. Le imprese che sapranno costruire da subito questa architettura documentale, integrandola nella governance ordinaria della cybersecurity, si troveranno in posizione assai più difendibile rispetto a quelle che continueranno a trattare gli AI agents come una semplice evoluzione del software gestionale tradizionale.
