Arquitectura de IA empresarial: RAG encuentra, los LLM razonan, los modelos de decisión eligen
Por qué la recuperación de información y el razonamiento lingüístico no son suficientes: cómo GraphRAG, los agentes y los modelos de decisión del Sistema 1 como Jev separan el conocimiento, el contexto, el razonamiento, la toma de decisiones y la ejecución.
Fuentes: The Emerging Architecture of Enterprise AI — RAG Finds, LLMs Reason, Jev Decides.
Encontrar hechos y razonar sobre ellos ya no es una habilidad poco común. El problema del diseño abierto consiste en generar opciones rápidas y limitadas en las que el software empresarial pueda confiar, sin convertir cada paso mínimo en una generación de texto libre.
Los debates del sector siguieron una secuencia familiar: modelos fundamentales, ampliación mediante recuperación de información, recuperación ampliada con grafos, y luego agentes. Cada etapa cerraba una brecha diferente. Hubo un nivel que permaneció poco desarrollado: la toma de decisiones—no la deliberación conversacional, ni otro texto extenso, sino un resultado escrito y delimitado que una aplicación pueda ejecutar.
Los tomadores de decisiones al estilo System 1, como Jev (TypeSafe AI), hacen que ese nivel sea tangible. Indican que las plataformas de producción podrían necesitar una ruta de decisión dedicada, además de la recuperación de información y el razonamiento lingüístico.
La evolución de la IA empresarial
Un cronograma simplificado ayuda a delimitar la pieza que falta.
1. LLMs: “¿Qué texto se puede generar?”
Los modelos fundamentales han permitido que las máquinas dominen la lectura y escritura del lenguaje natural. Lo que “saben” sigue dependiendo del entrenamiento previo y de la ventana de contexto proporcionada durante la inferencia.
Dentro de las empresas, esa brecha se manifiesta de inmediato. El conocimiento crítico rara vez está contenido en los pesos del modelo; se encuentra en documentos, repositorios, APIs, bases de datos, políticas, manuales de operación, tickets, correos electrónicos, reglas empresariales, wikis y aplicaciones.
Esa presión llevó a avanzar al siguiente nivel tecnológico.
2. RAG: “¿Dónde se encuentra el material?”
La generación reforzada por recuperación permite a los modelos consultar los almacenamientos de la empresa. En lugar de exigir una recuperación total a partir de los pesos, las cadenas de procesamiento obtienen el material relevante y lo incorporan como contexto de trabajo.
La cadena de procesamiento pasó a ser:
Almacenamientos de la empresa → Obtención → Contexto de trabajo → Modelo de lenguaje → Respuesta
Ese salto fue de gran ayuda. RAG sigue topando con un muro estructural: la búsqueda de documentos similares no es lo mismo que comprender cómo se relacionan los datos de la empresa.
Considere una disputa sobre cobertura:
“¿Qué causó el rechazo de esta reclamación, y merece ser elevada a un nivel superior?”
Responder puede requerir seguir este camino:
Cliente → Póliza → Producto → Cobertura → Reclamación → Diagnóstico → Exclusión → Cláusula de la póliza → Regla regulatoria
Eso no es solo un problema de búsqueda por palabras clave. Es un problema de relaciones y razonamiento.
3. GraphRAG: “¿Cómo están conectadas estas cosas?”
Luego llegaron los grafos y GraphRAG. En lugar de fragmentos aislados, las plataformas modelan entidades y conexiones entre ellas. Por ejemplo:
Customer
│
├── owns → Policy
│ │
│ ├── covers → Product
│ │
│ └── governed by → Rule
│
└── submitted → Claim
│
├── relates to → Diagnosis
│
└── evaluated against → Coverage
La navegación sustituye a la recuperación del “párrafo más cercano”. Esa es la capa de conocimiento empresarial que subyace al conocimiento estructurado, al trabajo al estilo OKF y a los experimentos con GraphRAG.
Incluso así, queda otra pregunta: una vez que se comprende y analiza el contexto, ¿qué debería hacer realmente el sistema?
4. Agentes: “¿Qué debería suceder a continuación?”
Los diseños de agentes consideran al modelo de lenguaje como director. Puede deliberar, elegir herramientas, llamar a APIs, inspeccionar resultados, seleccionar el siguiente paso, invocar otra herramienta y continuar hasta que se complete la tarea.
Ese poder genera una presión arquitectónica: se le pide al mismo modelo de propósito general que se encargue de cada etapa:
Understand
↓
Reason
↓
Choose
↓
Route
↓
Decide
↓
Call API
↓
Inspect result
↓
Decide again
↓
Call another API
Surgen entonces preguntas incómodas. ¿Necesita cada microdecisión de los agentes un modelo de razonamiento complejo? ¿Debería un modelo centrado en el lenguaje tomar decisiones como:
“¿Dirigir este ticket al Equipo A o al Equipo B? ¿Continuar con este flujo de trabajo? ¿Es necesario que interviniera un humano? ¿Cuál de las cinco acciones predefinidas es la adecuada? ¿Esta transacción supera el umbral de escalada?”
A menudo se trata de problemas de decisión, y no de problemas de generación de lenguaje.
Modelos de decisión del Sistema 1
Aquí es importante Jev. TypeSafe AI lo define como un modelo del Sistema 1. Conceptualmente, la distinción es sencilla:
- Un LLM está optimizado principalmente para generar lenguaje (“¿Qué redacción es la adecuada?”).
- Un modelo de decisión utiliza un estado estructurado y responde a preguntas predefinidas con resultados estructurados (“¿Cuál es la decisión de software adecuada?”).
Los materiales públicos describen a Jev como un sistema que emite respuestas predefinidas junto con información basada en el estado de la aplicación compartida, dando prioridad a la velocidad sobre la redacción detallada. Esa separación permite una arquitectura más limpia.
La capa que falta
La IA empresarial no tiene por qué tener solo este aspecto:
Enterprise Data
↓
RAG
↓
LLM
↓
Agent
↓
Actions
Un diseño más separado se ve así:
Enterprise Systems
↓
Knowledge Engineering
↓
Enterprise Knowledge Layer
↓
Context Engineering
↓
┌──────────────┬──────────────┐
│ │ │
▼ ▼ ▼
Reasoning Decision Rules
LLM Model Engine
│ │ │
└──────────────┴──────────────┘
↓
Agent Control
↓
Deterministic Code
↓
APIs / Workflows
Las responsabilidades quedan más claras.
Los LLM no tienen que hacerlo todo
Considere un flujo de servicio de seguros. Un cliente escribe:
“Esta solicitud de indemnización por hospitalización fue rechazada, pero parece merecer cobertura.”
La plataforma debe establecer primero el contexto. Puede obtener registros del cliente, detalles de la póliza, configuración del producto, coberturas, datos de las solicitudes, información sobre hospitales, exclusiones, cláusulas de la póliza y normativas regulatorias. Ahí es donde una capa de conocimiento empresarial y GraphRAG resultan útiles.
El LLM puede entonces razonar:
“La rechazo parece estar relacionado con la exclusión X. La cláusula Y podría crear una excepción bajo la condición Z.”
A continuación vienen las opciones limitadas:
Does this require human review?
→ YES
Which workflow?
→ Claims InvestigationPriority?
→ HighAdditional evidence required?
→ YESCustomer communication template?
→ Coverage Review
Se trata de decisiones estructuradas, no de generación abierta; exactamente donde encaja un modelo de decisión como Jev.
La arquitectura comienza a verse diferente
La IA empresarial puede representarse como responsabilidades cognitivas distintas.
Capa de conocimiento
¿Qué hechos conoce la empresa?
OKF — gráficos de conocimiento — documentos — código fuente — APIs — bases de datos.
Capa de contexto
¿Qué información es relevante para este problema?
RAG, GraphRAG, ingeniería de contexto.
Capa de razonamiento
¿Qué significa esta información?
LLMs y modelos de razonamiento.
Capa de decisión
Dada esta situación, ¿qué debería hacer la plataforma?
Modelos de decisión como Jev.
Capa de ejecución
¿Cómo se debe ejecutar esa decisión?
APIs, flujos de trabajo, reglas de negocio, software determinista.
La separación es importante: la inteligencia no requiere que un modelo gigantesco haga todo.
Y esto cambia la forma en que debemos pensar sobre el conocimiento empresarial
La infraestructura de conocimiento de la empresa es más que una actualización para la recuperación de información. Puede convertirse en el sustrato de estado para la toma de decisiones por parte de las máquinas.
Imagínese un grafo que contenga:
Customer
Policy
Product
Claim
Agent
Branch
API
Business Rule
Regulation
Risk
Transaction
con relaciones como:
Customer → owns → Policy
Policy → belongs to → ProductPolicy → covers → BenefitClaim → relates to → PolicyClaim → triggered by → EventProduct → governed by → RuleRule → derived from → Regulation
El sistema ya no se limita a recuperar “documentos sobre reclamaciones”. Construye una vista estructurada del estado empresarial que diferentes primitivas de inteligencia pueden utilizar:
- LLM para razonamiento
- Modelo de decisión para opciones limitadas
- Reglas para restricciones deterministas
- Código para ejecución
Esa composición es más mantenible que un único mega-prompt.
La parte interesante: la confianza se convierte en un primitivo arquitectónico
Los modelos de decisión también reflejan la confianza. Muchas aplicaciones de IA se limitan a indicar “el modelo emitió X”. Los operadores también necesitan saber: ¿qué tan seguro es el resultado, y qué se ejecuta cuando la confianza es demasiado baja?
Imagínese:
Decision
↓
Confidence
↓
┌───────────────┐
│ │
High Low
│ │
▼ ▼
Auto Human
execute review
Los umbrales deben ajustarse según cada caso de uso, pero el patrón es muy poderoso. Trate la salida de la IA como una decisión con incertidumbre, y luego codifique la política de autonomía:
High confidence
↓
Autonomous execution
Medium confidence
↓
Secondary validationLow confidence
↓
Human intervention
Las industrias reguladas necesitan especialmente esa estructura.
Esto también podría cambiar la economía de la IA
Si cada pequeña decisión tomada por un agente consume muchos recursos de procesamiento, el costo y la latencia aumentan a escala de flota: miles o millones de llamadas. Cuando hay muchas decisiones estrechas y repetitivas, un decisor especializado puede modificar la curva de costo y latencia.
Eso da lugar a otra capa de enrutamiento:
Complex reasoning
↓
LLM
Bounded decision
↓
Decision ModelDeterministic rule
↓
Rule EngineExecution
↓
Code
El objetivo no es reemplazar a los LLM. En concreto, se trata de dejar de usarlos para tareas que no necesitan realizar.
También cambia la forma en que medimos la IA
Los paneles de control actuales suelen registrar usuarios, prompts, tokens, uso del modelo, latencia, adopción y costo. Todo eso sigue siendo útil. Una vez que la IA toma decisiones operativas, aparece otra capa de métricas.
Métricas de inteligencia en la toma de decisiones
| Métrica | Qué nos indica |
|---|---|
| Volumen de decisiones |
Eso traslada la conversación desde la adopción de la IA hacia la economía de la inteligencia artificial.
Y existe una advertencia importante
Jev es completamente nuevo. Cabe destacar que las fechas de presentación pública están fijadas para septiembre de 2026, por lo que aún hay poca evidencia independiente. En consecuencia, sería prematuro considerar a Jev —o a cualquier otro sistema emergente de toma de decisiones— como un sustituto comprobado para los LLM.
La pregunta experimental útil es:
En qué casos un sistema diseñado específicamente para tomar decisiones supera a un modelo de lenguaje, a un motor de reglas clásico o a una combinación de ambos?
Eso merece ser medido, no asumido.
El experimento que vale la pena realizar
Elija un flujo de proceso empresarial bien definido; como ejemplo, Service Request Routing—y proporcione el mismo contexto estructurado a varios enfoques diferentes.
Enfoque 1
LLM → salida estructurada → lógica de la aplicación
Enfoque 2
Motor de reglas → decisión determinista
Enfoque 3
Modelo de decisión → decisión tipada
Enfoque 4
Híbrido:
Rules
↓
Decision Model
↓
LLM when ambiguity requires reasoning
↓
Human when confidence is insufficient
Luego se mide la precisión, la calibración de certeza, la latencia, el costo, el uso de tokens, la tasa de escalada, la explicabilidad, la mantenibilidad, los modos de fallo y el resultado empresarial.
Ese experimento supera a otro ranking que afirma que un modelo es simplemente “mejor”. El objetivo no es coronar a Jev. Se trata de averiguar qué primitiva de inteligencia pertenece a dónde.
De RAG a razonamiento a toma de decisiones
Si volvemos a mirar la escalera:
RAG preguntó:
“¿Dónde se encuentra el material?”
Los gráficos de conocimiento preguntaron:
“¿Cómo están conectadas estas cosas?”
GraphRAG preguntó:
“¿Qué ruta de contexto se debe seguir?”
Los LLMs preguntaron:
“¿Qué significa este contexto?”
Los agentes preguntaron:
“¿Qué debería suceder a continuación?”
Los modelos de decisión añaden:
La inteligencia en la toma de decisiones pregunta:
“Dado este estado, ¿qué acción definida debería elegir la plataforma?”
Esa es una distinción arquitectónica significativa.
Por lo tanto, la pila de IA empresarial puede volverse cognitiva, no solo técnica
A menudo los equipos representan la arquitectura de IA como componentes:
LLM
Vector DB
Embedding Model
RAG
Orchestrator
API Gateway
Guardrails
Una visión basada en responsabilidades cognitivas se parece más a:
ENTERPRISE AI
│
┌────────────┴────────────┐
│ │
KNOWLEDGE CONTEXT
│ │
KG / OKF / Data RAG / GraphRAG
│ │
└────────────┬────────────┘
│
┌─────────┴─────────┐
│ │
REASONING DECISION
│ │
LLM/SLM Jev / similar
│ │
└─────────┬─────────┘
│
ORCHESTRATION
│
GUARDRAILS
│
HUMAN-IN-LOOP
│
EXECUTION
│
APIs / Workflows
El diseño de IA empresarial está alejándose del enfoque de un solo modelo para gobernarlo todo y orientándose hacia un portafolio de primitivas de inteligencia — cada una adaptada para una tarea cognitiva diferente.
El panorama general
Un tema recurrente en el diseño de IA empresarial:
El futuro podría no estar determinado por quien posea el modelo más grande. Podría decidirse por quien construya el mejor sistema alrededor de esos modelos.
La diferenciación radica cada vez más en la combinación de conocimientos propietarios, relaciones estructuradas, ingeniería de contexto, deliberación, inteligencia en la toma de decisiones y ejecución regulada. Cabe destacar que el LLM es solo un componente.
La próxima evolución se presenta de la siguiente manera:
Los modelos de generación darán paso a sistemas de comprensión, luego a sistemas de razonamiento, después a sistemas de toma de decisiones y finalmente a sistemas de acción.
Por lo tanto, la ventaja sostenible podría residir menos en un único punto de control y más en la conexión que une conocimiento, contexto, razonamiento, decisiones y acción; se trata de un problema de ingeniería más complejo que simplemente buscar un mayor número de parámetros.