Los datos de tu negocio nunca viven en un solo lugar.
Un ticket que abre un laberinto de datos
Imagina que tu empresa acaba de lanzar un sistema de atención al cliente con IA.
Un cliente importante envía un ticket: "¿Cuánto le queda de garantía a los servidores que compramos en el Proyecto Alpha el trimestre pasado? ¿Pueden indicarnos también las condiciones del contrato y el contacto de soporte técnico actual?"
Suena como una pregunta corriente. Pero cuando tu responsable técnico lee el ticket, se queda en silencio unos segundos.
Porque sabe que responder eso requiere que el sistema:
- Consulte el perfil y el historial de proyectos del cliente en el CRM
- Consulte el contrato de compra y las condiciones de garantía del Proyecto Alpha en el sistema de gestión de contratos/ERP
- Consulte la fecha de entrada en inventario y los números de serie de esos servidores en el sistema de gestión de activos
- Consulte quién es el responsable actual de éxito del cliente en el sistema de RR. HH.
Estos cuatro sistemas los mantienen equipos técnicos distintos, usan bases de datos diferentes y tienen controles de acceso distintos.
Un sistema RAG convencional no tiene forma de resolver esto. Lo único que puede responder es: "Lo siento, no encuentro información relevante."
Eso es justo lo que Agentic RAG está diseñado para resolver.
RAG tradicional: un recuperador de un solo intento
Repasemos rápido cómo funciona RAG.
La idea central de RAG (Retrieval-Augmented Generation, generación aumentada por recuperación) es simple: el conocimiento de entrenamiento de un LLM es estático, mientras que los datos empresariales son dinámicos y privados. La solución es recuperar fragmentos de documentos relevantes de una base de datos antes de generar la respuesta, incorporarlos al contexto y dejar que el LLM responda con base en ese material.
Pregunta del usuario → [búsqueda vectorial] → recuperación de fragmentos relevantes → [LLM] → respuesta generada
Este flujo funciona bien cuando hay una sola base de conocimiento y la pregunta es clara. Pero tiene dos limitaciones fundamentales.
Limitación uno: una sola recuperación, sin iteración. Se recupera una vez, se le entrega al LLM una vez, y se termina. Si esa primera recuperación no encuentra la información clave, toda la cadena se rompe y el LLM solo puede adivinar o decir "no lo sé".
Limitación dos: un solo corpus, sin enrutamiento. El RAG tradicional asume que todo el conocimiento vive en una única base de datos vectorial. En una empresa real, los datos están repartidos entre CRM, ERP, Confluence, data warehouses, repositorios de documentos privados... y cada sistema tiene su propio punto de acceso y sus propios límites de permisos.
Una analogía: el RAG tradicional es un bibliotecario que solo puede buscar libros en la planta baja, mientras que el libro que necesitas puede estar en el cuarto piso, detrás de un permiso de acceso distinto.
Agentic RAG: un departamento de recuperación que piensa
El cambio central de Agentic RAG es este: convertir una recuperación puntual en un proceso de recuperación planificado e iterativo.
Ya no es un flujo pasivo de consulta y respuesta, sino un flujo de trabajo ejecutado por varios agentes especializados, cada uno con una responsabilidad distinta.
Usemos el ejemplo del ticket de soporte para desglosar cómo funciona todo el flujo.
Paso 1: el orquestador descompone la tarea
La pregunta del usuario llega primero al orquestador (Orchestrator).
El orquestador no recupera nada directamente. Primero entiende la estructura de la pregunta: ¿cuántas necesidades de información independientes implica? ¿Hay dependencias entre ellas? ¿A qué fuentes de datos hay que acceder?
Para nuestro ticket, el orquestador lo descompone en:
- Subtarea A: consultar en el CRM los datos básicos del cliente para "Proyecto Alpha" (ID de cliente, número de proyecto)
- Subtarea B: con el número de proyecto, consultar las condiciones de garantía en el sistema de contratos
- Subtarea C: con el número de proyecto, consultar números de serie y fecha de entrada en inventario en el sistema de gestión de activos
- Subtarea D: consultar en RR. HH. quién es el responsable de soporte técnico actual
Las subtareas B y C dependen del resultado de la subtarea A (primero hay que obtener el número de proyecto). La subtarea D puede ejecutarse en paralelo.
Este grafo de dependencias es el plan de ejecución que produce el agente planificador (Planner Agent).
Paso 2: reescritura de consultas para cada fuente de datos
Cada fuente de datos espera las consultas en un formato distinto. El CRM puede necesitar búsqueda por palabras clave, el sistema de contratos puede requerir SQL estructurado, y la base de datos vectorial necesita búsqueda semántica.
El reescritor de consultas (Query Rewriter) traduce cada subtarea en lenguaje natural al formato de consulta que cada fuente objetivo puede entender:
- Para el almacén vectorial del CRM:
"Proyecto Alpha registro de compra {nombre del cliente}" - Para el sistema de contratos:
SELECT warranty_terms FROM contracts WHERE project_id = 'Alpha-XXX' - Para gestión de activos:
"Proyecto Alpha servidor fecha de entrada número de serie"
Paso 3: recuperación paralela a través de límites de permisos
El agente de difusión de búsqueda (Search Fanout Agent) consulta varias fuentes de datos al mismo tiempo.
Aquí aparece un problema de ingeniería clave: los permisos.
Las distintas fuentes de datos tienen distintos controles de acceso. Los datos del CRM pueden estar abiertos al equipo de ventas, pero los de RR. HH. solo son accesibles para administradores, y los datos de contratos pueden requerir aprobación legal. El framework de Agentic RAG necesita mantener en esta capa un "pool de credenciales" -- tokens de acceso distintos para cada fuente de datos -- y asegurarse de que la recuperación nunca exceda el alcance real de autorización del usuario actual.
Esto no es solo un problema técnico, también es un problema de cumplimiento: la IA no debería poder saltarse controles de acceso a datos que nunca debiste tener solo porque formulaste la petición en lenguaje natural.
Paso 4: verificación de suficiencia -- la innovación más importante
Una vez que llegan todos los resultados de recuperación, pasan al agente de contexto suficiente (Sufficient Context Agent).
Este es el diseño que más distingue a Agentic RAG del RAG tradicional: el sistema juzga activamente si la información reunida hasta el momento basta para responder la pregunta original, y si no es suficiente, indica con precisión qué falta antes de volver a recuperar.
En nuestro caso del ticket, el verificador podría encontrar:
✅ Encontrado: perfil del cliente, número de proyecto, números de serie de los equipos ✅ Encontrado: responsable de soporte técnico ❌ Falta: el sistema de contratos devolvió un documento, pero las condiciones de garantía están en un PDF adjunto que la búsqueda vectorial no encontró
En lugar de decir simplemente "información insuficiente", el verificador genera una descripción precisa de la brecha:
"Se obtuvo el número de proyecto Alpha-2024-087, los números de serie SN-XXX-YYY-ZZZ y la fecha de entrada en inventario de marzo de 2024. Se recuperó el documento principal del contrato, pero las condiciones de garantía están en el Anexo B del contrato. Es necesario volver a buscar en el repositorio de anexos de contrato específicamente 'plazo de garantía del Anexo B'."
Esa retroalimentación impulsa una segunda ronda de recuperación: el reescritor genera una consulta más precisa centrada en el anexo del contrato.
Este bucle de "recuperar → evaluar → recuperar de nuevo" continúa hasta que el verificador de suficiencia determina que la información está completa, o hasta alcanzar el límite máximo de iteraciones.
Paso 5: la síntesis produce la respuesta final
Con toda la información reunida, el agente de síntesis (Synthesis Agent) combina los fragmentos provenientes de cuatro sistemas distintos en una respuesta coherente, precisa y con fuentes citables:
"Los 3 servidores adquiridos en el Proyecto Alpha (número de proyecto Alpha-2024-087, números de serie SN-XXX-001 a 003) tienen una garantía de 36 meses desde su fecha de entrada en inventario (15 de marzo de 2024), según la Sección 4.2 del Anexo B del contrato, con vencimiento el 14 de marzo de 2027. El responsable actual de soporte técnico es Li Ming (extensión 4521, [email protected])."
Cada frase tiene una fuente rastreable.
Permisos entre sistemas: más difícil que la tecnología
Vale la pena tratar por separado el manejo de los límites de permisos.
En una empresa real, los permisos de datos son un problema multidimensional:
| Dimensión | Descripción | Ejemplo |
|---|---|---|
| Permisos por rol | Distintos roles ven datos distintos | Ventas puede ver el resumen del contrato, pero no el texto completo |
| Clasificación de datos | Una misma base de datos puede tener distintos niveles de confidencialidad | Salario de empleados vs. directorio de empleados |
| Permisos temporales | Algunos datos tienen restricciones de acceso por tiempo | Los datos financieros son de solo lectura durante una auditoría |
| Permisos entre sistemas | Los datos del Sistema A no deben aparecer en el contexto del Sistema B | El RGPD exige que los datos no salgan de su jurisdicción |
Un framework de Agentic RAG necesita aplicar estas reglas en cada llamada de recuperación, no autorizar todo de una sola vez al indexar.
Esto implica que la arquitectura debe implementar verificación de permisos en el momento de la consulta, en lugar del enfoque simplista de vectorizar todo en un único repositorio.
En términos de bases de datos: el RAG tradicional es como unir todas las tablas con un JOIN gigante y entregárselo al LLM; Agentic RAG es como generar dinámicamente, para cada consulta, una SQL filtrada por permisos.
Tres decisiones ineludibles en la práctica
Cuando implementas Agentic RAG en producción, hay tres decisiones que siempre aparecen.
Decisión uno: estrategia de enrutamiento -- ¿reglas estáticas o enrutamiento por LLM?
Enrutamiento estático: definir reglas de antemano según palabras clave o metadatos de la consulta para decidir a qué fuente de datos ir. Rápido y predecible, pero débil ante consultas abiertas.
Enrutamiento por LLM: dejar que el LLM entienda la intención de la consulta y decida dinámicamente a dónde enrutarla. Flexible, pero cada decisión de enrutamiento consume una llamada al LLM, lo que añade latencia y costo.
Decisión dos: profundidad de iteración -- ¿cuándo detenerse?
El sistema puede quedar atrapado en un bucle infinito -- cada ronda de recuperación parece indicar que aún falta algo, y sigue buscando indefinidamente.
A nivel de ingeniería hace falta definir:
- Un número máximo de iteraciones (normalmente entre 2 y 4 rondas)
- Un presupuesto de tiempo (responder con lo que se tenga al agotarse el plazo)
- Una estrategia de degradación (responder con la información disponible y marcarla como potencialmente incompleta al superar el límite de iteraciones)
Decisión tres: el equilibrio entre latencia y precisión
Agentic RAG es más lento que el RAG tradicional, y eso es inevitable. Las llamadas múltiples al LLM, la recuperación en paralelo y la evaluación de suficiencia añaden latencia en cada paso.
| Enfoque | Multiplicador de costo | Multiplicador de latencia | Caso de uso ideal |
|---|---|---|---|
| RAG tradicional | 1x | 1x | Preguntas simples, una sola base de conocimiento |
| Adaptive RAG | 1.5-2x | 1.2-2x | Escenarios mixtos con complejidad de consulta variable |
| CRAG (RAG correctivo) | 3-5x | 2-3x | Alta exigencia de precisión, latencia de segundos aceptable |
| Agentic RAG completo | 5-10x | 3-6x | Multi-hop complejo, correlación entre repositorios, escenarios asíncronos |
No todos los escenarios necesitan un Agentic RAG completo.
Clasificar la intención de la consulta -- dirigiendo las consultas complejas al flujo Agentic y las simples al RAG tradicional -- permite mantener el costo y la latencia promedio dentro de un rango razonable.
Reflexión final
Creo que la esencia de Agentic RAG es convertir la recuperación en una estrategia ejecutable: si una pasada no basta, sigue buscando hasta que sea suficiente. Y es el propio sistema el que decide qué significa "suficiente".
Ese cambio suena sencillo, pero exige pasar de un modelo sin estado de "consulta-respuesta" a un flujo de trabajo con estado de "objetivo-planificación-ejecución-evaluación-iteración".
Es el mismo reto general que enfrenta cualquier sistema de agentes: la gestión del estado es la dificultad central.
Si estás construyendo un sistema de IA empresarial que abarca múltiples fuentes de datos, Agentic RAG no es solo una mejora de la técnica de recuperación. Te obliga a repensar la arquitectura de datos, el diseño de permisos y la orquestación del flujo de trabajo. Resolver bien esas tres cosas importa más que elegir un framework o un proveedor de nube en particular.
Referencias
- Google Research, Unlocking dependable responses with Gemini Enterprise Agent Platform's Agentic RAG, junio de 2026
- Microsoft, Agentic Retrieval Overview -- Azure AI Search, GA del 2026-04-01
- Microsoft, What is a Knowledge Source? -- Azure AI Search
- Amazon Web Services, Knowledge Bases for Amazon Bedrock -- Multiple Data Sources, abril de 2024
- MarsDevs, Agentic RAG: The 2026 Production Guide (incluye comparativas de costo/latencia entre enfoques)
- Google Research, Deeper Insights into Retrieval-Augmented Generation: The Role of Sufficient Context