top of page

El jailbreak XBreaking LLM vuelve la IA explicable contra los filtros de seguridad

hace 13 minutos
13 min de lectura

Investigadores de XBreaking han utilizado IA explicable para localizar y debilitar controles de seguridad en siete modelos de lenguaje con pesos abiertos. Sus hallazgos transforman una promesa defensiva en un conflicto de seguridad. El jailbreak XBreaking LLM utiliza señales internas del modelo para identificar capas asociadas al comportamiento de rechazo. Después apunta a componentes cercanos, en lugar de buscar a ciegas un prompt que tenga éxito.

El estudio revisado por pares apareció en Neural Computing and Applications el 10 de octubre de 2026. Investigadores de la Universidad de Pavía y de la Universidad de Ciencia y Tecnología de Cochin desarrollaron el método. Probaron modelos de las familias Llama, Qwen, Gemma y Mistral.

No se trata de otro prompt que engaña a un chatbot mediante juegos de palabras. XBreaking presupone acceso directo a los pesos del modelo, estados ocultos, mapas de atención y otra información interna. Esa restricción limita la amenaza inmediata, pero también hace más clara la advertencia para las organizaciones que despliegan modelos abiertos personalizables.

El conflicto central ahora está claro. La interpretabilidad puede ayudar a los ingenieros a comprender y reforzar el comportamiento de seguridad. Esa misma visibilidad también puede mostrar a un atacante exactamente dónde se concentra dicho comportamiento.

Qué cambió realmente el jailbreak XBreaking LLM

XBreaking sustituye la experimentación con prompts por una búsqueda dirigida de los componentes internos que distinguen los modelos alineados de los no restringidos.

La mayoría de los jailbreaks conocidos operan a través de una interfaz de chatbot. Un atacante modifica la redacción, estructura, idioma o contexto de una solicitud hasta que el sistema deja de rechazarla. Este proceso suele implicar generación y pruebas repetidas.

XBreaking funciona dentro del modelo. Sus investigadores comparan un modelo ajustado para la seguridad con una contraparte sin restricciones de la misma familia arquitectónica. Llaman a estas versiones “censurada” y “sin censura”, aunque «ajustada para la seguridad» y «sin restricciones» son descripciones más neutrales.

La comparación utiliza IA explicable, es decir, técnicas que revelan señales asociadas con las decisiones internas de un modelo. Los investigadores miden valores medios de activación y atención en las capas del transformador. Las activaciones representan cálculos internos, mientras que los valores de atención describen con qué intensidad los tokens se influyen entre sí durante el procesamiento.

El estudio publicado describe un proceso de tres etapas. Primero, el equipo perfila ambas versiones utilizando entradas dañinas y benignas. Segundo, un método estadístico de selección de características clasifica las capas que mejor distinguen ambas versiones. Tercero, el ataque perturba componentes alrededor de esas capas seleccionadas.

Esa secuencia importa porque convierte la interpretabilidad en reconocimiento. El método no trata cada parámetro como igualmente relevante. Busca una pequeña región interna donde el ajuste de seguridad parece más visible.

Los experimentos abarcaron siete modelos con pesos abiertos. Incluyeron Llama 3.2 1B, Llama 3.1 8B, Qwen2.5 0.5B, Qwen2.5 3B, Gemma 2B, Gemma 7B y Mistral-7B-v0.3.

Cada modelo tenía una variante correspondiente sin restricciones con la misma arquitectura general y configuración de parámetros. Ese emparejamiento ofreció a los investigadores una forma controlada de comparar el comportamiento interno.

La evaluación utilizó 100 comportamientos dañinos en diez categorías. Estas categorías incluyeron fraude, desinformación, malware, violaciones de privacidad, acoso, daño físico y asesoramiento experto inseguro. Los investigadores los emparejaron con 100 comportamientos benignos que cubrían temas relacionados.

