Visión general
RAG amplía la respuesta de un modelo con información recuperada de fuentes externas. Un AI Agent añade capacidad de decidir, planificar y utilizar herramientas para alcanzar un objetivo. Agentic RAG combina ambos mundos: la recuperación deja de ser un paso rígido y pasa a formar parte de un proceso dirigido por un agente.
La diferencia importante no está en el nombre del producto ni en cuántos componentes tenga el diagrama, sino en quién decide el siguiente paso y con qué límites.
Tres enfoques, tres responsabilidades
Arquitectura comparada
RAG
El flujo suele estar predeterminado. La recuperación mejora el contexto, pero el sistema no necesita autonomía para decidir qué tarea ejecutar a continuación.
AI Agent
La pieza diferencial es el bucle de decisión. El agente puede escoger herramientas, observar resultados y adaptar los siguientes pasos.
Agentic RAG
Agentic RAG no implica necesariamente múltiples agentes ni MCP. Puede implementarse con un solo agente que determine qué información necesita, la recupere, evalúe si es suficiente y repita el proceso cuando proceda.
Comparativa rápida
| Característica | RAG | AI Agents | Agentic RAG |
|---|---|---|---|
| Recuperación de información | Sí | Opcional | Sí, dinámica |
| Planificación | No / limitada | Sí | Sí |
| Uso de herramientas | No necesario | Habitual | Habitual |
| Memoria / estado | Opcional | Habitual según el caso | Opcional según el flujo |
| Iteración | Limitada | Sí | Sí |
| Decide qué consultar | Normalmente no | Puede | Sí |
| MCP | No necesario | Opcional | Opcional |
| Complejidad | Baja–media | Media–alta | Alta |
Cuándo usar cada enfoque
La seguridad cambia con la autonomía
En RAG, la atención se concentra en autorización documental, aislamiento entre tenants, procedencia de fuentes, envenenamiento del conocimiento y prompt injection indirecta. Al introducir agentes, se suman permisos de herramientas, identidad máquina, secretos, límites de ejecución, trazabilidad de acciones y capacidad de detener el proceso.
Agentic RAG hereda ambos conjuntos de riesgos. El componente de recuperación ya no es únicamente una fuente de contexto: puede convertirse en una decisión autónoma repetida dentro de un bucle. Por eso conviene limitar fuentes, presupuesto de iteraciones, herramientas disponibles y acciones permitidas.
- Trata el contenido recuperado como entrada no confiable.
- Separa identidad del agente, identidad del usuario y permisos de las herramientas.
- Aplica mínimo privilegio y allowlists donde haya acciones.
- Registra decisiones, fuentes consultadas y llamadas a herramientas relevantes.
- Define límites de tiempo, coste, iteraciones y condiciones de parada.
Dónde encaja MCP
MCP puede proporcionar una interfaz estandarizada para que aplicaciones y agentes accedan a herramientas y fuentes, pero no define por sí mismo que una arquitectura sea agéntica. Un agente puede trabajar sin MCP y un servidor MCP puede utilizarse en un flujo que no sea Agentic RAG.
Arquitectónicamente conviene tratar MCP como una capa de integración con su propia superficie de confianza: servidores autorizados, capacidades expuestas, credenciales, validación de entradas y control de las acciones que pueden ejecutar.
Mi criterio de arquitectura
No añadiría un agente solo porque el patrón sea más moderno. Si una consulta determinista con RAG resuelve el problema, introducir planificación, memoria y herramientas añade superficie de ataque, coste y dificultad operativa sin aportar necesariamente más valor.
La autonomía debe justificarse por la necesidad. Cuanto más pueda decidir o ejecutar el sistema, más explícitos deben ser sus límites, permisos, evidencias y mecanismos de supervisión.
Referencias de base
Miguel Ángel Carriazo
Arquitectura, infraestructura, ciberseguridad y gobierno de IA. CyberLibrary AI · OpenTrust Group.