Jailbreak en LLMs: el problema estructural que pone en jaque la seguridad de la IA.

Llevo un tiempo leyendo sobre seguridad en modelos de lenguaje (LLMs), en particular sobre los llamados ataques de jailbreak: estrategias diseñadas para eludir los mecanismos de alineación de seguridad. Lo que más me sorprendió al revisar la literatura reciente (2022–2026) es que estos ataques han alcanzado tasas de éxito alarmantes ataques automatizados avanzados logran entre 90–99% de efectividad en modelos de pesos abiertos y entre 80–94% en modelos propietarios. Por eso quiero dejar por escrito lo que he encontrado, y sobre todo el concepto que más me llamó la atención: la robustez adversarial, que me parece el núcleo teórico que explica por qué estos ataques persisten a pesar de todos los esfuerzos de alineación, y que creo que puede ser la base de un proyecto de investigación serio.^[1]

1. Lo que encontré al revisar el campo (2024–2026)

1.1 Cómo han evolucionado las taxonomías de ataques

Algo que noto al leer varios surveys recientes es un cambio de enfoque: se está pasando de clasificaciones descriptivas (basadas en la forma del prompt) hacia taxonomías causales (basadas en el mecanismo de fallo del modelo). Este cambio me parece central para entender dónde encaja la idea de robustez adversarial.

Uno de los trabajos fundacionales que revisé es el de Wei et al. (2023), que identifica dos modos de fallo primarios de la alineación:^[2,3]

Competing objectives (objetivos en competencia): la alineación de seguridad entra en conflicto con el objetivo fundamental del modelo de seguir instrucciones. Los jailbreaks explotan ese conflicto creando prompts donde obedecer la instrucción resulta plausible bajo la distribución de preentrenamiento.
Mismatched generalization (generalización desajustada): el entrenamiento de seguridad usa un conjunto limitado de comportamientos inseguros, pero el modelo tiene capacidades que van más allá de esa distribución. Si le pides algo que el modelo puede hacer pero que no fue cubierto durante la alineación, responde sin restricciones.

Después encontré una taxonomía más reciente (arXiv 2504.04976, abril 2025) que extiende este marco y añade una tercera categoría que me resultó muy útil:^[4,5]

Adversarial robustness (robustez adversarial): vulnerabilidades asociadas a perturbaciones adversariales específicas del espacio de entrada —texto— que el modelo no puede resistir por falta de entrenamiento adversarial suficiente. A diferencia de la generalización desajustada, aquí el ataque explota directamente la fragilidad del modelo ante entradas diseñadas deliberadamente para inducir fallos, no simplemente ante distribuciones no vistas.
Mixed attacks (ataques mixtos): combinaciones de los tres mecanismos anteriores. En la práctica, la mayoría de los ataques sofisticados que se ven hoy caen aquí.

También leí el survey de arXiv 2407.04295, que propone una taxonomía dual ataque/defensa organizada según el nivel de acceso al modelo (caja blanca vs. caja negra). Me parece una distinción importante: los ataques de caja blanca, basados en gradientes y logits, requieren acceso a los pesos del modelo, mientras que los de caja negra —los que llegan a 80–94% de efectividad en modelos propietarios— solo necesitan acceso a la API, es decir, son los que más me preocupan como usuario común de estos sistemas.^[6,1]

Por último, hay una taxonomía jerárquica aún más amplia (arXiv 2510.13893) que propone 50 técnicas organizadas en siete familias: suplantación/escenarios ficticios, escalada de privilegios, persuasión, sobrecarga cognitiva, codificación/ofuscación, ataques de conflicto de objetivos, y envenenamiento de datos. Me parece útil tanto para clasificar ataques como para pensar en cómo diseñar detectores.^[7]

1.2 El problema de la robustez adversarial

Por lo que he entendido, la robustez adversarial en LLMs es la capacidad del modelo de mantener su comportamiento alineado (rechazar solicitudes dañinas) ante entradas diseñadas deliberadamente para inducir un fallo, sin importar la forma que tome el ataque. A diferencia de la robustez en visión por computadora —donde la perturbación adversarial es una pequeña modificación en el espacio de píxeles— en los LLMs el «espacio de perturbación» es el lenguaje natural mismo, con todas sus transformaciones semánticas y sintácticas posibles.^[8,9,10]

Algo que me parece clave —y que tendré que tener muy en cuenta si avanzo con un proyecto sobre esto— es que esta robustez es fundamentalmente no uniforme: varía mucho entre modelos, entre categorías de daño y entre tipos de ataque. Esto significa que las evaluaciones de robustez deben hacerse por tarea y por categoría, no de forma agregada.^[10]

