Dónde entra un modelo de lenguaje en la arquitectura

Una función con modelo de lenguaje casi nunca es «el modelo» a secas. Hay un servicio propio, el orquestador, que en cada turno junta varias piezas en un mismo texto: las instrucciones que escribió el equipo, datos del cliente, fragmentos recuperados de un índice de documentos, el historial de la conversación y el mensaje nuevo. Ese texto viaja al proveedor, y lo que vuelve se pinta en el navegador o se convierte en una llamada a una herramienta interna.

Para revisarlo sirve el mismo método de cualquier modelado de amenazas: dibujar los flujos y marcar las fronteras de confianza. La diferencia es que dentro de ese texto único el modelo no separa con fiabilidad lo que es una orden de lo que es un dato. Por eso cada fuente que alimenta el contexto cuenta como entrada, la escriba quien la escriba, y cada salida del modelo cuenta como algo que hay que validar antes de usar.

OWASP mantiene una lista de diez riesgos para aplicaciones con modelos de lenguaje, la edición de 2025, y casi todos se ven en este diagrama: la inyección de instrucciones (LLM01), la revelación de información sensible (LLM02), el manejo inadecuado de la salida (LLM05), la agencia excesiva de las herramientas (LLM06) o el consumo sin límites (LLM10). En este módulo se leen en código y en registros, no en una lista.

Abre el laboratorio y lee arquitectura.txt. El índice de recuperación tiene tres colecciones que se reindexan cada noche y cualquiera de ellas puede acabar en el contexto de una conversación, como muestra la captura peticion-al-proveedor.txt. Dos las escriben equipos de la empresa. La tercera la escribe cualquier comprador desde la página de un libro, y eso la convierte en un canal por el que un tercero puede hacer llegar texto al modelo sin conversar con él.

Todo lo que entra en el contexto sale de la empresa: el proveedor lo recibe en cada turno y, según config-asistente.yml, lo retiene un tiempo. La plantilla lia-sistema.txt solo necesita dos datos del cliente, pero orquestador.py añade además el perfil entero «por si el modelo lo necesita». Es el patrón que lleva a la revelación de información sensible: datos que nadie pidió viajando a un tercero y quedando en sus registros.

Compara los campos del perfil en la captura con los que usa la plantilla.

Cada mensaje cuesta dinero en la factura del proveedor y tiempo en el orquestador. Si nada limita cuántos mensajes manda un cliente, cuántos turnos dura una conversación o cuánto se puede gastar en el mes, una sola cuenta (o un programa que se haga pasar por muchas) puede agotar el presupuesto o tumbar el servicio. Es el riesgo que OWASP llama consumo sin límites. Lee la sección de límites de config-asistente.yml.

Con lo leído ya se puede contestar la pregunta del encargo sin haber hablado con Lía: por dónde le entra texto ajeno, qué sale hacia el proveedor y qué falta limitar. Ese mapa es la base de las demás revisiones del módulo, porque cada flecha del diagrama es un sitio donde poner un control en el código y no en las instrucciones del modelo.