La adopción acelerada de inteligencia artificial en las organizaciones está reviviendo dos arquitecturas de datos que muchos equipos habían postergado: data mesh y data fabric. La razón es operativa, no teórica: los sistemas de IA necesitan datos confiables, bien catalogados y accesibles a escala, exactamente lo que estas arquitecturas prometen resolver.
Data mesh y data fabric no son conceptos nuevos. El primero fue popularizado por Zhamak Dehghani hacia 2019 como una respuesta a los cuellos de botella de los equipos centralizados de datos: en lugar de un lago de datos monolítico, propone distribuir la responsabilidad del dato a los dominios de negocio que lo generan y consumen. El data fabric, por su parte, es una capa de integración semántica y automatizada que conecta fuentes heterogéneas sin moverlas físicamente, usando metadatos activos para que los datos sean descubribles y reutilizables. Ambos enfoques comparten un objetivo: que el dato correcto llegue a quien lo necesita, cuando lo necesita, con la calidad adecuada.
Por qué la IA fuerza a resolver lo que se había pospuesto
Durante años, muchas organizaciones operaron con arquitecturas de datos fragmentadas sin consecuencias inmediatas visibles. Los analistas sabían dónde estaban los datos, los pipelines funcionaban con fricciones tolerables y los reportes salían aunque tarde. La IA generativa rompió ese equilibrio: un modelo de lenguaje que consume datos de múltiples dominios no puede operar con silos manuales, metadatos inconsistentes o linaje opaco. Cuando un agente de IA toma una decisión basada en datos incorrectos o desactualizados, el error escala a velocidad y volumen que los procesos manuales de calidad no pueden contener. El resultado es que proyectos de IA que fracasan en producción están forzando conversaciones de arquitectura que los equipos evitaban desde hace años.
Según el marco DAMA-DMBOK, la gestión de metadatos y el data lineage —la trazabilidad del origen, transformación y movimiento de un dato— son capabilities centrales de cualquier programa de gobernanza maduro. En la práctica, son también los dos requisitos no negociables para que un sistema de IA opere de forma auditable. Sin saber de dónde viene un dato ni cómo fue transformado, no es posible validar los outputs de un modelo ni cumplir con los requisitos de explicabilidad que exigen marcos regulatorios como el AI Act europeo o los lineamientos en desarrollo de la ANPD en Brasil.
Data mesh: ownership de dominio como condición de escala
El principio central de data mesh es que cada dominio de negocio actúa como productor y responsable de sus propios data products —conjuntos de datos con calidad garantizada, documentados y expuestos con una interfaz estándar. En la terminología de Dehghani, esto se conoce como “data product thinking”: el dato deja de ser un subproducto de los procesos operativos y se gestiona con la misma rigurosidad que un producto de software. Para la IA, esto importa porque los modelos de machine learning y los agentes de IA requieren datos con contratos explícitos: esquema estable, SLA de calidad, propietario identificable. Un data product bien definido cumple esos requisitos por diseño.
La implementación de data mesh, sin embargo, no es trivial. Requiere asignar data stewards —responsables operativos del dato dentro de cada dominio— con tiempo, herramientas y autoridad real para mantener la calidad. La experiencia en la región muestra que este es el punto de fractura más común: las organizaciones adoptan la retórica del data mesh sin redistribuir la responsabilidad efectiva ni asignar los recursos que esa responsabilidad requiere. El resultado es un catálogo poblado a medias y data products que nadie actualiza.
Data fabric y metadatos activos: el rol del catálogo inteligente en Argentina, Brasil y México
El data fabric se apoya en metadatos activos —metadatos que no solo describen los datos sino que se usan para automatizar su descubrimiento, integración y gobierno. Herramientas como catálogos de datos con capacidades de IA incorporada pueden inferir relaciones entre datasets, proponer clasificaciones de sensibilidad y alertar cuando el linaje de un dato cambia. Esta automatización es especialmente relevante para organizaciones en América Latina que operan con equipos pequeños de datos pero con entornos multicloud y fuentes heterogéneas.
En el contexto regulatorio de la región, la capa de metadatos activos tiene implicancias directas. La Ley 25.326 de Argentina y la LGPD de Brasil exigen poder identificar qué datos personales se procesan, con qué base legal y durante cuánto tiempo. Un data fabric con linaje automatizado puede responder esas preguntas de forma reproducible. En México, la LFPDPPP impone obligaciones similares para el sector privado. Las organizaciones que ya invirtieron en data fabric para soportar sus proyectos de IA tienen, como subproducto, una infraestructura de trazabilidad que simplifica el cumplimiento de estas leyes. Las que no lo hicieron enfrentarán el mismo problema dos veces: una para la IA y otra para el regulador.
Cuándo aplica data mesh y cuándo data fabric — y cuándo ninguno de los dos
Data mesh aplica cuando la organización tiene múltiples dominios de negocio con datos propios, equipos técnicos distribuidos y un problema de ownership —nadie sabe quién es responsable de qué dato. No aplica en organizaciones pequeñas con un solo equipo de datos centralizado: el overhead de coordinación supera los beneficios. Data fabric aplica cuando el problema es de integración heterogénea —muchas fuentes, muchos formatos, baja reutilización— y el equipo no puede o no quiere mover los datos a un repositorio central. No es la solución correcta cuando el problema de fondo es calidad en origen: una capa de integración sobre datos sucios produce datos sucios integrados más rápido. Ambas arquitecturas son complementarias y muchas organizaciones grandes las implementan en capas, pero el orden importa: primero ownership y calidad, después integración y escala.
El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), ubica el data lineage y la gestión de metadatos en las capabilities de nivel 6 a 8 de madurez —las más avanzadas. Eso significa que una organización que aún no tiene ownership claro de sus datos ni catálogo operativo no está lista para implementar data mesh o data fabric de forma efectiva. El camino correcto es secuencial: establecer stewardship, catalogar, medir calidad, y recién entonces escalar con arquitecturas distribuidas.
La especificación completa del modelo de data product de Zhamak Dehghani está disponible en datamesh-architecture.com; el marco CDMC del EDM Council, en edmcouncil.org. Ambos son puntos de partida más útiles que cualquier vendor deck.
