Ghostjacking: quando l’agente AI diventa vettore di attacco interno

Premessa

La tecnica offensiva denominata “ghostjacking” descrive una situazione nella quale un’azione apparentemente innocua — l’inserimento di una voce manipolata in un registro di sicurezza o in un log di sistema — è sufficiente a indurre un agente di intelligenza artificiale aziendale a eseguire operazioni dannose, trasformandolo di fatto in uno strumento di attacco interno. La tecnica si colloca nell’ampia famiglia delle “prompt injection” indirette, già oggetto di attenzione da parte dell’ENISA e dell’OWASP, e presenta caratteri di particolare insidiosità perché non richiede accesso diretto ai sistemi bersaglio: l’agente AI, dotato di permessi legittimi, diventa il veicolo dell’offesa.

Per quanto di stretto interesse in questa sede, il fenomeno si colloca all’intersezione di tre grandi corpi normativi europei che si trovano in fase di piena applicazione o di progressiva entrata a regime: il Regolamento (UE) 2016/679 (GDPR), il Regolamento (UE) 2024/1689 sull’intelligenza artificiale (AI Act), e la Direttiva (UE) 2022/2555 in materia di sicurezza delle reti e dei sistemi informativi (NIS2), recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138. Vengono inoltre in rilievo le Linee Guida dell’EDPB, i provvedimenti del Garante per la protezione dei dati personali e le indicazioni operative emanate dall’Agenzia per la Cybersicurezza Nazionale (ACN).

Il presente contributo si propone di analizzare la natura tecnica e giuridica del ghostjacking, di mappare il quadro normativo applicabile e di fornire indicazioni operative per i DPO e i responsabili della compliance nelle organizzazioni che impiegano sistemi di intelligenza artificiale agentica.

La tecnica del ghostjacking: definizione, meccanismo e tassonomia

Il termine “ghostjacking” — va detto sin dall’inizio — non è ancora consolidato nella letteratura tecnica ufficiale né è oggetto di una definizione normativa. Si tratta, infatti, di una denominazione emergente per una variante evoluta di prompt injection indiretta, nella quale il vettore di attacco non è un input dell’utente umano all’agente AI, bensì un dato esterno che l’agente legge autonomamente nel corso della propria operatività.

In termini più pragmatici: un agente AI aziendale — si pensi a un sistema di monitoraggio della sicurezza, a un assistente alla gestione degli incidenti, o a un copilot integrato nei sistemi DevOps — opera leggendo fonti di dati strutturati: log di sistema, registri di eventi, database di ticket, output di tool di orchestrazione. Se uno di questi dati contiene una stringa progettata per essere interpretata come istruzione dall’agente, quest’ultimo può eseguire l’istruzione stessa con i propri privilegi, che sono per definizione legittime credenziali di sistema.

La differenza rispetto alla prompt injection diretta — già ampiamente studiata — risiede nella superficie di attacco. Mentre la prompt injection diretta richiede accesso all’interfaccia utente del modello, quella indiretta, di cui il ghostjacking è una declinazione, sfrutta la catena di approvvigionamento dei dati che l’agente elabora.

L’ENISA, nel suo rapporto sulle minacce emergenti ai sistemi di AI (ENISA, Threat Landscape for Artificial Intelligence), ha già censito le prompt injection indirette come una delle principali categorie di rischio per i sistemi di intelligenza artificiale dispiegati in contesti aziendali. Analogamente, l’OWASP Top 10 for Large Language Model Applications annovera la “Indirect Prompt Injection” tra le vulnerabilità critiche per i sistemi LLM.

Il ghostjacking si distingue ulteriormente per il fatto che il vettore di iniezione è specificamente un registro di sicurezza o un log di evento, ovvero un dato che per sua natura è letto frequentemente dagli agenti di monitoraggio e che gode di un livello di fiducia elevato nell’architettura di sicurezza dell’organizzazione. Trattasi, in altri termini, di un attacco che mina la catena di fiducia interna ai sistemi informativi, sfruttando le stesse misure difensive come punto di ingresso.

Il quadro normativo di riferimento

Il Regolamento (UE) 2016/679 (GDPR)