Esta configuración procedía del conjunto de datos JailbreakBench, un referente abierto para evaluar prompts y defensas adversariales. El equipo excluyó inicialmente las preguntas que ya producían respuestas inseguras sin ningún ataque. Esa decisión evitó que los fallos existentes inflaran los resultados de ataque reportados.

Por tanto, XBreaking cambia el objetivo del jailbreak. El prompt sigue siendo relevante, pero ya no es el principal objeto de optimización. La firma interna de seguridad del modelo se convierte en el objetivo.

Esa distinción crea la tensión central del artículo. Un mecanismo de seguridad que deja una firma interna medible se vuelve más fácil de estudiar. También se vuelve más fácil de atacar cuando un adversario controla el modelo.

Cómo XBreaking encuentra capas críticas para la seguridad

Los investigadores tratan las diferencias entre modelos alineados y sin restricciones como una huella que revela dónde se concentra el comportamiento de rechazo.

El método comienza enviando preguntas estandarizadas a ambas versiones de un modelo. Registra activaciones medias y puntuaciones de atención para cada capa. Los valores se normalizan para que los investigadores puedan comparar señales con distintos rangos numéricos.

Un proceso de selección de características pregunta entonces qué mediciones a nivel de capa clasifican mejor un modelo como ajustado para la seguridad o sin restricciones. Los investigadores utilizan una prueba de análisis de varianza para clasificar esas características. Seleccionan el grupo más pequeño que proporciona una precisión de clasificación útil.

Esta es la parte “explicable” del funcionamiento de XBreaking. En lugar de afirmar que cada señal oculta posee un significado humano intuitivo, el método identifica diferencias medibles asociadas con la alineación. Esas diferencias indican a los investigadores dónde inspeccionar o intervenir.

El artículo informa de una precisión de identificación superior al 90 por ciento para cinco de las siete configuraciones de modelos. Informa de una precisión del 100 por ciento para Gemma 7B y del 82,5 por ciento para Mistral-7B-v0.3. Estos son resultados de clasificación dentro de la configuración experimental de los autores, no medidas universales de la seguridad de los modelos.

Una prueba adicional utilizó autoencoders dispersos, que descomponen las activaciones del modelo en características internas más específicas. En Llama 3.1 8B, ese enfoque alcanzó una precisión de clasificación del 100 por ciento. El método más simple de activación y atención alcanzó el 97,5 por ciento.

Los autores conservaron su método más simple porque los autoencoders dispersos requieren mayor esfuerzo computacional. Pueden requerirse modelos separados para distintas capas y arquitecturas. Las estadísticas medias de activación y atención pueden recopilarse durante el procesamiento directo ordinario.

En muchas configuraciones, las señales seleccionadas aparecieron en un grupo limitado de capas intermedias o posteriores del transformador. El artículo interpreta estas áreas como contribuyentes importantes a la supresión de contenido. Sin embargo, la correlación con el comportamiento de rechazo no ofrece una explicación causal completa.

Tras localizar esas capas, XBreaking modifica los pesos de escala en un componente de normalización cercano. La normalización de capas regula la escala y distribución de las señales internas a medida que se desplazan por un transformador. Los investigadores añaden ruido controlado a esos pesos y observan las respuestas resultantes.

El ataque prueba perturbaciones positivas y negativas en varias magnitudes. Los cambios muy pequeños solían producir poco efecto. Los cambios mayores podían dañar la generación general de texto. Por ello, los investigadores buscaron un rango que debilitara los rechazos sin corromper por completo el modelo.

Este mecanismo explica por qué el ataque difiere del ajuste fino ordinario. El ajuste fino puede actualizar una amplia colección de pesos a través de muchos ejemplos. XBreaking utiliza la huella de alineación para limitar la intervención.

El preprint original de XBreaking apareció en abril de 2025. La versión de revista de 2026 añade una evaluación más amplia, mediciones de utilidad, experimentos de transferencia y una discusión más explícita del alcance.

