Il jailbreak universale alla vigilia dell’AI Act: ecco l’impatto nella sicurezza aziendale

Venerdì scorso, mentre ero in call con il mio team di threat intelligence è rimbalzata la notizia che da ore animava i canali riservati del nostro settore. Un noto red teamer che si firma “Pliny the Liberator” sosteneva di aver trovato un metodo per eludere i filtri di sicurezza di pressoché tutti i modelli di AI di frontiera in produzione (da GPT-5.6 Sol a Claude Opus 5 e Claude Fable 5).

Non è la prima rivendicazione di questo tipo e non sarà l’ultima. Ma il tempismo è emblematico: il prossimo 2 agosto entra in piena applicazione l’articolo 55 dell’AI Act europeo, che impone ai fornitori di modelli general purpose a rischio sistemico obblighi stringenti di red-teaming, gestione degli incidenti e resilienza cibernetica.

Chi ricopre il ruolo di CISO non può derubricare la vicenda a semplice folklore per addetti ai lavori: è un caso di studio reale su come si stia espandendo la superficie d’attacco delle aziende che hanno già integrato questi LLM nei propri processi core.

Occorre fare chiarezza incrociando tre piani: i dati della ricerca scientifica recente, i requisiti dei regolatori e gli interventi concreti che sto introducendo nella postura di sicurezza della mia organizzazione.

Nessun allarmismo: solo una guida operativa per chi deve giustificare le proprie scelte di difesa davanti al Consiglio di Amministrazione con argomenti più solidi di un titolo di giornale.

Cosa significa jailbreak universale alla luce della ricerca accademica

La prima regola nel nostro lavoro è il rigore: le dichiarazioni non verificate si trattano con scetticismo, anche quando provengono da ricercatori stimati. Al momento, la tecnica citata da Pliny non è stata resa pubblica né sottoposta a peer review o validazione indipendente.

Come evidenziato da diversi analisti, occorre anzitutto distinguere tra due definizioni di “universalità”:

• Universalità per prompt: un singolo attacco funziona su prompt diversi all’interno dello stesso modello.
• Universalità per architettura: un singolo prompt funziona identicamente su modelli e provider differenti.

Confondere questi due concetti porta a valutazioni del rischio errate.

Un quadro concreto

Ciò che invece è già dimostrato, replicabile e documentato in sede scientifica traccia un quadro estremamente concreto:

• Bijection Learning (ICLR 2025): È stato dimostrato come sia possibile insegnare al modello, nel contesto della singola sessione, un cifrario reversibile arbitrario per mascherare le istruzioni dannose. Il dato critico emerso è controintuitivo: i modelli con capacità di ragionamento più avanzate sono risultati più vulnerabili di quelli meno complessi. La stessa profondità di comprensione contestuale che rende utile l’LLM lo rende anche più idoneo ad apprendere le regole per eludere i propri filtri.
• Boundary Point Jailbreaking (2026): Questa ricerca ha sfatato l’assunto secondo cui un modello “sbloccato” subisca un degrado prestazionale tale da renderlo inefficace. La tecnica garantisce un tasso di elusione dei classificatori tra il 92% e il 100%, registrando una perdita di prestazioni irrilevante (pari al 2% nel caso peggiore). Per il Board il significato è chiaro: un attaccante può ottenere risposte malevole mantenendo intatta la qualità di generazione del modello. Non existe alcun “degrado di protezione” su cui fare affidamento come misura mitigante passiva.
• Red-teaming automatizzato (giugno 2026): Uno studio europeo condotto dal team di Nicola Franco ha testato modelli di ultima generazione (tra cui Fable 5 e Opus 4.8) su oltre 7.800 intenti malevoli ripartiti su dieci categorie di rischio. I tassi di attacco riuscito (11,5% su Opus 4.8 e 6,1% su Fable 5) confermano un fatto preciso: gli attacchi automatizzati riescono a individuare falle residue senza intervento umano continuativo, affinando i prompt in modo iterativo. Lo scenario di rischio per noi cambia: l’attaccante non deve essere un esperto di AI safety, gli basta eseguire script di probing automatizzato su scala.

Il Jailbreak è un rischio d’impresa, non un problema del fornitore: ecco perché

In molti Comitati Rischi persiste l’idea errata che la vulnerabilità ai jailbreak sia un problema “a monte”, legato esclusivamente al vendor di intelligenza artificiale.

È un’impostazione concettuale errata. Dal momento in cui un LLM viene integrato mediante API o agenti nei flussi operativi dell’azienda (CRM, copiloti di sviluppo, analisi documentale), la vulnerabilità del modello diventa a tutti gli effetti un vettore di attacco contro la nostra infrastruttura.

Analizzo il problema su tre direttrici operative:

• Sviluppo ed elusione di exploit: Un modello privo dei guardrail nativi facilita la generazione di varianti di codice malevolo ottimizzate per evitare la detection degli EDR o per accelerare lo sviluppo di exploit su vulnerabilità note. È un fattore di moltiplicazione dell’efficienza per chi attacca.
• Social Engineering ad alta precisione: L’assenza di filtri permette la generazione su scala di campagne di spear-phishing prive dei consueti indicatori sintattici o contestuali. I messaggi possono riflettere lo stile comunicativo interno, riducendo l’efficacia dei normali strumenti di awareness aziendale.
• Data Exfiltration e Prompt Injection su agenti: È il rischio primario per l’infrastruttura. Se un agente AI dispone di accessi a database, API aziendali o strumenti di ticketing, una prompt injection riuscita non si limita a produrre un output inappropriato: può indurre l’agente a eseguire query non autorizzate, esfiltrare credenziali o modificare record di produzione. Passiamo dal rischio reputazionale del chatbot alla violazione diretta della riservatezza e integrità dei dati.