Il GDPR non disciplina direttamente gli agenti di intelligenza artificiale né le tecniche di prompt injection, ma fornisce il quadro entro cui valutare le conseguenze di un attacco ghostjacking quando questo coinvolge dati personali — circostanza tutt’altro che ipotetica, considerato che i log di sistema spesso contengono informazioni personali riferibili a dipendenti, utenti o soggetti terzi.

L’articolo 5, paragrafo 1, lettera f), del GDPR sancisce il principio di “integrità e riservatezza”, imponendo che i dati personali siano trattati in maniera da garantirne “un’adeguata sicurezza […], compresa la protezione, mediante misure tecniche e organizzative adeguate, da trattamenti non autorizzati o illeciti e dalla perdita, dalla distruzione o dal danno accidentali.” Un agente AI compromesso che accede, esfiltra o modifica dati personali costituisce per definizione un trattamento non autorizzato, con conseguente violazione del principio di integrità e riservatezza.

L’articolo 32 GDPR, che declina il principio di sicurezza in obblighi concreti, richiede al titolare e al responsabile del trattamento di adottare misure tecniche e organizzative adeguate, tenendo conto — tra gli altri elementi — “della natura, dell’ambito di applicazione, del contesto e delle finalità del trattamento, nonché del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fisiche.” È di immediata evidenza che un sistema di AI agentica con accesso a repository di dati personali configura un contesto ad elevato rischio, che impone misure corrispondentemente rafforzate.

L’articolo 33 GDPR disciplina la notifica al Garante in caso di violazione dei dati personali, fissando il termine di settantadue ore dalla conoscenza dell’evento. Un attacco ghostjacking che determini accesso non autorizzato, perdita o alterazione di dati personali costituisce, ad ogni evidenza, una “violazione dei dati personali” ai sensi dell’articolo 4, paragrafo 12, GDPR, con conseguente obbligo di notifica — salvo che l’organizzazione sia in grado di dimostrare che “è improbabile che la violazione dei dati personali presenti un rischio per i diritti e le libertà delle persone fisiche.” Questa condizione appare difficilmente sostenibile quando l’agente compromesso aveva accesso a sistemi sensibili.

La Data Protection Impact Assessment (DPIA), prevista dall’articolo 35 GDPR, riveste un ruolo centrale: si ritiene che qualunque sistema di AI agentica con accesso a dati personali e con capacità di azione autonoma su sistemi informativi debba essere soggetto a DPIA preliminare, in ragione dell’elevato rischio strutturale che presenta. Il Garante italiano ha già indicato, nei propri provvedimenti in materia di AI, che i sistemi dotati di autonomia decisionale e accesso massivo a dati personali rientrano nelle categorie per le quali la DPIA è obbligatoria.

Il Regolamento (UE) 2024/1689 (AI Act)

L’AI Act, entrato in vigore il 1° agosto 2024, con applicazione progressiva delle diverse disposizioni sino al 2027, introduce un sistema di classificazione dei sistemi di AI per livello di rischio che rileva direttamente ai fini dell’analisi del ghostjacking.

Va detto che la categoria degli “agenti AI” non è disciplinata dall’AI Act con una norma ad hoc: la nozione di “sistema di intelligenza artificiale” rilevante è quella dell’articolo 3, paragrafo 1, AI Act, che definisce il sistema di AI come “un sistema automatizzato progettato per funzionare con livelli di autonomia variabili e che, per obiettivi espliciti o impliciti, inferisce, a partire dagli input che riceve, come generare output quali previsioni, contenuti, raccomandazioni o decisioni che possono influenzare ambienti fisici o virtuali.” Gli agenti AI aziendali rientrano senza difficoltà in questa definizione.

La classificazione per livello di rischio dell’AI Act determina gli obblighi applicabili. Per i sistemi di AI ad “alto rischio” — che includono, ai sensi dell’Allegato III, i sistemi destinati a essere utilizzati come componenti di sicurezza nella gestione e nel funzionamento delle infrastrutture digitali critiche — l’AI Act impone una serie di requisiti di robustezza, trasparenza e supervisione umana che appaiono direttamente pertinenti al problema del ghostjacking.

