ETD

• indirect prompt injection, provider deployer gap

AI assistants such as ChatGPT, Claude, and Gemini, when connected to a company's own email, documents, or internal tools, can be induced to quietly leak that organisation's data to a stranger instead, not because the underlying model has malfunctioned, but because a hidden instruction buried inside content it was asked to process directed it to do so. This is indirect prompt injection, and the underlying flaw is not limited to chatbots: it affects any AI system a business builds on a large language model that reads content it was not given directly by its own user and can then act on it, whether that is a chat assistant answering a question, a coding agent executing commands on its own, or a backend system with no chat window that a person ever sees. It exists because these models have no structural way to distinguish an instruction from the data they are asked to process, a property, not a design flaw, but the very thing that makes them useful in the first place. A closely related incident at Microsoft 365 Copilot in 2025 illustrates how such an attack can operate in practice: a single crafted email was reported to enable attackers to exfiltrate user data without a click or any action required of the victim.
This thesis asks why EU law leaves this gap open, and why no single actor currently has a legal duty to close it. The EU AI Act requires providers of general-purpose AI models to test for this kind of manipulation under Article 55 before releasing a model, and the Code of Practice implementing that duty has already been adopted by the major providers. But that testing happens on the model alone, in isolation, before deployment, and it cannot reach what actually creates the risk in practice: which documents a company connects to its AI, what tools it lets that AI use, and what data a compromised tool call could ultimately reach. Those choices are made separately by every business that deploys the technology, not by the provider, and no current instrument of EU law requires anyone to test them.
The AI Act's deployer-facing provisions, Articles 15 and 26, would in principle reach this problem, but they apply only where a system is independently classified as high-risk, which the ordinary enterprise deployment this thesis examines is not, and the 2026 Digital Omnibus reform has pushed even that narrower obligation back to December 2027 at the earliest. The GDPR applies throughout this period in principle, but Article 32 provides no benchmark for what constitutes adequate protection against this specific and relatively new risk, leaving both businesses and supervisory authorities without settled guidance on what compliance requires. Comparable regimes elsewhere in EU law, including the operational resilience testing required under the Digital Operational Resilience Act (DORA) and the cybersecurity duties imposed by the second Network and Information Security Directive (NIS2), show that deployment-specific testing obligations of exactly this kind are neither novel nor unworkable in practice; they simply have not yet been extended to this particular risk.
Having identified this provider-deployer gap, the thesis proposes two measures to narrow it without waiting for legislative reform or judicial development that would fully close it. In the short term, it drafts a Data Processing Agreement clause that businesses can adopt immediately, allocating testing and incident-response responsibilities between themselves and their AI provider. In the longer term, it proposes a statutory disclosure duty requiring providers to publish exactly what their pre-market testing did, and did not, cover, giving every deploying business, not only those with the bargaining power to negotiate favourable contract terms, the same baseline information about the risk they are taking on.

Gli assistenti AI come ChatGPT, Claude e Gemini, quando collegati alla posta elettronica, ai documenti o agli strumenti interni di un'azienda, possono essere indotti a far trapelare silenziosamente i dati di quell'organizzazione a uno sconosciuto, non perché il modello sottostante abbia malfunzionato, ma perché un'istruzione nascosta nel contenuto che gli è stato chiesto di elaborare lo ha indirizzato a farlo. Questa è l'iniezione indiretta di prompt, e il difetto sottostante non si limita ai chatbot: riguarda qualsiasi sistema di intelligenza artificiale costruito su un modello linguistico di grandi dimensioni che legge contenuti non forniti direttamente dall'utente e può agire su di essi, che si tratti di un assistente chat che risponde a una domanda, di un agente di programmazione che esegue comandi autonomamente, o di un sistema di backend senza finestra di chat visibile a una persona. Esiste perché questi modelli non hanno un modo strutturale per distinguere un'istruzione dai dati che devono elaborare, una proprietà, non un difetto di progettazione, ma proprio ciò che li rende utili in primo luogo. Un incidente strettamente correlato al Microsoft 365 Copilot nel 2025 illustra come un attacco di questo tipo possa operare in pratica: è stato segnalato che un'email appositamente creata consentiva agli attaccanti di esfiltrare dati degli utenti senza cliccare né richiedere alcuna azione alla vittima.
Questa tesi si interroga sul motivo per cui la legge dell'UE lascia aperto tale vuoto e sul perché nessun attore abbia attualmente l'obbligo legale di colmarlo. Il Regolamento UE sull'IA richiede ai fornitori di modelli di IA di uso generale di testare questo tipo di manipolazioni ai sensi dell'Articolo 55 prima di rilasciare un modello, e il Codice di Condotta che attua tale obbligo è già stato adottato dai principali fornitori. Tuttavia, tali test vengono effettuati solo sul modello, in isolamento, prima della distribuzione, e non possono simulare ciò che, in pratica, crea il rischio: quali documenti un'azienda collega alla sua IA, quali strumenti permette di usare e quali dati potrebbe raggiungere un tool compromesso. Queste scelte sono fatte separatamente da ciascuna azienda che distribuisce la tecnologia, non dal fornitore, e attualmente nessuno strumento dell'UE impone di testarle.
Le disposizioni dell'AI Act rivolte ai deployer, gli articoli 15 e 26, coprirebbero in teoria questo problema, ma si applicano solo quando un sistema è classificato ad alto rischio, cosa che l'implementazione aziendale ordinaria analizzata in questa tesi non è. Inoltre, la riforma digitale Omnibus del 2026 ha spostato quell'obbligo più ristretto al dicembre 2027, al più presto. In linea di principio, il GDPR si applica per tutto questo periodo, ma l'Articolo 32 non fornisce un criterio di riferimento su ciò che costituisca una protezione adeguata contro questo rischio specifico e relativamente nuovo, lasciando sia le aziende che le autorità di vigilanza senza linee guida definitive su ciò che richieda la conformità. Regimi comparabili altrove nel diritto dell'UE, come i test di resilienza operativa richiesti dal Digital Operational Resilience Act (DORA) e i doveri di cybersecurity imposti dalla seconda Direttiva NIS (NIS2), dimostrano che obblighi di test specifici per la distribuzione di questo tipo non sono né innovativi né impraticabili in pratica; semplicemente, non sono ancora stati estesi a questo rischio specifico.
Dopo aver individuato questa lacuna tra fornitore e deployer, la tesi propone due misure per ridurla senza attendere riforme legislative o sviluppi giudiziari che la colmino completamente. A breve terminerò; si propone una clausola di accordo sul trattamento dei dati che le aziende possono adottare immediatamente, assegnando tra loro e con il fornitore di IA le responsabilità di test e di risposta agli incidenti. A lungo termine, si propone un obbligo legale di divulgazione che imponga ai fornitori di pubblicare esattamente che cosa hanno coperto e che cosa no nei loro test pre-market, offrendo a ogni azienda che distribuisce, non solo a quelle con potere contrattuale favorevole, le stesse informazioni di base sul rischio che assumono.