Jailbreaks de IA en 2027: guía práctica de arquitectura defensiva

Un asistente que responde mal y un agente que ejecuta una acción indebida plantean riesgos distintos. Cuando una aplicación puede consultar información privada, emitir reembolsos o llamar a servicios externos, protegerla exige algo más que un buen prompt.

La decisión clave es separar lo que propone el modelo de lo que autoriza y ejecuta la aplicación. El modelo interpreta la solicitud; el backend comprueba identidad, permisos y reglas de negocio antes de producir efectos.

Esta guía está dirigida a desarrolladores que integran modelos de lenguaje con herramientas y datos empresariales. Presenta una arquitectura de referencia y ejemplos de sus controles, no una aplicación completa lista para producción.

Alcance temporal: publicada en noviembre de 2026 como preparación para 2027. Las recomendaciones se apoyan en documentación disponible al revisar el artículo; las versiones y herramientas pueden cambiar.

1. Qué queremos evitar

Conviene distinguir tres conceptos:

• Inyección directa de prompts: una solicitud intenta desviar el comportamiento del modelo.
• Inyección indirecta: las instrucciones llegan dentro de documentos, páginas web, correos o resultados de herramientas.
• Jailbreak: un intento de eludir las restricciones de seguridad del modelo.

OWASP clasifica la inyección de prompts como LLM01:2025. Esa clasificación identifica un riesgo; no demuestra por sí sola qué porcentaje de aplicaciones es vulnerable.

Considera un asistente de soporte que resume un documento adjunto. Si el documento incluye una orden para aprobar un reembolso, esa orden debe seguir siendo contenido del documento. No puede convertirse en autorización para mover dinero.

Objetivo de diseño: reducir la probabilidad de que el modelo siga instrucciones maliciosas y limitar las consecuencias si llega a hacerlo.

2. Arquitectura: el modelo propone, el backend decide

Organiza el flujo en seis etapas:

1. Autenticar: el backend identifica al usuario y su organización.
2. Recuperar: las consultas aplican permisos antes de incorporar documentos al contexto.
3. Interpretar: el modelo recibe la solicitud y los datos externos con su procedencia identificada.
4. Validar: el backend comprueba la estructura de la propuesta.
5. Autorizar: las reglas del servidor determinan si la operación está permitida y si requiere aprobación.
6. Ejecutar y registrar: un servicio con permisos limitados realiza la operación y conserva evidencia del resultado.

El modelo no debe poder sustituir ninguno de esos controles mediante texto. Tampoco debe recibir credenciales con las que pueda saltarse el servicio de autorización.

3. Preparar un entorno de referencia

Los ejemplos de Python usan Python 3.12 y Pydantic 2. Es una elección para esta guía, no una afirmación de que otras versiones sean incompatibles.

Instala únicamente lo necesario para los fragmentos:

La activación anterior corresponde a Bash. En PowerShell, utiliza el script de activación de la carpeta Scripts del entorno virtual.

Para las evaluaciones, la guía de inicio de Promptfoo indica Node.js 22.22.0 o posterior al momento de esta revisión. Comprueba ese requisito al configurar tu entorno.

4. Tratar las entradas y el contexto como datos

Aplicar límites sin alterar silenciosamente el contenido

Limita el tamaño de las solicitudes, los archivos, los resultados de herramientas y el contexto acumulado. Añade controles de frecuencia, tiempo de ejecución y consumo.

La normalización Unicode puede servir para detectar ciertas variantes de texto, pero no neutraliza una inyección. Eliminar indiscriminadamente caracteres invisibles también puede modificar idiomas, identificadores o código legítimo. Si normalizas para analizar, define qué transformaciones aceptas y conserva el original cuando sea necesario, con controles de acceso y retención.

Un filtro que detecta expresiones sospechosas es una señal adicional. No reemplaza los permisos ni las reglas de negocio.

Separar instrucciones y material externo

Mantén las instrucciones de la aplicación en los mensajes reservados para ese fin. No insertes allí texto arbitrario del usuario, documentos recuperados ni resultados de navegación.

Identifica la procedencia del contenido externo y úsalo como evidencia. Un documento interno también puede contener errores o instrucciones introducidas por un tercero.

El formato JSON, las etiquetas XML y los delimitadores ayudan a organizar el contexto, pero no crean una barrera de seguridad. Del mismo modo, una etiqueta que diga “verificado” no concede permisos: esa clasificación debe proceder de controles del backend.

La documentación de seguridad para agentes de OpenAI recomienda separar las entradas no confiables y restringir los datos que pasan entre etapas. Estas medidas reducen el riesgo, sin eliminarlo.

5. Validar propuestas con un esquema reducido

Evita herramientas genéricas como execute_sql para un agente de soporte que solo necesita consultar pedidos o solicitar reembolsos. Expón operaciones específicas y valida sus argumentos en el servidor.

Este esquema representa una propuesta de reembolso:

El esquema rechaza campos adicionales, importes fuera del rango y tipos incorrectos. El límite de 100.000 unidades mínimas es ilustrativo y debe ajustarse al producto y la moneda.

Un JSON válido todavía puede solicitar una operación indebida. Este esquema no demuestra que el pedido pertenezca al usuario, que sea reembolsable ni que exista una aprobación.

La identidad, la organización, la moneda y el destino del dinero deben obtenerse de fuentes autorizadas del servidor. No los aceptes como hechos porque los haya generado el modelo.

