Los LLM de decisión: cuándo debe decidir un modelo y cuándo no

Pregúntesele a los profesionales qué falla en los sistemas de agentes y la respuesta rara vez es la capacidad. El fallo es más sutil: el modelo decide, y nadie puede distinguir entre un razonamiento sólido y uno meramente fluido.

La salida de un modelo es una muestra. Una decisión tiene propiedades que una muestra no posee: determinismo para una entrada fija, invariantes que debe satisfacer y una pista de auditoría que indica por qué se eligió esta opción y no otra. Cuando esas propiedades faltan, la “decisión” es una suposición de alta confianza vistiendo la ropa de una decisión real.

Este artículo aborda esa brecha con un tratamiento mecánico: una taxonomía de cinco roles de decisión, una regla para enrutar cada decisión al modelo más pequeño competente para ella y el mecanismo de verificación que convierte “el agente decidió X” en algo que más adelante se pueda demostrar como sólido. Concluye con una rúbrica que se puede aplicar a cualquier acción en su propio sistema.

“Para agentes locales, la brecha a la que me enfrento constantemente no es la capacidad, sino la verificación. El agente dice que leyó un archivo, llamó a una herramienta o tomó una decisión…” — r/LocalLLaMA, “Mejores Agentes Locales — Jun 2026”

“Cuando un agente LLM falla, es una caja negra y nadie sabe por qué. El cuello de botella real para la adopción no es llevar un modelo de 92 % a 96 % de precisión, [sino saber por qué decidió X].” — r/AI_Agents, “La brecha entre la decisión y la ejecución”

La comunidad ha convergido en tres instintos: no confiar en el modelo con la llamada final, enrutar la decisión al modelo competente más pequeño y hacer la decisión explicable. Lo que ha estado faltando es el marco que hace accionables los tres simultáneamente.

Por qué “responde, pero ¿decide?”

La salida de un modelo es una distribución de tokens colapsada en una sola secuencia, y la misma prompt ejecutada dos veces puede producir dos secuencias que divergen exactamente en el token que importa. Una decisión, en cambio, es determinista para una entrada fija, satisface invariantes explícitos y deja una pista de auditoría que registra qué rama se tomó y por qué.

Cuando un modelo “decide” sin un mecanismo que lo rodee, ninguna de esas propiedades existe. No hay un invariante que la salida esté obligada a respetar, no hay un registro de la rama tomada ni una forma de reproducir la decisión para verificar que se mantuvo. La brecha no es la inteligencia: es que una salida probabilística ha sido colocada en una ranura diseñada para una salida determinista.

El instinto del profesional es mantener el modelo fuera de la decisión por completo:

“El LLM nunca toma decisiones finales en el sistema. Su rol es puramente: refinamiento de la lógica, pruebas de esfuerzo, generación de escenarios, explicación.” — r/AI_Agents, “Usando un LLM como un ‘agente de razonamiento’ para validar precios…”

Esa es la postura correcta enunciada como una máxima. Para aplicarla, se necesita una manera de clasificar qué rol debería tener el modelo para una acción dada, que es lo que la taxonomía siguiente proporciona.

Cinco roles de decisión

Cada decisión que toma un sistema puede asignarse a uno de cinco roles. El rol determina cuánta confianza se puede tener en la salida del modelo, cómo se audita, cómo falla y si un humano debe estar en el bucle.

Léanla tabla como una restricción, no como un menú. La mayoría de los sistemas rotos comparten un defecto: un solo modelo llena los cinco roles a la vez, de modo que un rol que demanda determinismo (decisor) es atendido por un componente optimizado para la fluidez (generador). Donde el modelo actúa como generador, no se necesita ninguno de los mecanismos de decisión: se necesita la revisión de contenido. El fallo a evitar es la confusión entre estos: “el agente decidió eliminar el entorno” suele ser una compuerta de aprobación faltante, no un problema de calidad de la decisión.

Enrutar la decisión al modelo competente más pequeño

Una vez fijado el rol, la pregunta de enrutamiento es qué capa de modelos lo atiende. Los profesionales reportan la ganancia directamente:

“Enrutamiento de modelos: Haiku para decisiones de clasificación/enrutamiento, Sonnet para ejecución, Opus solo para diseño/planificación. El costo bajó un 60 % aproximadamente una vez que dejé de usar Opus para todo.” — r/AI_Agents, “¿Cuál es su pila de agentes IA completa en 2026”

Esa cifra proviene de tratar la selección de modelos como una decisión por rol en lugar de una por sistema. Una llamada de enrutamiento — “¿esto es un triaje de correos electrónicos o una aprobación de reembolso?” — es una clasificación, y la clasificación no necesita un modelo de frontera; necesita un modelo pequeño, rápido y de baja temperatura, porque se ejecuta miles de veces. La mecánica de capas — selección basada en capacidad, consciente del costo y consciente de la latencia, más cadenas de respaldo — se cubre en Enrutamiento de Modelos: Deja de Usar Un Solo Modelo para Todo; los patrones de orquestación alrededor de múltiples modelos están en Diseño de Sistemas de Modelo Múltiple.