In particolare, l’articolo 9 AI Act richiede l’adozione di un sistema di gestione dei rischi “continuo e iterativo”, che identifichi e mitighi i rischi noti e ragionevolmente prevedibili per i sistemi ad alto rischio. L’articolo 15 impone requisiti di “accuratezza, robustezza e cybersicurezza”, stabilendo che i sistemi di AI ad alto rischio devono essere “progettati e sviluppati in modo da raggiungere un livello appropriato di accuratezza, robustezza e cybersicurezza” e “da resistere, nei limiti del ragionevole, ai tentativi di soggetti terzi non autorizzati di alterarne l’uso, gli output o le prestazioni attraverso l’utilizzo di vulnerabilità.” Il ghostjacking è per l’appunto un tentativo di questo tipo.

L’articolo 14 AI Act disciplina la “supervisione umana” (human oversight), richiedendo che i sistemi ad alto rischio siano progettati in modo da consentire agli utenti di monitorare il funzionamento e di intervenire, sospendere o interrompere l’operatività del sistema. Questa previsione ha un’immediata ricaduta sulla progettazione degli agenti AI: un sistema privo di meccanismi efficaci di supervisione umana che venga compromesso tramite ghostjacking non solo subisce un danno, ma viola anche i requisiti strutturali dell’AI Act.

Per i sistemi di AI a uso generale (General Purpose AI — GPAI), disciplinati dagli articoli da 51 a 56 AI Act, vigono obblighi specifici per i fornitori, tra cui la predisposizione di politiche di sicurezza e la documentazione delle capacità e limitazioni del modello. Chi integra un modello GPAI in un agente aziendale riveste spesso anche il ruolo di “deployer” ai sensi dell’AI Act, con obblighi corrispondenti in materia di monitoraggio e supervisione.

La Direttiva NIS2 e il decreto legislativo n. 138/2024

La Direttiva (UE) 2022/2555 (NIS2), recepita in Italia con il decreto legislativo 4 settembre 2024, n. 138, introduce obblighi di sicurezza informatica per i soggetti essenziali e importanti operanti in settori critici. Per quanto di stretto interesse in questa sede, la NIS2 rileva sotto tre profili principali.

Il primo profilo riguarda le misure di sicurezza. L’articolo 21 della Direttiva NIS2 — recepito dall’articolo 24 del d.lgs. 138/2024 — impone ai soggetti interessati di adottare misure tecniche, operative e organizzative “adeguate e proporzionate” per gestire i rischi posti alla sicurezza dei sistemi informativi, tra cui esplicitamente: la gestione degli incidenti, la sicurezza della catena di approvvigionamento, le pratiche di igiene informatica di base, le politiche relative all’uso della crittografia, la sicurezza delle risorse umane e il controllo degli accessi. Un sistema di AI agentica compromesso tramite ghostjacking costituisce tipicamente un incidente di sicurezza rilevante ai fini della NIS2.

Il secondo profilo riguarda la notifica degli incidenti. L’articolo 23 della Direttiva NIS2 — recepito dall’articolo 25 del d.lgs. 138/2024 — prevede una procedura di notifica articolata: un “preallarme” entro ventiquattro ore dalla conoscenza dell’incidente significativo, una notifica completa entro settantadue ore, e una relazione finale entro un mese. L’ACN è il CSIRT nazionale designato per la ricezione delle notifiche. Un attacco ghostjacking che comprometta sistemi rilevanti di un soggetto essenziale o importante è suscettibile di configurare un “incidente significativo” ai sensi dell’articolo 23, paragrafo 3, della Direttiva.

Il terzo profilo riguarda la responsabilità del management. L’articolo 20 della Direttiva NIS2 — recepito dall’articolo 23 del d.lgs. 138/2024 — impone agli organi di gestione dei soggetti essenziali e importanti di approvare le misure di sicurezza, di supervisionarne l’attuazione e di rispondere personalmente in caso di violazione. Ciò implica che la decisione di dispiegare sistemi di AI agentica senza adeguata analisi del rischio non è una questione tecnica delegabile, ma una decisione di governance con conseguenze dirette in capo al management.

Le Linee Guida dell’EDPB e i provvedimenti del Garante