La convergenza normativa: AI Act, NIS2 e GDPR

Il contesto odierno è segnato dalla contestuale entrata in vigore di framework sanzionatori stringenti:

• AI Act (Art. 55): Dal 2 agosto 2026, l’AI Office della Commissione Europea acquisisce pieni poteri sanzionatori sui fornitori di modelli General Purpose AI (GPAI) a rischio sistemico. Gli obblighi per i provider includono il red-teaming avversariale e la tracciatura degli incidenti. Tuttavia, la responsabilità per le organizzazioni che usano tali modelli richiede la valutazione della supply chain tecnologica: dobbiamo censire le integrazioni GPAI, verificare la documentazione (Allegato XII) e gestire il rischio di terze parti esattamente come facciamo per qualsiasi software critico.
• Direttiva NIS 2: Con l’inquadramento operativo della direttiva, i soggetti essenziali e importanti devono garantire la sicurezza della catena di approvvigionamento. Un incidente causato da un componente AI vulnerabile rientra a tutti gli effetti nel perimetro di gestione degli incidenti con obbligo di notifica stringente.
• GDPR: L’esfiltrazione di dati personali indotta da attacchi di jailbreak o indirect prompt injection costituisce un data breach. La sovrapposizione tra le sanzioni GDPR e quelle dell’AI Act (fino al 7% del fatturato globale) rende la corretta messa in sicurezza dei modelli un requisito di continuità aziendale.

La lacuna nella rilevazione degli incidenti a livello nazionale

Dall’analisi dei report diffusi dall’Agenzia per la Cybersicurezza Nazionale (ACN) relativi al primo semestre 2026 emerge un incremento costante di eventi cyber gestiti dal CSIRT Italia e dei bollettini emessi.

Tuttavia, la classificazione tradizionale degli incidenti fatica ancora a isolare l’AI come vettore o acceleratore autonomo di rischio.

I framework di censimento correnti catalogano gli attacchi secondo tassonomie consolidate (vulnerabilità software, phishing, ransomware).

Per un CISO questo significa non poter fare affidamento esclusivo sui feed esterni di threat intelligence: occorre implementare internamente telemetrie in grado di identificare anomale logiche di prompting, pattern ripetitivi di query o deviazioni nel comportamento degli agenti nei log applicativi.

Architettura difensiva e azioni operative

In conformità con le raccomandazioni accademiche e con le linee guida internazionali (a partire dalla OWASP Top 10 for LLM Applications), l’approccio corretto prevede l’implementazione del principio della Defense-in-Depth applicato allo stack dell’intelligenza artificiale.
Non ci affidiamo alla robustezza nativa del modello.

L’architettura che abbiamo definito si articola su più livelli di controllo indipendenti.

Decisioni operative adottate

• Red-Teaming Continuativo: Superamento del modello di test una tantum in fase di acquisizione. Implementazione di test automatizzati ricorrenti tramite framework open-source per simulare la costante evoluzione delle tecniche di elusione.
• Third-Party Risk Management (AI Act Compliance): Inserimento nei processi di procurement della richiesta vincolante della documentazione di sicurezza e dei report di adversarial testing previsti dall’AI Act per i fornitori di LLM.
• Playbook di Incident Response dedicati: Aggiornamento delle procedure di gestione incidenti includendo scenari specifici di prompt injection e jailbreak, definendo metriche di escalation tempestive per i reparti Legal e Compliance.
• AI Governance nel comitato rischi: Integrazione della valutazione della robustezza degli algoritmi direttamente nei report periodici di rischio presentati al Board, trattandola al pari della conformità e della continuità operativa.

La superficie d’attacco dei modelli di frontiera

A prescindere dall’effettiva portata tecnica delle ultime rivendicazioni apparse sui social network, la ricerca indipendente conferma un dato oggettivo: i modelli di frontiera presentano una superficie d’attacco residua reale, quantificabile e automatizzabile.

Con l’entrata inoperatività delle sanzioni dell’AI Act, la finestra temporale per adeguare le difese aziendali è chiusa.

Le organizzazioni che hanno già strutturato una difesa in profondità attorno ai propri processi AI manterranno l’operatività in sicurezza.

Le altre rischiano, invece, di gestire le vulnerabilità dei propri modelli nel peggiore dei modi: in fase di gestione di un data breach.

Riferimenti principali

• D. Zhu et al., “Jailbroken Frontier Models Retain Their Capabilities”, arXiv:2605.00267, 2026.
• B.R.Y. Huang, M. Li, “Endless Jailbreaks with Bijection Learning”, ICLR 2025.
• AI Security Lab (N. Franco), “Measuring the Residual Jailbreak Surface of Frontier Large Language Models”, Giugno 2026.
• XenoSpectrum, “Claim of a ‘Jailbreak That Breaks All AI’: Two Kinds of Universality to Verify With GPT-5.6 and Claude”, Luglio 2026.
• Unione Europea, AI Act (Regolamento UE 2024/1689), art. 55 e Allegato XII.
• Agenzia per la Cybersicurezza Nazionale / CSIRT Italia, Relazione e sintesi operativa, 2026.
• OWASP Foundation, “OWASP Top 10 for Large Language Model Applications”.