Bug, jailbreak e inyección de prompt: ¿qué tienen realmente en común?
Bug, jailbreak, inyección de prompt. Tres problemas diferentes, una raíz común: un LLM no sigue reglas escritas en el código — ha aprendido comportamientos de miles de millones de ejemplos. Por eso, corregirlo es mucho más complejo que aplicar un simple parche.
Después de ver cómo un LLM puede equivocarse solo, cómo puede ser burlado con un jailbreak y cómo una inyección de prompt puede manipular su comportamiento, surge una pregunta inevitable: ¿las empresas que desarrollan estos modelos lo saben? ¿Están trabajando en ello?
Sí. Y aún así es complicado.
El problema no es técnico. Es estructural.
Un software tradicional tiene reglas escritas por alguien. Si hay un error, encuentras la línea de código incorrecta y la corriges. Un LLM funciona de manera diferente: sus "reglas" no están escritas explícitamente. Emergen del entrenamiento, comprimidas en miles de millones de parámetros numéricos que nadie puede leer directamente. No hay una línea de código que diga "no ayudes a hacer cosas peligrosas". Hay un conjunto de pesos estadísticos que, en promedio, producen ese comportamiento. Y en promedio no significa siempre.
Por eso las soluciones existen, pero ninguna es definitiva.
La primera es el RLHF -- Aprendizaje por Refuerzo con Retroalimentación Humana. Durante el entrenamiento, personas reales evalúan las respuestas del modelo. Esas evaluaciones se usan para ajustar los pesos en la dirección correcta. Es el mecanismo principal con el que los modelos aprenden a rechazar peticiones peligrosas, a calibrar la incertidumbre, y a comportarse de manera útil sin ser dañinos. Funciona, pero depende de la calidad y cantidad del feedback humano, y no cubre todos los casos posibles. Un jailbreak bien hecho encuentra exactamente los casos que el feedback no cubrió.
La segunda es el red teaming. Antes de lanzar un modelo, equipos dedicados intentan hacerlo fallar. Prueban jailbreak, inyecciones de prompts, casos límite y escenarios de abuso. Es un trabajo más de detective que de ingeniero. Sirve para encontrar vulnerabilidades antes que otros las descubran. El problema es que los posibles prompts son infinitos. Un equipo humano no puede cubrirlos todos. Por eso, hoy se usan modelos automatizados para hacer red teaming en otros modelos. Los resultados son prometedores, pero no definitivos.
La tercera son los filtros. Son capas de control que analizan el input antes de llegar al modelo y el output antes de llegar al usuario. Son útiles para casos obvios, con palabras clave o patrones reconocibles. Pero son menos útiles contra ataques sofisticados. No funcionan bien contra inyecciones de prompts indirectas. Tampoco contra solicitudes que parecen inofensivas por separado, pero no lo son en contexto.
Finalmente, está el alineamiento. Es el campo que busca que los modelos persigan realmente nuestros objetivos. No solo aproximaciones estadísticas de esos objetivos. Es el problema más profundo y menos resuelto. No porque nadie trabaje en ello. De hecho, algunas de las mentes más brillantes del sector lo hacen. Pero alinear un sistema que no razona como un humano es un problema sin solución general aún.
Nada de esto significa que estos instrumentos sean inutilizables o que el futuro sea oscuro. Significa que estamos en una fase donde la tecnología avanza más rápido que nuestra capacidad para hacerla robusta. Usarla conscientemente, sabiendo sus límites, sigue siendo nuestra mejor defensa.
Ninguna de estas técnicas elimina realmente el problema. Lo hace menos probable, más costoso de explotar, más fácil de controlar. Pero no lo elimina.
Es el precio de una tecnología que genera respuestas basadas en correlaciones estadísticas. No en una comprensión real del significado. Y es por eso que bugs, jailbreaks e inyecciones de prompts no son anomalías desconectadas: son manifestaciones diferentes del mismo límite fundamental.