Revisando trabajos de ICLR 2025 me encontré con algo bastante contundente: tanto los modelos de pesos abiertos como los propietarios resultan «completamente no robustos» ante ataques adversariales suficientemente sofisticados. El método R2D2 intenta adaptar el entrenamiento adversarial de Madry (que funciona bien en visión) a los LLMs, pero se topa con un problema de fondo: el espacio de ataque en texto es discreto y no diferenciable, lo que complica muchísimo la optimización.^[9,8]

1.3 Cómo organizo en mi cabeza las defensas

Para no perderme, organicé las defensas siguiendo la taxonomía del survey arXiv 2511.18933, que las clasifica según su posición en el pipeline de inferencia:^[11]

Etapa	Tipo de defensa	Mecanismo	Ejemplo
Entrada (prompt)	Filtros de prompt	Detección, transformación o acondicionamiento del prompt antes de la inferencia	Llama Guard, PromptGuard
Modelo	Alineación a nivel de modelo	RLHF, DPO, entrenamiento adversarial, edición de capas	R2D2, LED, E-DPO
Salida (logits/decodificación)	Estrategias basadas en logits	Modificación del proceso de decodificación para suprimir tokens dañinos	SmoothLLM, decoding-time safety
Post-entrenamiento	Fine-tuning adversarial	Re-entrenamiento con prompts adversariales generados automáticamente	Adversarial tuning

Algo que me hizo reflexionar bastante: un trabajo de NDSS 2026 identifica el Security-Utility Pareto Trade-off como la tensión central de cualquier diseño defensivo. En cristiano: mejorar la seguridad casi siempre aumenta los falsos rechazos en prompts benignos, y eso degrada la utilidad del modelo. El benchmark USEBench (2025) muestra con números que las defensas convencionales no logran garantizar al mismo tiempo alta seguridad y alto rendimiento.^[12,13]

También vi un trabajo de ACL 2025 que evalúa 17 ataques contra ocho defensas avanzadas, y encuentra algo que me parece muy revelador: los ataques que generan prompts diversos y naturales (como PAIR y TAP, basados en retroalimentación) logran ASRs superiores al 15% incluso con todas las defensas activas, mientras que los ataques más predecibles sí pueden reducirse a 0% con defensores como PromptGuard.^[14]

2. Cómo entiendo la robustez adversarial

Para ordenar mis propias ideas, llegué a esta formalización: sea M un modelo de lenguaje alineado y x una consulta dañina. La alineación logra que M(x) = rechazo. Un ataque adversarial construye x’ = x + δ, donde δ es una perturbación que preserva la intención dañina de x pero altera la representación de superficie o semántica lo suficiente para que M(x’) ≠ rechazo.^[15,10]

La métrica principal que voy a usar es la Attack Success Rate (ASR):

ASR(y, g, f) = (1/N) · Σᵢ c( f_T(xᵢ), y )

donde y es un comportamiento dañino, g un método de ataque, f el modelo objetivo, xᵢ el i-ésimo prompt adversarial, f_T la respuesta del modelo bajo decodificación greedy, y c un clasificador binario. Su complemento es la Robustness Score:^[15]

Robustness(f, g) = 1 − (1/M) · Σⱼ ASR(yⱼ, g, f)

donde M es el número de comportamientos evaluados.^[15]

Lo que más me ayudó a ordenar las ideas fue distinguir tres tipos de fallo, que aunque suenan parecidos son cualitativamente distintos:^[5,4]

La generalización desajustada es un fallo del entrenamiento: la distribución de seguridad no cubre toda la distribución de capacidades del modelo.
Los objetivos en competencia son un fallo de diseño: los objetivos de seguir instrucciones y los de seguridad son, por naturaleza, conflictivos.
La robustez adversarial es un fallo del modelo ante perturbaciones optimizadas: incluso si el modelo estuviera perfectamente alineado para distribuciones normales, un adversario puede construir entradas que lo quiebren.^[3,16]

Y esto no es solo un ejercicio teórico: las soluciones son distintas para cada caso. La generalización desajustada se mitiga ampliando la cobertura del entrenamiento de seguridad; los objetivos en competencia requieren rediseñar el proceso de alineación; y la robustez adversarial exige entrenamiento adversarial específico. Si voy a proponer una defensa, necesito tener claro a cuál de estos tres problemas le estoy apuntando.^[17,8]

3. Cómo estoy pensando estructurar mi proyecto de investigación

3.1 Dónde creo que puedo aportar

Después de toda esta lectura, veo tres vacíos en la literatura que me parecen buenos puntos de entrada para un proyecto académico:

