Razonamiento: árbol de lógica sobre una base geométrica estable

¿Qué debe razonar un modelo y qué debe resolver la infraestructura?

«Dejémoslo que lo piense el modelo» es la decisión de arquitectura más
cara que se puede tomar. Un LLM razona sobre lenguaje; no razona con
garantías sobre reglas, aritmética, temporalidad o restricciones. Y la
diferencia entre dejarlo todo en el modelo y dividir el razonamiento es la
diferencia entre un agente que parece fiable y uno que lo es.

Introducción

Llevamos toda la serie construyendo capas: conocimiento, memoria, contexto.
Y hay una pregunta que las sostiene a todas y que nadie quiere responder,
porque la respuesta incomoda: ¿quién razona?

Porque cuando un agente toma una decisión, hay dos «máquinas» en la sala: el
LLM (que razona sobre lenguaje, con generalización y sin garantías) y la
infraestructura (que resuelve reglas, aritmética, temporalidad y
restricciones, con garantías y sin generalización). La tentación —y el error
más común— es ponerlo todo en el LLM: «el modelo es muy inteligente, que lo
resuelva todo».

Hoy fijamos la división, porque es una de las decisiones de arquitectura
más importantes de toda la serie, y la que más separa a un agente de
producción de uno de demo.

El problema

Un banco ha desplegado un agente de detección de fraude que «analiza las
operaciones y detecta lo sospechoso». En la demo, detectaba bien los patrones
clásicos. En producción, dos fallos opuestos y graves:

  • Falsos negativos por razonamiento numérico. Una operación de 9.999 €
    estaba justo por debajo del umbral de 10.000 € que el modelo «sabía». El
    modelo la dejó pasar porque «no superaba el umbral», sin aplicar la regla
    real, que es acumulativa: tres operaciones de 9.999 € en una semana sí
    superan el umbral agregado. El modelo no suma; «aproxima».
  • Falsos positivos por ignorar el tiempo. Un viaje al extranjero con tres
    cargos en tres días marcó «sospechoso», sin que el modelo aplicara que el
    cliente había declarado el viaje (memoria episódica) y que la tarjeta
    estaba en el modo «viaje». El modelo vio tres cargos en tres días y
    generalizó «fraude», ignorando el contexto temporal y declarativo.

En ambos casos, el modelo no era «demasiado tonto». Se le había pedido que
hiciera razonamientos que no son su fuerte
: aritmética exacta sobre
umbrales, acumulación en el tiempo, y aplicación de reglas condicionales.
Cosas que una infraestructura resuelve con garantías y que un LLM resuelve
con aproximación.

El concepto

La decisión de arquitectura es dividir el razonamiento entre dos
ejecutores con capacidades distintas:

Lo que debe razonar el LLM (y lo hace bien):
– Interpretar lenguaje: entender la pregunta, el documento, la intención.
– Generalizar: reconocer patrones no vistos, extrapolar de casos similares.
– Sintetizar: combinar información heterogénea en una respuesta coherente.
– Formular: redactar, resumir, explicar, traducir entre dominios.
– Razonamiento blando: juicios de probabilidad, «esto se ve raro»,
priorización por relevancia.

Lo que debe resolver la infraestructura (y lo hace con garantías):
Reglas de negocio. «Si el descuento > 15 %, requiere aprobación del
director». Determinista, verificable, auditable.
Aritmética y umbrales. Sumas, totales, comparaciones exactas,
acumulaciones. El LLM aproxima; la infraestructura calcula.
Restricciones y constraints. «Este endoso es inválido si hay
siniestro abierto». Verificación, no adivinación (la ontología, día 4).
Razonamiento de grafo. Recorridos multi-hop: «¿qué depende de X?». El
LLM no recorre grafos; la infraestructura lo hace (día 7).
Razonamiento temporal. Vigencia, caducidad, acumulación en el tiempo,
«qué está vigente ahora». El LLM no tiene reloj ni línea de tiempo
fiable.
Planificación y verificación de estado. «¿Se ha hecho ya este paso?».
Consulta de estado, no memoria del modelo.

El principio general: el LLM razona sobre lenguaje y generalización; la
infraestructura resuelve lo que exige exactitud, determinismo, garantías y
auditoría.
Y la arquitectura del agente es, en gran parte, el mapa de
«esto lo hace el modelo, esto lo hace la infraestructura».

¿Por qué importa tanto? Porque los fallos de los dos ejecutores son de
naturaleza distinta, y solo uno de los dos es aceptable en producción:

  • El fallo del LLM es aproximación: da una respuesta plausible que no es
    exacta. Es un fallo silencioso: no avisa de que se ha equivocado.
  • El fallo de la infraestructura (mal diseñada) es determinista: o
    aplica la regla o no. Un fallo determinista es detectable, testable y
    auditable.

En un entorno donde una decisión mal tomada tiene coste (un fraude que pasa,
un descuento fuera de política, un endoso inválido), el fallo silencioso del
LLM es inaceptable. Por eso lo que exige exactitud tiene que salir del
LLM y entrar en la infraestructura.

Arquitectura

En el diagrama de la serie, el razonamiento es la capa que coordina a los
dos ejecutores:

              AGENTES
                 ↓
          REASONING  ← HOY: división LLM / infraestructura
       ┌──────┴──────┐
       ↓             ↓
    LLM         INFRAESTRUCTURA
 (lenguaje,    (reglas, aritmética,
  generalización, restricciones, grafo,
  síntesis)      temporalidad, estado)
                 ↓
     MEMORY + CONTEXT + KNOWLEDGE

La capa de reasoning no es el LLM: es el coordinador que decide, para
cada parte de la decisión, quién la ejecuta. El LLM propone; la
infraestructura verifica, calcula y restringe. Y el resultado de esa
colaboración es lo que el agente presenta como decisión.