L’EDPB ha adottato, nel corso degli anni, diversi documenti rilevanti per il tema in esame, unitamente a quelli ereditati dal Gruppo di lavoro Articolo 29. [Nota redazionale: verificare gli estremi di eventuali linee guida EDPB in materia di uso di sistemi di AI nel contesto lavorativo prima della pubblicazione; le Linee Guida 05/2022 hanno per oggetto l’uso della tecnologia di riconoscimento facciale da parte delle autorità di contrasto.] Il Parere 2/2017 del Gruppo di lavoro Articolo 29 sul trattamento dei dati sul luogo di lavoro (WP 249) rileva per i log di sistema che contengano dati riferibili ai dipendenti.

Il Garante per la protezione dei dati personali ha mostrato un’attenzione crescente ai sistemi di AI: si ricordano, in questa sede, i provvedimenti in materia di ChatGPT (provvedimento del 30 marzo 2023 e successivi aggiornamenti), che hanno fissato principi applicabili anche ai sistemi di AI dispiegati in contesti aziendali, e le indicazioni generali sui sistemi di monitoraggio dei lavoratori che impiegano tecnologie di AI. Non si ha evidenza, alla data del presente contributo, di provvedimenti specifici del Garante in materia di prompt injection o ghostjacking, ma le categorie concettuali già elaborate sono pienamente applicabili.

Analisi giuridica del fenomeno: responsabilità, qualificazioni e nessi causali

La qualificazione del ghostjacking come trattamento non autorizzato

Quando un agente AI compromesso tramite ghostjacking accede, copia, modifica o trasmette dati personali, si realizza un trattamento non autorizzato ai sensi del GDPR. La peculiarità giuridica del fenomeno sta nel fatto che l’agente opera con credenziali legittime: non vi è, dal punto di vista tecnico, un accesso non autorizzato nel senso tradizionale (violazione di autenticazione o bypass di controllo degli accessi), ma vi è un uso distorto di accessi legittimi per finalità non autorizzate.

Questa circostanza non esclude la violazione del GDPR: il principio di “limitazione della finalità” di cui all’articolo 5, paragrafo 1, lettera b), GDPR impone che i dati personali siano trattati “per finalità determinate, esplicite e legittime, e successivamente trattati in modo che non sia incompatibile con tali finalità.” L’uso dell’agente AI per finalità imposte da un attaccante esterno è manifestamente incompatibile con qualsiasi finalità determinata e legittima.

Il nesso di causalità e la responsabilità del titolare del trattamento

Un profilo problematico — e, secondo il parere di chi scrive, tra i più interessanti sotto il profilo dogmatico — riguarda il nesso di causalità tra la condotta del titolare del trattamento e il danno prodotto dall’attacco ghostjacking.

Il GDPR adotta, all’articolo 82, un regime di responsabilità civile per danni derivanti da violazione del Regolamento che prevede un’inversione dell’onere della prova: il titolare o il responsabile è responsabile del danno cagionato da un trattamento non conforme al GDPR, salvo che dimostri “che l’evento dannoso non gli è in alcun modo imputabile.” La Corte di Giustizia dell’Unione Europea, nella sentenza del 4 maggio 2023 (causa C-300/21, UI c. Österreichische Post AG), ha chiarito che non esiste una soglia minima di gravità del danno per l’accesso al risarcimento, ma che il danno deve essere reale e non meramente ipotetico.

Il titolare del trattamento che ha dispiegato un agente AI senza adeguata analisi del rischio, senza DPIA, senza misure di sicurezza appropriate ai sensi dell’articolo 32 GDPR, difficilmente potrà invocare l’esonero da responsabilità. La robustezza del sistema rispetto alle prompt injection è da considerarsi un rischio “ragionevolmente prevedibile” — come attestano i documenti ENISA e OWASP già citati — e la sua mancata considerazione configura culpa in eligendo e in vigilando.

La responsabilità ai sensi dell’AI Act

L’AI Act introduce, agli articoli 72 e seguenti, un sistema di sorveglianza del mercato e di enforcement. Per i sistemi ad alto rischio, la mancata adozione delle misure di cybersicurezza previste dall’articolo 15 può comportare sanzioni amministrative sino a 15 milioni di euro o al 3% del fatturato mondiale annuo totale, a seconda di quale importo sia superiore, ai sensi dell’articolo 99, paragrafo 4, AI Act.

