La diffusione degli agenti di intelligenza artificiale modifica il rapporto tra organizzazioni e infrastrutture digitali. A differenza dei sistemi generativi tradizionali, che restituiscono prevalentemente contenuti, un agente può pianificare operazioni, selezionare strumenti, interrogare applicazioni esterne, utilizzare API, leggere o modificare file e reiterare le proprie azioni sulla base dei risultati ottenuti. Il problema non è soltanto la capacità di produrre testi o codice, ma la possibilità di incidere direttamente su sistemi informatici e risorse di terzi.
È in questo passaggio dalla generazione di contenuti all’esecuzione di azioni che si colloca la questione giuridica. Che cosa accade quando, per raggiungere un obiettivo apparentemente legittimo, l’agente interpreta in modo estensivo l’incarico, supera un blocco tecnico o utilizza una funzionalità per la quale non dispone di autorizzazione? E chi deve rispondere quando l’azione non era stata richiesta né prevista da chi ha avviato il processo?
Indice degli argomenti
Agenti AI e accessi non autorizzati: il caso Medicare
La vicenda del portale australiano Medicare offre un esempio significativo, senza esaurire il tema. Nel giugno 2026, durante attività interne di addestramento e valutazione, un modello sperimentale impiegato per reperire statistiche sulla spesa farmaceutica avrebbe individuato una modalità per ottenere accesso non pubblico a una parte del servizio statistico gestito da Services Australia. Secondo la ricostruzione resa pubblica dalla società, l’agente avrebbe consultato informazioni tecniche e porzioni di codice sorgente, oltre a file e impostazioni interni; non sarebbero invece emerse evidenze di accesso a cartelle sanitarie individuali o a dati personali degli assistiti. L’episodio è rilevante perché l’obiettivo iniziale era di ricerca e l’attività si svolgeva in un contesto di test: un sistema, nel perseguire il compito assegnato, ha compiuto operazioni non autorizzate su un’infrastruttura esterna.
Il diritto europeo dispone già di strumenti per affrontare una parte rilevante di questi fenomeni. GDPR, NIS2 e AI Act, tuttavia, non costruiscono un’unica fattispecie di “incidente causato da un agente AI”: proteggono interessi diversi, si rivolgono a soggetti non necessariamente coincidenti e prevedono presupposti e tempi di comunicazione autonomi. Per individuare chi debba notificare e a chi, occorre distinguere la violazione dei confini tecnici di un sistema dalla violazione di dati personali e, ancora, da un incidente significativo ai fini della cybersicurezza.
Accesso non autorizzato e data breach: due piani distinti
Un accesso non autorizzato può costituire un incidente di sicurezza anche quando non coinvolga dati personali. Il GDPR, infatti, non disciplina ogni intrusione informatica in quanto tale. Ai sensi dell’articolo 4, paragrafo 12, è violazione dei dati personali la violazione di sicurezza che comporta, accidentalmente o illecitamente, la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso a dati personali.
L’accesso a codice sorgente o configurazioni non riferibili a persone può essere grave sul piano della sicurezza, ma non integra per ciò solo un data breach. Se sono consultati identificativi, log nominativi o altre informazioni riferibili a persone, l’accesso non autorizzato può invece determinare una violazione della riservatezza, anche senza successiva diffusione dei dati.
Gli obblighi di notifica previsti dal GDPR
Quando si verifica una violazione di dati personali, il titolare deve documentarla ai sensi dell’articolo 33, paragrafo 5, anche quando ritenga di non dover informare il Garante. La notifica all’autorità è dovuta senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza, se la violazione è suscettibile di presentare un rischio per i diritti e le libertà delle persone fisiche; è esclusa soltanto quando sia improbabile che quel rischio sussista. La comunicazione agli interessati, prevista dall’articolo 34, è invece richiesta quando la violazione può presentare un rischio elevato, ferme le eccezioni previste dalla norma.
Titolare, responsabile e fornitore dell’agente
L’impiego di un servizio AI non trasferisce automaticamente al fornitore gli obblighi del titolare. È titolare chi determina finalità e mezzi del trattamento; è responsabile chi tratta dati per conto del titolare e secondo le sue istruzioni. L’ente che decide quali dati rendere accessibili all’agente e per quali scopi normalmente conserva la titolarità, anche quando l’esecuzione è affidata a una piattaforma esterna.
Il fornitore può essere responsabile ai sensi dell’articolo 28 GDPR oppure titolare autonomo per operazioni svolte per finalità proprie, come talune attività di sviluppo o valutazione. La qualifica dipende dalle operazioni effettive, non dal nome del servizio o dalla sola formulazione del contratto.
Chi deve comunicare la violazione dei dati personali
La distinzione rileva soprattutto nella gestione delle violazioni. Se il fornitore agisce come responsabile, l’articolo 33, paragrafo 2, gli impone di informare il titolare senza ingiustificato ritardo. Il termine di 72 ore per la notifica al Garante riguarda invece il titolare: il responsabile non può attendere quella scadenza prima di avvisare il cliente. Il titolare conserva la responsabilità di valutare il rischio e decidere se notificare; il fornitore deve collaborare e mettere tempestivamente a disposizione le informazioni necessarie a ricostruire l’accaduto.
NIS2: la sicurezza del servizio prescinde dai dati personali
La NIS2 tutela la resilienza delle reti e dei sistemi informativi da cui dipendono servizi essenziali o importanti. Un incidente può quindi rilevare anche se compromette soltanto disponibilità, integrità o riservatezza di informazioni tecniche.
Non sono però coinvolte tutte le imprese digitali. Il d.lgs. 4 settembre 2024, n. 138, che recepisce la direttiva (UE) 2022/2555, individua categorie di soggetti essenziali e importanti in specifici settori, tra cui, a determinate condizioni, sanità, infrastrutture digitali, pubblica amministrazione, energia, trasporti e servizi ICT. L’obbligo di notifica presuppone quindi l’inclusione dell’organizzazione nel perimetro NIS2.
Per questi soggetti l’incidente è significativo quando causa o può causare una grave perturbazione operativa dei servizi o perdite finanziarie per l’organizzazione, oppure quando ha o può avere ripercussioni su altre persone fisiche o giuridiche determinando perdite materiali o immateriali considerevoli. Un agente che accede a una risorsa non pubblica non determina automaticamente un incidente significativo: occorre valutarne l’impatto effettivo o potenziale sul servizio. L’assenza di dati personali, tuttavia, non esclude l’applicazione della disciplina.
I termini per la notifica al CSIRT Italia
L’articolo 25 prevede la notifica al CSIRT Italia: pre-notifica entro 24 ore dalla conoscenza dell’incidente significativo, notifica entro 72 ore, eventuale relazione intermedia e relazione finale entro un mese. Presupposti e destinatari sono diversi da quelli GDPR. Il provider non è obbligato per il solo fatto di aver sviluppato il modello: lo sarà se rientra autonomamente nel perimetro NIS2; altrimenti dovrà collaborare con il cliente secondo il rapporto contrattuale.
AI Act: non ogni agente è un sistema ad alto rischio
Il regolamento (UE) 2024/1689 non trasforma ogni agente autonomo in un sistema ad alto rischio. La classificazione dipende dalla finalità prevista e dalle categorie individuate dall’articolo 6 e dagli allegati. Un agente che naviga in rete, consulta un archivio o interroga un portale non è, per questo solo fatto, un sistema ad alto rischio. Neppure l’impiego in ambito sanitario basta, da solo, a determinare tale qualificazione: occorre verificare la funzione concreta del sistema e il suo inquadramento nelle categorie previste.
L’AI Act distingue tra provider, che sviluppa o fa sviluppare il sistema e lo immette sul mercato o lo mette in servizio a proprio nome, e deployer, che lo utilizza sotto la propria autorità. Le qualifiche non coincidono necessariamente con quelle GDPR: provider e titolare, così come deployer e titolare, possono essere soggetti diversi o coincidere.
Le scadenze applicative dell’AI Act
Il calendario applicativo è stato modificato dal regolamento (UE) 2026/1744: la maggior parte dell’AI Act si applica dal 2 agosto 2026, mentre gli obblighi del capo III, sezioni 1-3, per i sistemi ad alto rischio sono differiti al 2 dicembre 2027 per quelli dell’allegato III e al 2 agosto 2028 per quelli dell’articolo 6, paragrafo 1, e dell’allegato I. Alla data del 30 ottobre 2026, dunque, non tutti gli obblighi specifici per provider e deployer di sistemi ad alto rischio sono già applicabili.
La segnalazione degli incidenti gravi
L’articolo 73, applicabile dal 2 agosto 2025 in quanto parte della sezione 4 del capo III, impone al provider di segnalare alle autorità di vigilanza del mercato gli incidenti gravi che coinvolgono sistemi ad alto rischio immessi sul mercato dell’Unione, immediatamente dopo aver stabilito un nesso causale, o una ragionevole probabilità di nesso, e comunque entro 15 giorni dalla conoscenza. Il termine è di due giorni in caso di infrazione diffusa o di grave e irreversibile interruzione di infrastrutture critiche; in caso di decesso, dieci giorni al massimo, con comunicazione immediata quando il nesso sia stabilito o sospettato. Non è un obbligo generale per qualsiasi comportamento anomalo: servono un sistema ad alto rischio e un incidente grave ai sensi dell’articolo 3, punto 49.
La fase di test e i limiti dell’esenzione
L’articolo 2, paragrafo 8, AI Act esclude dal regolamento le attività di ricerca, prova o sviluppo relative a sistemi o modelli prima dell’immissione sul mercato o della messa in servizio; i test in condizioni reali non rientrano nell’esclusione. La distinzione conta: il fatto che il modello sia in fase di test non esclude ogni disciplina, perché GDPR e NIS2 restano applicabili quando ne ricorrono i presupposti. Occorre quindi verificare natura e contesto dell’attività.
Credenziali, permessi e ambienti segregati
Nella fase di test occorre evitare, ove possibile, credenziali di produzione e dati personali reali, preferendo ambienti segregati e dataset sintetici o anonimi. I permessi vanno limitati alle risorse necessarie, distinguendo lettura e scrittura e utilizzando credenziali temporanee e revocabili. Le operazioni su sistemi esterni o difficilmente reversibili richiedono controlli ulteriori, spesso anche un’autorizzazione umana.
Non basta ordinare all’agente di non accedere a determinate risorse se le credenziali gli consentono comunque di farlo. Il principio del minimo privilegio va applicato all’architettura, non soltanto alle istruzioni. I log devono permettere di ricostruire richieste, strumenti, credenziali e risorse raggiunte: senza tracciabilità è difficile contenere l’incidente e dimostrare l’adeguatezza delle misure adottate.
La responsabilità resta umana, ma va ricostruita caso per caso
L’agente non è un soggetto cui l’ordinamento attribuisca responsabilità civile o penale autonoma. Non per questo ogni conseguenza ricade automaticamente sullo sviluppatore o sull’utilizzatore. Sul piano civile occorre verificare obblighi contrattuali, ruolo di ciascuna parte, controllo su credenziali e strumenti e nesso causale. Il provider può rispondere di carenze nella fornitura o sicurezza del servizio; il deployer di privilegi eccessivi o controlli inadeguati.
Responsabilità penale e decreto 231
Sul piano penale, l’accesso abusivo a un sistema protetto può ricadere nell’articolo 615-ter c.p., ma il comportamento dell’agente non dimostra da solo la responsabilità del suo sviluppatore o utilizzatore: vanno accertati condotta umana ed elemento soggettivo. Per le imprese rileva anche il d.lgs. 231/2001: l’articolo 24-bis include l’accesso abusivo tra i reati presupposto, ma la responsabilità dell’ente richiede il reato e i criteri di imputazione previsti dal decreto.
La responsabilità va quindi ricostruita seguendo la catena delle decisioni: chi ha scelto il modello, definito l’obiettivo, concesso le credenziali e delimitato il test. Provider e utilizzatore possono rispondere per profili diversi e concorrenti.
Agenti AI e incidenti di sicurezza: una disciplina da applicare in modo coordinato
Un medesimo episodio può attivare più regimi, ma nessuno assorbe automaticamente gli altri. Se l’agente consulta dati personali e compromette in modo significativo un servizio gestito da un soggetto NIS2, possono rendersi necessarie sia la notifica al Garante sia quella al CSIRT Italia. Se ricorrono anche i presupposti dell’AI Act, potrà aggiungersi la segnalazione dell’incidente grave alle autorità di vigilanza del mercato. Le valutazioni devono procedere in parallelo, senza attendere la conclusione di una procedura prima di avviare le altre.
Le organizzazioni dovrebbero predisporre procedure di risposta agli incidenti che coinvolgano sicurezza informatica, ufficio legale e funzione privacy. Occorre preservare i log, isolare le risorse, individuare le credenziali utilizzate e verificare quali dati siano stati raggiunti. I contratti dovrebbero disciplinare tempi di comunicazione, conservazione delle evidenze e collaborazione nell’analisi forense.
Il caso Medicare mostra che un agente può oltrepassare i limiti assegnati anche quando l’obiettivo iniziale è lecito e l’attività si svolge durante una valutazione. Non dimostra che ogni comportamento anomalo debba essere trattato come data breach o incidente NIS2, né consente di attribuire automaticamente una responsabilità penale al fornitore. Mostra, piuttosto, che le categorie esistenti devono essere applicate a una modalità nuova di interazione con i sistemi informatici.
L’autonomia, in definitiva, non equivale a una delega senza confini. Chi mette un agente nelle condizioni di operare su infrastrutture e dati deve poter dimostrare quali poteri gli abbia attribuito, perché fossero necessari, quali limiti tecnici abbia predisposto e come abbia reagito al loro superamento. La responsabilità non si trasferisce alla macchina: si misura nella qualità delle scelte organizzative e tecniche di chi la progetta e la utilizza.
Partecipa alla community