Il caso giudiziario più interessante in materia di prompt injection, finora, non è nato da malware, exploit complessi o compromissioni infrastrutturali. Nasce da una tecnica quasi banale: testo bianco su sfondo bianco inserito in un atto processuale.
Proprio questa banalità rende il precedente brasiliano così importante.
Quando un deposito digitale entra in una pipeline di intelligenza artificiale, ciò che conta non è solo ciò che il giudice vede, ma anche ciò che la macchina legge.
Il caso Galileu impone una riflessione anche all’Europa e all’Italia.
L’atto processuale, originariamente destinato alla lettura umana, diventa anche materiale elaborabile da strumenti automatici. Se diventasse input computazionale, potrebbe diventare payload.
Da ciò derivano conseguenze tecniche, giuridiche e deontologiche per magistrati, pubbliche amministrazioni, avvocati, consulenti tecnici e fornitori di soluzioni legal-tech.
Indice degli argomenti
Il caso Galileu: la banalità tecnica di un precedente storico
Nel procedimento pendente presso la 3ª Vara do Trabalho di Parauapebas, nello Stato brasiliano del Pará, il sistema Galileu ha individuato in una petizione iniziale alcuni frammenti di testo occultati e indirizzati direttamente all’intelligenza artificiale.
Galileu è una soluzione sviluppata dal Tribunal Regional do Trabalho della 4ª Regione e poi adottata a livello nazione dal Conselho Superior da Justiça do Trabalho per supportare attività della giustizia del lavoro brasiliana, come riportato nella comunicazione ufficiale del TRT4.
Secondo la ricostruzione ufficiale, il messaggio nascosto avrebbe ordinato all’AI di contestare la petizione in modo superficiale e di non impugnare i documenti, a prescindere dalle istruzioni ricevute.
Il testo era stato reso invisibile mediante caratteri bianchi su sfondo bianco, ma era comunque leggibile da strumenti di estrazione testuale e da applicazioni di elaborazione automatica del file.
La novità non sta nel fatto che un modello linguistico può essere attaccato tramite prompt injection: questo era già noto alla comunità di AI security.
La novità sta nel fatto che il vettore dell’attacco sia un atto processuale e che il comando ostile sia stato valutato secondo la logica della lealtà processuale.
Da quel momento in poi, la sicurezza dell’AI non riguarda più solo la sicurezza delle applicazioni, ma anche la correttezza del processo.
Galileu non ha risolto la controversia, né ha qualificato giuridicamente la condotta. Ha rilevato l’anomalia, segnalato il rischio, impedito il processamento del contenuto malevolo e ha lasciato la valutazione al magistrato.
Il controllo umano sul passaggio decisivo
Il giudice Luiz Carlos de Araújo Santos Junior ha poi esaminato personalmente il contenuto prima di adottare dei provvedimenti, garantendo così un controllo umano sul passaggio decisivo.
Secondo le ricostruzioni disponibili, la condotta è stata ritenuta lesiva dell’immagine della giustizia e, per questo motivo, è stata applicata una sanzione pari al 10% del valore della causa e il caso è stato trasmesso agli organi disciplinari competenti. Il procedimento è identificato con il numero 0001062-55.2025.5.08.0130.
Dal documento come prova a quello come payload
Il caso ci costringe a chiedersi se l’intelligenza artificiale possa commettere errori.
Il punto critico è: se affidassimo agli strumenti algoritmici una parte del lavoro di lettura, classificazione, sintesi o supporto all’analisi degli atti, allora anche l’attacco al processo potrebbe spostarsi dal contenuto visibile del file al suo livello computazionale.
Il problema qui non è l’intelligenza artificiale che prende il posto del giudice, ma il fatto che l’atto viene progettato in modo da poter essere compreso anche dalla macchina.
Si tratta di un passaggio culturale, ancor prima che tecnologico.
Prompt injection negli atti giudiziari: come cambia la superficie d’attacco
Per decenni si è concepito il documento processuale come un oggetto da produrre, notificare, depositare e valutare.
Nell’ambiente AI-enabled, invece, lo stesso contenuto si legge anche come sequenza di token, metadati, segmenti, embedding e contesto operativo.
La sua materialità giuridica convive con una nuova materialità computazionale. Ciò cambia la superficie d’attacco. Non rileva solo ciò che appare nella pagina.
Diventano significativi i metadati, i layer nascosti, il testo al di fuori dell’area visibile, i commenti PDF, i campi dei moduli, le annotazioni, le stringhe OCR, i font di dimensione minima, il colore dei caratteri e qualsiasi altro elemento che un essere umano potrebbe non notare, ma che un software è in grado di leggere.
Il deposito digitale può quindi contenere due livelli semantici: uno visibile, rivolto al giudice o alla controparte, e uno occulto, destinato alla macchina. Non si tratta di un semplice uso imprudente di un chatbot per scrivere un atto.
Ci troviamo di fronte alla possibilità che si utilizzi un file apparentemente ordinario per interferire con strumenti informatici istituzionali.
Che cos’è una prompt injection
La prompt injection è una tecnica con cui un attaccante inserisce istruzioni ostili in un input destinato a un modello linguistico, con l’obiettivo di alterarne il comportamento, fargli ignorare istruzioni precedenti o indurlo a produrre un output favorevole all’attaccante. Nell’OWASP Top 10 for Large Language Model Applications del 2025, la prompt injection è classificata come LLM01, ovvero come la prima categoria di rischio per le applicazioni basate su LLM.
Il paragone con la SQL injection è utile, a condizione che non venga forzato. In entrambi i casi, il problema è la confusione tra dati e comandi.
Nella SQL injection, un input non correttamente neutralizzato viene interpretato dal database come un’istruzione.
Nella prompt injection, invece, il testo apparentemente documentale viene interpretato dal modello come un comando da eseguire.
Da tempo, OWASP sottolinea la necessità di separare i dati dalle istruzioni nella categoria “Injection”; nel mondo LLM, tuttavia, questo principio diventa più difficile da applicare, in quanto il linguaggio naturale è costituito da contenuto, contesto e comando.
Un caso di indirect prompt injection
Il caso di Galileu rientra più precisamente nella categoria dell’indirect prompt injection.
L’attaccante non scrive direttamente in una finestra di chat “ignora le istruzioni precedenti”.
Inserisce invece il comando in un file che verrà acquisito dallo strumento algoritmico e processato successivamente.
Il modello non riceve il comando come un’interlocuzione diretta, ma come parte del contesto documentale.
La differenza rispetto a un normale errore di output è sostanziale: in questo caso, infatti, il modello non rischia di sbagliare perché “allucina”, ma perché qualcuno ha alterato il materiale informativo su cui dovrebbe lavorare.
Si tratta, quindi, di una manipolazione dell’ambiente informativo, ancor prima che del risultato.
È qui che il rischio aumenta.
Nei sistemi RAG, il contenuto viene scomposto in porzioni, trasformato in embedding e salvato in un indice vettoriale, per poi essere richiamato uando l’utente formula una domanda.
Se l’istruzione ostile entrasse a far parte della base di knowledge, potrebbe riemergere anche in un secondo momento, magari in un contesto diverso da quello originario.
A quel punto, la minaccia non riguarda più solo l’atto depositato, ma l’intera memoria applicativa che lo ha assorbito.
Non è sempre necessario che l’attacco abbia successo
Dal punto di vista giuridico, il problema non riguarda solo la verifica dell’effettiva manipolazione dell’AI.
Nel caso brasiliano, Galileu ha rilevato e bloccato il contenuto ostile. Eppure, la sanzione è stata comunque adottata.
Questo dato sposta l’attenzione dall’effetto prodotto all’intenzione incorporata nell’atto.
Il messaggio è chiaro: introdurre un’istruzione occulta in un deposito processuale, destinata a condizionare un sistema di supporto alle decisioni, potrebbe essere considerato un illecito, anche se l’attacco non andasse a buon fine.
Il disvalore non è soltanto tecnico, ma processuale. L’atto viene utilizzato come mezzo per interferire con il regolare funzionamento della catena informativa del processo.
Ed è qui che la questione smette di essere solo informatica. Un comando nascosto in un atto non manipola semplicemente un software, ma tenta di alterare il modo in cui una parte del processo conosce, seleziona e interpreta le informazioni.
In Italia
Naturalmente, applicare automaticamente questo precedente all’ordinamento italiano sarebbe improprio.
Ogni valutazione deve essere effettuata caso per caso, tenendo conto dell’intenzionalità, del contenuto del comando, della destinazione del file, dell’architettura dell’infrastruttura AI e dell’impatto concreto sul procedimento.
È fondamentale distinguere tra errore tecnico, negligenza nella redazione del documento e condotta intenzionale: un conto è un file malformattato, un altro è un testo occulto che contiene istruzioni dirette alla macchina e coerenti con un vantaggio processuale.
Il raccordo con le vulnerabilità LLM e le responsabilità
Il caso brasiliano rende concreto un aspetto della sicurezza degli LLM che spesso resta solo teorico: non è possibile proteggere il modello se la filiera che gli fornisce i dati resta scoperta.
Il nodo cruciale era proprio questo: riuscire a collegare tassonomie tecniche e responsabilità giuridiche, evitando di considerare la sicurezza dei modelli generativi come un problema a sé stante, slegato dal contesto applicativo.
La prompt injection non è più soltanto una voce dell’OWASP Top 10 né un esercizio per il red team.
Può trasformarsi in un fatto processuale, un incidente di sicurezza, una condotta disciplinarmente rilevante e un problema di affidabilità istituzionale. E se il prompt fosse stato generato e inserito autonomamente dall’AI utilizzata dallo studio legale?
AI Act: il caso riguarda anche l’Europa
Nel contesto europeo, l’AI Act rappresenta un punto di riferimento imprescindibile.
Non perché disciplini specificamente il caso brasiliano, ma perché impone di considerare i sistemi di IA utilizzati in contesti sensibili, inclusa la giustizia, come infrastrutture da governare, documentare e rendere controllabili.
Il punto, quindi, non è soltanto la qualità dell’output.
È il governo dell’intero sistema: progettazione, sorveglianza, documentazione tecnica, sicurezza informatica, tracciabilità e controllo umano.
L’articolo 6 del Regolamento UE 2024/1689 qualifica come ad alto rischio i sistemi indicati nell’allegato III, salvo specifiche eccezioni nei casi in cui non sussista un rischio significativo per la salute, la sicurezza o i diritti fondamentali.
Tra gli ambiti sensibili rientrano l’amministrazione della giustizia, i settori della biometria, delle infrastrutture critiche, dell’istruzione, del lavoro, dell’accesso ai servizi essenziali, dell’applicazione della legge e della migrazione.
Il caso Galileu ci aiuta a riportare l’AI Act fuori dal linguaggio della sola compliance e dentro la realtà dei flussi documentali: un atto può diventare il veicolo di un comando ostile.
In un’infrastruttura AI utilizzata per attività giudiziarie, robustezza, cyber security, logging, trasparenza e supervisione umana non sono adempimenti burocratici, ma condizioni essenziali per garantire il contraddittorio e la fiducia nel procedimento.
Pubblica amministrazione e NIS2: il fascicolo come asset da proteggere
Sarebbe riduttivo limitare il problema alla giustizia. Ogni amministrazione che utilizza l’intelligenza artificiale per istanze, allegati, relazioni, reclami o fascicoli eredita lo stesso rischio: scambiare un file per una fonte neutra, quando invece potrebbe contenere istruzioni ostili.
Le linee guida AgID per l’adozione dell’intelligenza artificiale nella PA vanno lette anche in questa prospettiva: non basta scegliere uno strumento, ma è necessario definire chi lo utilizzerà, su quali dati, con quali limiti, con quali registrazioni e con quale controllo sugli output.
Le linee guida, messe in consultazione nel 2025, insistono infatti su governance, gestione del rischio, valutazione d’impatto, competenze, indicatori e controllo lungo il ciclo di vita dei sistemi di IA.
Nel 2026, l’Agenzia ha avviato iniziative per sviluppare e acquisire soluzioni di intelligenza artificiale per la pubblica amministrazione, confermando che l’AI deve essere considerata come un’infrastruttura organizzativa e non solo come un semplice componente software.
Per quanto riguarda la cyber security, il recepimento italiano della direttiva NIS2, attuato con il decreto legislativo del 4 settembre 2024, n. 138, ha rafforzato gli obblighi in materia di sicurezza e di notifica degli incidenti, ampliando il numero di soggetti coinvolti e attribuendo all’Agenzia per la cybersicurezza nazionale il ruolo di Autorità competente NIS.
L’ACN sottolinea che il nuovo quadro normativo mira ad accrescere il livello di sicurezza informatica delle imprese e delle pubbliche amministrazioni, imponendo obblighi di gestione del rischio, misure tecniche e organizzative e ’obbligo di notifica degli incidenti.
In questa prospettiva, la prompt injection documentale non è un rischio concettuale riservato agli addetti ai lavori.
Si tratta, infatti, di un rischio operativo per la sicurezza informatica di tutte le organizzazioni che fanno analizzare i propri contenuti da strumenti AI, quali tribunali, enti pubblici, autorità indipendenti, studi legali, società di consulenza e fornitori di tecnologie legali.
Ordinamento italiano: difensore, consulente tecnico e doveri di lealtà
Nel diritto processuale civile italiano, il primo riferimento è l’articolo 88 c.p.c., econdo cui le parti e i loro difensori devono comportarsi con lealtà e probità in giudizio.
In caso di violazione da parte dei difensori, il giudice deve riferirne alle autorità che esercitano il potere disciplinare.
Dal punto di vista deontologico, il Codice forense impone all’avvocato doveri di indipendenza, lealtà, correttezza, probità, dignità, decoro, diligenza e competenza, tenendo conto del rilievo costituzionale e sociale della difesa. L’articolo 9 del Codice opera come clausola generale di responsabilità professionale.
Non tutte le anomalie tecniche in un file comportano automaticamente una responsabilità.
Diverso è il caso in cui l’occultamento sia intenzionale e finalizzato a condizionare uno strumento algoritmico inserito in un atto destinato alla controparte, al giudice o a un’infrastruttura giudiziaria.
In tale ipotesi, almeno in astratto, potrebbero emergere profili di violazione dei doveri di lealtà, probità processuale e correttezza professionale.
Il tema non riguarda solo il difensore. Anche i consulenti tecnici, i periti, i CTP e i professionisti informatici forensi possono produrre documenti, dataset, relazioni o allegati destinati a essere acquisiti in procedimenti giudiziari o amministrativi.
Se tali materiali fossero elaborati con l’intelligenza artificiale o fossero destinati a essere elaborati da modelli generativi, sarebbe sufficiente garantire la tracciabilità, la verificabilità, il controllo umano e l’assenza di istruzioni occulte.
L’AI può supportare l’attività professionale. Tuttavia, non può sostituire la responsabilità del professionista né oscurare il metodo utilizzato.
Un elaborato tecnico o difensivo prodotto con il supporto dell’intelligenza artificiale dovrebbe poter essere spiegato, verificato e ricondotto a scelte umane consapevoli.
Le contromisure
Dire al modello “non farti ingannare” non basta. È come affidare la sicurezza di un database alla speranza che riconosca da solo un attacco SQL injection. La protezione deve iniziare prima che il contenuto arrivi al modello.
Prima che il modello possa essere letto, deve superare un controllo tecnico che può essere effettuato da un sistema di verifica in grado di individuare gli elementi presenti nel file, ma non visibili nella pagina, e che non richiede necessariamente l’intervento di un operatore umano.
La prima regola operativa dovrebbe essere chiara: nessun atto proveniente da terzi deve essere consegnato direttamente a una catena di elaborazione.
AI senza controlli preliminari
È necessario estrarre il testo, normalizzarlo, identificare le anomalie, separare il contenuto documentale dalle possibili istruzioni, conservare la versione originale e produrre una versione sanitizzata per l’elaborazione.
Per mitigare il rischio di injection di prompt, OWASP raccomanda di validare gli input, separare le istruzioni dai dati, limitare le capacità del modello e controllare l’output.
Nei PDF e negli atti digitali andrebbero verificati almeno: testo invisibile, olori anomali, font troppo piccoli, livelli nascosti, testo fuori pagina, commenti, metadati, allegati incorporati, campi modulo e contenuti OCR.
Il caso Galileu dimostra che l’ispezione visiva non è sufficiente: ciò che non è visibile per il lettore può essere perfettamente leggibile dalla macchina.
Nei sistemi RAG, è necessario poi controllare la fase di ingest. Non tutto ciò che viene estratto da un file deve necessariamente finire nell’indice vettoriale. I chunk contenenti istruzioni dirette al modello, formule imperative sospette o testo occulto devono essere isolati, segnalati e, se necessario, esclusi dal contesto generativo.
Il NIST AI RMF Generative AI Profile suggerisce un approccio alla gestione del rischio lungo l’intero ciclo di vita dei sistemi generativi, basato su governance, mappatura, misurazione e gestione dei rischi.
Questo approccio è particolarmente rilevante nei contesti istituzionali o professionali ad alto impatto.
Non è necessario trasformare ogni studio legale o ufficio pubblico in un laboratorio di sicurezza dell’intelligenza artificiale.
Bisogna peròevitare l’errore opposto, ovvero diconsiderare l’AI come un normale motore di ricerca documentale.
In concreto, il controllo non dovrebbe essere lasciato alla sensibilità del singolo operatore.
Dovrebbe essere trasformato in una procedura: prima il file originale, poi l’estrazione, poi la verifica degli elementi non visibili e, infine, l’eventuale inserimento nello strumento AI.
Lezione brasiliana: la Prompt injection negli atti giudiziari è un problema tecnico, giuridico, deontologico
La questione non è impedire l’uso dell’AI nei tribunali, negli studi professionali o nelle amministrazioni.
Bisogna smetterla di considerarla uno strumento neutro che legge documenti neutri. Questo caso dimostra che la giustizia digitale non può limitarsi alla dematerializzazione del fascicolo.
Quando l’intelligenza artificiale entra nel ciclo documentale, il processo diventa anche un ambiente cyber-informativo.
La correttezza del contraddittorio dipende non solo dalla qualità degli argomenti giuridici, ma anche dall’integrità degli input, dalla sicurezza del flusso di elaborazione e dalla capacità di individuare manipolazioni invisibili.
La prompt injection negli atti giudiziari non appartiene a una sola categoria. Si tratta di un problema di natura:
- tecnica, in quanto sfrutta il modo in cui i modelli leggono il testo;
- giuridica, perché incide sul procedimento;
- deontologica, poiché chiama in causa la correttezza del professionista, e organizzativa, in quanto obbliga gli uffici e gli studi a ripensare i controlli sui documenti.
La risposta non è rinunciare all’AI, ma governarla: con strumenti sicuri, file sanitizzati, log, audit, formazione, presidio umano e responsabilità chiaramente attribuite.
Il precedente brasiliano dice qualcosa di semplice: l’AI non sposta altrove la responsabilità umana. La rende solo più difficile da eludere.
Nel processo assistito da algoritmi, le competenze tecniche, la lealtà professionale e la cyber security non sono più ambiti separati.
Partecipa alla community