A livello nazionale, si applica il regime generale della responsabilità extracontrattuale e, per i produttori di sistemi AI, il Codice del Consumo e la normativa sui prodotti difettosi.

Il profilo penale: la rilevanza del reato informatico

Sotto il profilo penale, l’attacco ghostjacking — nella fase realizzata dall’aggressore — può integrare diverse fattispecie del codice penale italiano. L’articolo 615-ter c.p. (accesso abusivo a un sistema informatico) potrebbe essere integrato dalla condotta dell’aggressore che inserisce la stringa malevola nel log, qualora ciò implichi accesso non autorizzato al sistema di logging. L’articolo 617-quater c.p. (intercettazione, impedimento o interruzione illecita di comunicazioni informatiche) e l’articolo 635-bis c.p. (danneggiamento di informazioni, dati e programmi informatici) possono rilevare a seconda dell’esito dell’attacco.

Per l’organizzazione vittima, il profilo penale rileva indirettamente: la mancata adozione di misure di sicurezza adeguate può essere elemento valutabile nell’ambito del d.lgs. 231/2001, qualora l’ente non abbia adottato un modello organizzativo adeguato che preveda presidi specifici per i rischi connessi all’uso di sistemi AI.

Profili critici: le zone grigie del quadro normativo vigente

L’assenza di una disciplina specifica per gli agenti AI

Si ritiene che una delle lacune più significative del quadro normativo vigente sia l’assenza di una disciplina specifica per gli agenti AI autonomi — ossia per quei sistemi che non si limitano a generare testo o raccomandazioni, ma che compiono azioni concrete su sistemi informativi, interagiscono con API esterne, modificano database, inviano comunicazioni.

L’AI Act disciplina i “sistemi di AI” in senso lato, ma non contiene una regolamentazione ad hoc dell’AI agentica, la cui specificità risiede proprio nella capacità di azione autonoma e nella conseguente amplificazione del rischio. Nè si ha evidenza, allo stato, di documenti interpretativi da parte della Commissione europea o dell’AI Office che colmino questa lacuna.

Il problema del “trust boundary” nei sistemi di logging

Un profilo tecnico-giuridico di notevole interesse riguarda la questione del “trust boundary” — ossia del perimetro di fiducia entro cui un sistema AI è autorizzato a operare. I log di sicurezza sono tradizionalmente considerati fonti affidabili nell’architettura di sicurezza aziendale: sono generati da sistemi interni, protetti da controlli di accesso, e letti da strumenti di analisi con elevati privilegi.

Il ghostjacking sovverte questa logica: trasforma una fonte fidata in vettore di attacco. Da un punto di vista giuridico, ciò pone la questione se il titolare del trattamento — e il produttore del sistema AI — debbano considerare anche le fonti di dati interne come potenzialmente compromesse, e dunque adottare misure di sanitizzazione degli input anche per i log di sistema.

Si ritiene che questa sia una misura che rientra nel novero di quelle “adeguate” ai sensi dell’articolo 32 GDPR e dell’articolo 15 AI Act, considerato lo stato attuale della conoscenza tecnica sul tema. In termini più pragmatici: un sistema AI che accetta come istruzione qualsiasi stringa contenuta in un log non ha implementato misure di sicurezza adeguate per il contesto in cui è dispiegato.

La sovrapposizione di regimi normativi e il rischio di frammentazione della compliance

Un ulteriore profilo critico riguarda la sovrapposizione — non sempre coordinata — tra GDPR, AI Act e NIS2 in relazione allo stesso evento. Un incidente ghostjacking che coinvolga dati personali e colpisca un soggetto essenziale ai sensi della NIS2 genera obblighi di notifica paralleli: al Garante (art. 33 GDPR, entro 72 ore), all’ACN/CSIRT nazionale (art. 25 d.lgs. 138/2024, entro 24 ore per il preallarme), e — qualora il sistema AI coinvolto sia ad alto rischio — eventualmente anche all’autorità di vigilanza sull’AI Act.

Appare chiaro allo scrivente che questa frammentazione dei canali di notifica e delle autorità competenti genera un rischio operativo significativo per le organizzazioni, che possono trovarsi a dover gestire contemporaneamente più procedimenti con tempistiche differenti e interlocutori diversi. Una risposta coordinata richiede che i piani di incident response siano predisposti tenendo conto di tutti e tre i regimi, con processi interni chiari e responsabilità assegnate.

