Per una piccola o media impresa che sta introducendo assistenti AI su documenti, email o archivi interni, la novità è concreta: il 6 ottobre 2026 AgID ha pubblicato una notizia sul nuovo paper CERT-AgID dedicato agli “Explosive Prompts”. Si tratta, nella descrizione pubblica, di istruzioni malevole che possono essere acquisite durante la lettura di un testo e produrre effetti solo più avanti, quando si verifica una condizione prevista. Il punto operativo è semplice: un documento non deve poter diventare, da solo, un comando aziendale.
Il tema riguarda i sistemi agentici, cioè applicazioni in cui il modello non si limita a rispondere in linguaggio naturale, ma può proporre o attivare azioni tramite strumenti collegati. In azienda questo può significare, a seconda dell’architettura adottata, assistenti che leggono contratti, ticket di assistenza, basi di conoscenza, caselle email o documenti caricati in una piattaforma. Il fatto documentato da AgID non è che ogni prodotto AI sia esposto allo stesso rischio. È un altro: il confine tra contenuto letto e azione eseguita diventa una scelta progettuale decisiva.
AgID riferisce che CERT-AgID ha costruito un ambiente sperimentale minimale per separare il comportamento del modello da quello del sistema incaricato di gestire le azioni. La notizia pubblica confronta due modalità: una con accettazione automatica delle richieste prodotte dal modello e una fondata su controlli esterni indipendenti. È la distinzione che interessa a chi deve scegliere o configurare uno strumento: la sicurezza non può dipendere soltanto dalla capacità dell’AI di “comportarsi bene”, ma deve essere applicata fuori dal modello, prima dell’esecuzione.
Una prompt injection è un tentativo di inserire istruzioni nel materiale che il modello deve elaborare, così da orientarne il comportamento. Gli Explosive Prompts aggiungono una componente temporale: l’istruzione può restare latente e attivarsi in seguito, per esempio quando l’assistente incontra una parola, una data o una richiesta compatibile con il trigger. Per l’impresa il rischio non è solo una risposta sbagliata in chat. Il problema nasce quando quella risposta può trasformarsi in un’azione: inviare dati, modificare un record, inoltrare un messaggio, aprire un ticket, avviare una procedura.
Da qui discende la regola tecnica principale: il modello linguistico non dovrebbe essere il giudice ultimo dei propri permessi. Se l’assistente propone un’azione, un componente esterno deve verificare identità dell’utente, ruolo, contesto, destinatario, tipo di dato e livello di rischio. Non è la stessa cosa chiedere all’AI se un’operazione sia ammessa e imporre a un sistema separato di autorizzarla sulla base di regole verificabili. In una PMI senza reparto informatico interno, questa separazione va chiesta al fornitore e resa visibile nelle impostazioni, non accettata come formula generica sulla sicurezza.
Il quadro europeo rafforza questo criterio, senza trasformare automaticamente ogni assistente AI aziendale in un sistema ad alto rischio. L’articolo 14 dell’AI Act, nella versione consolidata indicata dall’AI Act Service Desk al 27 luglio 2026, prevede per i sistemi AI ad alto rischio misure di supervisione umana proporzionate al rischio, al livello di autonomia e al contesto d’uso. Tra le funzioni richiamate ci sono la possibilità di monitorare, interpretare, ignorare, sovrascrivere o interrompere l’output del sistema. Anche quando la disciplina non si applica direttamente allo strumento usato da una PMI, il principio resta utile: più l’assistente può agire, meno basta un’approvazione implicita.
La differenza si vede nei processi. Un assistente che riassume un documento espone soprattutto al rischio di un output inesatto, che una persona può rileggere e correggere. Un assistente collegato a email, gestionale o archivi riservati entra invece nel flusso operativo. Lo stesso errore può arrivare a clienti, fornitori, dipendenti o adempimenti interni. La tecnologia può essere simile, ma il profilo di rischio cambia quando cambia ciò che il sistema è autorizzato a fare.
Per questo i privilegi minimi non sono una finezza da grandi organizzazioni. Se l’assistente deve cercare informazioni in una cartella condivisa, non dovrebbe avere accesso indistinto a tutto l’archivio aziendale. Se prepara una bozza di risposta, non dovrebbe poterla inviare senza un passaggio autorizzativo quando contiene dati personali, importi, allegati o istruzioni operative. Se interagisce con un gestionale, lettura, proposta e scrittura dovrebbero restare operazioni separate. Così un errore del modello non diventa automaticamente un errore del sistema.
Serve anche una traccia verificabile. L’articolo 12 dell’AI Act Service Desk, riferito ai sistemi ad alto rischio nella versione consolidata del 27 luglio 2026, richiama la registrazione automatica degli eventi lungo il ciclo di vita, con log utili a identificare rischi, supportare il monitoraggio e tracciare il funzionamento. Per strumenti AI ordinari occorre valutare contratto e configurazione: l’impresa dovrebbe sapere se può ricostruire chi ha chiesto un’azione, quale documento era coinvolto, quale output è stato generato e quale autorizzazione è stata concessa o negata.
Senza log, un incidente legato a un assistente AI rischia di essere ricostruito solo a posteriori, con informazioni parziali. Con registrazioni progettate bene, diventa invece possibile capire se l’anomalia nasceva dal documento, dal modello, da una regola di autorizzazione troppo ampia o da un account usato impropriamente. Questo non elimina l’errore, ma permette di correggere il processo: restringere un permesso, aggiungere una conferma umana, isolare un archivio, rivedere la procedura di caricamento dei documenti.
La pagina AgID non consente di ricavare una percentuale generale di rischio né di valutare singoli prodotti commerciali. Sarebbe scorretto concludere che tutti gli assistenti AI siano insicuri, come sarebbe scorretto considerare risolto il problema davanti a un’etichetta di “AI sicura”. La domanda utile per l’impresa è più circoscritta: quali azioni può compiere davvero lo strumento, con quali dati, attraverso quali permessi e con quale possibilità di blocco esterno rispetto al modello.
Il limite da porre agli assistenti AI non è il divieto di leggere documenti aziendali. È la separazione fra lettura, proposta e decisione operativa. Finché l’AI aiuta a interpretare testi e prepara bozze controllabili, il rischio principale resta la qualità dell’output. Quando diventa un intermediario capace di attivare strumenti, la sicurezza passa dall’architettura: autorizzazioni esterne, privilegi minimi, supervisione umana e log. È lì che l’impresa deve decidere prima dove mettere il confine.
Per approfondire
Nuovo paper del CERT-AGID sugli Explosive Prompts e la sicurezza dei sistemi agentici
Article 14: Human oversight
Article 12: Record-keeping
