Data fabrics y agentes IA: por qué MCP cambia la ecuación

Un agente IA sin acceso a los datos correctos en el momento adecuado no es un agente: es un chatbot con pretensiones. Este es el problema de fondo que aborda un reciente análisis de InfoWorld, publicado esta semana, que propone los data fabrics como infraestructura de base para construir agentes más capaces. La pieza llega en un momento en que MCP lleva varios meses consolidándose como el estándar de facto para que los LLMs llamen herramientas externas, y la pregunta ya no es si usar MCP, sino qué poner al otro lado del protocolo.

La convergencia de ambas ideas —data fabrics y MCP— no es casual. A medida que los equipos de ingeniería despliegan agentes en producción, el cuello de botella se desplaza del modelo al acceso a datos: fuentes dispersas, esquemas heterogéneos, permisos granulares y latencias impredecibles. Resolver eso con integraciones punto a punto no escala. La propuesta es resolver el problema una sola vez, en la capa de datos.

Qué es un data fabric y por qué aparece ahora en esta conversación

Un data fabric es una arquitectura que abstrae el acceso a datos distribuidos —bases de datos relacionales, data lakes, APIs, almacenes de documentos— bajo una capa semántica unificada. El agente no necesita saber si un dato vive en Snowflake, en un PostgreSQL on-premise o en un bucket S3: consulta la capa y recibe una respuesta estructurada.

Esto encaja bien con cómo funciona MCP en la práctica. Un MCP server actúa como intermediario entre el modelo y una fuente de datos o herramienta concreta. Si ese servidor apunta a un data fabric en lugar de a un sistema individual, el agente hereda automáticamente toda la amplitud de fuentes que el fabric gobierna, sin que haya que registrar un MCP server por cada sistema de origen. El número de integraciones a mantener cae de forma drástica.

Dónde encaja esto en el ecosistema Claude

En Claude Code, configurar un MCP server se hace en `claude_desktop_config.json` o directamente desde la CLI. La arquitectura habitual que vemos en despliegues de equipos medianos implica varios servidores especializados: uno para búsqueda vectorial, otro para acceso a bases de datos relacionales, otro para APIs internas. Cada uno tiene su lógica de autenticación, su manejo de errores y su esquema de respuesta.

Sustituir ese conjunto fragmentado por un único MCP server que hable con un data fabric unificado simplifica el grafo de dependencias del agente. Además, si el fabric incorpora control de acceso basado en roles, el agente hereda esas políticas sin lógica adicional en el lado del servidor MCP, lo cual tiene implicaciones directas en auditoría y cumplimiento.

Para equipos que trabajan con subagentes en Claude Code —agentes especializados que se invocan desde un orquestador principal— esto también tiene sentido: cada subagente puede consultar el mismo fabric con credenciales distintas, manteniendo la separación de privilegios que una arquitectura multiagente requiere.

Para quién tiene sentido esto hoy

No para todos. Un equipo pequeño con tres fuentes de datos homogéneas probablemente no necesita esta complejidad. El caso de uso natural son organizaciones con datos distribuidos en múltiples sistemas, requisitos regulatorios sobre trazabilidad de accesos y agentes que operan en producción con cierto nivel de autonomía.

En la práctica, los perfiles que más se benefician son:

• Equipos de ingeniería de datos que ya mantienen una capa semántica y quieren exponerla a agentes sin escribir docenas de conectores.
• Arquitectos de soluciones enterprise que diseñan sistemas donde varios agentes necesitan acceder a las mismas fuentes con distintos niveles de permiso.
• Equipos de cumplimiento que necesitan un registro centralizado de qué agente accedió a qué datos y cuándo.

Los modelos con ventanas de contexto amplias —como Claude Opus 4.8 con su opción de 1M tokens— permiten ingerir más contexto por llamada, pero eso no elimina la necesidad de una buena estrategia de acceso a datos. Contexto grande y datos bien gobernados son complementarios, no sustitutos.

Opinión EP

La idea de interponer una capa semántica entre los agentes y los datos de origen es sólida en arquitectura, aunque su valor real depende de cuánto trabajo previo lleve ya hecho el equipo en gobierno del dato. Adoptar un data fabric solo para alimentar agentes sería poner el carro delante del caballo; pero si esa infraestructura ya existe, conectarla vía MCP es una decisión que ahorra meses de mantenimiento de integraciones.