Antes de construir infraestructura vectorial, considera la federación: agentes de AI con acceso por herramientas a tus sistemas actuales. Para la mayoría de los casos de uso empresarial, eso es todo lo que necesitas.
Alguien te dijo que pivotaras hacia AI. Agrega una capa de AI. “Necesitamos ser AI-first.”
Razonable. Entonces empiezas a pensar: ¿qué necesita la AI? Datos. Obvio.
El manual se escribe solo: centraliza datos en un lugar, monta una base de datos vectorial, haz chunking, construye un pipeline RAG, quizá fine-tunea un modelo. Luego consúltalo. Lanza el chatbot. Declara victoria.
A esto le llamo el impuesto de la centralización de AINo el costo de tener un data warehouse, eso suele estar justificado. El impuesto es construir una infraestructura de datos paralelaespecífica para AI encima de lo que ya tienes: bases de datos vectoriales, pipelines de embeddings, estrategias de chunking, modelos personalizados. Una capa completamente nueva, solo para AI.
Puede que eventualmente necesites parte de eso. Pero probablemente no todavía. Y probablemente no para los casos de uso que crees.
Lo más probable es que ya tengas sistemas que guardan tus datos: CRMs, plataformas de soporte, sistemas de facturación, quizá un data warehouse. La pregunta no es si centralizar los datos (probablemente ya lo hiciste). La pregunta es si la AI necesita su propia copia por separado, transformada en embeddings y almacenada en otra base de datos.
La respuesta casi siempre es no.
Si buscas diferenciación, si intentas demostrar economías unitarias, si compites por no quedarte atrás, construir infraestructura específica para AI antes de ver retornos es un error estratégico. Estás creando un estate de datos paralelo para preguntas que no has validado.
Y aquí está la trampa: una vez que invertiste meses construyendo pipelines de embeddings e infraestructura vectorial, pivotar duele aunque aparezcan mejores opciones. No es solo deuda técnica. Es un lock-in estratégico a una arquitectura que puede ya estar obsoleta.
Seamos directos
Alguien pregunta: “¿Cuál es la salud de este cliente?”
Para eso no necesitas un pipeline RAG. No necesitas una base de datos vectorial. No necesitas tu propio modelo. No necesitas un data warehouse con meses de trabajo ETL.
Lo que necesitas: un agente de AI con capacidad de tool calling y un modelo base sólido. Eso es todo. Lo demás es optimización.
Un sistema de AI agéntico con acceso a herramientas puede consultar tu CRM, traer tickets de soporte recientes, revisar el estado de facturación y sintetizar una evaluación de salud en segundos, con datos en tiempo real, sin infraestructura que tengas que construir ni mantener.
Esto no es teórico. Es lo que ya es posible hoy con MCP (Model Context Protocol) y frameworks de orquestación de agentes.
Si tu caso de uso de AI se parece a “dame información sobre X de nuestros sistemas”, detente. No recurras al manual de centralización. Hay un camino más rápido.
El Manual de Centralización de AI
Cuatro enfoques, la misma trampa: construir infraestructura específica para AI en lugar de aprovechar lo que ya tienes:
Pipelines RAG. Divide tus documentos en chunks, genera embeddings, guárdalos en una base de datos vectorial, recupera los top-k matches, mételos al contexto. Funciona para “chat con tu PDF”. Se rompe cuando necesitas resultados estructurados precisos: pides un conteo o una agregación y obtienes números alucinados. Los equipos siguen optimizando estrategias de chunking y umbrales de similitud, resolviendo el problema equivocado.
Modelos fine-tuneados a medida. Recolecta datos de entrenamiento, cura ejemplos, ejecuta jobs de fine-tuning, despliega, monitorea el drift. Semanas o meses de trabajo. Para cuando lanzas, los modelos base mejoraron y tu fine-tune ya quedó atrás.
Data warehouses para AI. Ya tienes Snowflake o BigQuery para analytics. El manual de AI dice: ahora construye capas semánticas, crea transformaciones específicas para AI, quizá replica en un vector store. Más infraestructura, más mantenimiento, cuando un agente de AI podría simplemente consultar tu warehouse existente directamente con tool calling.
Knowledge graphs para AI. Modela tu dominio como entidades y relaciones, ingesta datos, construye lógica de traversal. Meses de trabajo, frágil cuando los schemas cambian, resolviendo un problema que los sistemas agénticos con herramientas suelen manejar con razonamiento.
Mismo patrón: asumir que la AI necesita su propia capa de datos. Mismo problema: construyes infraestructura paralela en lugar de conectarte a lo que ya existe.
Federación: La Alternativa al RAG Que Sí se Lanza
Una pregunta más simple: ¿por qué la AI necesita su propia copia de los datos?
Si los agentes de AI pueden razonar, y las herramientas pueden consultar sistemas, y los LLMs pueden sintetizar, los datos pueden quedarse donde ya viven. Consulta en runtime. Sintetiza bajo demanda.
Eso es federación. En lugar de copiar datos a infraestructura específica para AI, dale a los agentes herramientas para consultar tus sistemas existentes directamente.
*Aclaración importante: Un warehouse en Snowflake con un servidor MCP es federación. Consultas los datos donde viven. El warehouse cumple su propósito y los agentes de AI acceden a él directamente sin necesitar una capa vectorial encima. La federación no es anti-warehouse, es anti-duplicación.*
Lo que hace esto viable hoy:
Capacidad del modelo. Los LLMs de frontera manejan razonamiento en múltiples pasos y orquestación de herramientas de forma confiable. Las ventanas de contexto sostienen resultados de múltiples consultas a sistemas. Los modelos hacen síntesis que hace dos años habrían requerido código personalizado.
Estandarización de herramientas con MCP. El Model Context Protocol se consolidó como el estándar para conectar agentes de AI a sistemas externos. Los principales proveedores de modelos: Anthropic, OpenAI lo adoptaron. El ecosistema incluye miles de integraciones pre-construidas: CRMs, sistemas de soporte, plataformas de facturación, bases de datos, herramientas de desarrollo. Y hay runtimes de MCP que manejan la autorización en el momento de la consulta, los agentes se autentican como el usuario en lugar de depender de cuentas de servicio con permisos excesivos.
Frameworks de agentes. La capa de orquestación maduró. El razonamiento chain-of-thought permite que los agentes corrijan errores y lleguen a respuestas correctas. El manejo de errores que antes requería código explícito ahora es comportamiento emergente.
Tres Patrones de Arquitectura para Agentes de AI
Cada patrón construye sobre el anterior. Empieza simple, agrega complejidad solo cuando llegues a los límites.
Patrón 1: Federación Simple con Tool Calling
El patrón base. Un agente de AI recibe una consulta, usa tool calling para consultar sistemas fuente via servidores MCP y sintetiza la respuesta.
No lo subestimes. Con los LLMs actuales, la federación simple maneja la mayoría de las consultas “dame información sobre X”: verificaciones de estado, búsquedas, investigación entre sistemas, sin infraestructura personalizada.
La idea clave: el agente es la capa de join. Razona entre fuentes, maneja diferencias de schema con comprensión semántica y sintetiza respuestas coherentes. No necesitas modelar las relaciones de antemano, el agente las resuelve en el momento de la consulta.
Cómo funciona: El agente mantiene un estado mínimo, solo lo suficiente para rastrear la conversación y coordinar las llamadas a herramientas MCP. Cada consulta golpea los sistemas fuente directamente, obtiene datos frescos y devuelve resultados. Frameworks como LangGraph ofrecen persistencia de estado y checkpointing de fábrica, eso solo ya te lleva lejos.
Funciona para: Verificaciones de estado, búsquedas, consultas entre sistemas, tareas de investigación. “¿Cuál es la salud de Acme Corp?” “Muéstrame los tickets recientes de este cliente.” “¿Cómo va nuestro pipeline este trimestre?” “Compara el historial de soporte de este cliente con su estado de facturación.”
Limitaciones: Agrega latencia (típicamente 2-5 segundos para consultas multi-sistema, más el tiempo de inferencia del modelo). Sin memoria persistente entre sesiones. A medida que se consultan más herramientas y sistemas en una sesión, el contexto crece y la precisión puede degradarse.
Cuándo falla: Consultas que requieren cálculos sobre grandes datasets (agregaciones de miles de registros), requisitos de respuesta sub-segundo, o consultas donde la latencia de las APIs fuente se acumula de forma inaceptable.
Patrón 2: Federación con Cómputo Efímero
La federación simple maneja la mayoría de las consultas. Pero algunas tareas necesitan más: agregaciones complejas, transformaciones de datos, joins sobre grandes conjuntos de resultados o generar artefactos desde datos obtenidos.
Para esos casos, agrega cómputo efímero.
Cómo funciona: El agente de AI obtiene datos via herramientas MCP y luego levanta cómputo temporal, un entorno sandboxed donde puede ejecutar código, correr SQL contra bases de datos en memoria o procesar datos programáticamente. Los resultados regresan y el cómputo se elimina. Entornos sandboxed como E2B están construidos específicamente para este patrón.
Funciona para: Joins entre sistemas sobre miles de registros, agregaciones complejas, generación de código a partir de datos, ensamblaje de documentos, scripts analíticos.
Limitaciones: Orquestación más compleja. Agrega latencia (tiempo de arranque del cómputo más tiempo de ejecución). La lógica de join puede complicarse cuando los schemas no coinciden, terminas escribiendo fuzzy matching o pidiéndole al agente que razone sobre resolución de entidades.
Cuándo falla: Datasets que superan lo que cabe en memoria (típicamente más de 100K registros según el ancho del schema), consultas que requieren datos históricos que los sistemas fuente no retienen, o cuando necesitas resultados cacheados para acceso repetido.
Patrón 3: AI Agéntico con Memoria a Largo Plazo
Agrega contexto persistente que se acumula entre sesiones. El agente de AI federa para datos actuales pero también mantiene memoria de decisiones, contexto y precedentes.
Cómo funciona: Antes de consultar sistemas en vivo, el agente revisa la memoria en busca de historial relevante. No se trata de embeddear todo tu estate de datos, sino de persistir contexto generado por el agente: decisiones tomadas, precedentes establecidos, preferencias del usuario aprendidas. Capas de memoria como Mem0 y Zep están emergiendo para resolver esto.
La diferencia con el RAG tradicional: Almacenas contexto generado por el agente, no documentos fuente crudos. Es inteligencia acumulada de las interacciones, no datos replicados. La memoria es append-only y crece orgánicamente del uso real.
Funciona para: Soporte a decisiones con precedente (“¿Debemos aprobar este descuento? ¿Qué hicimos con deals similares?”), experiencias personalizadas que mejoran con el tiempo, trazas de auditoría del razonamiento del agente.
Limitaciones: La arquitectura de memoria aún está madurando en el ecosistema. Necesitas decisiones explícitas sobre qué vale la pena persistir. La recuperación de memoria agrega latencia y puede traer contexto irrelevante.
¿Y los Casos Extremos?
“¿Qué hay de los schema mismatches?” Cuando el “Account” de Salesforce no coincide con el “Customer” de Stripe, eso es un problema de SQL, no de vectores. Un agente de AI con contexto del schema puede escribir joins que manejen convenciones de nombres y fuzzy matching. Necesitas un modelo capaz y herramientas MCP bien diseñadas, no embeddings.
“¿Qué hay de encontrar clientes similares?” Antes de recurrir a similitud vectorial, pregúntate: ¿el pattern matching de SQL, los joins y el filtrado pueden llevarte ahí? La mayoría de los casos de uso de “similitud” son estructurales, no semánticos. El razonamiento del agente con herramientas puede lograrlo.
“¿Y la latencia y los costos de API?” Sí, la inferencia del LLM cuesta dinero. Compáralo con tres meses de inversión en infraestructura antes de haber validado si el caso de uso importa. El costo del modelo es la forma más barata de aprender.
Cuándo realmente necesitas búsqueda vectorial: Búsqueda semántica sobre grandes conjuntos de documentos no estructurados donde la búsqueda por palabras clave falla. Ese es el punto fuerte del RAG. Constrúyelo como una herramienta aislada: un vector store expuesto via MCP, no como una capa centralizada de datos de AI.
El patrón: resuelve problemas aislados con herramientas aisladas.
La Asimetría que Importa
Quizá eventualmente necesites un vector store para búsqueda semántica sobre documentos. Quizá necesites un modelo fine-tuneado para lenguaje específico del dominio. Quizá necesites embeddings para similitud real a escala.
Pero no tienes que construir nada de eso para empezar a entregar valor.
Esa es la asimetría. Siempre puedes agregar infraestructura específica para AI después: vector stores, modelos personalizados, pipelines de embeddings para los casos aislados que genuinamente los requieran. La arquitectura tools-first lo acomoda. Construye el vector store cuando hayas probado que necesitas búsqueda semántica. Fine-tunea un modelo cuando los modelos base claramente se queden cortos.
Lo inverso no es fácil. Una vez que invertiste meses en pipelines de embeddings e infraestructura vectorial, tienes equipos manteniéndolos y stakeholders defendiendo la inversión. Pivotar a enfoques más simples basados en herramientas implica infraestructura abandonada y conversaciones difíciles sobre costos hundidos.
Empieza con herramientas MCP. Lanza valor en días. Agrega complejidad solo donde se ganó.
¿Si empiezas con el manual de centralización de AI? Para cuando hayas construido los pipelines de embeddings y lanzado la infraestructura vectorial, los competidores que empezaron con herramientas van en su tercera iteración. Ya validaron lo que los usuarios realmente quieren. Están capturando mercado mientras tú debuggeas la precisión del retrieval.
La Conclusión
Tus datos ya viven en algún lugar: CRMs, plataformas de soporte, sistemas de facturación, data warehouses. Los agentes de AI con herramientas MCP pueden consultar esos sistemas directamente y sintetizar respuestas en segundos.
¿Schema mismatches? Un agente con contexto puede razonarlos. ¿Joins entre sistemas? Cómputo efímero. ¿Búsqueda por similitud? Suele ser solo pattern matching en SQL. ¿Búsqueda semántica sobre documentos no estructurados? Ahí es donde un vector store se gana su lugar: como una herramienta MCP entre muchas, no como la base de tu arquitectura.
El patrón que sigo viendo funcionar: empieza con federación, lanza valor rápido, luego agrega infraestructura especializada solo para los problemas específicos que genuinamente la requieren. Los vector stores, modelos personalizados y pipelines de embeddings tienen su lugar. Pero ese lugar suele ser más estrecho de lo que sugiere el manual estándar.
La mayoría de los casos de uso de AI empresarial son variaciones de “dame información sobre X de nuestros sistemas”. Para eso, los agentes y las herramientas son suficientes. Las organizaciones que lanzan más rápido ya lo entendieron.
Consulta los datos donde viven. Agrega complejidad solo donde se ganó.
