Quando un documento prova a comandare l’AI: come proteggere il lavoro delegato

Immaginiamo una piccola impresa che affida a un assistente basato sull’intelligenza artificiale, o AI, il confronto di tre preventivi. Il compito è ragionevole: leggere, trovare differenze e preparare una sintesi. In uno dei documenti, però, compare una frase che invita l’assistente a ignorare i criteri del cliente e a scegliere quel fornitore. Il documento sta provando a trasformarsi da materiale da esaminare in qualcuno che impartisce ordini. Questo esempio è ipotetico, ma descrive un rischio studiato: la prompt injection, cioè l’inserimento di istruzioni malevole nel contenuto che un sistema AI legge.

La domanda utile per chi lavora non è soltanto quanto sia intelligente l’assistente. È anche chi possa orientarne le decisioni e quali azioni gli siano consentite. Un preventivo dovrebbe descrivere un’offerta; non dovrebbe avere il potere di cambiare l’incarico. Sembra una distinzione da buon senso, finché il collega incaricato di leggere è un sistema che tratta anche gli ordini come testo.

Quando il materiale da leggere cambia ruolo

Un prompt è una richiesta o un’istruzione rivolta a un modello, il componente AI che elabora il contenuto e produce risposte. Nell’attacco indiretto, l’istruzione non arriva dall’utente che ha assegnato il lavoro: è inserita da un terzo in una pagina, un’email o un documento. Il tentativo è farle attribuire un’autorità che non possiede. Non serve immaginare un allegato che esegue un programma: il veicolo può essere il testo stesso.

OpenAI descrive questo problema come una forma di manipolazione diretta all’AI e segnala che i rischi crescono quando il sistema accede a dati sensibili e può agire per conto dell’utente. È la spiegazione di un fornitore, non una misura indipendente della frequenza degli attacchi. Aiuta a comprendere il meccanismo; non permette di concludere che ogni documento sia pericoloso o che ogni assistente reagisca allo stesso modo.

Una frase sospetta può chiedere di cambiare la risposta, cercare informazioni estranee al compito o trasmetterle altrove. Anche un invito presentato come urgente, autorevole o necessario alla verifica va confrontato con l’incarico originale. Una citazione contenuta nel documento, invece, può essere semplicemente un passaggio da analizzare: il contesto conta. Per chi usa l’assistente, il punto è mantenere separati il contenuto della fonte e l’autorizzazione ad agire.

Dalla risposta sbagliata all’azione sbagliata

Un agente AI è un sistema che usa un modello insieme a strumenti per svolgere passaggi di un lavoro: per esempio consultare pagine o intervenire su un’applicazione. Il modello, l’applicazione e i suoi permessi sono elementi diversi. La possibilità di produrre una frase non equivale alla possibilità di inviare un’email. Il rischio concreto dipende anche da questo collegamento fra lettura e azione.

Anthropic, nel lavoro sulle difese per l’uso del browser, illustra come contenuti esterni possano tentare di dirottare un agente. Presenta anche un esempio con istruzioni poco visibili in un’email, destinate a provocare l’inoltro di informazioni riservate. Sono scenari di ricerca e prove del fornitore: non sono una statistica degli incidenti nelle imprese. L’azienda descrive miglioramenti delle difese, ma riconosce che il problema non è risolto.

Torniamo al nostro ufficio immaginario. Se l’assistente può soltanto preparare una sintesi, il documento ostile potrebbe tentare di influenzarla. Se può anche cercare altri file e inviare messaggi, diventano possibili conseguenze diverse. Dare accesso all’intero archivio per confrontare tre preventivi sarebbe una delega difficile da giustificare. Il risparmio di qualche passaggio non spiega, da solo, perché quel lavoro debba coinvolgere anche documenti che non c’entrano.

Che cosa dimostra la ricerca

InjecAgent, uno studio del 2024, propone una raccolta di prove per valutare gli attacchi indiretti contro agenti collegati a strumenti. Una raccolta standardizzata di questo tipo è chiamata benchmark: serve a confrontare sistemi in condizioni definite. Il lavoro considera sia azioni dannose per l’utente sia la sottrazione di dati privati e mostra vulnerabilità nei sistemi esaminati.

Questa evidenza sostiene che il rischio merita controlli. Non consente di assegnare una probabilità di incidente al software usato da un’impresa nel 2026. Versione del modello, strumenti, istruzioni e condizioni delle prove cambiano il significato dei risultati. Leggere un numero senza questi elementi sarebbe un modo molto efficiente di perdere il contesto.

Google propone un’impostazione di sicurezza a più livelli: responsabilità umana definita, poteri limitati e azioni osservabili. Combina controlli tradizionali con difese che usano il ragionamento del sistema. Il documento presenta la direzione di lavoro di Google, non una certificazione di invulnerabilità. La conseguenza pratica che possiamo ricavarne è che la sicurezza della delega va progettata anche intorno al modello, non affidata soltanto alla sua capacità di riconoscere un trucco.

Un incarico che si possa controllare

Per un primo utilizzo in ufficio, proponiamo di separare la preparazione dalla decisione operativa. Nel confronto dei preventivi, l’assistente può produrre una bozza con prezzi, esclusioni e domande ancora aperte; una persona verifica i passaggi rilevanti prima di assumere un impegno. È una scelta organizzativa, da adattare al lavoro effettivo, e rende chiaro dove termina il compito automatico.

Una sequenza pratica può essere questa:

• Definire il risultato: quali documenti confrontare, quali criteri usare e quali informazioni devono comparire nella bozza.
• Concedere soltanto gli accessi necessari, verificando i permessi effettivi dell’applicazione con chi li gestisce.
• Stabilire quali azioni richiedono un controllo umano, come un invio esterno o una modifica a un documento condiviso.
• Prima di autorizzare un’azione, controllare destinatario, contenuto, allegati e coerenza con l’incarico.

OpenAI raccomanda a sua volta di limitare gli accessi, assegnare compiti espliciti e leggere con attenzione le conferme prima delle azioni rilevanti. Non presenta queste precauzioni come una garanzia assoluta. Una richiesta chiara aiuta, ma non sostituisce i limiti dei permessi: scrivere “non condividere dati” e lasciare disponibile un invio incontrollato sono due decisioni diverse.

Nel nostro esempio, un buon punto di controllo è la bozza comparativa accompagnata dai riferimenti ai preventivi. Chi la legge deve poter risalire ai passaggi che giustificano la scelta. Se spunta la proposta di inviare un file a un destinatario estraneo, la domanda da risolvere è molto concreta: quale parte dell’incarico autorizza questo passaggio? La giustificazione trovata nel documento esaminato non basta.

Il confine da mantenere

Per una piccola impresa, partire da un compito circoscritto permette anche di chiarire le responsabilità: chi assegna il lavoro, chi gestisce gli accessi e chi approva il risultato destinato all’esterno. Può essere la stessa persona, ma i momenti restano distinguibili. Prima di estendere la delega, proponiamo di verificare che siano visibili le fonti usate e le azioni proposte, così da discutere errori concreti invece di fidarsi di un riepilogo rassicurante.

La prompt injection riguarda un confine preciso: una fonte consultata può contenere informazioni utili senza ottenere il diritto di comandare l’assistente. Mantenere quel confine richiede un incarico leggibile, accessi proporzionati e controlli sulle conseguenze. Il vantaggio dell’AI resta la possibilità di ridurre il lavoro ripetitivo; la scelta su che cosa autorizzare rimane una parte del lavoro che vale la pena rendere esplicita.