sistema: OPERATIVO
← volver a todos los hacks
RESEARCH MEDIUM NEW

Más nuevo no siempre es más seguro: alineación de seguridad no monótona entre generaciones

Un artículo de mayo de 2026 que somete a red teaming cuatro generaciones de Gemma halló que el modelo intermedio era mucho más fácil de jailbreakear que su predecesor y su sucesor: la seguridad no mejora en línea recta.

2026-06-12 // 6 min affects: gemma-2, gemma-3, gemma-4

¿Qué es esto?

Un preprint publicado en arXiv el 30 de mayo de 2026 (2606.00813) plantea una observación incómoda: la seguridad de una familia de modelos no mejora de forma fiable de una generación a la siguiente. Los autores aplicaron una sonda de red teaming automatizado a cuatro generaciones de la familia abierta Gemma de Google (aproximadamente de 7B a 31B de parámetros) y hallaron que la generación intermedia era notablemente más vulnerable a los jailbreaks que tanto el modelo anterior que la precedía como el modelo más nuevo que la sucedía.

Las cifras principales, según informa el artículo: Gemma 3 (12B) mostró una tasa de éxito de ataque (ASR) del 68,7 % ± 5,7 %, marcadamente superior a la de su predecesor Gemma 2 (45,5 % ± 7,2 %) y a la de su sucesor Gemma 4 (33,9 % ± 1,8 %). Dicho de otro modo, la curva subió antes de bajar. Si usted había supuesto «versión más nueva = modelo más seguro» y migró de Gemma 2 a Gemma 3, habría pasado a un sistema más fácil de jailbreakear, no menos. Esto es lo que los autores denominan alineación de seguridad no monótona.

Cómo funciona

El estudio utiliza una búsqueda evolutiva de calidad-diversidad llamada MAP-Elites como motor de red teaming. En lugar de optimizar un único mejor jailbreak, MAP-Elites mantiene un «archivo» de prompts diversos que tienen éxito cada uno en una región distinta de un espacio de comportamientos de ataque. El resultado no es un payload único, sino un mapa de numerosos ataques distintos por modelo, que es lo que hace significativa la comparación entre generaciones: se mide una superficie de ataque amplia, no una cadena aislada con suerte.

El segundo hallazgo trata sobre la transferencia. Los ataques evolucionados contra una generación se reprodujeron contra las demás. Se transfieren a Gemma 3 en un 44–46 %, pero a Gemma 4 solo en un 14–18 %. Esa brecha es la parte alentadora del resultado: las mejoras de seguridad de Gemma 4 parecen generalizar más allá de las distribuciones de ataque evolucionadas contra los modelos anteriores, en lugar de limitarse a memorizar parches para prompts conocidos. Conviene señalar también que algunas categorías de daño —el artículo destaca la reproducción de contenido con copyright y ciertos prompts de cibercrimen— registran cerca del 100 % de éxito en todas las generaciones, un recordatorio de que el ASR agregado oculta categorías donde la alineación apenas se movió.

Aquí no se reproduce ninguna cadena de jailbreak funcional, y el valor del artículo es diagnóstico más que ofensivo: se trata de una metodología de medición, en la línea bien establecida de los trabajos sobre ataques adversarios transferibles contra modelos alineados (Zou et al., 2023).

Por qué importa

La mayoría de las decisiones de actualización asumen implícitamente una mejora monótona: la nueva versión es mejor en los benchmarks, por tanto más segura, por tanto un reemplazo sin riesgo. Este artículo demuestra que esa suposición no se sostiene. Una regresión puede introducirse por un cambio en los datos de instruction-tuning, una nueva plantilla de conversación, un salto de capacidades que supere al entrenamiento de seguridad, o un desplazamiento del comportamiento de rechazo, ninguno de los cuales aparece en una tabla de capacidades. Para quien fija una versión de modelo en producción, «pasamos a la última versión» no es prueba de mayor seguridad; puede ser lo contrario.

El hallazgo también debilita el hábito de evaluar solo el modelo más reciente. Si la seguridad es no monótona, su modelo de amenazas debe tener en cuenta la versión concreta que despliega, incluidas versiones más antiguas aún fijadas en sistemas de larga duración.

Defensas

  • Vuelva a probar en cada cambio de versión. Trate una actualización de modelo como un cambio de código: ejecute su conjunto de evaluación de jailbreaks y categorías de daño contra la versión exacta que va a desplegar, y condicione el despliegue a los resultados. No herede el visto bueno de seguridad de la versión anterior.
  • Mida una distribución, no un único prompt. El red teaming consciente de la diversidad (calidad-diversidad / búsqueda por archivo) expone debilidades amplias que un ataque optimizado aislado pasa por alto. Mantenga un archivo de categorías funcionales y reprodúzcalo contra cada nueva versión.
  • Vigile la transferencia como señal anticipada. Si los ataques de la generación anterior aún se transfieren bien al nuevo modelo, sus mejoras de seguridad son probablemente superficiales. Una baja transferencia es indicio débil de generalización real.
  • Siga el ASR por categoría, no solo el promedio. Las cifras agregadas ocultan categorías (el artículo destaca el copyright y ciertos prompts de cibercrimen) que se mantienen cerca del 100 % entre generaciones. Defiéndalas con controles externos —filtros de salida, gating de herramientas y de retrieval— en lugar de confiar en el rechazo a nivel del modelo.
  • Fije y documente la versión. Registre exactamente qué build de modelo evaluó y desplegó, para que una actualización silenciosa del proveedor no altere discretamente su postura de riesgo.

Estado

ElementoDetalle
Artículo«Cross-Generational Transfer of Adversarial Attacks Reveals Non-Monotonic Safety Alignment in LLMs»
ID arXiv2606.00813
Publicado30 de mayo de 2026
Modelos estudiadosGoogle Gemma, cuatro generaciones (~7B–31B)
MétodoRed teaming de calidad-diversidad MAP-Elites
Resultado claveGemma 3 (12B) ASR 68,7 % > Gemma 2 45,5 %, > Gemma 4 33,9 %
Transferencia entre generaciones44–46 % a Gemma 3; 14–18 % a Gemma 4
NaturalezaEstudio de medición defensiva — sin código de explotación publicado

Sources