Jailbreak: cuando se empuja a la IA a saltarse sus propias reglas

Qué es

Jailbreak es lograr que un sistema de inteligencia artificial haga lo que sus

instrucciones le indican no hacer. No se vulnera el programa: se trabaja con

lenguaje. Se le pide actuar como otro personaje, se disfraza la petición de

ejercicio hipotético, se insiste hasta que cede.

Funciona porque la política que lo gobierna está redactada: su

system prompt es texto compitiendo con

más texto, y una política se discute. Lo que sí contiene el intento no es esa

redacción, sino los guardrails: límites que

el software impone y que no se negocian con una frase mejor armada.

En palabras de contador

Es el rodeo para que alguien haga una excepción al procedimiento. Nadie fuerza

la cerradura: se insiste y se replantea hasta que el de enfrente cede. En un

despacho es el cliente que pregunta lo mismo de cinco formas hasta que le dan la

respuesta que quería.

La diferencia con prompt injection es

de origen: aquí empuja el propio usuario, de frente; allá venía escondida en el

material que mandaste a procesar.

Ejemplo aplicado

El auxiliar que insiste hasta que el asistente concluye. La herramienta

tiene indicado no afirmar un criterio sin fundamento, pero tras dos

"dime hipotéticamente" entrega una conclusión sin sustento que acaba copiada en

un correo al cliente.

La herramienta que el despacho compró. En la demostración se niega a

mostrar su configuración; en el uso diario basta pedirle que repita lo que tiene

escrito arriba.

El bot de atención del despacho. Un tercero lo lleva, pregunta tras

pregunta, a fijar por escrito una postura que nadie autorizó a nombre de

la firma.

Para qué sirve en un despacho

• Entender que una instrucción escrita orienta al modelo, pero no lo obliga.
• Acordar con el equipo que las reglas de una herramienta no se rodean.
• Preguntarle al proveedor qué pasa cuando alguien lo intenta y si queda registro.
• Decidir qué información de clientes no entra a una herramienta, prometa lo que prometa.

Riesgos o limitaciones

El daño rara vez está en la respuesta, sino en lo que el despacho hace con ella:

una conclusión sacada "hipotéticamente" se lee igual de firme que una

sustentada, y al salir nadie recuerda de dónde vino. Si además el asistente

ejecuta acciones, lo rodeado no fue una opinión sino una operación.

Ninguna defensa alcanza por sí sola: los filtros del proveedor contienen los

intentos conocidos, no los que se inventarán mañana. Y tu responsabilidad sobre

la información del cliente no se transfiere al proveedor que la procesa.

Buena práctica

Antes de contratar, haz tres preguntas: qué hace el sistema cuando alguien

intenta saltarse sus reglas, si eso queda en los

logs y es atribuible a un usuario, y qué puede

ejecutar el asistente sin que una persona confirme. La tercera pesa más:

mientras solo redacte, el daño es recuperable.

Hacia adentro: que todo lo que salga con el nombre del despacho pase por

revisión humana, y que quien note

una respuesta con más alcance del debido lo comente en vez de usarla. Lo

dudoso, consúltalo con quien corresponda.

Preguntas frecuentes

¿Se puede blindar un modelo para que no ceda nunca? No con la tecnología

actual: se cierran los caminos conocidos y aparecen otros. El control que sirve

está en qué datos entran y qué puede ejecutar.

¿Y si en mi despacho nadie lo intentaría? El riesgo tiene dos caras: que

alguien del equipo doble la herramienta del despacho, y que alguien ya haya

doblado la que compraste.

¿Cómo me doy cuenta de que ocurrió? Casi siempre por la salida: una

respuesta con más alcance del que la herramienta debería tener. Revisa qué se

pidió, qué datos se usaron y a dónde fue.

Escrito y revisado por Ernesto Sobrino, contador.
Última revisión: 24 de agosto de 2026.