La adición que el enmarcado de la decisión aporta es la escalada basada en confianza, que hace que “el más pequeño competente” se mida en lugar de suponerse. Comience en la capa más pequeña. Si el modelo emite una confianza calibrada — o una autoevaluación estructurada — y supera un umbral, deténgase. Si no lo hace, escale una capa y registre la escalada. La competencia es entonces una propiedad verificada por llamada, no una propiedad asumida por modelo.

Una restricción permanece absoluta sin importar la capa: el rol de enrutador en sí mismo no debe ser una llamada de modelo de lenguaje libre. Una espina determinista — reglas sobre el tipo de tarea, el tamaño de la carga y el presupuesto de costo — selecciona la rama, y el modelo solo llena las decisiones de hoja dentro de ella. La espina es auditable y testeable por unidades; el modelo está contenido en lo que realmente es bueno.

Hacer la decisión verificable

Aquí es donde se cierra la brecha de “el agente dice que hizo X”. La solución es hacer de la decisión un artefacto estructurado de primera clase en lugar de un efecto secundario de un turno de chat:

1. Un almacén de decisiones estructurado. Cada decisión que se permite al modelo se escribe en una tabla, no en una línea de registro: la entrada, el rol, el modelo y la capa, la confianza, las alternativas consideradas, la marca de tiempo. Una decisión es algo que se puede SELECT más adelante. Si solo vive en un transcripción de conversación, es una suposición.
2. Un registro de decisiones, separado del registro de ejecución. El registro de ejecución dice qué pasó; el registro de decisiones dice qué se decidió y sobre qué base. La separación importa porque el fallo suele estar en la decisión, no en la ejecución: el agente ejecutó la eliminación perfectamente; el error estuvo en decidir eliminar. La mecánica del registro estructurado, solo de anexión, es la misma utilizada para las pistas de auditoría de cumplimiento en Barreras de Seguridad para LLM en la Práctica.
3. Invariantes y aserciones. Para los roles de decisor y evaluador, la decisión debe satisfacer invariantes comprobados después de que el modelo la emite, en código determinista. Un recomendador de precios puede emitir cualquier cosa; el invariante “el precio recomendado debe estar dentro del rango [piso, techo]” se impone por código. El modelo propone; el invariante dispone.
4. Compuertas de aprobación humana en el límite de irreversibilidad. La compuerta es una propiedad del radio de explosión de la acción, no de la confianza del modelo. Un reembolso por debajo de un umbral es autoaprobable; uno por encima, no lo es. Un modelo con 99 % de confianza aún no puede aprobar una acción irreversible para la cual no tiene un registro de auditoría.

La línea conductora: el empuje de precisión del 92 % al 96 % no es el cuello de botella; la explicabilidad sí lo es. Un sistema al 92 % con cada decisión registrada, verificada por invariantes y con compuerta en el límite se entrega de manera segura, porque el 8 % de decisiones erróneas son encontrables antes de que causen daño. Un sistema al 99 % con un proceso de decisión en caja negra no lo hace, porque el 1 % es un incidente vivo sin registro forense. Dónde reside la propia compuerta en un asistente — qué componente tiene la autoridad de aprobación y cómo llegan las solicitudes a él — se detalla en Arquitectura de Asistentes de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad.

Ejemplos trabajados

Tres sistemas, una asignación de rol cada uno.

Validación de precios — el modelo como recomendador, nunca decisor. Un agente revisa un cambio de precio del proveedor y produce una lista con ranking: aceptar, negociar en X, rechazar. La llamada final es una ranura de decisor llena por reglas deterministas: por debajo del piso de costo, aceptar automáticamente; por encima del techo, enrutar a un humano; en medio, aplicar el invariante “el precio negociado debe superar al último aceptado por el Y %”. El modelo nunca aprueba su propia recomendación, y la recomendación se encuentra en el almacén de decisiones con su trazado de rúbrica si algo sale mal.

Enrutamiento de tareas de agentes — la espina como decisor, el modelo en las hojas. Una solicitud entrante (correo, ticket, comando) se asigna una ruta por forma de la carga y categoría de intención — determinista, testeable por unidades. Un modelo pequeño solo llena la decisión de hoja dentro de la rama. Un mal enrutamiento es un evento de radio de explosión, que es exactamente por qué la selección de la rama debe ser determinista.

LLM como juez — el modelo como evaluador, la rúbrica como restricción. Un modelo puntúa la salida de otro contra una rúbrica versionada, y la puntuación junto con el trazado de la rúbrica se almacenan, no solo el número. El modo de fallo conocido es el sesgo de autoperfección — un modelo que puntúa su propio estilo de generación más alto — y la mitigación es estructural: versionar la rúbrica para que un modelo nunca puntúe silenciosamente contra criterios que él mismo moldeó.

El límite honesto

