Distinguir el LLM, el modelo y la aplicación

Cuando una empresa dice «queremos usar un LLM», todavía no ha descrito una aplicación. Ha nombrado una capacidad técnica. Entre el usuario y el modelo existen capas que deciden qué información entra, qué permisos se aplican, qué resultado se acepta y qué efectos están permitidos.

Esta distinción es básica porque muchos fallos atribuidos al «modelo» proceden en realidad de decisiones de aplicación: contexto incorrecto, datos obsoletos, permisos mal definidos, ausencia de validación o una herramienta concedida con demasiada autoridad.

Cuatro conceptos que conviene separar

Un modelo de lenguaje es un sistema entrenado para modelar y generar secuencias de tokens. Muchos LLM actuales se basan en arquitecturas Transformer, una familia introducida por Vaswani y colaboradores en 2017. Para diseñar aplicaciones empresariales no necesitas reproducir su entrenamiento, pero sí comprender que el modelo no es una base de datos ni una regla de negocio.

El proveedor ofrece acceso a uno o varios modelos y define APIs, políticas de uso, precios, regiones, límites y servicios auxiliares. Esos elementos pueden cambiar con el tiempo y forman parte de la arquitectura, pero no son propiedades intrínsecas del concepto «LLM».

La API es la interfaz con la que la aplicación envía entradas y recibe salidas. Puede ofrecer texto, salidas estructuradas, herramientas, streaming, archivos u otras capacidades. Estas funciones dependen del proveedor y de la versión concreta de la interfaz.

La aplicación es el sistema completo: identidad, permisos, proceso, contexto, datos, llamada al modelo, validación, herramientas, almacenamiento, observabilidad y revisión humana.

El modelo propone; la aplicación autoriza

Una arquitectura segura asigna responsabilidades según su naturaleza.

Usa código determinista para cálculos exactos, límites, permisos y reglas estables. Usa búsqueda o consultas estructuradas para recuperar información existente. Usa el modelo cuando la tarea exige interpretar lenguaje, manejar variación, clasificar con criterios no triviales, resumir o generar contenido.

Ejemplo: un comercial solicita una excepción de descuento. El modelo puede extraer el motivo y resumirlo. Una regla calcula si el porcentaje supera el umbral. Una consulta obtiene margen y condiciones vigentes. Una persona con autoridad aprueba la excepción. Pedir al LLM «decide si se aprueba» mezcla interpretación, cálculo, política y autoridad.

Capacidad no equivale a garantía

Que un modelo pueda producir JSON no garantiza que los valores sean correctos. Que pueda seleccionar una herramienta no significa que deba ejecutarla. Que conozca un concepto no implica que disponga de los datos actuales de tu empresa.

Esta separación puede representarse así:

usuario → aplicación → contexto/herramientas → modelo → validación → regla/acción → resultado

El modelo ocupa una parte del flujo. La autoridad final permanece en la aplicación y, cuando corresponde, en una persona.

Entrada, inferencia y salida

Durante una invocación, la aplicación construye una entrada. El modelo procesa esa entrada dentro de su contexto y genera una salida. El comportamiento depende del modelo, las instrucciones, el contexto, la configuración y la tarea.

El modelo no «consulta» automáticamente tu ERP, tu CRM o tu repositorio documental. Para hacerlo, la aplicación necesita proporcionar esos datos directamente, recuperarlos o exponer una herramienta que pueda consultarlos.

Tampoco debes suponer memoria empresarial persistente por el hecho de mantener una conversación. La persistencia es una propiedad del producto o de la aplicación que almacena y vuelve a introducir información, no una propiedad que debas atribuir sin más al modelo.

Diseña fronteras de fallo

Antes de construir una interfaz, define qué ocurre si:

• el modelo no está disponible;
• supera el tiempo aceptable;
• la salida incumple el contrato;
• falta información necesaria;
• la herramienta devuelve error;
• una fuente está desactualizada;
• el usuario carece de permiso;
• el resultado requiere revisión humana.

