Fiducia e sicurezza IA: i rischi dei jailbreak poetici

Le poesie non dovrebbero essere in grado di convincere un sistema di IA ad aiutare qualcuno a costruire un'arma nucleare. Eppure, recenti ricerche suggeriscono che i prompt poetici possono aggirare i filtri di sicurezza in molti modelli linguistici di grandi dimensioni (LLM). Per qualsiasi organizzazione che implementa l'IA, questo è un chiaro avvertimento sulla fiducia e la sicurezza: i guardrail da soli non bastano. È necessaria una gestione sistematica del rischio IA, una governance rigorosa e pratiche di implementazione sicure.

Questo articolo spiega cosa sono i "jailbreak poetici", perché sono importanti per la sicurezza dell'IA aziendale e come le aziende possono rispondere con controlli pratici, dalle policy di governance al testing continuo.

Nota: Non forniamo, riproduciamo o promuoviamo prompt o istruzioni dannose. Il nostro obiettivo è comprendere il rischio e proteggere la tua organizzazione.

Cosa sono i "jailbreak poetici" e perché sono importanti

Alla fine del 2025, i ricercatori dell'Icaro Lab (Sapienza Università di Roma e DexAI) hanno pubblicato uno studio sulla "poesia avversaria" come metodo per sconfiggere le salvaguardie degli LLM[1][2][3]. I loro risultati mostrano che:

Le domande pericolose — su argomenti come armi nucleari o malware — venivano respinte se poste direttamente.
Le stesse domande, se inserite in poesie accuratamente elaborate, ottenevano spesso risposta.
I tassi di successo sono stati elevati in molti dei principali modelli commerciali[1][2][3].

Nello specifico, le poesie avversarie create manualmente hanno raggiunto un tasso di successo medio del 62% su 25 modelli testati, con alcuni fornitori che hanno superato il 90%[1][2][3]. Quando 1.200 prompt in prosa dannosi sono stati convertiti automaticamente in versi, le versioni poetiche hanno prodotto tassi di successo di circa il 43%, rappresentando un aumento di cinque volte rispetto alle baseline non poetiche che avevano solo l'8,08% di successo[1][2].

L'idea si basa su lavori precedenti sui suffissi avversari — stringhe senza senso o aggiunte lunghe e confuse che disturbano i filtri dei modelli. Ad esempio, la ricerca sulle tecniche avversarie mostra che una formattazione non convenzionale dei prompt può aggirare i controlli sui contenuti.

Perché la struttura poetica può aggirare i guardrail dei modelli

A livello generale, la maggior parte dei sistemi di sicurezza negli LLM si basa sul riconoscimento di pattern:

I system prompt e le policy dicono al modello cosa dovrebbe o non dovrebbe fare.
I classificatori di sicurezza ed euristiche scansionano prompt e risposte alla ricerca di contenuti non consentiti (es. incitamento all'odio, istruzioni per armi).

Gli attacchi di poesia avversaria sfruttano le debolezze in questi livelli[1][2]:

Indirezione e metafora: L'intento dannoso è avvolto in un linguaggio figurato e indiretto che non corrisponde a semplici parole chiave o pattern.
Sintassi frammentata: Grammatica spezzata e strutture insolite confondono i classificatori addestrati su testi standard.
Sovraccarico di contesto: Prompt lunghi e stilizzati possono sovrastare i semplici pattern di sicurezza, spingendo il modello verso l'essere "utile" piuttosto che "prudente".[1][2]

Dal punto di vista della fiducia e sicurezza nell'IA, la lezione fondamentale è che i filtri dei contenuti non sono interruttori binari. Sono probabilistici, e gli avversari possono cercare sistematicamente formulazioni che riescono a passare.

Come falliscono i guardrail degli LLM: comportamento del modello e superfici di attacco

Per progettare difese sensate, è utile capire dove si collocano gli attuali guardrail e come falliscono.

Tipi di guardrail negli LLM moderni

La maggior parte dei fornitori stratifica diversi meccanismi:

Filtri di pre-addestramento: Rimuovono alcuni esempi dannosi dai dati utilizzati per addestrare il modello base.
Apprendimento per rinforzo da feedback umano (RLHF): Insegna ai modelli a essere più utili, onesti e innocui.
System prompt e policy: Istruzioni come "non fornire mai indicazioni su attività illegali".
Classificatori di contenuti: Controlli esterni o interni al modello che segnalano contenuti non consentiti.
Filtri di post-elaborazione: Controlli finali sul testo generato prima che raggiunga l'utente.

Questi sono cruciali, ma operano su pattern visti durante l'addestramento. Quando gli aggressori inventano nuovi trucchi linguistici — come i travestimenti poetici — il modello può comportarsi in modi imprevisti[1][2].

Come i prompt avversari confondono i filtri

I prompt avversari (inclusi i jailbreak poetici) sfruttano diverse proprietà degli LLM:

Utilità sovra-generalizzata: Gli LLM vengono premiati per soddisfare le richieste degli utenti; se una richiesta sembra benigna o artistica, la propensione alla sicurezza viene indebolita.
Sfruttamento dell'ambiguità: Se il testo può essere plausibilmente interpretato come finzione, metafora o descrizione innocua, il modello potrebbe propendere per rispondere.
Punti ciechi dei classificatori: I classificatori di sicurezza sono spesso addestrati su contenuti dannosi più letterali e diretti. La formulazione creativa o obliqua è sottorappresentata.

Non si tratta solo di una questione teorica. Gli studi sulla sicurezza degli LLM e sul jailbreaking condotti da gruppi come Anthropic, OpenAI e ricercatori accademici rilevano ripetutamente che i nuovi metodi di jailbreak possono raggiungere tassi di successo elevati finché i modelli non vengono aggiornati.

Dal punto di vista della governance dell'IA, ciò significa che le organizzazioni non possono considerare "il modello X è sicuro per impostazione predefinita" come un presupposto duraturo. La sicurezza è condizionata dal contesto, dalla configurazione e dalla supervisione continua.

Impatto aziendale: cosa significa per le imprese che utilizzano l'IA

La maggior parte delle aziende non chiede agli LLM informazioni sulle armi nucleari. Ma le stesse debolezze che consentono jailbreak estremi possono esporre vulnerabilità più banali, ma critiche per il business.

Scenari di rischio per chatbot rivolti ai clienti e agenti interni

Alcuni scenari realistici includono:

Aggiramento delle policy nei chatbot per i clienti Gli utenti potrebbero convincere un bot bancario o assicurativo a rivelare criteri di scoring interni, suggerire regole di rilevamento frodi o indicare modi per manipolare i prezzi.
Fuga di informazioni interne o regolamentate I copiloti interni addestrati su dati riservati potrebbero essere ingannati, tramite prompt indiretti o creativi, per riassumere documenti sensibili o condividere dati personali, creando incidenti di sicurezza dei dati IA.
Amplificazione dell'ingegneria sociale Gli aggressori possono utilizzare gli LLM per generare contenuti di phishing altamente mirati o per testare prompt avversari prima di interagire con i tuoi sistemi pubblici.
Shadow AI e integrazioni non verificate I team possono incorporare LLM generici nei flussi di lavoro senza revisione di sicurezza. Anche se il modello a monte è "sicuro", la tua integrazione potrebbe aggirare o indebolire le sue salvaguardie.

Esposizione normativa e reputazionale

I regolatori e gli organismi di standardizzazione stanno convergendo rapidamente sulle aspettative per la sicurezza dell'IA aziendale e la governance:

L'EU AI Act richiede gestione del rischio, test e monitoraggio per i sistemi di IA ad alto rischio.
Il NIST AI Risk Management Framework enfatizza l'identificazione, la misurazione e la mitigazione continua dei rischi dell'IA.
Le normative di settore (es. GDPR, HIPAA, regole di condotta finanziaria) si applicano ancora quando la gestione errata dell'IA porta a esposizione di dati o risultati discriminatori.

Un singolo incidente di jailbreak di alto profilo — specialmente uno che coinvolge consigli non consentiti, incidenti di sicurezza o fuga di dati personali — può:

Innescare indagini e sanzioni.
Danneggiare la fiducia dei clienti e la percezione del marchio.
Forzare rollback improvvisi delle funzionalità di IA, minando la tua roadmap di innovazione.

Ecco perché la fiducia e la sicurezza nell'IA devono essere trattate come una funzione di rischio aziendale, non solo come una decisione di selezione del modello.

Controlli operativi: implementazione e test sicuri dell'IA

Le scelte tecnologiche e le pratiche di implementazione contribuiscono notevolmente a un'implementazione sicura dell'IA. L'obiettivo non è eliminare completamente il rischio, ma rendere gli attacchi riusciti più rari, meno dannosi e rapidamente rilevabili.

Red-teaming e test avversari (senza condividere exploit)

Una gestione efficace del rischio IA richiede test strutturati:

Red-teaming interno: Progetta esercizi in cui esperti di sicurezza e di dominio tentano di indurre comportamenti non consentiti dai tuoi modelli, incluse formulazioni creative come poesia o gioco di ruolo.
Partner di test esterni: Collabora con aziende specializzate o programmi di bug-bounty che comprendono il comportamento degli LLM, con chiare linee guida di divulgazione che evitino di pubblicizzare prompt pericolosi.
Copertura degli scenari: Testa non solo contenuti dannosi ovvi (armi, autolesionismo) ma anche rischi specifici per il business: frodi, fuga di dati, elusione delle policy.

Documenta e classifica i risultati, quindi reinseriscili nella configurazione del modello, nell'ingegneria dei prompt e negli aggiornamenti delle policy.

Monitoraggio, logging e strategie di rollback

Anche con buoni test, alcuni jailbreak appariranno solo in produzione. I controlli operativi dovrebbero includere:

Logging completo (con salvaguardie della privacy): Cattura prompt e risposte per i sistemi ad alto rischio in modo da poter indagare sugli incidenti.
Rilevamento automatico delle anomalie: Usa euristiche o modelli secondari per segnalare pattern insoliti (es. prompt lunghi e stilizzati che assomigliano a noti attacchi di jailbreak).
Rollback sicuro e feature flag: Rendi facile disabilitare o reindirizzare determinate funzionalità (es. generazione a forma libera su argomenti sensibili) mentre indaghi.
Canali di feedback: Consenti a dipendenti e clienti di segnalare comportamenti sospetti dell'IA.

Queste sono pratiche di affidabilità standard, adattate ai rischi specifici degli LLM.

Governance, conformità e obblighi dei fornitori

I controlli tecnologici sono solo una parte del quadro. La governance dell'IA definisce le regole di ingaggio: chi può implementare cosa, sotto quali vincoli e con quali controlli.

Policy, controlli di accesso e SLA dei fornitori

Gli elementi chiave della governance includono:

Policy di utilizzo accettabile e sicurezza per i sistemi di IA, su misura per il tuo settore e la tua propensione al rischio.
Controllo degli accessi basato sui ruoli: Limita chi può implementare modelli, modificare prompt o connettere nuove fonti di dati.
Inventario di modelli e fornitori: Mantieni una mappa aggiornata di dove vengono utilizzati gli LLM, quali dati vedono e quali salvaguardie sono in atto.
Due diligence dei fornitori e SLA: Richiedi ai tuoi fornitori di IA e cloud di descrivere le loro architetture di sicurezza, i cicli di aggiornamento, la segnalazione degli incidenti e le soluzioni di conformità IA.

Come le soluzioni di conformità riducono l'esposizione aziendale

Gli approcci di conformità moderni vanno oltre i semplici audit:

Monitoraggio continuo dei controlli: Convalida che il logging, l'accesso e i filtri di sicurezza rimangano attivi e configurati correttamente.
Policy-as-code: Implementa determinati guardrail (es. campi dati consentiti, regole di redazione) direttamente nel middleware, non solo nei documenti cartacei.
Allineamento con i framework: Mappa i controlli su standard come NIST AI RMF, ISO/IEC 42001 (sistemi di gestione dell'IA) e regole di protezione dei dati di settore.

Ciò trasforma gli impegni di alto livello sulla fiducia e la sicurezza dell'IA in meccanismi applicabili.

Rafforzamento di agenti e chatbot IA

Molte organizzazioni stanno ora implementando copiloti personalizzati, agenti di flusso di lavoro e chatbot specifici per il dominio. Questi portano efficienza, ma anche nuove considerazioni sulla sicurezza dell'IA aziendale.

Scelte di progettazione per ridurre gli output sensibili

Quando progetti agenti IA personalizzati, puoi:

Ridurre al minimo le autorizzazioni: Dai a ogni agente l'accesso solo ai dati e agli strumenti di cui ha assolutamente bisogno.
Vincolare la generazione: Usa output strutturati, template o la generazione aumentata dal recupero (RAG) per ridurre il testo speculativo e a forma libera.
Aggiungere l'approvazione in più passaggi per azioni ad alto rischio (es. modifica dei limiti utente, emissione di rimborsi) invece di lasciare che l'agente agisca autonomamente.
Implementare filtri secondari: Applica filtri sugli argomenti e sulla prevenzione della perdita di dati (DLP) attorno al modello, non solo al suo interno.

Questi approcci riducono il raggio d'azione quando un tentativo di jailbreak ha successo.

Dove applicare i filtri dei contenuti e gestire i compromessi tra scala e rischio degli LLM

I modelli più potenti sono generalmente più capaci, ma anche più sfruttabili. Considera:

L'utilizzo di modelli più piccoli e strettamente limitati per casi d'uso particolarmente sensibili.
La combinazione di modelli: uno per il ragionamento, un altro per la revisione della sicurezza.
Il posizionamento dei filtri su più livelli: nell'interfaccia utente, nel middleware e nell'API del modello.

Questo è particolarmente importante per la sicurezza dei dati IA, dove l'esposizione accidentale può essere dannosa quanto l'esfiltrazione deliberata.

Checklist pratica e passi successivi per i team

Per trasformare questi concetti in azione, i team interfunzionali (sicurezza, dati, prodotto, legale, conformità) possono lavorare attraverso una checklist focalizzata.

Azioni immediate (0–90 giorni)

Inventaria i tuoi sistemi di IA Documenta dove vengono utilizzati gli LLM, a quali dati accedono e quali utenti servono.
Classifica i casi d'uso per rischio Identifica le aree ad alto impatto: consulenza ai clienti, decisioni finanziarie, contesti di salute o sicurezza, accesso ai dati personali.
Esegui un esercizio di red-teaming mirato Includi prompt creativi (es. formulazioni metaforiche o poetiche) per testare i guardrail.
Rafforza le configurazioni Abilita le funzionalità di sicurezza a livello di fornitore; aggiungi controlli middleware per argomenti sensibili e campi dati.
Aggiorna policy e formazione Educa sviluppatori, product manager e team di supporto sui rischi di jailbreak e sulle pratiche di prompt sicure.
Stabilisci monitoraggio e percorsi di escalation Decidi cosa viene registrato, chi esamina gli incidenti e con quale rapidità rispondere.

Azioni a medio termine (3–12 mesi)

Allineati con un framework di rischio formale come il NIST AI RMF o la guida specifica di settore dei regolatori.
Integra il rischio IA nella gestione del rischio aziendale: reporting a livello di consiglio di amministrazione, registri dei rischi e audit interno.
Automatizza le valutazioni ove possibile, in modo che le nuove implementazioni attivino revisioni standardizzate invece di controlli ad hoc.

Per un senso più ampio delle migliori pratiche, le risorse del NIST, i principi dell'IA dell'OCSE e le pagine di ricerca sulla sicurezza dei principali fornitori offrono una guida utile.

Dove si inseriscono i partner specializzati

Non ogni organizzazione ha una profonda competenza interna sull'ingegneria della sicurezza degli LLM, sui test di jailbreak e sulla governance dell'IA. Lavorare con un integratore specializzato può accelerare il tuo viaggio dalla sperimentazione a operazioni robuste e conformi.

Encorp.ai si concentra su soluzioni di IA pragmatiche e sicure per le aziende. Le nostre soluzioni di gestione del rischio IA aiutano i team ad automatizzare parti dei loro flussi di lavoro di valutazione del rischio IA, integrare controlli di sicurezza e conformità nelle pipeline di distribuzione e passare da revisioni una tantum alla supervisione continua.

Se stai pianificando o scalando iniziative di IA, puoi anche esplorare i nostri servizi più ampi su https://encorp.ai per vedere come approcciamo implementazioni di IA sicure e orientate al valore.

Conclusione: bilanciare innovazione e sicurezza

I jailbreak poetici sono un vivido promemoria del fatto che la fiducia e la sicurezza nell'IA non si risolvono con una messa a punto del modello una tantum o con una manciata di filtri di contenuto[1][2]. Poiché gli aggressori scoprono nuovi modi per mascherare l'intento — attraverso versi, giochi di ruolo o altri prompt creativi — le organizzazioni devono trattare la sicurezza degli LLM come un programma continuo, non come una funzionalità.

Combinando una solida gestione del rischio IA, una governance dell'IA robusta, una progettazione attenta di agenti e chatbot e pratiche di implementazione sicura dell'IA, le aziende possono catturare i vantaggi dell'IA generativa tenendo sotto controllo i rischi inaccettabili. L'obiettivo non è eliminare ogni fallimento, ma capire dove i tuoi sistemi sono vulnerabili, costruire difese sensate e rispondere rapidamente quando le cose vanno male.

Gestita in questo modo, l'IA diventa non solo potente, ma affidabile: una tecnologia su cui i tuoi clienti, dipendenti e regolatori possono contare.

Nota: Non forniamo, riproduciamo o promuoviamo prompt o istruzioni dannose. Il nostro obiettivo è comprendere il rischio e proteggere la tua organizzazione.

Cosa sono i "jailbreak poetici" e perché sono importanti

Le domande pericolose — su argomenti come armi nucleari o malware — venivano respinte se poste direttamente.
Le stesse domande, se inserite in poesie accuratamente elaborate, ottenevano spesso risposta.
I tassi di successo sono stati elevati in molti dei principali modelli commerciali[1][2][3].

Perché la struttura poetica può aggirare i guardrail dei modelli

A livello generale, la maggior parte dei sistemi di sicurezza negli LLM si basa sul riconoscimento di pattern:

I system prompt e le policy dicono al modello cosa dovrebbe o non dovrebbe fare.
I classificatori di sicurezza ed euristiche scansionano prompt e risposte alla ricerca di contenuti non consentiti (es. incitamento all'odio, istruzioni per armi).

Gli attacchi di poesia avversaria sfruttano le debolezze in questi livelli[1][2]:

Indirezione e metafora: L'intento dannoso è avvolto in un linguaggio figurato e indiretto che non corrisponde a semplici parole chiave o pattern.
Sintassi frammentata: Grammatica spezzata e strutture insolite confondono i classificatori addestrati su testi standard.
Sovraccarico di contesto: Prompt lunghi e stilizzati possono sovrastare i semplici pattern di sicurezza, spingendo il modello verso l'essere "utile" piuttosto che "prudente".[1][2]