Data mesh es la idea más citada y menos implantada de la ingeniería de datos de la última década. Casi siete años después de que apareciera el concepto, la mayoría de los equipos de datos usa el vocabulario (dominio, producto de datos, plataforma self-service) y una minoría hizo el cambio de verdad. La diferencia entre ambos grupos casi nunca es tecnológica.
Este texto separa lo que sobrevivió de lo que se trabó, a partir del análisis de 2026 de Thoughtworks, una observación cualitativa de proyectos de clientes, sin cifras de adopción. Donde la opinión es nuestra, lo decimos.
Lo que data mesh nunca fue: una herramienta
La tesis central de la propia Thoughtworks es que el mesh es un paradigma sociotécnico: cambiar el comportamiento es más difícil que cambiar la herramienta, y no existe producto de góndola que lo entregue. Eso desarma la forma más común de empezar, que es comprar una plataforma y esperar que la organización se reordene a su alrededor.
Los cuatro principios siguen en pie, y conviene leerlos como preguntas de gestión:
- Propiedad por dominio. Quien produce el dato responde por él, incluida su calidad.
- Dato como producto. Quien lo consume es cliente, con expectativas de plazo, formato y soporte.
- Plataforma self-service. Un equipo central entrega la infraestructura común para que los dominios no reinventen pipelines.
- Gobierno federado y computacional. Las reglas se deciden en conjunto y se aplican con código, no con reuniones.
Data mesh es una decisión sobre quién responde por el dato, no sobre dónde vive el dato.
Lo que sobrevivió: producto, contrato y plataforma liviana
La lectura más útil del estado actual es la lista de lo que ya se volvió práctica común, según Thoughtworks: productos de datos, contratos, definiciones de SLO/SLA y paneles de calidad. Sumamos una observación propia: lo que sobrevive es lo que cabe dentro de un equipo, sin exigir reestructurar la empresa.
Los data contracts son el ejemplo más claro. Un contrato versionado entre productor y consumidor, con schema, SLO de calidad, términos de uso y política de acceso, entrega el beneficio central del mesh (previsibilidad para quien consume) sin pedirle a nadie que cambie el organigrama.
Otro punto que se consolidó es el modelo híbrido de plataforma: un equipo central provee la base común (almacenamiento, orquestación, catálogo, observabilidad) y los dominios eligen las herramientas de la última milla. El equipo central deja de ser portero y pasa a ser centro de habilitación. La plataforma, en este diseño, se trata como producto interno, con roadmap, usuarios y metas de servicio propias.
Lo que se trabó: dominios de fachada y gobierno por comité
Los patrones de falla que lista Thoughtworks son conocidos para quien vio estos proyectos de cerca:
- Dominios que son equipos de TI rebautizados, sin mandato ni autoridad de negocio. El organigrama cambió; la decisión sigue en el mismo lugar.
- Parálisis de análisis sobre fronteras. Más de un año mapeando el legado y discutiendo límites perfectos de dominio, cuando las fronteras van a cambiar igual.
- Un gerente de proyecto rebautizado como dueño de producto de datos, sin capacitación ni tiempo en la agenda para el rol.
- Gobierno por comité en lugar de política codificada.
- Plataforma completa antes de probar valor.
El cuello de botella más terco, según el texto, es el alineamiento entre áreas: jurídico, compliance, riesgo y negocio deben acordar las políticas antes de poder automatizarlas. Ese trabajo no se terceriza a ingeniería. Es el mismo problema que aparece al intentar tratar el gobierno de datos como código: el código es la parte fácil, la decisión compartida es la parte lenta.
Hay además una trampa de diseño: mapear un caso de uso a un producto de datos. El resultado es un catálogo de tablas descartables, sin reutilización. Thoughtworks recomienda un producto de datos liviano y reutilizable, y advierte que si es demasiado grande reconstruye un silo y si es demasiado pequeño crea un nuevo problema de aguja en el pajar.
Por qué la IA reabrió la conversación
El motivo por el que el tema volvió a la agenda de dirección es práctico: un agente de IA es un consumidor de datos que no perdona la ambigüedad. Thoughtworks llama al mesh prerrequisito de una IA confiable y describe productos de datos de uso dual, que sirven a analytics y a IA, con salidas que pueden ser un endpoint de inferencia, un flujo de eventos, un conjunto de datos listo para IA o incluso un servidor MCP.
La afirmación de que el mesh es el prerrequisito es opinión de una consultoría que vende el modelo; la tomamos como dirección, no como ley. Pero el razonamiento detrás es sólido: un agente es tan confiable como el contrato del dato que consulta. Eso conecta directamente con lo que describimos en dato listo para IA: dato limpio, contextualizado y trazable, con un dueño que responde.
Cómo empezar sin implantar el mesh completo
Para una empresa mediana, el mesh completo suele costar más de lo que entrega. Lo que recomendamos, como práctica nuestra y no como método de mercado, es un comienzo pequeño y deliberado:
- Elija un dominio con dolor real y un dueño de negocio dispuesto, por ejemplo comercial o finanzas. Un dominio sin patrocinador de negocio es el caso del dominio de fachada.
- Defina uno o dos productos de datos, con consumidores nombrados. Si nadie lo consume, no es un producto.
- Nombre un dueño por producto, con tiempo reservado, y escriba el contrato: schema, SLO de frescura y de calidad, política de acceso y canal de soporte.
- Publique el contrato versionado y mida el uso. Un producto que nadie usa en 90 días vuelve a revisión o se apaga.
- Solo entonces generalice la plataforma, a partir de lo que pidieron los dos primeros productos, no de un diagrama.
El criterio de parada también importa: si, después de los dos primeros productos, la ganancia de confianza en el dato no aparece en las conversaciones de decisión, el problema está en la priorización, y más estructura no ayuda.
Preguntas que siempre vuelven
Tres dudas aparecen en casi toda conversación sobre el tema.
¿Qué es data mesh?
Data mesh es un enfoque sociotécnico en el que cada dominio de negocio es dueño de los datos que produce, los entrega como producto a quienes los consumen y se apoya en una plataforma común con gobierno aplicado en código. No es una herramienta ni una arquitectura de almacenamiento: es una forma de distribuir la responsabilidad sobre el dato.
¿Vale la pena data mesh para una empresa mediana?
Rara vez en su forma completa. Con pocos dominios y un equipo de datos pequeño, la coordinación central todavía es más barata que la federación. Lo que vale la pena llevarse del mesh es la parte que cabe en un equipo: producto de datos con dueño, contrato versionado y métrica de uso. Si la empresa crece en dominios y en consumidores, el diseño puede evolucionar desde esa base.
¿Cuál es la diferencia entre data mesh y un data lake o lakehouse?
Lake y lakehouse son decisiones de almacenamiento y procesamiento; mesh es una decisión de responsabilidad. Un mesh puede correr sobre un lakehouse, sobre un warehouse o sobre ambos. La pregunta que responde el mesh es quién es dueño de cada conjunto de datos y de su calidad, mientras que la del lakehouse es dónde y cómo se almacena el dato.