Cómo funciona un modelo (y por qué eso es el problema)

Un modelo de lenguaje grande se entrena para una tarea que suena modesta: dado un fragmento de texto, predecir el siguiente trozo, una y otra vez. De esa mecánica salen el resumen, la respuesta y el borrador, porque el texto más probable que sigue a una pregunta bien planteada suele ser una respuesta útil. Pero el modelo no «sabe» nada ni «quiere» nada: continúa un texto de la forma que su entrenamiento hizo probable.

Eso tiene una consecuencia para quien lo defiende. El modelo no tiene un lugar donde guardar reglas que respete pase lo que pase. Todo lo que ve —tu política, la pregunta del cliente, un documento— es del mismo material: texto que condiciona la siguiente predicción. No hay un compartimento de «órdenes del sistema» separado del de «datos a procesar».

Cuando Aura responde, el sistema arma una ventana de contexto: pega la instrucción del sistema («eres el asistente de Brisa, sé amable, no reveles datos internos»), luego el historial, luego el mensaje del cliente, y se lo entrega todo al modelo como un bloque continuo de texto. Para el modelo no hay un borde que diga «de aquí para abajo son datos, no me obedezcas». Hay tokens, y ya.

Esa es la grieta de la que sale casi todo lo demás en esta ruta. La seguridad de aplicaciones clásica se apoya en separar el código de los datos —una consulta parametrizada no ejecuta lo que el usuario escribe—. En un modelo esa separación no existe de fábrica: el «código» (tus instrucciones) y los «datos» (lo que escribe el cliente) comparten el mismo canal.

La reacción intuitiva ante esto es poner un filtro: bloquear mensajes que contengan «ignora las instrucciones» o «revela tu prompt». No funciona como defensa de fondo. El espacio de formas de decir lo mismo es enorme —otro idioma, una paráfrasis, texto codificado, una historia que envuelve la orden— y el modelo entiende todas. Un filtro de palabras atrapa los intentos ingenuos y da una falsa sensación de estar cubierto.

La ruta parte de aquí: el problema es de arquitectura, no de vocabulario. Un filtro de entrada puede ser una capa más, pero la defensa real es diseñar el sistema para que, aunque el modelo se deje convencer, no pueda hacer nada grave —porque no tiene el permiso, porque la acción la autoriza otro componente, porque el dato sensible no está a su alcance—.

Si el modelo no distingue dato de instrucción y no se puede filtrar el problema por completo, ¿dónde vive entonces la seguridad? En lo que el modelo NO puede hacer aunque lo pida. Un modelo al que convencen de «emitir un reembolso» no es un incidente si emitir reembolsos exige una aprobación humana que el modelo no puede dar. La frase que se lo inventó es inofensiva cuando la acción está fuera de su alcance.

Esa es la idea que vas a aplicar sala tras sala: el texto que le das al modelo es la parte débil y no se puede blindar del todo; la parte fuerte es la arquitectura que lo rodea. Diseñar esa arquitectura —límites, permiso mínimo, aislamiento, validación de la salida— es el oficio de esta ruta.

Ya razonaste de dónde sale el fallo raíz. Ahora compruébalo sobre el despliegue de Aura: abre cómo arma su ventana de contexto y confirma que la instrucción del sistema y el mensaje del cliente quedan pegados en un solo flujo, sin una frontera que el modelo garantice entre orden y dato. El registro de ese ensamblado lleva anotado un código de la sala.