MLCommons Jailbreak Benchmark v1.0: lo que revela (y oculta) el Resilience Gap

¿Qué es esto?

El 2 de octubre de 2026, MLCommons y unos 35 coautores de la industria y la academia publicaron en arXiv el MLCommons Jailbreak Benchmark v1.0. Es la primera ejecución completa, de extremo a extremo, de la metodología de jailbreak del consorcio: selección de prompts, generación de ataques, anotación humana, calibración del juez, puntuación e informe. El benchmark no inventa ataques: aplica técnicas de jailbreak ya conocidas a 264 prompts semilla (24 por cada una de once categorías de riesgo) y mide con qué frecuencia la respuesta infringe el estándar de evaluación AILuminate v1.4.

La métrica principal es el Resilience Gap (RG): cuánto cae la tasa de respuestas conformes cuando el mismo prompt se reescribe con una técnica de jailbreak. Se evaluaron ocho modelos de pesos abiertos.

Cómo funciona

Cada semilla se ejecuta dos veces contra el mismo modelo: sin modificar (referencia) y transformada por uno de los once ataques reportados. Se implementaron doce ataques, mapeados a una taxonomía de cuatro familias, ocho categorías y diecisiete mecanismos; uno (Content Framing & Deception) quedó fuera de los resultados cuantitativos por una limitación del juez. Las respuestas se puntúan de 0 a 2 en Legitimización y Habilitación (Enablement), y reglas específicas por riesgo convierten esas puntuaciones en un veredicto conforme o no conforme, emitido por un conjunto de jueces LLM calibrado con etiquetas humanas.

Los autores no divulgan deliberadamente los prompts de ataque exactos, las plantillas ni el código, que comparten solo con auditores autorizados. Este artículo sigue la misma regla: no se reproduce ninguna carga útil.

Por qué importa

Cifras del artículo y del análisis de ActuIA (5 de octubre de 2026):

• La proporción de respuestas inseguras sube del 11,08 % (referencia) al 18,65 % bajo ataque, un Resilience Gap medio de 7,57 puntos.
• Los tres modelos más pequeños («Accessible») muestran una brecha media de unos 21 puntos, que los autores consideran preliminar por el tamaño reducido de la muestra.
• Delitos violentos y armas de destrucción masiva presentan los mayores aumentos; las familias más eficaces son el juego de roles/plantillas y los envoltorios/esquemas.
• Tres modelos grandes (Gemma 4 31B, DeepSeek-V4-Pro, Kimi K2.6) muestran una brecha negativa, es decir, menos respuestas inseguras bajo ataque. Los autores apuntan como posibles causas una robustez real, efectos del evaluador o de la decodificación, o rechazos provocados por el propio formato del jailbreak.

La otra mitad de la historia es la calidad de la medición. El acuerdo entre anotadores humanos fue de 0,88 en el veredicto final, pero solo de 0,54 (Legitimización) y 0,63 (Habilitación) en las subpuntuaciones, con apenas 40 respuestas anotadas por duplicado. ActuIA indica que el juez no detectó el 16,4 % de las respuestas inseguras y marcó por error el 37,9 % de las seguras, por lo que las tasas absolutas no deben leerse como estimaciones precisas. Además, el benchmark solo cubre texto de un único turno: sin diálogo multiturno, imágenes ni agentes con herramientas. Uno de los ataques fue generado por un modelo que también figura en el panel evaluado, lo que puede sesgar al alza su brecha.

Defensas

El artículo es una metodología de evaluación, no una defensa, pero deja orientaciones prácticas para los equipos que evalúan modelos:

1. Informar resultados emparejados. Mida juntos el comportamiento de referencia y bajo ataque, y lea el Resilience Gap junto a las medidas de capacidad y de sobrerrechazo: un modelo que rechaza todo es trivialmente «seguro».
2. Tratar una brecha negativa como una pregunta, no como un aprobado. Revise el error del evaluador, la decodificación y los rechazos provocados por el formato antes de concluir que el modelo es robusto.
3. Cuantificar el error del juez. Publique márgenes de error y calibre los jueces con etiquetas humanas fiables antes de comparar modelos.
4. Evitar la contaminación. Excluya del panel evaluado cualquier modelo usado para generar ataques o juzgar respuestas.
5. No quedarse en el texto de un solo turno. Añada pruebas multiturno, multimodales y agénticas a su propio red teaming, porque este benchmark no las cubre.
6. Combinar controles. Un benchmark solo mide los rechazos del modelo; mantenga filtrado de salidas, herramientas con mínimo privilegio y monitorización alrededor del modelo.

Estado

Elemento	Detalle
Artículo	arXiv 2610.02827, enviado el 2 de octubre de 2026
Modelos evaluados	8 de pesos abiertos (3 «Accessible», 5 «Large»); modelos cerrados vía API excluidos
Tasa de respuestas inseguras referencia / ataque	11,08 % / 18,65 %
Previsto	v1.1 con una verdad de referencia humana más amplia, un nuevo juez y pruebas posteriores de modelos cerrados; sin fecha (según ActuIA, 5 de octubre de 2026)