Cómo convencer a un LLM para que ignore sus reglas

Un LLM puede fallar por muchos motivos. A veces el error viene de sus límites: predice la próxima palabra, trabaja con probabilidades y puede dar información incorrecta. Pero hay otro tipo de errores. No vienen de un límite técnico del modelo. Surgen cuando alguien lo lleva más allá de lo que debería hacer.

Esto se llama jailbreak.

Lo primero que debes entender es que un jailbreak no necesita habilidades técnicas. No requiere acceso especial ni herramientas específicas. Solo necesitas un prompt, un texto bien escrito. No se entra al modelo desde afuera, no se cambian los pesos, no se rompe nada. Se usa la interfaz normal, la que usa cualquiera, y se crea una solicitud que hace que el modelo actúe diferente.

Un ejemplo clásico: pides a un LLM que te explique cómo construir algo peligroso y se niega. Luego le pides que interprete a un escritor de thrillers. En una escena, el protagonista --un químico-- explica el proceso a un colega. Mismo contenido, mismo resultado final. Pero el modelo lo procesa como escritura creativa, no como instrucción directa. El guardrail no falló porque alguien hackeó el sistema. Falló porque alguien reformuló la pregunta.

Esto es posible porque las reglas de un LLM no están escritas en el código como un firewall. Se aprenden durante el entrenamiento, con ejemplos, retroalimentación humana e instrucciones incorporadas. Son probabilísticas, no absolutas. Y como todo lo probabilístico, tienen márgenes. El jailbreak busca esos márgenes.

Hay investigadores de seguridad que prueban los límites de los modelos. Buscan vulnerabilidades antes que otros. Hay curiosos que quieren saber dónde termina la protección. Y dónde empieza el modelo real. También hay periodistas que documentan los límites de sistemas usados por millones. Y luego están quienes buscan contenido que el modelo normalmente rechazaría. Como instrucciones peligrosas o contenido ilegal.

Las motivaciones varían. Pero la técnica, a menudo, es la misma.

Existen tres grandes categorías de enfoque. La primera es cambiar el contexto. Pides al modelo que asuma un rol. Que actúe "como si" fuera otro sistema sin restricciones. La segunda es la fragmentación. Divides una solicitud problemática en partes aparentemente inofensivas. Cada parte supera los filtros por sí sola. La tercera, la más sofisticada, es manipular las instrucciones del sistema. En el próximo post la llamaremos inyección de prompts.

Lo que une estos enfoques es una idea básica. El modelo no entiende éticamente lo que hace. Tiene patrones. Y los patrones se pueden eludir si sabes reformular la solicitud.

El jailbreak no prueba que los modelos sean peligrosos. Prueba que los modelos son herramientas. Y que dependen de quién los usa y de la calidad de las protecciones. La distancia entre "el modelo se equivoca solo" y "alguien lo hace fallar a propósito" es más corta de lo que parece. Y en medio está el territorio que exploramos en esta serie.