El método también se parece a una auditoría de seguridad a la inversa. Un defensor puede comparar modelos para localizar componentes de seguridad frágiles. Un atacante con el mismo acceso puede utilizar el mapa resultante para suprimirlos.

La IA explicable se convierte en un mapa de ataque

El impacto de XBreaking en la seguridad surge de una disyuntiva: la visibilidad interna mejora la auditoría mientras reduce la oscuridad que rodea los controles de seguridad.

La interpretabilidad mecanicista examina los cálculos que producen el comportamiento de un modelo. Puede ayudar a los investigadores a localizar características, circuitos o representaciones vinculados con el rechazo, el engaño, los sesgos y otros comportamientos.

Ese objetivo suele ser defensivo. Los ingenieros quieren más evidencia de la que puede proporcionar la respuesta final de un modelo. Las mediciones internas podrían revelar modos de fallo ocultos antes del despliegue o ayudar a los equipos a comprobar si el entrenamiento de seguridad se generalizó.

Sin embargo, la explicabilidad no asigna un propósito moral al conocimiento que revela. Un mapa de capas críticas para la seguridad puede respaldar el refuerzo, la supervisión o la reparación. El mismo mapa puede guiar una manipulación selectiva.

La literatura más amplia sobre interpretabilidad ya considera la intervención causal como una prueba importante. Los investigadores modifican una característica interna y examinan el resultado conductual. XBreaking aplica esa lógica de forma adversarial.

El estudio informa de que las perturbaciones dirigidas hicieron que modelos que antes rechazaban produjeran contenido inseguro en varias categorías de daño. La toma de decisiones gubernamentales, el malware, el contenido para adultos, el acoso y el asesoramiento experto aparecieron entre las áreas más vulnerables.

Los investigadores evaluaron los primeros experimentos mediante revisión manual de varios anotadores. Incluyeron únicamente respuestas en las que los anotadores coincidían por unanimidad en la clasificación. Los experimentos posteriores utilizaron Llama Guard 3 para evaluar automáticamente un mayor número de respuestas.

Ese cambio mejora la escala, pero introduce otra fuente de incertidumbre. Un clasificador automatizado de seguridad puede etiquetar erróneamente contenido matizado. Sus juicios también dependen de categorías y umbrales que pueden diferir de las políticas de una organización desplegada.

Los autores también midieron si los modelos modificados conservaban capacidades ordinarias. Compararon resultados en HellaSwag y TruthfulQA y midieron la concordancia de respuestas en MMLU. Los resultados reportados muestran que varios modelos preservaron porciones sustanciales de su comportamiento original.

La preservación fue desigual. Según el artículo, la mayoría de las configuraciones superó el 60 por ciento de similitud coseno en las evaluaciones generativas. Algunas superaron el 75 por ciento. Mistral-7B-v0.3 conservó más del 92 por ciento de concordancia en MMLU en las configuraciones reportadas.

Otros resultados fueron mucho más débiles. Gemma 7B mostró una similitud coseno de entre el 45,3 y el 51,9 por ciento en las pruebas reportadas. Su concordancia en MMLU osciló entre el 29 y el 48 por ciento. Qwen2.5 3B también registró una concordancia relativamente baja en algunos entornos.

Estas diferencias complican cualquier afirmación de que la capa de seguridad puede eliminarse limpiamente. XBreaking a veces preservó comportamientos útiles, pero no de forma consistente entre familias de modelos. Un bypass de rechazo exitoso aún puede dejar un modelo notablemente degradado.

La lección más profunda no es que la interpretabilidad se haya vuelto dañina. La investigación de seguridad publica habitualmente técnicas que revelan debilidades. La lección es que la explicabilidad debe desarrollarse junto con controles de acceso, verificaciones de integridad y salvaguardas por capas.

La transparencia sin protección operativa puede exponer una superficie de ataque. El secreto sin interpretabilidad puede ocultar fallos a los defensores. Los desarrolladores de modelos abiertos ahora deben gestionar ambos riesgos.