Adempimenti per DPO e imprese

Alla luce di quanto sviluppato nei paragrafi precedenti, possono, a titolo esemplificativo, essere proposti alcuni adempimenti basilari per imprese e DPO strutturati secondo un approccio progressivo dalla fase di progettazione a quella di gestione degli incidenti.

Va innanzitutto effettuata la mappatura dei sistemi AI agentici. il DPO e il responsabile della sicurezza devono condurre una ricognizione completa dei sistemi di AI dotati di capacità di azione autonoma su sistemi informativi aziendali, distinguendo tra sistemi sviluppati internamente, sistemi acquisiti da fornitori e sistemi basati su modelli GPAI di terze parti. La mappatura deve includere le fonti di dati lette dall’agente (log, database, API, strumenti di orchestrazione), i privilegi di accesso di cui dispone e le azioni che è autorizzato a compiere.

Occorre, inoltre, procedere alla classificazione del rischio AI Act. Per ciascun sistema di AI agentica identificato, è necessario determinare la categoria di rischio applicabile ai sensi dell’AI Act (rischio inaccettabile, alto rischio, rischio limitato, rischio minimo) e verificare se il sistema rientra in una delle categorie dell’Allegato III. I sistemi di AI impiegati nella gestione della sicurezza informatica e nel controllo degli accessi sono candidati forti alla classificazione come sistemi ad alto rischio, con conseguente applicazione degli obblighi previsti dagli articoli da 9 a 16 AI Act.

Va eseguita la DPIA, perché per tutti i sistemi di AI agentici che trattano dati personali e presentano un rischio elevato, è obbligatoria l’esecuzione di una DPIA ai sensi dell’articolo 35 GDPR, prima del dispiegamento del sistema. La DPIA deve includere una valutazione specifica del rischio di prompt injection indiretta e ghostjacking, con descrizione delle misure di mitigazione adottate.

Analogamente, appare utile procedere ad una revisione architetturale dei sistemi AI. In collaborazione con i team tecnici, il DPO deve verificare che i sistemi AI agentici dispiegati implementino misure di sicurezza adeguate rispetto al rischio di ghostjacking, tra cui: separazione logica tra dati di configurazione e dati elaborati, sanitizzazione degli input provenienti da fonti esterne (inclusi i log di sistema), meccanismi di validazione delle istruzioni rispetto a un insieme predefinito di azioni autorizzate, e sistemi di logging delle azioni dell’agente AI separati dai log di sistema generali.

Essenziale, inoltre, appare l’aggiornamento dei contratti con i fornitori di AI, per cui le clausole contrattuali relative ai sistemi di AI forniti da terze parti devono essere integrate con previsioni specifiche in materia di sicurezza rispetto alle vulnerabilità di tipo prompt injection, obblighi di notifica in caso di scoperta di vulnerabilità nel sistema AI, e attestazioni di conformità all’articolo 15 AI Act per i sistemi ad alto rischio.

Di particolare importanza anche la formazione del personale. Infatti, i team che gestiscono sistemi di AI agentici devono ricevere formazione specifica sui rischi di prompt injection e ghostjacking, con particolare attenzione ai segnali di compromissione (comportamenti anomali dell’agente, azioni non attese, accessi a risorse non usuali) e alle procedure di escalation e contenimento.

I piani di incident response devono essere aggiornati per includere scenari specifici di compromissione di agenti AI, con indicazione delle soglie di notifica, dei canali di comunicazione (Garante e ACN) e dei responsabili interni. Il piano deve prevedere la possibilità di sospendere immediatamente l’operatività dell’agente AI compromesso senza interrompere i sistemi sottostanti.

Sotto il profilo degli adempimenti GDPR, occorrerà procedere alla revisione dei registri delle attività di trattamento (RAT). il registro ex articolo 30 GDPR deve essere aggiornato per includere i trattamenti di dati personali effettuati tramite agenti AI, con indicazione specifica delle fonti di dati elaborate, delle finalità, delle categorie di dati coinvolti e delle misure di sicurezza adottate. Sotto lo stesso profilo, dovrà procedersi alla supervisione del fornitore di AI come responsabile del trattamento, poiché qualora il sistema AI sia gestito da un fornitore esterno che accede a dati personali dell’organizzazione, è necessario verificare la sussistenza di un accordo di responsabilità del trattamento ai sensi dell’articolo 28 GDPR, con previsione specifica degli obblighi di sicurezza applicabili ai sistemi di AI agentici.

