La detección de jailbreaks debe identificar las inyecciones de prompts y las entradas que eluden las políticas antes de que generen salidas no permitidas o sorteen los controles de seguridad, y debe hacerlo junto con defensas arquitectónicas por capas, no como una medida aislada. El enfoque recomendado combina la detección continua con la defensa en profundidad y la revisión humana de las acciones de alto riesgo.
En resumen:
- Combinar métodos de detección por capas, como los umbrales de perplejidad y la comparación de salidas, reduce significativamente la tasa de éxito de los ataques de jailbreak.
- Las defensas arquitectónicas deben aislar el contenido no fiable, separar el razonamiento de la ejecución y exigir una revisión humana de las acciones sensibles para contener posibles brechas.
- Las pruebas adversariales continuas con ataques de variantes aproximadas, de origen humano y multimodales son esenciales para identificar las técnicas de jailbreak en evolución.
- Las auditorías independientes ayudan a validar la eficacia de la detección, los protocolos de escalado y los permisos de las herramientas, y aportan pruebas creíbles a los reguladores.
- Ninguna defensa por sí sola evita todos los jailbreaks, por lo que sigue siendo crucial adoptar un enfoque exhaustivo de defensa en profundidad combinado con supervisión humana.
Índice
- Cómo son los jailbreaks en la práctica: ataques directos e indirectos
- Métodos de detección y señales que debe supervisar
- Arquitectura de defensa en profundidad que limita el impacto cuando falla la detección
- Pruebas adversariales y supervisión continua para medir qué funciona
- Lista de comprobación operativa y guía de actuación para la gobernanza de agentes de IA
- Perspectiva editorial: qué priorizar el próximo trimestre
- Cómo ayudamos a los equipos a validar la detección y demostrar el cumplimiento
- Preguntas frecuentes
- Fuentes
Cómo son los jailbreaks en la práctica: ataques directos e indirectos
Una inyección directa de prompts se produce cuando un usuario introduce una instrucción directamente en la ventana de chat para indicar al agente que ignore su prompt de sistema o adopte una nueva identidad que elimine las restricciones de seguridad. Una inyección indirecta de prompts es más peligrosa en los despliegues empresariales porque la instrucción maliciosa llega dentro de los datos que procesa el agente, como una página web que resume, un correo electrónico que lee o un documento recuperado de una base de conocimiento. Las directrices del NCSC consideran que se trata de un problema fundamentalmente distinto de la inyección SQL, ya que los grandes modelos de lenguaje no separan claramente las instrucciones de los datos, lo que convierte esta vulnerabilidad en un problema estructural, no subsanable mediante parches.
Los ataques también se agrupan en categorías reconocibles que determinan cómo probar las defensas y protegerse frente a ellos:
- Los jailbreaks de origen humano utilizan identidades elaboradas, escenarios de interpretación de roles o planteamientos hipotéticos para inducir salidas restringidas.
- Los jailbreaks basados en la ofuscación ocultan la intención mediante codificación, espaciado inusual, cambios a otros idiomas o sustitución de tokens.
- Los jailbreaks basados en heurísticas encadenan patrones de prompts conocidos que ya han logrado eludir filtros.
- Los jailbreaks basados en la retroalimentación iteran automáticamente y utilizan las propias negativas del modelo para perfeccionar el siguiente intento.
- Los jailbreaks basados en el ajuste fino explotan los procesos de personalización para debilitar la alineación durante el entrenamiento.
- Los jailbreaks basados en parámetros de generación manipulan la temperatura, top-p o la configuración de muestreo para obtener contenido suprimido.
Los vectores específicos de los agentes añaden más riesgos: la manipulación de la invocación de herramientas que engaña a un agente para que llame a la API equivocada; la desviación del plan, en la que el razonamiento de varios pasos se orienta de forma inadvertida hacia un objetivo no previsto; la autonomía excesiva concedida mediante permisos demasiado amplios; y los ataques multimodales incrustados en imágenes o audio que los filtros exclusivamente textuales nunca inspeccionan.
Métodos de detección y señales que debe supervisar
Una detección eficaz actúa en varias capas del flujo de procesamiento, y ninguna señal por sí sola cubre todas las clases de ataques. Los detectores a nivel de prompt identifican muchos intentos de ofuscación y ataques heurísticos antes de que lleguen al modelo. Las señales internas del modelo, cuando la arquitectura permite acceder a ellas, detectan lo que los patrones textuales pasan por alto. Las comprobaciones de salida detectan lo que supera ambas capas.
- Los umbrales de perplejidad señalan entradas con patrones de probabilidad de tokens inusualmente altos o bajos que sugieren ofuscación o sufijos adversariales.
- La búsqueda de coincidencias de patrones y coincidencias aproximadas detecta técnicas de ofuscación conocidas, incluidos trucos de codificación y sustitución de caracteres.
- Las comprobaciones de perturbación y consistencia comparan las respuestas del modelo ante versiones ligeramente modificadas de una misma entrada y señalan la inestabilidad que sugiere manipulación.
- El análisis de logits y gradientes examina los cambios en la probabilidad de rechazo a nivel interno del modelo; está disponible cuando se controlan los pesos del modelo o se dispone de acceso mediante API a las probabilidades logarítmicas.
- Los métodos de agregación de salidas regeneran una respuesta varias veces y comparan su similitud, señalando los casos en los que las salidas divergen notablemente o una capa de clasificación de intenciones discrepa de la solicitud declarada.
Una evaluación a gran escala concluyó que ninguna defensa por sí sola detiene por completo todas las categorías de jailbreak, aunque combinar varias defensas reduce de forma sustancial la mayoría de las clases de ataques, mientras que algunos métodos avanzados siguen teniendo éxito. Esta conclusión procede de la investigación de ACL 2025 sobre la evaluación de jailbreaks e implica que los equipos deben asignar presupuesto a una cobertura por capas, no a un único detector.
Cada método conlleva contrapartidas. Las comprobaciones de perplejidad añaden latencia y pueden generar falsas alarmas ante consultas técnicas o multilingües legítimas. Las comprobaciones de perturbación multiplican el coste de inferencia, ya que requieren varias llamadas al modelo por solicitud. Una revisión de la investigación sobre defensas frente a jailbreaks recoge expresamente estas lagunas de cobertura, y la respuesta práctica consiste en ajustar los umbrales por categoría de riesgo: tolerancias más estrictas y más comprobaciones redundantes para las acciones que afectan a datos sensibles, y tolerancias más flexibles para las interacciones conversacionales de bajo riesgo.

