La salida del modelo como dato no confiable

En una aplicación clásica, el texto que llega de fuera se trata con desconfianza: el formulario del cliente se valida, se codifica antes de mostrarlo y nunca se pega dentro de una consulta. Con un modelo dentro aparece una tentación: pensar que lo que escribe el modelo es «nuestro», porque lo genera nuestro sistema. No lo es. El modelo escribe a partir de lo que leyó, y lo que leyó incluye el mensaje del cliente, los documentos adjuntos, los correos de terceros y lo que recuperó de una base de documentos. Cualquiera de ellos puede empujar la salida hacia una forma que nadie previó.

Además, el modelo no garantiza la forma de lo que produce: la misma petición puede devolver un texto limpio un día y uno con marcado, comillas o caracteres especiales al siguiente. Por eso la regla de diseño es sencilla de decir: la salida del modelo se trata como una entrada no confiable más, con los mismos controles que se le pondrían a un texto escrito por un desconocido. La lista de riesgos de OWASP para aplicaciones con modelos de lenguaje lo recoge en su edición de 2025 como el manejo inadecuado de la salida (LLM05:2025).

Cuando una salida causa un problema, la primera pregunta de la investigación no es «qué dijo el modelo», sino «de dónde salió lo que dijo». Si el texto vino del propio cliente, el riesgo es uno; si vino de un documento que subió un tercero y que nadie revisó, la superficie es mucho más ancha, porque cualquiera que logre que su documento llegue a un caso puede influir en lo que el asistente escribe. Es la versión de salida de la inyección indirecta que viste en el módulo 2.

Abre la traza del caso SIN-40218. Sigue el hilo desde lo que se adjuntó hasta lo que se vio en el panel, y localiza el documento del que salió el texto que el navegador terminó interpretando.

No todo destino es igual de peligroso. Un texto que se muestra como texto plano, o que solo se guarda, no se ejecuta: lo peor que hace es verse raro. El riesgo aparece cuando el destino interpreta el texto: un navegador que lo trata como marcado, una base de datos que lo trata como consulta, un intérprete de órdenes que lo trata como comando, una hoja de cálculo que evalúa como fórmula lo que empieza por un signo igual. Ahí el texto deja de ser dato y pasa a ser instrucción para otro sistema.

El inventario dice, para cada destino, cómo trata el texto y qué control se le aplica antes. Cuenta los destinos que interpretan la salida (como marcado, consulta, orden, objeto o fórmula) y no tienen ningún control. Los que la tratan como texto plano no cuentan, aunque digan «ninguno».

Una salida casi nunca va a un solo sitio. El mismo resumen que se ve en una tarjeta puede acabar en una exportación, un correo o un registro, y cada copia se interpreta con reglas distintas. Por eso, al investigar, no basta con cerrar el destino donde alguien vio el problema: hay que seguir la salida a todos los sitios a los que viajó y preguntarse qué hace cada uno con ella.

En la traza del caso aparecen los destinos a los que se envió el resumen. Uno es el panel. Busca el otro y compruébalo en el inventario: también interpreta el texto y tampoco tiene control.

La tentación, después de un caso así, es arreglarlo en las instrucciones del modelo: «no copies marcado», «no escribas fórmulas». Eso reduce la frecuencia, pero no la garantiza, porque el modelo no obedece siempre y el texto de un tercero puede empujarlo en otra dirección. La defensa que sí aguanta vive en el código que consume la salida: cada destino aplica el control que corresponde a cómo interpreta el texto —codificar para la página, parametrizar para la consulta, no pasar por un intérprete de órdenes, neutralizar el signo igual en la hoja—, igual que lo haría con un texto de un desconocido.

Las salas que siguen recorren esos controles destino por destino.