Existe una clase de decisión que un LLM no debe tomar, y no es una cuestión de escala: acciones que son irreversibles, de altas apuestas y sin plan de respaldo — eliminación de datos, movimiento de fondos, compromisos externos. La verificación es imposible para una acción que no se puede revertir, que es por qué “agente autónomo” sigue chocando contra el mismo muro sin importar la calidad del modelo.

El humano en el bucle que no es teatro se sienta exactamente en ese límite y en ninguna otra parte. Un humano revisando cada decisión de bajas apuestas añade fricción y ninguna seguridad; un humano ausente de cada decisión de altas apuestas es el incidente. El mismo principio aparece en una forma más estrecha en la memoria de agentes: los bucles de memoria auto-reforzantes ponen las escrituras de memoria candidatas detrás de una aprobación humana explícita antes de que algo llegue al estado duradero — la compuerta dimensionada a lo que la escritura puede romper. Para sistemas de agentes múltiples, la pregunta correspondiente es quién puede actuar en nombre de quién, y la mecánica de identidad, delegación y pista de auditoría para ello está en Seguridad de Agentes A2A y MCP.

La rúbrica de decisión

Ejecute esta contra cualquier acción en su sistema:

1. Clasifique el rol. ¿Decisor, recomendador, evaluador, generador o enrutador? Un rol sin nombre es un error: un modelo en una ranura de decisor vistiendo la confianza de un generador.
2. Elija la capa para ese rol. La más pequeña competente, con escalada basada en confianza para que la competencia se mida por llamada.
3. Defina la verificación. ¿Qué invariantes deben cumplirse? ¿Qué va en el almacén de decisiones? ¿Cuál es el trazado de auditoría? Un rol sin ruta de verificación es un decisor por defecto.
4. Fije la compuerta humana desde el radio de explosión, no desde la confianza. Irreversible o de altas apuestas → con compuerta. De lo contrario → automático, con la decisión registrada para que sea encontrable.

La misma disciplina, aplicada a elecciones de ingeniería en lugar de acciones de tiempo de ejecución, es lo que hacen los registros de decisión — los Registros de Decisión para el Desarrollo Impulsado por IA capturan por qué se hizo una elección para que pueda revisarse más adelante; la rúbrica anterior hace lo mismo para las decisiones que toma un sistema en ejecución.

Lo que viene: el decisor como producto

El marco predice su propia comoditización: una vez que “enrutar la decisión al modelo competente más pequeño” se convirtió en un patrón, el siguiente paso fue una clase de modelo que no hace más que decidir. Ese paso ya ha llegado.

A lo largo de octubre de 2026, varios proveedores lanzaron modelos construidos sobre una receta compartida — un esqueleto Qwen congelado, un adaptador LoRA de rango 256 y una cabeza de esquema conjunta — que emiten decisiones tipificadas en una única pasada directa: una elección de un conjunto enumerado, un sí/no, o una puntuación, con probabilidades calibradas y sin texto libre. No hay una cadena de pensamiento que esperar, porque no hay generación. La latencia reportada por el proveedor se sitúa entre aproximadamente 8 y 210 ms en toda la clase — desde la variante más pequeña (d1-3B, unos 8 ms) hasta la más grande (d3, unos 209 ms) — y las huellas son del terreno de GPU pequeñas: d1-3B en unos 1.67 GB, d3-flash en unos 6.6 GB en Q4_K_M. El soporte también se movió rápido: llama.cpp integró el soporte nativo de arquitectura para varios de estos modelos dentro de aproximadamente dos semanas del lanzamiento.

Dos consecuencias para el marco anterior. Primero, la regla de enrutamiento obtiene una expresión de hardware que no tenía antes: el rol de decisor puede ser atendido por un modelo pequeño dedicado en lugar de un modo de prompt de uno general, lo que hace que la decisión de la capa competente más pequeña sea parcialmente automática — la capa existe para su tipo de decisión o no. Segundo, nada cambia con respecto a la verificación. Una decisión tipificada en 8 ms aún necesita el almacén de decisiones, los invariantes y la compuerta en el límite de irreversibilidad; lo que la clase de modelo elimina es el costo de generación y la no determinación, no la carga de auditoría. Decisiones más rápidas multiplican el número de registros de decisiones que auditar — el cuello de botella nunca fue la velocidad del modelo, ni tampoco es la inteligencia del modelo.

Las otras direcciones a observar son más sutiles. La fiabilidad de las llamadas de herramientas para modelos pequeños se acerca a la saturación — el entrenamiento posterior en el uso de herramientas es el paso de alto impacto más barato de la pila, lo que desplaza la atención hacia las filas superiores. Los horizontes de planificación confiables siguen extendiéndose, lo que hace que el rol de decisor sea alcanzable para tareas más largas y hace crecer la carga de verificación con el horizonte. Ambas alimentan la misma conclusión: el recurso escaso en los sistemas de agentes son las decisiones que más adelante se puede demostrar que fueron sólidas, y todo lo demás está llegando a ese punto.