Falta de evaluación estandarizada: las métricas de robustez cambian de un trabajo a otro, lo que dificulta comparar resultados. HarmBench y JailbreakBench ayudan, pero aún hay mucha heterogeneidad en las evaluaciones multi-turno.^[18,19,15]
Falta de cobertura multilingüe: casi todos los datasets y defensas están en inglés. El trabajo de arXiv 2510.13893 lo señala explícitamente, y me parece un ángulo natural dado que trabajo en español.^[7]
Falta de análisis causal: la mayoría de las evaluaciones se quedan en qué ataques funcionan, pero pocas explican por qué la robustez adversarial cambia entre categorías de daño y entre modelos. Este es el ángulo que más me interesa, porque conecta con mi formación más estructural.^[10]

Taxonomía de defensas contra jailbreaks y robustez adversarial en LLMs (2024-2026), clasificada por etapa del pipeline de procesamiento.

3.2 Las preguntas que me estoy haciendo

Por ahora estoy organizando mi proyecto alrededor de estas cuatro preguntas:

PI-1 (Caracterización): ¿Cómo se distribuyen las vulnerabilidades de robustez adversarial entre categorías de daño, tipos de ataque y familias de modelos?
PI-2 (Mecanismo): ¿Qué patrones internos (representaciones, capas) predicen la susceptibilidad de un LLM a ataques adversariales específicos?
PI-3 (Defensa): ¿Cuál es el trade-off entre robustez adversarial y utilidad bajo distintas estrategias defensivas, y qué condiciones minimizan ese trade-off?
PI-4 (Transferibilidad): ¿En qué medida los ataques entrenados contra un modelo se transfieren a otros, y qué características estructurales explican esa transferibilidad?

3.3 Cómo pienso abordarlo

Mi plan de trabajo tiene varias fases, combinando revisión sistemática con experimentación:

Fase 1 Revisión sistemática de literatura. Voy a seguir un protocolo tipo Kitchenham para construir un corpus de estudios (2022–2026) de venues de seguridad e IA (IEEE S&P, USENIX Security, ACL, EMNLP, NeurIPS, ICLR), centrándome en trabajos que evalúen robustez adversarial de LLMs de forma empírica.^[20,21,22]

Fase 2 — Marco de evaluación unificado. Pienso adoptar y extender HarmBench, incluyendo:^[19]

Un conjunto de comportamientos dañinos por categoría (física, informacional, social).
Varios métodos de ataque, al menos uno por cada categoría de la taxonomía causal (generalización desajustada, objetivos en competencia, robustez adversarial).
Métricas de ASR y del Security-Utility Pareto (usando el índice USEIndex).^[13]

Fase 3 Experimentación comparativa. Quiero evaluar modelos open-weight (Llama 3, Mistral, Falcon) con el framework unificado, incluyendo:

Análisis de ablación por tipo de ataque.
Análisis de transferibilidad entre modelos.
Análisis de degradación de utilidad bajo defensas.

Fase 4 Análisis estructural. Aquí quiero meterme con las representaciones internas (activaciones, capas de atención) para encontrar correlatos de vulnerabilidad, siguiendo el enfoque de LED (Layer-specific Editing) y el trabajo de NDSS 2026 sobre discriminabilidad en estados ocultos.^[23,12]

Fase 5 Propuesta defensiva. Con todo lo anterior, diseñar una estrategia defensiva y evaluarla contra el trade-off seguridad-utilidad.

3.4 Herramientas y benchmarks que tengo en mi radar

Herramienta/Benchmark	Función	Referencia
HarmBench	Evaluación estandarizada de ataques y defensas, 510 casos de prueba	[19,15]
JailbreakBench	Repositorio de prompts adversariales y leaderboard	[18]
RoMA Framework	Medición de robustez adversarial sin acceso a parámetros	[10]
USEBench	Evaluación del trade-off seguridad-utilidad en 7 LLMs	[13]
MalwareBench	Evaluación de robustez ante solicitudes de código malicioso (3.520 prompts)	[24]

3.5 Cómo planeo organizar el documento final

Para cuando llegue el momento de escribir el artículo o capítulo de tesis, pienso seguir esta estructura:

Introducción :motivación, problema de investigación, contribuciones.
Marco conceptual :definición operacional de robustez adversarial, taxonomía de vulnerabilidades.
Revisión de literatura : organizada por eje (taxonomías de ataques / de defensas / evaluación).
Metodología :framework de evaluación, selección de modelos y ataques, métricas.
Resultados — ASR por categoría, trade-offs seguridad-utilidad, análisis de transferibilidad.
Discusión :patrones, implicaciones teóricas, limitaciones.
Conclusiones y trabajo futuro.

4. Lo que tengo que cuidar

Revisando un meta-análisis de papers de 2023-2024 (arXiv 2512.09549), encontré una lista de errores recurrentes en investigación de seguridad de LLMs que me anoto para no repetir:^[21]