Arquitectura de defensa en profundidad que limita el impacto cuando falla la detección
Algunos ataques no se detectarán. La arquitectura que rodea la detección determina si un fallo se convierte en una molestia menor o en un incidente grave. Las directrices de Microsoft para defenderse frente a la inyección indirecta de prompts recomiendan tratar estos ataques como inevitables e incorporar la contención al propio diseño del sistema.
- Aísle el contenido no fiable. La inferencia en cuarentena y los controles del flujo de información, incluidas las técnicas de señalización de contenido no fiable y el marcado explícito de datos, mantienen el contenido recuperado o aportado por el usuario claramente separado de las instrucciones fiables del sistema.
- Separe el razonamiento de la ejecución. Un patrón de doble LLM utiliza un modelo en cuarentena para leer contenido no fiable y generar un resumen estructurado, mientras que otro modelo independiente y con privilegios actúa únicamente sobre ese resumen depurado, no sobre la entrada original.
- Someta cada llamada a herramientas a controles de autorización. Emita tokens de API con privilegios mínimos, valide los parámetros conforme a un esquema estricto y canalice cualquier acción que supere un umbral de riesgo definido a través de un flujo de aprobación.
- Exija una revisión humana de las acciones sensibles. El acceso a datos privados, las transferencias de fondos y los comandos del sistema requieren la intervención de una persona; las comprobaciones automatizadas pueden clasificar estas solicitudes, pero nunca deben autorizarlas por sí solas.
- Añada comprobaciones deterministas externas al modelo. La autorización final de las acciones de alto impacto debe basarse en una lógica de reglas que el modelo de lenguaje no pueda eludir mediante argumentos.
Consejo profesional: Trate los permisos de las herramientas como las credenciales de una base de datos en producción: con un alcance limitado, rotación periódica y registro de cada llamada.
Pruebas adversariales y supervisión continua para medir qué funciona
Las defensas estáticas pierden eficacia a medida que evolucionan las técnicas de ataque, por lo que las pruebas deben ser continuas, no limitarse a una auditoría puntual. Las baterías de pruebas eficaces combinan varios enfoques.
- El fuzzing Best-of-N ejecuta numerosas variaciones aleatorias de plantillas de jailbreak conocidas para revelar debilidades que un único caso de prueba pasaría por alto.
- Los corpus de jailbreaks de origen humano recogen patrones de ataque creativos que la generación automatizada tiende a pasar por alto.
- Las pruebas basadas en la retroalimentación y en parámetros de generación simulan atacantes que iteran a partir de las respuestas del modelo o manipulan directamente la configuración de muestreo.
- Los escenarios multimodales prueban entradas de imagen y audio junto con el texto, ya que los filtros ajustados únicamente para texto dejan estos canales expuestos.
Supervise la tasa de éxito de los ataques (ASR) y la tasa de elusión (BR) como métricas principales de calibración, junto con la tasa de falsos positivos, el impacto en la latencia y cualquier deterioro medible de la experiencia de usuario debido a la fricción añadida. La investigación que clasifica los ataques de jailbreak señala que los ataques basados en heurísticas suelen detectarse con facilidad, mientras que los métodos más recientes basados en la retroalimentación y en parámetros de generación eluden muchos detectores, lo que justifica dar más peso en las pruebas a las categorías más difíciles.
Realice ejercicios de equipo rojo con una periodicidad fija, no solo después de un incidente, y considere los fallos repetidos ante una misma clase de ataque como una señal para reducir los privilegios de inmediato, en lugar de esperar a que se reentrene el modelo. Registre los pares completos de entradas y salidas, todas las llamadas a herramientas, cada paso del plan y cada decisión de los mecanismos de protección. Este registro es lo que permite revisar un incidente y lo que respalda posteriormente los informes de cumplimiento.
Lista de comprobación operativa y guía de actuación para la gobernanza de agentes de IA
Convertir los principios de detección y arquitectura anteriores en un programa repetible exige supervisar un conjunto reducido de controles en todos los agentes en producción.
- Examine las entradas para detectar patrones de ofuscación conocidos y anomalías de perplejidad.
- Valide las salidas mediante clasificadores de intenciones antes de que lleguen al cliente.
- Controle cada llamada a herramientas mediante credenciales con privilegios mínimos y validación de esquemas.
- Exija una revisión humana de las acciones que afecten a datos sensibles o sean irreversibles.
- Ejecute pruebas adversariales con una periodicidad fija, no solo de forma reactiva.
- Verifique que las vías de escalado lleguen a un representante humano cuando un agente no pueda resolver un problema.
| Área de control | Qué comprobar | Por qué importa |
|---|---|---|
| Cobertura del escalado | Si los problemas sin resolver llegan a un agente humano | La mayoría de los agentes auditados fallan en este paso |
| Control de acceso a herramientas | Alcances con privilegios mínimos en cada llamada a la API | Limita el alcance del daño cuando falla la detección |
| Pruebas adversariales | Ejercicios de equipo rojo con periodicidad fija y seguimiento de ASR y BR | Detecta desviaciones antes que los atacantes |
Las auditorías independientes convierten esta lista de comprobación en pruebas. Una revisión documentada que verifica el comportamiento del escalado, los permisos de las herramientas y las decisiones de los mecanismos de protección proporciona a los equipos de cumplimiento un documento que pueden presentar a los reguladores, y ofrece a los equipos de Seguridad, Experiencia de Cliente (CX) y Producto una referencia común en lugar de tres evaluaciones distintas del mismo agente.
Perspectiva editorial: qué priorizar el próximo trimestre
Consideramos que la mayoría de los equipos de seguridad y CX siguen invirtiendo demasiado poco en pruebas adversariales en comparación con lo que destinan a la configuración inicial de los mecanismos de protección. Estos mecanismos pierden eficacia a medida que los atacantes se adaptan, y no se puede dar por hecho que una defensa que superó una revisión hace seis meses siga siendo eficaz. Recomendamos priorizar una periodicidad fija de pruebas, instrumentar cada llamada a herramientas y cada control de autorización de acciones, y considerar obligatoria, no opcional, la revisión humana de cualquier operación que afecte a datos sensibles. Prevea contrapartidas efectivas en materia de latencia y falsos positivos, y alinee a los equipos de Seguridad, CX y Producto en torno a los flujos de escalado antes de que un incidente fuerce esa conversación. Conviene considerar la auditoría independiente como una vía para validar la cobertura con pruebas que un regulador pueda aceptar.
— Sergio Llorens
Cómo ayudamos a los equipos a validar la detección y demostrar el cumplimiento
Auditamos agentes de IA conversacional de cualquier proveedor, lo que le permite obtener una comprobación independiente de la detección de jailbreaks, el comportamiento del escalado y los permisos de las herramientas sin depender de la información declarada por el propio proveedor. La supervisión continua revela las carencias que una revisión puntual pasa por alto y convierte datos de conversaciones dispersos en alertas sobre las que los equipos de Seguridad, CX y Producto pueden actuar conjuntamente.

