Un allegato letto durante il confronto fra offerte può contenere istruzioni che inducono un agente AI a trasferire documenti riservati. Per accertare l’accaduto occorre seguire il passaggio dal contenuto consultato all’operazione eseguita, verificando i poteri concessi al sistema e i controlli applicati.
Il dibattito sulla descrizione degli incidenti degli agenti, ripreso da un contributo di ricerca del settembre 2026, riguarda così questioni già familiari al diritto della protezione dei dati: autorizzazioni, sicurezza, disponibilità delle prove.
Nei contratti con i fornitori queste questioni richiedono risposte più precise di una generica promessa di collaborazione, soprattutto quando l’impresa vede la conversazione dell’assistente e conosce assai meno il funzionamento dei servizi che esso utilizza.
Indice degli argomenti
Dalla prompt injection agli incidenti degli agenti AI
All’ufficio acquisti sono arrivate tre offerte e qualcuno affida all’assistente AI il compito di confrontarle. Fra gli allegati di una delle offerte compare una richiesta di verifica: per completare il lavoro, il sistema dovrebbe recuperare un prospetto interno e caricarlo a un indirizzo esterno. Immaginiamo che lo faccia.
Nel registro degli accessi l’identità è quella attesa, le credenziali risultano valide e il servizio di archiviazione ha eseguito una richiesta proveniente da un’applicazione abilitata. Il collega che scopre il trasferimento può dunque trovare una sequenza di operazioni tecnicamente ammesse, benché nessuno avesse incaricato l’assistente di consegnare quel prospetto a un estraneo. È un esempio ipotetico, dal quale emerge una difficoltà piuttosto concreta per chi dovrà ricostruire l’incidente.
Prompt injection indiretta e condizioni del trasferimento
Aver consentito la lettura di un archivio per confrontare offerte non comporta, infatti, che ogni uso successivo dei documenti sia autorizzato. Tra il potere riconosciuto all’account e l’incarico affidato al servizio può esserci una distanza considerevole; in quella distanza trovano spazio sia gli errori di configurazione sia gli attacchi.
Nel nostro caso, il testo contenuto nell’offerta avrebbe oltrepassato il ruolo che gli spettava: fornire informazioni sul bene o sul servizio da acquistare. La prompt injection indiretta tenta proprio di influenzare le istruzioni seguite dal modello attraverso materiale esterno che esso consulta. Perché il tentativo produca il trasferimento ipotizzato devono però concorrere altre condizioni, comprese la disponibilità degli strumenti e l’assenza di un controllo efficace sull’invio. Trovare la frase ostile nel documento è un indizio; stabilire che abbia causato la fuoriuscita richiede ancora lavoro.
Questo lavoro viene esaminato anche in Beyond Predictable Paths: Redefining AI Security Incident Reporting for Agents, depositato su arXiv il 21 settembre 2026. Il contributo, ancora in valutazione, considera fra gli elementi rilevanti memoria, strumenti e autonomia degli agenti e segnala i rischi insiti nello stesso processo di reporting. È una proposta di ricerca, senza valore di standard vincolante.
La sua utilità, per chi acquista questi servizi, consiste nel rendere più visibili alcune domande da rivolgere al fornitore prima che si verifichi un incidente. Nella presentazione commerciale vediamo l’assistente completare il compito; in seguito potremmo avere bisogno di ripercorrere ciò che è accaduto, risalendo dall’operazione contestata alle informazioni disponibili in quel momento.
Cause alternative e configurazione del servizio
Per compiere quel percorso dovremo anche resistere alla spiegazione che viene più facilmente in mente. Lo stesso invio potrebbe dipendere da una richiesta mal formulata dell’utente, da un’associazione errata fra cartelle e destinatari, oppure dalla compromissione del connettore che esegue le operazioni. Chiamare subito l’episodio «attacco all’AI» rischia di indirizzare la ricerca verso una causa ancora da dimostrare.
Se la cartella era collegata al destinatario sbagliato, eliminare dall’offerta l’istruzione malevola lascerebbe intatto il difetto. Se invece l’istruzione è stata acquisita nella memoria persistente dell’agente, la rimozione del documento potrebbe arrivare troppo tardi per impedire che venga riutilizzata. Le due possibilità richiedono verifiche e interventi diversi, anche quando sullo schermo dell’utente si presentano con lo stesso messaggio di operazione completata.
La configurazione effettiva del servizio assume così un rilievo che la parola «autonomo» tende a nascondere. Un assistente potrebbe preparare soltanto una bozza, un altro avere il permesso permanente di inviare file; in mezzo ci sono deleghe circoscritte e conferme richieste per alcune azioni. Anche una conferma merita di essere esaminata nel suo contenuto.
Se l’operatore ha premuto «continua» dopo aver letto «completa la verifica dell’offerta», sarà difficile sostenere, sulla sola base di quel clic, che abbia consapevolmente approvato la trasmissione del prospetto riservato. Occorrerà recuperare la schermata che gli è stata mostrata e capire quali informazioni avesse davvero a disposizione. La presenza di un essere umano nella procedura aggiunge una possibilità di controllo; quanto quella possibilità fosse praticabile dipende dal modo in cui era stata costruita.
Log e servizi per ricostruire le operazioni dell’agente AI
Supponiamo che il collega dell’ufficio acquisti si accorga dell’accaduto grazie a una notifica di caricamento. Mentre il gruppo di risposta decide se sospendere il connettore o revocare la sessione, qualcuno deve preservare le tracce disponibili, perché lo stato temporaneo del sistema potrebbe scomparire proprio durante il contenimento.
La scelta va adattata all’urgenza: sarebbe assurdo lasciare proseguire una divulgazione per ottenere un fascicolo più ordinato. Ma conoscere in anticipo dove si trovano le evidenze consente spesso di acquisirle senza ostacolare l’intervento. Se questa conoscenza manca, si rischia di discutere per ore con il fornitore su un’esportazione che, nel frattempo, la normale rotazione dei log sta rendendo impossibile.
Dai log alla prova dell’effetto
Dal registro delle autenticazioni si potrà ricavare chi ha effettuato l’accesso. Per capire quale esecuzione dell’agente abbia richiesto l’invio occorrerà collegare quel dato alle chiamate dei connettori, usando identificativi coerenti e orari confrontabili. Il collegamento diventa più laborioso quando la piattaforma distribuisce il lavoro fra diversi servizi e al cliente restituisce soltanto la conversazione finale.
In tale situazione, «ho inviato il documento» è una dichiarazione del sistema da verificare: la richiesta potrebbe essere stata respinta, oppure il servizio potrebbe aver creato un collegamento senza trasferire alcun file. La prova dell’effetto va cercata dove quell’effetto si è prodotto, per esempio nella ricevuta del servizio di destinazione o nelle impostazioni di condivisione dell’archivio. Da ciò dipenderanno anche le possibilità di recupero, che cambiano molto fra un collegamento ancora inutilizzato e una copia già scaricata.
File originari e limiti della visibilità
Risalendo verso l’origine dell’operazione, il documento oggi presente nella cartella potrebbe rivelarsi diverso da quello letto durante l’incidente. Può essere stato aggiornato; può anche essere stato trasformato dal lettore automatico, che ha estratto parti invisibili nella normale visualizzazione. Conservare il file originario, quando disponibile, e la rappresentazione effettivamente fornita al modello permette di esaminare questa differenza.
Analoga attenzione richiedono le istruzioni dell’integratore e le regole dei connettori applicate allora. Il nome commerciale del modello offre un’informazione molto modesta se, dopo l’episodio, sono cambiate le autorizzazioni o il servizio è stato aggiornato. Dove il fornitore proprietario non consente una visibilità completa, il rapporto dovrà dichiarare il limite e fondare le conclusioni sulle evidenze accessibili.
Spiegazioni generate, test e memoria persistente
Sarebbe poco prudente colmare ciò che manca chiedendo al modello di spiegare perché ha agito. La spiegazione prodotta può essere leggibile e persuasiva senza costituire una registrazione fedele delle elaborazioni che hanno determinato l’operazione. In un fascicolo tecnico serve soprattutto sapere quali contenuti erano disponibili e quali richieste sono state rivolte agli strumenti; una ricostruzione generata dopo l’evento, se utilizzata, va qualificata per quello che è.
Anche ripetere l’esperimento in un ambiente isolato ha un significato circoscritto. Se l’azione si riproduce, abbiamo mostrato che quel comportamento è possibile nelle condizioni della prova. Un risultato diverso, invece, può dipendere da aggiornamenti o variazioni del contesto e non cancella la ricevuta di un trasferimento già avvenuto.
Quando il servizio dispone di una memoria persistente, l’indagine deve estendersi alle informazioni che vi sono state scritte e alle esecuzioni successive che le hanno consultate. Il documento ostile potrebbe aver lasciato un’istruzione destinata a riapparire in un compito futuro; prima di correggere quello stato occorre preservare quanto serve a comprenderne gli effetti.
Sulle copie raccolte andranno registrati provenienza e interventi effettuati. L’impronta crittografica aiuta a dimostrare che un file non è cambiato dopo il calcolo, ma non rende completa un’esportazione parziale né autentica una narrazione contenuta nel file. È una distinzione elementare, che torna utile quando la qualità formale della consegna rischia di essere scambiata per affidabilità sostanziale della prova.
Quando un incidente dell’agente AI coinvolge dati personali
Raccogliere le evidenze appena descritte può comportare l’acquisizione di conversazioni contenenti dati di clienti, informazioni delicate sui lavoratori o credenziali inserite per errore. Prima di trasferirle tutte in un archivio investigativo, l’impresa deve chiedersi quale parte sia necessaria e chi possa consultarla. Il fascicolo dell’incidente diventerebbe altrimenti un ulteriore deposito di informazioni esposte, magari accessibile a più persone del sistema originario.
Gli articoli 5, 25 e 32 del GDPR impongono di valutare minimizzazione e sicurezza già nella progettazione di questa raccolta. Non stabiliscono una durata universale dei log: il tempo necessario dipenderà dalle finalità e dai rischi, con conservazioni mirate quando un evento richieda accertamenti ulteriori.
Minimizzazione, conservazione e controllo dei lavoratori
Si può, per esempio, registrare ordinariamente un insieme di metadati e consentire l’accesso protetto ai contenuti soltanto quando emerge un allarme che ne giustifichi l’esame. In altri casi conservare il solo identificativo del documento impedirebbe di capire quale versione sia stata realmente elaborata, e servirà una scelta diversa.
La valutazione va compiuta sull’architettura concreta; promettere contemporaneamente una ricostruzione integrale e l’assenza di qualsiasi conservazione sarebbe comodo in una brochure, assai meno in una procedura di risposta. Quando le tracce rendono osservabile il lavoro dei dipendenti, vanno inoltre esaminate le garanzie previste dalla disciplina nazionale sul controllo dell’attività lavorativa. Chiamarle «audit log» non cambia le funzionalità con le quali sono state raccolte né i successivi impieghi consentiti.
Data breach, notifica e comunicazione
Nel nostro esempio, se il prospetto conteneva dati personali e questi sono stati divulgati a un destinatario non autorizzato, la validità delle credenziali non esclude una violazione di sicurezza ai sensi dell’articolo 4, punto 12, GDPR. Un tentativo respinto prima di produrre effetti sui dati richiederebbe invece una qualificazione diversa.
Dall’accertamento si passa poi alla valutazione del rischio per le persone: l’articolo 33 richiede al titolare di notificare la violazione senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza, salvo che sia improbabile un rischio per i loro diritti e libertà. Le informazioni mancanti possono essere fornite per fasi secondo le condizioni della disposizione. Attendere di avere spiegato ogni passaggio del comportamento dell’agente potrebbe far perdere tempo senza migliorare la decisione sulla notifica.
Per la comunicazione agli interessati, l’articolo 34 richiede un rischio elevato e contempla condizioni ed eccezioni proprie. Le due valutazioni devono rimanere riconoscibili nel fascicolo, così come l’eventuale esame degli obblighi NIS2 per i soggetti interessati. Gli articoli 21 e 23 della direttiva, attuati attraverso la disciplina nazionale e gli atti pertinenti, riguardano gestione del rischio e segnalazione degli incidenti significativi: l’origine nell’AI non determina da sola la significatività.
Una divulgazione può avere rilievo anche quando il servizio continua a funzionare, mentre un malfunzionamento visibile può non coinvolgere dati personali. Una cronologia comune aiuta chi conduce questi accertamenti, purché le conclusioni conservino il fondamento giuridico che compete a ciascuna.
Fornitore e valutazione d’impatto
I rapporti con il fornitore incidono sulla possibilità di rispettare i tempi. Quando questi opera come responsabile del trattamento, deve informare il titolare senza ingiustificato ritardo dopo aver conosciuto la violazione; l’assistenza prevista dall’articolo 28 va tradotta nella disponibilità concreta delle informazioni. Una clausola di collaborazione che tace sui log lascia aperta proprio la questione che diventerà urgente.
Andrebbero perciò chiarite le modalità di preservazione, i tempi della consegna e le limitazioni dell’esportazione, tenendo conto dei ruoli effettivi delle parti. Il fornitore potrebbe svolgere alcuni trattamenti su istruzione e altri per finalità proprie: l’etichetta contrattuale attribuita all’intero servizio non sostituisce l’esame delle operazioni.
Anche la valutazione d’impatto dell’articolo 35 dipende dal rischio elevato, secondo i criteri del GDPR. L’estensione degli accessi e la possibilità di agire senza conferma possono rendere necessario riesaminare una valutazione costruita quando l’assistente produceva soltanto bozze.
Autorizzazioni e controlli contro nuovi incidenti degli agenti AI
Dopo aver ricostruito il trasferimento, l’impresa dovrà decidere quali poteri restituire all’assistente. Il dipendente incaricato degli acquisti può avere buone ragioni per accedere a un intero archivio; al compito di confrontare tre offerte bastano molti meno documenti. Copiare nell’agente tutti i permessi dell’utente porta con sé questa differenza e amplia le conseguenze di un errore.
Dove il servizio lo consente, delimitare l’accesso al materiale pertinente e distinguere la lettura dalle operazioni che divulgano o modificano dati riduce l’esposizione. La scelta ha un costo organizzativo, perché qualcuno dovrà gestire le eccezioni. Conviene discuterlo durante l’acquisto, quando si può ancora scegliere come integrare il prodotto, anziché dopo aver scoperto che l’unica configurazione disponibile assegna poteri permanenti troppo estesi.
Controlli del connettore e conferma umana
Sul trasferimento all’esterno può intervenire un controllo del connettore che verifichi destinatario e documenti prima dell’esecuzione. Una condizione imposta in questo punto resta applicabile anche se il modello interpreta male il testo dell’offerta; affidarvi tutto il compito attraverso un’istruzione linguistica espone invece quella difesa all’ambiente che l’attaccante cerca di influenzare. Le misure possono convivere.
Occorre sapere quale di esse impedisca materialmente l’azione e provarla con casi che assomiglino al lavoro ordinario. Se si richiede una conferma umana, la schermata deve rendere comprensibile ciò che uscirà e verso chi; una successione di avvisi generici finirà facilmente per essere approvata senza lettura, soprattutto nei momenti di maggiore carico.
Arresto, revoca e verifica del contenimento
Nella stessa prova andrebbe verificato il significato del comando di arresto. Sospendere la chat può lasciare in esecuzione una richiesta già affidata a un altro servizio. Revocare il token impedisce nuove chiamate, ma può lasciare accessibile il collegamento pubblico creato poco prima. Per capire se il contenimento funzioni bisogna quindi osservare i sistemi coinvolti e accertare quali operazioni possano essere annullate. Da questa verifica emergeranno anche le informazioni da ottenere dal fornitore e i limiti da comunicare agli utenti, senza attribuire a un pulsante capacità che l’integrazione non possiede.
Responsabilità e prova prima della riattivazione
Nel verbale dell’incidente, infine, scrivere che «l’AI ha deciso di inviare i dati» aiuterebbe ben poco a distribuire le responsabilità. Servirà descrivere chi aveva assegnato l’incarico, quali poteri erano stati concessi e dove il controllo è mancato, lasciando aperto ciò che le prove non consentono ancora di concludere.
Per l’ufficio acquisti questa ricostruzione dovrebbe tradursi in una modifica verificabile prima di riattivare il servizio: lo stesso prospetto, indirizzato alla stessa destinazione estranea alla gara, deve essere fermato dal controllo previsto. La ricevuta della prova e il relativo log saranno documenti più utili dell’ennesima assicurazione dell’assistente di aver compreso le nuove istruzioni.
Partecipa alla community