Un artículo titulado The Fragility of Jailbreak Robustness Across Operational States, aceptado en EMNLP 2026 Findings, hace una afirmación estrecha e incómoda: la puntuación de robustez de un modelo es una propiedad de la configuración en la que se midió, no del modelo. Manteniendo fijo el ataque y cambiando solo un prompt de sistema ordinario —uno que no tenía nada que ver con la seguridad—, la tasa de éxito del ataque pasó en un caso del 2% al 58%, una variación de 56 puntos. El resultado abarca siete modelos alineados y tres ataques representativos.

El mecanismo propuesto

Los autores relacionan el efecto con la posición de las representaciones ocultas a lo largo de lo que denominan un eje de rechazo. Una proyección sobre ese eje predice si un determinado jailbreak tiene éxito, lo que reformula un prompt de sistema operativo como algo que desplaza silenciosamente al modelo a lo largo de una dirección relevante para la seguridad, sin ninguna intención adversarial por parte de quien lo escribió.

Lo que el artículo no dice

No sostiene que los modelos se hayan vuelto menos seguros, y un titular del tipo «los modelos son fáciles de jailbreakear» invierte el argumento. El hallazgo trata sobre la medición: informar de la robustez como una sola cifra de ASR en una configuración básica genera una falsa sensación de confianza, porque el número no resiste el contacto con un prompt operativo. Esa es una crítica a una metodología utilizada en las fichas de seguridad de los proveedores y en los benchmarks públicos, no un nuevo ataque.

Dos detalles que conviene no confundir

La aceptación es en Findings, no en la pista principal de EMNLP, una distinción que los resúmenes de prensa suelen omitir. Y la fecha de arXiv se refiere al envío de una versión concreta: se trata de la v1, enviada el 31 de agosto, sin revisiones posteriores, por lo que no es un trabajo antiguo que reaparece con una fecha de publicación nueva.

Por qué debería importar a los profesionales

En producción, el prompt del sistema lo escribe el integrador, no el laboratorio. Si la robustez medida con el prompt predeterminado del laboratorio no se traslada, entonces cada cifra de seguridad que se muestra a un comprador describe una configuración que no existirá en su producto. La implicación práctica es que el red-teaming debe ejecutarse contra el prompt real de producción y repetirse cada vez que ese prompt cambie, algo que hoy se trata como una simple corrección editorial de rutina.