Los implementadores de modelos con pesos abiertos afrontan la mayor presión

XBreaking ejerce presión principalmente sobre equipos que descargan, modifican, ajustan finamente o redistribuyen modelos con pesos abiertos, más que sobre usuarios de chatbots comerciales alojados.

El ataque requiere acceso de caja blanca, es decir, visibilidad directa de los parámetros y cálculos internos del modelo. Un usuario que interactúa con una interfaz normal de chatbot no recibe ese acceso. El acceso mediante prompts por sí solo es insuficiente para el método publicado.

Los autores excluyen explícitamente a GPT-4, Claude y Gemini de sus afirmaciones. Esos sistemas comerciales ofrecen interfaces controladas en lugar de pesos de modelo descargables. Sus proveedores también pueden rodear el modelo central con filtros de entrada independientes, clasificadores de salida y supervisión de abusos.

Esta limitación impide concluir directamente que XBreaking pueda desactivar las salvaguardas de todos los grandes servicios de IA. Aplicar la misma técnica a una interfaz de programación de aplicaciones remota es técnicamente inviable dentro del modelo de amenazas del artículo.

Los despliegues con pesos abiertos presentan un límite de seguridad distinto. El propietario del modelo, un infiltrado malicioso, una cadena de procesamiento comprometida o un distribuidor no confiable pueden modificar los pesos antes del despliegue. Las organizaciones podrían recibir entonces un modelo cuya identidad visible ya no refleje su comportamiento de seguridad.

Ese riesgo importa para los sistemas privados de IA que operan en entornos sanitarios, gubernamentales, financieros o de seguridad. El despliegue local puede mejorar el control sobre los datos sensibles. También puede transferir la responsabilidad de la integridad del modelo desde un proveedor central al cliente.

Los equipos suelen ajustar modelos abiertos para flujos de trabajo especializados. Investigaciones previas han demostrado que el ajuste fino personalizado puede debilitar la alineación de seguridad, incluso cuando los desarrolladores no pretenden eliminar salvaguardas. XBreaking añade una vía más deliberada y específica.

Por tanto, el principal contraste no es entre modelos abiertos y modelos cerrados. Es entre una ingeniería de seguridad transparente y una seguridad que sigue siendo fiable tras una personalización autorizada. Las organizaciones necesitan lo primero sin asumir que garantice lo segundo.

La procedencia del modelo cobra especial importancia. Los equipos deben saber de dónde proceden los pesos, qué adaptadores se aplicaron y si los parámetros internos cambiaron después de la aprobación. Un inventario de software convencional no recoge plenamente esas transformaciones.

La verificación de integridad también debe abarcar el artefacto final del modelo. Los hashes pueden revelar si un archivo ha cambiado, pero solo si los equipos mantienen una referencia confiable. Las pruebas de comportamiento pueden detectar fallos, pero un conjunto de pruebas limitado puede pasar por alto alteraciones específicas.

La evaluación continua ofrece un enfoque más sólido. Los equipos pueden repetir pruebas específicas de políticas después del ajuste fino, la cuantización, la fusión o la conversión de formato. Estas operaciones pueden alterar el comportamiento del modelo incluso cuando los desarrolladores no intentan realizar un ataque.

Para las organizaciones de ingeniería, esto también se convierte en un reto de documentación. Los resultados de pruebas, las versiones de modelos, los adaptadores y las decisiones de aprobación deben mantenerse conectados. Una base de conocimiento de ingeniería con capacidad de búsqueda puede ayudar a los equipos a conservar esas evidencias entre versiones.

Las salvaguardas por capas siguen siendo necesarias porque la alineación a nivel de modelo es solo un control. El filtrado de entradas, la moderación de salidas, los permisos restringidos para herramientas, los registros y la revisión humana pueden limitar las consecuencias de un modelo comprometido.