Una buena aplicación no convierte todos esos escenarios en «volver a preguntar al modelo». Algunos requieren reintento, otros una ruta manual y otros detener el proceso.

Arquitectura mínima suficiente

Empieza por el sistema más sencillo que pueda demostrar la capacidad necesaria. Una única llamada con buen contexto puede ser mejor que una cadena de cinco modelos. Un workflow fijo puede ser más predecible que un agente. Una consulta SQL puede ser más fiable que pedir al modelo que infiera un dato que ya existe estructurado.

Anthropic ha documentado esta idea en su guía de sistemas agentic: comenzar con soluciones simples y añadir complejidad solo cuando mejora resultados de forma demostrable. Esa recomendación procede de un proveedor, no de un estándar universal, pero coincide con un principio general de ingeniería: complejidad adicional necesita una justificación observable.

Ejemplo: análisis de solicitudes comerciales

Supón que una aplicación recibe solicitudes por correo y debe preparar una propuesta para revisión.

El modelo puede:

• interpretar el texto libre;
• identificar intención;
• extraer requisitos;
• redactar una síntesis.

La aplicación debe:

• autenticar al usuario;
• consultar precios y disponibilidad;
• aplicar reglas comerciales;
• validar campos;
• impedir acciones no autorizadas;
• guardar estado;
• registrar qué ocurrió;
• enviar a revisión cuando corresponda.

Si mañana sustituyes el modelo, la arquitectura de negocio no debería desaparecer con él.

Entrenamiento no es inferencia

Otro error frecuente es mezclar cómo se construyó el modelo con cómo lo utiliza una aplicación. El entrenamiento ajusta parámetros a partir de grandes conjuntos de datos y procesos de optimización. La inferencia utiliza un modelo ya entrenado para producir una salida a partir de una entrada concreta.

En la mayoría de aplicaciones empresariales, el equipo no entrena un LLM desde cero. Diseña contexto, herramientas, recuperación, validación y evaluación alrededor de un modelo disponible. Fine-tuning, cuando se utiliza, es otra decisión distinta y no sustituye datos actuales, permisos ni lógica de negocio.

Esta separación ayuda a formular preguntas correctas. «¿Cómo hacemos que el modelo conozca nuestro catálogo actual?» suele resolverse mediante datos o recuperación, no entrenando de nuevo el modelo cada vez que cambia un producto. «¿Cómo hacemos que use siempre este formato?» puede requerir salidas estructuradas y validación, no más datos de entrenamiento.

Define la frontera de confianza

Marca qué salidas del modelo pueden consumirse automáticamente y cuáles son solo propuestas. Una clasificación de baja consecuencia puede alimentar un routing automático después de superar un benchmark. Una recomendación financiera, una modificación irreversible o una decisión de acceso pueden necesitar otra autoridad.

La frontera no depende solo de lo bueno que sea el modelo. Depende de reversibilidad, detectabilidad del error, impacto y capacidad de recuperar el estado anterior.

Ejercicio: mapa de responsabilidades

Elige una aplicación LLM real o proyectada y crea una tabla con:

• resultado esperado;
• tarea del modelo;
• reglas deterministas;
• datos estructurados;
• conocimiento documental;
• herramientas;
• permisos;
• estado persistente;
• validaciones;
• revisión humana;
• fallos y rutas alternativas.

Después marca cada componente como modelo, aplicación, fuente externa o persona.

Si una decisión con autoridad empresarial sigue asignada al modelo sin validación ni permiso externo, revisa el diseño.

Resultado de la lección

Debes terminar con un mapa en el que el LLM aparece como una capacidad dentro de un sistema mayor. Esta separación permitirá entender en la siguiente lección qué información recibe realmente el modelo en cada invocación y por qué una ventana de contexto grande no equivale a memoria ilimitada ni a conocimiento pertinente.