Da ultimo, occorrerà verificare la conformità NIS2 dei sistemi in uso, perché i soggetti che rientrano nell’ambito di applicazione del d.lgs. 138/2024 devono verificare che la gestione del rischio connesso ai sistemi di AI agentici sia integrata nel sistema di gestione della sicurezza informatica richiesto dall’articolo 24 del decreto, con documentazione delle misure adottate e dei processi di revisione periodica.

Considerazioni sulla progettazione sicura dei sistemi di AI agentica: il principio di “security by design”

Il principio di “privacy by design e by default” — sancito dall’articolo 25 GDPR e ispirato alla filosofia progettuale di Ann Cavoukian — trova un corrispondente nel principio di “security by design” che permea l’articolo 15 dell’AI Act e l’approccio NIS2 alla gestione del rischio. Per quanto di stretto interesse in questa sede, entrambi i principi impongono che la sicurezza non sia aggiunta ex post come strato superficiale, ma sia integrata sin dalla fase di progettazione del sistema.

In termini più pragmatici: un sistema di AI agentica che non sia stato progettato tenendo conto del rischio di prompt injection indiretta non potrà essere reso sicuro semplicemente aggiungendo filtri successivi. Le scelte architetturali fondamentali — la definizione del “trust boundary” dell’agente, il meccanismo di validazione degli input, l’insieme delle azioni autorizzate, i meccanismi di supervisione umana — devono essere effettuate sin dall’inizio, con documentazione adeguata delle scelte e delle motivazioni.

L’ENISA, nelle proprie linee guida sulla sicurezza dei sistemi di AI, raccomanda l’adozione di un approccio “least privilege” per gli agenti AI: l’agente deve disporre del minimo insieme di privilegi necessari per svolgere il proprio compito, in modo che una sua eventuale compromissione abbia un impatto limitato. Questo principio — ben noto nell’ambito della sicurezza informatica tradizionale — assume un’importanza ancora maggiore nel contesto dei sistemi AI agentici, che per loro natura tendono ad accumulare permessi per poter operare in modo efficace.

Si suggerisce, in questa prospettiva, di adottare un modello di “sandboxing” per gli agenti AI: confinare l’operatività dell’agente in un ambiente controllato, con accessi limitati e monitorati, e con meccanismi di approvazione umana per le azioni ad alto impatto. Questo approccio è coerente con il requisito di supervisione umana dell’articolo 14 AI Act e con il principio di minimizzazione del rischio del GDPR.

Il ruolo del DPO nella governance dei sistemi di AI agentica

Il DPO — figura prevista dall’articolo 37 GDPR e dotata dei compiti di cui all’articolo 39 — è chiamato a svolgere un ruolo centrale nella governance dei sistemi di AI agentica, ruolo che va ben oltre la tradizionale consulenza in materia di trattamento dei dati personali.

In termini più concreti: il DPO deve essere coinvolto sin dalla fase di selezione e progettazione dei sistemi di AI agentici, non solo nella fase di implementazione o, peggio, di risposta agli incidenti. Questo coinvolgimento precoce è funzionale alla conduzione della DPIA, alla valutazione delle misure di sicurezza adottate e alla verifica della conformità al GDPR e all’AI Act.

Va detto che l’AI Act introduce, accanto al DPO, ulteriori figure di governance: il “deployer responsabile” dei sistemi ad alto rischio (art. 26 AI Act) e — per i sistemi GPAI — gli obblighi specifici in capo al fornitore del modello. In sostanza, si profila un sistema di governance multilivello in cui DPO, CISO, Legal e management sono chiamati a operare in modo coordinato, con responsabilità e compiti chiaramente definiti.

Il tema della catena di approvvigionamento dell’AI: responsabilità lungo la filiera