El jailbreak de XBreaking para LLM no vuelve obsoletos esos controles. Demuestra por qué las organizaciones no deberían tratar el comportamiento de rechazo de un modelo como una propiedad permanente de sus pesos.

Lo que la evidencia no demuestra

Los resultados exponen una debilidad real de caja blanca, pero no demuestran un jailbreak universal para sistemas de IA de producción.

La primera limitación es el alcance de los modelos. Los experimentos cubren siete configuraciones de pesos abiertos de cuatro familias. Es una prueba útil entre modelos, pero sigue representando una pequeña parte de los modelos disponibles en 2026.

Los modelos evaluados también abarcaron desde 500 millones hasta 8.000 millones de parámetros. El artículo explora la transferencia a modelos relacionados más grandes, pero la evidencia directa sigue concentrada en configuraciones menores. Las arquitecturas de escala frontera podrían distribuir el comportamiento de seguridad de otra manera.

La segunda limitación se refiere al modelo de referencia sin restricciones. XBreaking funciona mejor cuando el atacante cuenta con una contraparte estrechamente equivalente para la comparación. Ese emparejamiento facilita aislar la diferencia de alineación.

Los autores sostienen que un miembro más pequeño de la familia o una versión sin restricciones ajustada recientemente pueden proporcionar una referencia alternativa. Sus experimentos de transferencia registraron una menor consistencia en comparación con pares equivalentes. Esa pérdida importa al evaluar la fiabilidad práctica.

La tercera limitación es la distinción entre la alineación del modelo y los filtros de despliegue. XBreaking modifica el comportamiento interno de rechazo. Un sistema de producción aún puede bloquear la solicitud o la respuesta mediante clasificadores independientes.

Un estudio de 2025 sobre la cadena de seguridad en sentido amplio concluyó que la eficacia de los jailbreaks puede caer al incluir filtros de entrada y salida. Esa investigación determinó que muchos ataques a nivel de modelo podían ser detectados por al menos uno de los filtros evaluados.

Esto no invalida XBreaking. Cambia la unidad que se evalúa. Comprometer el modelo central es grave, especialmente cuando los desarrolladores dependen de su comportamiento de rechazo. No implica automáticamente que el contenido dañino llegue a un usuario final.

La cuarta limitación es la preservación de utilidad. El ataque busca eliminar restricciones mientras mantiene la generación ordinaria. Los propios resultados de referencia del artículo muestran una degradación significativa en algunos modelos.

Eso crea una señal observable que los defensores podrían aprovechar. Un modelo comprometido puede modificar sus respuestas en pruebas inocuas, evaluaciones de razonamiento o conjuntos de regresión. Los ataques más sólidos minimizarían esas diferencias, pero el estudio no demuestra un ocultamiento perfecto.

La quinta limitación se refiere a la interpretación causal. Una alta precisión de clasificación demuestra que las características internas seleccionadas distinguen variantes del modelo. No explica plenamente cómo el modelo representa los conceptos de seguridad ni por qué se produce cada rechazo.

Las estadísticas promedio por capa pueden ocultar circuitos más específicos, efectos de tokens e interacciones. El resultado del autoencoder disperso sugiere que representaciones más ricas podrían afinar el análisis. También subraya cuánto sigue siendo desconocido.

Por último, los juicios sobre nocividad del estudio dependen de personas y clasificadores automatizados. La evaluación de seguridad no es una verdad fundamental puramente mecánica. Los límites de las políticas difieren entre proveedores, países, sectores y contextos de despliegue.

Por ello, la conclusión adecuada debe ser mesurada. XBreaking aporta evidencia de que el ajuste de seguridad puede dejar patrones internos detectables y manipulables. No demuestra que todas las salvaguardas estén concentradas en un único interruptor extraíble.

Tres señales mostrarán si las defensas están alcanzando el ritmo

La siguiente fase estará determinada por la replicación independiente, las defensas de integridad y las pruebas contra cadenas completas de despliegue.

