Introducción: por qué el jailbreak es un problema
Los modelos de lenguaje modernos intentan rechazar solicitudes dañinas o peligrosas, pero ninguna protección es perfecta. Los ataques de jailbreak diseñan prompts que eluden estas restricciones: piden imaginar un escenario hipotético, cambiar de rol, reformular la tarea de forma «segura», y así sucesivamente. Los investigadores y defensores quieren entender hasta qué punto estos ataques son realmente peligrosos.
La mayoría de los ataques funcionan en modo de caja negra: el atacante no tiene acceso a los pesos del modelo ni puede analizar sus mecanismos internos. Solo hay una API a la que se pueden enviar solicitudes y recibir respuestas. Por eso, todo el esfuerzo del atacante se reduce a ajustar el texto. Para evaluar la calidad de un ataque, no basta con saber si se logró eludir la protección, sino también a qué costo.
Normalmente se usa una métrica simple: la tasa de éxito de ataques (ASR). Pero no muestra cuántas solicitudes fueron necesarias. Y es precisamente el número de llamadas al modelo lo que a menudo se convierte en la principal limitación en la práctica: cuantas más solicitudes, mayor la probabilidad de ser detectado y más caro el ataque en tiempo y dinero.
ASR como métrica engañosa
Imaginemos dos formas de ataque. La primera prueba cientos de variantes de prompts hasta que una funciona. La segunda usa una plantilla previamente verificada y obtiene el resultado en tres intentos. Si ambos tienen el mismo porcentaje de éxito, al observar la ASR parecerán equivalentes. Pero en condiciones reales, el segundo método es claramente más peligroso: es más rápido, más barato y deja menos rastros.
Por eso, comparar solo por ASR se parece a una competencia de tiradores donde uno dispara desde tres metros y otro desde treinta, pero la victoria se otorga por el número de aciertos. Sin tener en cuenta las condiciones, el resultado carece de sentido. Para los jailbreaks, esa condición debería ser el presupuesto de llamadas al modelo.
Fair-ASR: contando las llamadas
En un trabajo reciente en arXiv, los investigadores propusieron el protocolo Fair-ASR. Su esencia es comparar ataques con el mismo límite de llamadas objetivo. Una llamada objetivo es una solicitud directamente al modelo atacado: se envía el prompt, se recibe la respuesta. Esta restricción es fácil de controlar, es igual para cualquier método y no requiere conocer el funcionamiento interno del modelo.
¿Por qué es importante? Algunas métricas intentan tener en cuenta la complejidad computacional, por ejemplo, mediante FLOPS. Pero para modelos cerrados y propietarios, estas estimaciones son imprecisas. En cambio, el número de llamadas es un indicador directo y comprensible. Si un ataque logra su objetivo en 10 solicitudes y otro necesita 1000, con un presupuesto de 10, el segundo simplemente no se llevará a cabo.
Además, los investigadores proponen monitorear por separado las llamadas del atacante: solicitudes a herramientas auxiliares, como otro modelo de lenguaje que genera los prompts. Esto permite ver el panorama completo: primero, cuántas solicitudes se destinaron al modelo objetivo; segundo, cuántos recursos adicionales se necesitaron.
Qué cambió con una comparación honesta
Los autores reevaluaron 11 ataques conocidos con Fair-ASR y descubrieron que su clasificación cambia drásticamente según el presupuesto asignado. Un ataque que parece potente con cien llamadas puede resultar débil con cinco, y viceversa. Esto significa que las conclusiones anteriores sobre la eficacia eran, como mínimo, incompletas.
También fue inesperado que los métodos simples no hayan desaparecido. Las perturbaciones aleatorias de prompts y las plantillas creadas manualmente siguen siendo muy competitivas cuando el acceso al modelo objetivo es limitado. No requieren grandes recursos computacionales y funcionan casi de inmediato.
En cambio, los ataques gestionados por LLM, donde un modelo auxiliar genera por sí mismo las variantes de evasión, mostraron un peor desempeño. Gastan muchas llamadas tanto en el modelo objetivo como en su propia generación. Ninguno de los ataques probados de este tipo resultó eficaz en ambos indicadores a la vez. O el resultado se logra con un gran presupuesto, o el ataque es demasiado costoso en llamadas auxiliares.
ReCode: un ataque eficaz inspirado en la investigación
Esta brecha entre la eficacia deseada y los costos reales llevó a los investigadores a crear su propia metodología: el ataque composicional ReCode. Utiliza una reescritura desensibilizante: la solicitud dañina original se reformula para que parezca neutral y no active respuestas defensivas. Luego se emplean dos primitivas simples y baratas que demostraron su eficacia durante la reevaluación con Fair-ASR.
Los resultados son contundentes. Con un presupuesto de solo 20 llamadas objetivo, ReCode logra un 85% de éxito en GPT-5, y en promedio solo se gastan 7.19 llamadas a herramientas auxiliares por solicitud. En comparación, muchos otros ataques con un presupuesto tan limitado son prácticamente inútiles. Y los que pueden presumir de indicadores comparables suelen requerir muchas más veces más recursos auxiliares.
Conclusiones
La investigación envía una señal clara: ya no se puede evaluar los ataques solo por la tasa de éxito. Se necesita un punto de referencia común, y el número de llamadas al modelo objetivo es la medida más transparente y universal disponible. Fair-ASR propone precisamente este enfoque, y podría convertirse en el estándar para futuras comparaciones.
Para quienes protegen modelos, la conclusión práctica importante es: no hay que obsesionarse con ataques complejos que usan inteligencia artificial como atacante. Los métodos simples y baratos — perturbaciones aleatorias, plantillas — siguen siendo una amenaza real con recursos limitados. Precisamente su resistencia a las defensas es lo que se debe probar en primer lugar. Los ataques complejos gestionados por LLM quizás sean llamativos en informes de laboratorio, pero en condiciones reales son demasiado costosos y no tan peligrosos como parecen.