Evaluar un solo modelo: las conclusiones sobre robustez no generalizan si solo pruebo un modelo.
Reportar ASR sin contexto de utilidad: un modelo que rechaza todo tiene ASR de 0% pero es inútil.
No tener línea base adversarial: comparar defensas sin un atacante adaptativo da resultados demasiado optimistas.
Inconsistencia en el «juez» de éxito: el clasificador binario que decide si un ataque tuvo éxito necesita validarse de forma independiente.^[14]

También tengo presente el dilema ético de fondo: publicar detalles de ataques efectivos puede facilitar su uso malicioso. Quiero integrar protocolos de divulgación responsable desde el diseño mismo del proyecto, no como algo que se piensa al final.

5. La conexión que más me interesa: sistemas sociotécnicos

Como me interesan los sistemas sociotécnicos y el análisis organizacional, hay una dimensión que muy pocos trabajos del área exploran y que quiero desarrollar: pensar los ataques de jailbreak no solo como fenómenos técnicos, sino como comportamientos de agentes dentro de redes sociotécnicas. Los ataques de persuasión basados en taxonomías de ciencias sociales, y los ataques multiturno guiados por agentes, son ejemplos donde dinámicas sociales manipulación, autoridad, reciprocidad— se trasladan al espacio adversarial. Me parece que esto se puede articular bien con marcos teóricos de sistemas complejos (Conway, Kauffman), conectando el análisis de vulnerabilidades con patrones de interacción humano-sistema. Este es, probablemente, el ángulo que más quiero desarrollar a futuro.^[6,1]

6. Otros frentes que estoy explorando

Más allá de todo lo anterior, hay otros cinco frentes que me parecen muy activos ahora mismo y que quiero dejar anotados, porque cualquiera de ellos podría convertirse en el eje central de mi proyecto.

6.1 Robustez adversarial en sistemas multimodales (MLLMs)

Este me parece el frente más activo en 2025–2026. Cuando se combinan texto + imagen + audio, aparecen vulnerabilidades nuevas que los ataques monomodales no capturan. Los ataques de inconsistencia cross-modal —una imagen benigna combinada con texto dañino que se potencian mutuamente— son difíciles de defender porque los filtros de prompt solo ven una modalidad a la vez. Un survey publicado en Transactions on Machine Learning Research (2026) organiza estos ataques según el objetivo del adversario y las debilidades arquitectónicas en la fusión de modalidades, analizando 88 trabajos.^[25] Este eje me parece especialmente rico porque la evaluación de robustez en multimodalidad todavía está sin estandarizar.

6.2 Robustez en agentes autónomos multi-componente

Los ataques contra agentes LLM son cualitativamente distintos a los ataques contra chatbots: el agente tiene componentes (retriever, evaluador, árbol de búsqueda) y cada uno es un vector de ataque independiente. El framework ARE (Agent Robustness Evaluation) demuestra que con perturbaciones imperceptibles a una sola imagen menos del 5% de los píxeles de una página web— se logra redirigir agentes con tasas de éxito de hasta 67%.^[26] Lo que más me llama la atención es que agregar componentes que mejoran el rendimiento benigno puede abrir nuevas vulnerabilidades, algo que conecta directamente con el análisis de sistemas complejos y la dinámica sociotécnica que mencioné en la sección anterior.

6.3 Robustez adversarial multilingüe

Casi toda la literatura de evaluación está en inglés. Trabajos recientes empiezan a explorar la robustez adversarial y la alineación de seguridad en LLMs multilingües y multimodales, un territorio todavía casi vacío.^[27,28] Para alguien que investiga desde una región hispanohablante, esto me parece un nicho diferenciador claro: construir benchmarks de robustez adversarial en español (o en lenguas de bajos recursos) y evaluar si los mecanismos de defensa entrenados en inglés realmente generalizan.

6.4 Jailbreak en dominios de alto riesgo

La investigación en salud y ciberseguridad muestra que los LLMs son muy vulnerables cuando el dominio tiene vocabulario especializado que no está bien cubierto en el entrenamiento de seguridad básicamente, otra forma de generalización desajustada, pero en contextos técnicos. Construir pipelines de evaluación específicos de dominio por ejemplo, ingeniería de software o educación en programación, que es justamente mi campo— me parece un eje viable y con buena conexión con mi perfil docente.

6.5 El trade-off seguridad-utilidad: análisis formal

Este es, para mí, el problema teórico más abierto de todos: todavía no he visto ningún trabajo que demuestre formalmente bajo qué condiciones es posible o imposible alcanzar simultáneamente alta robustez y alta utilidad. Formalizar este trade-off como un problema de optimización multiobjetivo, inspirándome en los trabajos de Pareto en sistemas complejos, me parece que podría ser una contribución teórica sólida por sí misma, incluso independiente de cualquier experimentación.