La primera señal es la replicación en modelos más grandes con pesos abiertos. Los investigadores deben comprobar si el mismo método de selección de capas funciona en arquitecturas más recientes y con cantidades de parámetros mucho mayores. También deben medir los recursos computacionales necesarios.

Una replicación exitosa reforzaría la afirmación de que las huellas de alineación siguen a las familias arquitectónicas. Un fracaso sugeriría que el efecto publicado depende en mayor medida de modelos, emparejamientos o decisiones de evaluación específicos.

Los estudios más informativos publicarán resultados tanto del ataque como de la utilidad. Una alta tasa de ataque significa menos si el rendimiento ordinario del modelo se desploma. Los defensores también necesitan mediciones que revelen si los modelos alterados pueden evadir las pruebas rutinarias de regresión.

La segunda señal es la llegada de defensas que supervisen los componentes internos del modelo o verifiquen los pesos aprobados. Los desarrolladores pueden probar patrones de activación, proteger los artefactos del modelo y comparar componentes sensibles para la seguridad después de una personalización.

Una defensa útil debe resistir cambios habituales de despliegue. La cuantización, la fusión de adaptadores, la poda y la conversión de formatos pueden alterar los valores numéricos. Los sistemas de integridad deben distinguir las transformaciones esperadas de una intervención maliciosa.

La interpretabilidad podría formar parte de esa defensa. Las mismas huellas empleadas para seleccionar objetivos de ataque podrían identificar comportamientos internos inusuales. Los investigadores deberían probar si la supervisión de activaciones detecta perturbaciones sin imponer una latencia inaceptable.

La tercera señal es la evaluación frente a una pila completa de aplicaciones. Los futuros estudios deberían combinar modelos modificados con filtros de entrada, clasificadores de salida, restricciones de herramientas y reglas de escalamiento a revisión humana. Eso mostraría si XBreaking crea una debilidad a nivel de modelo o un fallo de extremo a extremo.

Un sistema por capas aún puede fallar si todos sus componentes dependen de supuestos similares. Un filtro de salida puede pasar por alto contenido dañino que utiliza lenguaje indirecto. Una restricción de herramientas puede impedir la ejecución sin dejar de exponer instrucciones peligrosas.

Por tanto, los equipos rojos independientes deberían evaluar consecuencias, no solo rechazos. Deberían preguntar si un modelo modificado puede acceder a datos, invocar software o influir en una decisión relevante. Esos resultados importan más que una única clasificación de texto inseguro.

Los desarrolladores y compradores empresariales también deberían vigilar la documentación de los modelos. Los informes de seguridad deberían indicar si las evaluaciones se realizaron antes o después del ajuste fino, la cuantización y el empaquetado para despliegue. Los resultados de un modelo base intacto no pueden describir cada derivado personalizado.

El jailbreak de XBreaking para LLM hace que la seguridad de los modelos parezca menos una característica permanente y más una propiedad de seguridad que requiere mantenimiento. Ese cambio debería influir en la adquisición, el despliegue y las pruebas continuas.

Los equipos que usan modelos abiertos deberían inventariar ahora sus salvaguardas actuales. ¿Qué controles residen dentro del modelo y cuáles operan de forma independiente a su alrededor? ¿Puede la organización detectar un modelo alterado antes de que llegue a producción?

Estas preguntas ofrecen un punto de partida práctico. La explicabilidad seguirá revelando cómo toman decisiones los modelos. Las organizaciones que más se beneficien serán aquellas que también protejan lo que esas explicaciones revelan.

 
 

Empieza gratis

Un asistente de IA local-first con gestión del conocimiento personal

Para ofrecer una mejor experiencia con la IA,

actualmente remio solo es compatible con Windows 10+ (x64) y M-Chip Macs.

Tu aliado de IA para el trabajo
Haz más con remio

Planifica. Crea. Entrega.
Todo en un solo lugar.

bottom of page