Un profilo di crescente rilevanza pratica riguarda la catena di approvvigionamento dei sistemi di AI agentici. Nella maggior parte dei casi, un’organizzazione non sviluppa internamente il modello di AI che alimenta il proprio agente: acquista o licenzia un modello GPAI da un fornitore (tipicamente un grande operatore tecnologico internazionale), lo integra in un’architettura di orchestrazione, lo collega ai propri sistemi informativi e lo configura per i propri casi d’uso.

In questo schema, la responsabilità per le vulnerabilità del sistema — inclusa la suscettibilità a prompt injection indirette — è distribuita lungo la filiera. Il fornitore del modello GPAI è responsabile della robustezza intrinseca del modello rispetto alle tecniche di injection. Il fornitore del framework di orchestrazione è responsabile della sicurezza dell’architettura di integrazione. L’organizzazione deployer è responsabile della configurazione sicura, della definizione dei privilegi dell’agente e delle misure di supervisione.

L’AI Act affronta questo tema attraverso il sistema di obblighi differenziati per fornitori e deployer, ma — secondo il parere di chi scrive — non fornisce una risposta esaustiva al problema della responsabilità condivisa in caso di incidente che coinvolga più livelli della filiera. In assenza di una chiarificazione normativa o interpretativa, si suggerisce alle organizzazioni di disciplinare contrattualmente — in modo puntuale e non generico — la ripartizione delle responsabilità in caso di incidente connesso a vulnerabilità del sistema AI, incluse le vulnerabilità di tipo ghostjacking.

Conclusioni

Il ghostjacking, pur essendo una tecnica emergente ancora priva di una definizione normativa consolidata, rappresenta un caso esemplare delle tensioni che i sistemi di AI agentica introducono nel quadro giuridico europeo. Esso mette in evidenza almeno tre questioni aperte di rilievo sistematico, sulle quali si attende un’evoluzione normativa e interpretativa nei prossimi anni.

La prima questione riguarda l’adeguatezza del concetto di “misura tecnica adeguata” rispetto alla specificità dei rischi dell’AI agentica. L’articolo 32 GDPR e l’articolo 15 AI Act fanno entrambi riferimento a misure “adeguate” rispetto allo stato dell’arte e al rischio, ma la determinazione di cosa sia adeguato rispetto a tecniche di attacco come il ghostjacking richiede standard tecnici specifici che, alla data del presente contributo, non sono stati emanati né dall’ENISA né dall’AI Office. Si auspica che i prossimi documenti tecnici di questi organismi colmino questa lacuna.

La seconda questione riguarda la governance della catena di approvvigionamento dell’AI. La distribuzione della responsabilità tra fornitori di modelli, fornitori di framework di orchestrazione e deployer finali è, allo stato attuale, affidata principalmente alla contrattualistica privata, senza una disciplina normativa chiara.

La terza questione riguarda il coordinamento tra le autorità di supervisione. Un incidente ghostjacking che coinvolga dati personali, sistemi essenziali ai sensi della NIS2 e sistemi AI ad alto rischio genera, come si è visto, obblighi di notifica verso il Garante, verso l’ACN e — prospetticamente — verso l’autorità di vigilanza sull’AI Act. La frammentazione di questi canali, con tempistiche diverse e interlocutori diversi, costituisce un rischio operativo reale che richiede non solo adeguamenti interni alle organizzazioni, ma anche un coordinamento istituzionale tra le autorità nazionali. Non si ha evidenza, alla data del presente contributo, di meccanismi formali di coordinamento tra il Garante e l’ACN specificamente per gli incidenti che coinvolgano sistemi di AI, sebbene il d.lgs. 138/2024 preveda forme generali di cooperazione tra autorità.

In prospettiva evolutiva, appare chiaro allo scrivente che il quadro normativo europeo dovrà affrontare, nei prossimi anni, la sfida di disciplinare in modo più specifico l’AI agentica — un paradigma tecnologico che differisce sostanzialmente dall’AI generativa tradizionale per la sua capacità di azione autonoma e per la conseguente amplificazione dei rischi. Le organizzazioni che oggi dispiegano sistemi di AI agentici si trovano in una fase di transizione normativa complessa, in cui la prudenza, la documentazione delle scelte e il coinvolgimento precoce di tutte le funzioni di governance — DPO, CISO, Legal, management — rappresentano gli strumenti operativi di riferimento.