Las modalidades de servicio se adaptan a distintos puntos de partida:
- Flash Preview o Audit Sprint para una evaluación específica y de corta duración de un agente concreto.
- Lexic Compass para una auditoría completa, independiente del proveedor, del comportamiento del agente, el cumplimiento y la postura de seguridad.
- Enterprise Continuous Trust para la supervisión continua de todo el conjunto de agentes.
Empiece con una auditoría Lexic Compass si necesita pruebas listas para presentar a los reguladores sobre cómo se comportan realmente sus agentes.
Preguntas frecuentes
¿Qué es la detección de jailbreaks en agentes de IA conversacional?
La detección de jailbreaks identifica inyecciones de prompts y otras entradas que eluden las políticas, diseñadas para hacer que un agente de IA conversacional genere salidas no permitidas o sortee sus controles de seguridad. Se basa en señales como la puntuación de perplejidad, las comprobaciones de consistencia ante perturbaciones y la comparación de salidas, aplicadas por capas junto con controles arquitectónicos, no de forma aislada.
¿Es posible evitar por completo los jailbreaks?
Ningún enfoque actual elimina por completo el riesgo de jailbreak. La investigación a gran escala sobre jailbreaks concluyó que combinar varias defensas reduce significativamente muchas clases de ataques, pero algunos métodos avanzados siguen teniendo éxito; por ello, la defensa en profundidad y la revisión humana de las acciones de alto riesgo siguen siendo necesarias.
¿Cuál es la diferencia entre la inyección directa e indirecta de prompts?
La inyección directa de prompts se produce cuando se introduce una instrucción directamente en la conversación para anular el prompt de sistema. La inyección indirecta de prompts oculta la instrucción maliciosa en contenido externo que procesa el agente, como un documento o una página web, algo que las directrices de Microsoft consideran más difícil de contener.
¿Qué métricas debemos supervisar para saber si la detección funciona?
Supervise la tasa de éxito de los ataques y la tasa de elusión obtenidas en las pruebas adversariales, junto con la tasa de falsos positivos y el impacto en la latencia de la capa de detección. Un aumento de la tasa de éxito de los ataques en una batería de pruebas conocida indica que deben reducirse los privilegios de inmediato, en lugar de esperar a una actualización del modelo.
¿Cómo encajan las auditorías independientes en un programa de detección de jailbreaks?
Las auditorías independientes verifican el comportamiento de los agentes, la gestión del escalado y los permisos de las herramientas sin depender de los datos facilitados por el proveedor, y aportan a los equipos de cumplimiento pruebas que pueden defender ante los reguladores.
Fuentes
Estas fuentes han servido de base para los métodos de detección, los patrones arquitectónicos y la taxonomía expuestos anteriormente, y conviene consultarlas directamente para conocer los detalles técnicos de implementación.
- La inyección de prompts no es inyección SQL (NCSC)
- Defensa frente a los ataques de inyección indirecta de prompts | Microsoft Learn
- JailbreakRadar: evaluación exhaustiva de los ataques de jailbreak contra LLM (ACL 2025)
- Ataques de jailbreak y defensas para grandes modelos de lenguaje: una revisión (arXiv, 2024)
Creado con BabyLoveGrowth para mejorar la visibilidad en buscadores

