El data mesh no es una moda de arquitectura de datos: es la respuesta estructural al problema que la inteligencia artificial generativa volvió urgente. Cuando los agentes de IA consumen datos de decenas de dominios en tiempo real, el modelo centralizado de data warehouse colapsa. La pregunta ya no es si adoptar data mesh, sino cómo gobernarlo cuando los consumidores son máquinas, no personas.
Data mesh, el paradigma desarrollado por Zhamak Dehghani y popularizado a partir de 2019, propone descentralizar la propiedad del dato: cada dominio de negocio —finanzas, operaciones, producto, clientes— es dueño de sus propios data products y los expone al resto de la organización con estándares comunes. En vez de un equipo central de ingeniería que mueve y transforma todo, el ownership recae en quien mejor conoce el dato. La infraestructura se comparte; la responsabilidad, no. Este modelo resuelve cuellos de botella clásicos de los data lakes corporativos, pero crea tensiones propias cuando la IA entra en escena.
Por qué la IA presiona los cuatro principios del data mesh
El data mesh se apoya en cuatro principios: propiedad del dato por dominio, el dato como producto, infraestructura de autoservicio y gobernanza federada. Los tres primeros escalan razonablemente bien. El cuarto —gobernanza federada— es donde la IA introduce fricciones nuevas. Un agente de IA que razona sobre datos de clientes, inventario y contratos simultáneamente no distingue si está cruzando dominios con distintos niveles de clasificación. Si el data product de clientes tiene etiqueta PII y el de inventario no, el agente puede generar outputs que mezclan ambos sin que ningún steward de dominio lo haya autorizado explícitamente. El DAMA-DMBOK v2 identifica la integración entre dominios como uno de los puntos de mayor riesgo en arquitecturas distribuidas, y los flujos de IA lo amplifican.
El data lineage —la trazabilidad de origen, transformación y consumo del dato— se vuelve crítico en este escenario. Sin lineage granular, es imposible auditar qué dato alimentó qué decisión del modelo. Herramientas como OpenLineage o los módulos de linaje de catálogos como Apache Atlas, DataHub o Collibra permiten registrar esos flujos, pero solo si el data product fue diseñado desde el inicio para exponer metadata de linaje. En la mayoría de las organizaciones latinoamericanas, ese diseño no existe: los data products se construyeron para consumo humano, no para consumo de agentes.
El data steward de dominio necesita un nuevo mandato cuando el consumidor es un modelo
En un data mesh maduro, cada dominio tiene un data steward —en la nomenclatura del Data Governance Institute, el responsable de la calidad, semántica y política de acceso del dato dentro de su área. Cuando el consumidor era un analista, el steward podía gestionar accesos con listas de control y revisiones periódicas. Cuando el consumidor es un agente de IA que consulta el dato miles de veces por día y puede encadenar inferencias no previstas, el mandato cambia: el steward debe definir contratos de datos explícitos que incluyan restricciones de uso por tipo de consumidor, no solo por persona o equipo. Esto implica extender los data products con atributos de política: “este campo puede ser usado para entrenamiento”, “este campo puede alimentar outputs hacia externos”, “este campo requiere enmascaramiento antes de exponerse a modelos no validados”.
El marco CDMC (Cloud Data Management Capabilities) del EDM Council, que varias instituciones financieras de Brasil y México están adoptando como referencia, incluye la capability 8 de controles de datos sensibles como requisito para entornos de IA. La exigencia no es nueva: el Banco Central de Brasil, a través de la Resolución BCB 4.658/2018 sobre gestión de riesgo tecnológico, ya demandaba trazabilidad de datos críticos en entornos cloud. La novedad es que ahora esa trazabilidad debe extenderse hasta los pipelines de inferencia de los modelos.
Cuándo el data mesh resuelve el problema y cuándo no
El data mesh es apropiado cuando la organización tiene dominios de negocio bien definidos, equipos con capacidad técnica suficiente para operar data products, y un plano de gobernanza federada con políticas comunes acordadas. En esas condiciones, la IA se beneficia: encuentra datos clasificados, con linaje, con contratos explícitos, servidos por equipos que conocen su semántica. El riesgo de alucinación por datos incorrectos baja. El riesgo regulatorio —especialmente bajo la LGPD brasileña o la Ley 25.326 argentina, que exigen que el responsable del tratamiento pueda identificar la fuente y el propósito de cada dato personal procesado— se vuelve manejable.
El data mesh no resuelve el problema cuando la gobernanza federada es nominal: dominios que publican data products sin clasificación, sin steward activo, sin SLA de calidad. En ese escenario, descentralizar el ownership solo descentraliza el caos. Un CDO que quiera aprovechar los agentes de IA sin haber cerrado primero los contratos de datos entre dominios está construyendo sobre arena. El NIST AI RMF (AI Risk Management Framework) es explícito en este punto: la gestión del riesgo de IA requiere trazabilidad del dato de entrada como condición previa, no como mejora iterativa.
Tres acciones concretas para CDOs en organizaciones con data mesh parcial
La mayoría de las organizaciones latinoamericanas con arquitecturas de data mesh se encuentran en estadios intermedios: algunos dominios maduros, otros sin steward asignado, y catálogos de datos con cobertura parcial. Ante la presión de incorporar IA generativa, el riesgo es saltear los pasos de gobernanza. Las acciones con mayor retorno inmediato son tres. Primero, auditar qué data products están siendo consumidos —o podrían serlo— por modelos de IA, y verificar si tienen clasificación de sensibilidad y linaje registrado. Segundo, extender los contratos de datos existentes con una dimensión de política de uso por tipo de consumidor, empezando por los dominios de clientes y finanzas, que concentran la mayor densidad de datos personales bajo regulación. Tercero, alinear al data steward de cada dominio con el equipo de IA sobre los límites de uso del dato: sin ese diálogo, el modelo consumirá lo que técnicamente pueda acceder, no lo que la política autoriza.
El DAMA-DMBOK v2 y el CDMC del EDM Council son los marcos de referencia más utilizados en la región para estructurar esta transición; ambos están disponibles en sus sitios oficiales y son el punto de partida obligado antes de habilitar cualquier agente de IA sobre un data mesh en producción.
