Un paper intitolato The Fragility of Jailbreak Robustness Across Operational States, accettato a EMNLP 2026 Findings, sostiene in modo circoscritto e scomodo che il punteggio di robustezza di un modello è una proprietà della configurazione in cui è stato misurato, non del modello. Mantenendo fisso l’attacco e cambiando solo un normale system prompt — uno che non aveva nulla a che fare con la sicurezza — in un caso il tasso di successo dell’attacco è passato dal 2% al 58%, con uno scarto di 56 punti. Il risultato riguarda sette modelli allineati e tre attacchi rappresentativi.
Il meccanismo proposto
Gli autori collegano l’effetto alla posizione delle rappresentazioni nascoste lungo quello che definiscono un asse di rifiuto. Una proiezione su quell’asse predice se un dato jailbreak riesce — e questo riformula un system prompt operativo come qualcosa che sposta silenziosamente il modello lungo una direzione rilevante per la sicurezza, senza alcuna intenzione avversaria da parte di chi lo ha scritto.
Ciò che il paper non afferma
Non sostiene che i modelli siano diventati meno sicuri, e un titolo del tipo «i modelli sono facili da jailbrekkare» ribalta l’argomento. Il risultato riguarda la misurazione: riportare la robustezza come un singolo valore di ASR in una configurazione standard produce un falso senso di fiducia, perché quel numero non regge al confronto con un prompt operativo. È una critica a una metodologia usata nelle safety card dei vendor e nei benchmark pubblici, non un nuovo attacco.
Due dettagli da tenere distinti
L’accettazione è per Findings, non per il main track di EMNLP — una distinzione che i riassunti stampa spesso omettono. E la data di arXiv si riferisce all’invio di una specifica versione: questa è la v1, inviata il 31 agosto, senza revisioni successive, quindi non si tratta di un lavoro più vecchio riapparso con una nuova data di pubblicazione.
Perché i pratici dovrebbero interessarsene
In produzione il system prompt è scritto dall’integratore, non dal laboratorio. Se la robustezza misurata con il prompt predefinito del laboratorio non si trasferisce, allora ogni numero di sicurezza mostrato a un acquirente descrive una configurazione che non esisterà nel suo prodotto. La conseguenza pratica è che il red teaming deve essere eseguito sul prompt effettivo di produzione, e ripetuto ogni volta che quel prompt cambia — cosa che oggi viene trattata come una normale modifica redazionale.