6. Autorizar con datos del servidor

El siguiente fragmento se añade al anterior. Ilustra comprobaciones sobre un pedido; no ejecuta el pago ni implementa el flujo de aprobación:

El servidor construye la identidad a partir de la sesión autenticada y carga el pedido desde su base de datos. No debe construir esos objetos copiando datos proporcionados por el modelo.

En una implementación real, el saldo reembolsable debe tener en cuenta devoluciones anteriores y operaciones pendientes. Antes de ejecutar, vuelve a comprobar el estado relevante bajo los controles de concurrencia apropiados.

Para pagos externos, utiliza las garantías de idempotencia del proveedor y registra el estado de la operación. Un reintento tras un timeout no debe generar un segundo reembolso.

7. Obtener una aprobación que el modelo no pueda inventar

Una respuesta del modelo que diga “el usuario confirmó” no demuestra consentimiento. La política del servidor determina cuándo hace falta una aprobación y quién puede concederla.

Para un reembolso sensible:

1. El backend guarda una solicitud pendiente con usuario, organización, pedido, importe y moneda.
2. Una interfaz de confianza muestra esos datos a la persona autorizada.
3. El backend registra la aprobación tras validar su identidad y permisos.
4. Antes de ejecutar, comprueba que la aprobación corresponde a esa operación, sigue vigente y no se ha utilizado.
5. Si cambian los datos aprobados, solicita una nueva confirmación.

OWASP recomienda vincular la autorización a la transacción y verificarla en el servidor.

Un nonce es un valor que se utiliza una sola vez; no es sinónimo de hash criptográfico. Un token aleatorio o firmado puede formar parte del mecanismo, pero no sustituye la comprobación de identidad, la vinculación con la operación ni la protección contra reutilización.

8. Evaluar el sistema completo con Promptfoo

Prueba la aplicación con sus permisos, contexto y herramientas. Evaluar únicamente el texto que devuelve el modelo deja fuera los efectos que más importan.

Para iniciar la configuración:

El asistente permite describir la aplicación, configurar el destino y seleccionar pruebas. Guarda la configuración generada como promptfooconfig.yaml y ejecuta:

Estos comandos siguen el flujo de inicio documentado de Promptfoo. Debes configurar un endpoint real, credenciales de prueba y criterios de evaluación adecuados a tu aplicación.

Utiliza un entorno de pruebas y datos sintéticos. Si la herramienta genera ataques o evalúa respuestas mediante proveedores externos, revisa qué información les envía y sus costes. En CI, fija la versión validada en lugar de depender permanentemente de latest.

Incluye, como mínimo, estos escenarios:

• Una instrucción maliciosa dentro de un documento recuperado.
• Una conversación de varios turnos que intenta cambiar una decisión previa.
• Una solicitud para acceder a un pedido de otro usuario u organización.
• Un importe superior al saldo reembolsable.
• Una aprobación inexistente, vencida, reutilizada o asociada a otra operación.
• Un reintento de la misma operación después de un fallo de red.
• Una solicitud legítima que debe completarse.

Comprueba el resultado en el backend: ninguna escritura indebida, ningún acceso cruzado y ninguna ejecución sin autorización. Un mensaje del asistente que diga “rechazado” no basta si la herramienta ya produjo el efecto.

9. Medir seguridad y utilidad

Define los resultados esperados antes de ejecutar las pruebas:

• Éxito del ataque: proporción de casos adversarios que logran el efecto prohibido.
• Falsos positivos: proporción de solicitudes legítimas bloqueadas incorrectamente.
• Éxito legítimo: proporción de tareas permitidas que se completan correctamente.
• Operaciones sin autorización válida: recuento que debe ser cero en las pruebas.
• Coste y latencia: impacto de las defensas en el funcionamiento normal.

Indica el conjunto de pruebas, el modelo, su versión y la configuración evaluada. Un porcentaje sin ese contexto no permite comparar sistemas ni prometer protección en producción.

10. Comprobaciones antes de desplegar

• Mínimo privilegio: cada herramienta dispone solo de los permisos y recursos necesarios.
• Aislamiento de datos: los permisos se aplican al recuperar información y al ejecutar acciones.
• Salidas seguras: el texto generado no se interpreta directamente como SQL, comandos o HTML ejecutable.
• Destinos controlados: las llamadas externas y la carga de recursos remotos respetan las restricciones de red y datos.
• Secretos fuera del contexto: las credenciales permanecen en el backend.
• Trazabilidad: los registros permiten relacionar solicitud, propuesta, autorización y resultado, evitando almacenar secretos o datos personales innecesarios.
• Respuesta a incidentes: existe un mecanismo probado para desactivar herramientas sensibles.
• Regresión: los cambios de modelo, prompt, permisos o herramientas vuelven a pasar las evaluaciones relevantes.

Una arquitectura defensiva combina instrucciones claras, validaciones, permisos y pruebas. La pregunta decisiva para cada herramienta es: si el modelo propone una acción indebida, ¿qué control independiente impide que se ejecute?

Fuentes y documentación

• OWASP: LLM01:2025, Prompt Injection.
• OpenAI: seguridad al construir agentes.
• OWASP: autorización de transacciones.
• Promptfoo: inicio de evaluaciones de red teaming.

Revisión editorial y técnica: 9 de noviembre de 2026.