Caso de uso

El banco, con su agente de fraude. Descomponemos:

  1. Problema. El agente de fraude da falsos negativos (no suma umbrales
    acumulativos) y falsos positivos (ignora el contexto temporal y
    declarativo), porque todo el razonamiento está en el LLM.
  2. Decisión. Clasificar una operación (o un patrón de operaciones) como
    fraudulenta o legítima, y proponer la acción (bloquear, avisar, dejar
    pasar).
  3. Conocimiento necesario. Los umbrales de fraude y sus reglas
    acumulativas; el perfil de gasto del cliente; las declaraciones previas
    (viajes); las reglas por tipo de tarjeta.
  4. Datos. Operaciones, perfil del cliente, declaraciones, historial de
    fraudes del cliente.
  5. Relaciones. Operación → cliente → perfil; operación → tipo → regla de
    fraude; declaración viaje → cubre → operaciones en destino; operación →
    tarjeta → modo.
  6. Contexto. El cliente declaró un viaje; la tarjeta está en modo
    «viaje»; la operación es en el destino declarado; hay tres operaciones de
    9.999 € en la semana.
  7. Memoria. Episódica: «se declaró viaje a X del 1 al 10»; el historial
    del cliente es limpio (sin fraudes previos).
  8. Razonamiento. Infraestructura: calcular el acumulado semanal
    (3 × 9.999 = 29.997 € > umbral agregado) → dispara la regla; comprobar
    que la operación del viaje está cubierta por la declaración y el modo
    «viaje» → no es fraude. LLM: sintetizar «el patrón de tres operaciones
    de 9.999 € es un intento de structuring (evadir el umbral); el gasto del
    viaje es legítimo por la declaración» y redactar la justificación.
  9. Acción. Bloquear/investigar el patrón de structuring (regla
    acumulativa, infraestructura); dejar pasar el gasto del viaje (declarado,
    infraestructura); abrir la investigación con la justificación (LLM).
  10. Infraestructura. La división del razonamiento: la infraestructura
    resuelve la aritmética, la regla acumulativa y la verificación temporal;
    el LLM interpreta el patrón, generaliza (estructuring) y redacta. Sin la
    división, el modelo aproximaba y fallaba en los dos extremos.

Trade-offs

  • Coste. Dividir el razonamiento exige construir la parte de
    infraestructura (motor de reglas, calculadora de umbrales, verificación de
    temporalidad), que es trabajo adicional frente a «dejarlo en el modelo».
  • Complejidad. Dibujar la frontera «esto es del LLM, esto es de la
    infraestructura» es una decisión de diseño que hay que documentar y
    mantener. Una frontera mal dibujada produce fallos en la zona gris.
  • Latencia. Llamadas a la infraestructura (reglas, grafo, cálculo)
    añaden pasos. Pero en dominios de riesgo, la latencia de una verificación
    es barata frente al coste de un fallo.
  • Mantenimiento. Las reglas de negocio cambian (nuevo umbral, nueva
    restricción). La infraestructura de reglas tiene que actualizarse; el LLM
    no «aprende» el cambio, hay que decírselo.
  • Interpretabilidad. La división mejora la interpretabilidad: cada
    parte de la decisión tiene un ejecutor y un resultado verificable. Pero
    exige que ambos queden registrados (día 18).
  • Limitación honesta: la frontera no es nítida. Hay razonamientos que son
    medio-LLM, medio-infraestructura (un juicio que depende de un cálculo). La
    práctica es iterar: empezar con la división más conservadora (más en la
    infraestructura) y mover a lo seguro al LLM.

Implicación para la empresa

Para el CTO, la división del razonamiento es la decisión de arquitectura que
define la fiabilidad del agente: lo que queda en el LLM es aproximado; lo
que sale a la infraestructura es garantizado. Y en dominios de riesgo, esa
decisión es la diferencia entre un sistema que se puede auditar y uno que no.

Para el CRO (riesgo) y compliance, la implicación es directa: las reglas
regulatorias y de riesgo tienen que vivir en la infraestructura, no en el
prompt. Un regulador no va a aceptar «el modelo decidió» como respuesta a
«¿por qué se bloqueó esta operación?».

Para la alta dirección, el mensaje es de control: un agente cuya decisión es
una mezcla trazable de «lo que calculó la infraestructura» y «lo que
interpretó el modelo» es un agente que se puede explicar. Y un agente que se
puede explicar es un agente que se puede desplegar.

Conclusión

El razonamiento se divide: el LLM razona sobre lenguaje, generalización y
síntesis; la infraestructura resuelve reglas, aritmética, restricciones,
grafo, temporalidad y estado. El fallo del LLM es silencioso (aproximación);
el de la infraestructura es determinista (detectable y auditable). En
producción, lo que exige exactitud tiene que salir del modelo.

Hoy sabemos qué necesita un agente, cómo se construye su conocimiento, su
memoria, su contexto y su razonamiento. La pregunta que queda, y es la
natural, es: con todas esas capas, ¿qué es exactamente un agente
empresarial?
Mañana le damos la anatomía completa.

Siguiente artículo

Mañana: Un agente empresarial es mucho más que un LLM con herramientas.
Veremos la anatomía completa de un agente (LLM, memoria, contexto,
conocimiento, ontología, retrieval, tools, políticas, identidad, permisos,
observabilidad, evaluación) y cómo esas capas permiten pasar de un chatbot a
un agente.

Fuentes

  • La distinción entre razonamiento neuro (LLM) y simbólico (reglas, grafo,
    lógica) es el núcleo del enfoque neuro-simbólico; ver también el contenido
    de Cirtra, «The Renaissance of Meaning» (2026).
  • Definición de trabajo de la ICE: ver serie, Día 1.