Etiqueta: Normativa

Sin gobernanza de datos robusta no hay atención centrada en el paciente: esa es la conclusión que expertos del sector salud repiten con creciente urgencia. El problema no es la falta de datos clínicos sino la incapacidad de las organizaciones sanitarias para gestionarlos con calidad, trazabilidad y control de acceso suficientes para tomar decisiones confiables.

Los sistemas de salud generan volúmenes extraordinarios de datos — historiales clínicos, imágenes diagnósticas, registros de prescripción, resultados de laboratorio — que en muchas instituciones permanecen fragmentados en silos departamentales sin un marco de gobernanza que los integre. Cuando no existe un modelo claro de ownership del dato, los equipos clínicos trabajan con información inconsistente, duplicada o desactualizada. El resultado es directo: decisiones de tratamiento basadas en registros incompletos, errores en la identificación del paciente y pérdida de continuidad asistencial entre servicios.

Qué significa gobernanza de datos en un entorno hospitalario

En el contexto sanitario, gobernanza de datos implica definir quién es responsable de cada tipo de dato clínico — el data steward del registro del paciente, el custodio del sistema de historia clínica electrónica (HCE) —, bajo qué estándar de calidad debe mantenerse ese dato, y qué reglas de acceso aplican según el rol del profesional de salud. El marco DAMA-DMBOK es aplicable directamente: las capacidades de data quality, metadata management y data security son las tres palancas más críticas en el sector. Sin ellas, iniciativas de analítica clínica o de inteligencia artificial aplicada al diagnóstico se construyen sobre cimientos inestables.

Un punto que los expertos destacan es la necesidad de un master data management (MDM) del paciente: un identificador unívoco que permita consolidar todos los registros dispersos de una misma persona a través de distintos sistemas — admisión, laboratorio, farmacia, consultas externas. La ausencia de MDM en hospitales es una de las causas más documentadas de eventos adversos evitables. En el modelo DCAM del EDM Council, la capacidad de gestión de datos maestros corresponde al nivel intermedio de madurez; muchas instituciones sanitarias de la región no han alcanzado siquiera ese umbral.

Cuándo aplica / cuándo NO

Un programa de gobernanza de datos clínicos aplica cuando la organización opera con múltiples sistemas fuente que deben interoperar — HCE, PACS de imágenes, LIS de laboratorio, sistemas de facturación —, cuando exige reportes regulatorios ante autoridades sanitarias, o cuando planea incorporar analítica predictiva o modelos de IA en el flujo asistencial. No sustituye, en cambio, a los controles de ciberseguridad ni a los sistemas de gestión de calidad ISO 9001/15189 aplicados a procesos de laboratorio; esos son complementarios, no equivalentes. Tampoco resulta pertinente en organizaciones de atención ambulatoria pequeñas con un único sistema integrado y sin necesidad de interoperabilidad externa, donde bastan políticas internas de acceso y calidad de registro.

El cuadro regulatorio en América Latina exige más que buenas intenciones

En la región, los datos de salud son categorizados como datos sensibles en todos los marcos de protección de datos personales vigentes: la Ley 25.326 en Argentina, la Lei Geral de Proteção de Dados (LGPD) en Brasil, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) en México, y la Ley 1581 en Colombia. En todos los casos, el tratamiento de datos clínicos exige consentimiento explícito, medidas de seguridad reforzadas y, en el caso de Brasil, notificación a la Autoridade Nacional de Proteção de Dados (ANPD) ante incidentes de seguridad. Argentina, por su parte, está en proceso de reforma legislativa — el proyecto de nueva Ley de Protección de Datos Personales que actualiza la 25.326 mantiene la categoría especial para datos de salud con estándares más exigentes que los actuales.

Lo que cambia con un programa de gobernanza formal es la capacidad de demostrar cumplimiento ante estas exigencias. Una institución con data lineage documentado puede responder con precisión qué sistemas procesaron un determinado registro clínico, en qué momento y con qué autorizaciones. Una institución sin ese nivel de trazabilidad no puede, en la práctica, cumplir con las obligaciones de transparencia que imponen estas normas, aunque técnicamente tenga los datos almacenados.

Tres capacidades que un CDO de salud debe priorizar en este ciclo

Si la dirección de datos de una organización sanitaria busca dónde anclar un programa de gobernanza con impacto clínico y regulatorio inmediato, el orden de prioridad surge de las brechas más comunes en el sector:

• MDM del paciente: definir un golden record con identificador único y reglas de deduplicación antes de cualquier proyecto de analítica o IA clínica.
• Clasificación de datos sensibles: mapear qué conjuntos de datos caen bajo la categoría de datos de salud según la normativa local y qué controles de acceso diferenciado aplican a cada uno.
• Data stewardship clínico: asignar roles de data steward por dominio — registro del paciente, datos de medicación, datos de diagnóstico — con responsabilidades de calidad formalizadas, no como tarea adicional sino como función reconocida en el organigrama.

El marco de referencia más accionable para hospitales de mediana complejidad es el Non-Invasive Data Governance de Bob Seiner, que permite asignar responsabilidades de stewardship sin rediseñar la estructura organizacional existente — ventaja significativa en entornos hospitalarios donde la resistencia al cambio estructural es alta y los recursos de gestión son limitados.

Los marcos regulatorios de salud en LATAM ya exigen trazabilidad y seguridad diferenciada para datos clínicos; las instituciones que lleguen a esa exigencia sin gobernanza formal no estarán incumpliendo por falta de voluntad, sino por falta de infraestructura de gestión del dato — y esa distinción no interesa a ninguna autoridad de control.

Las naciones indígenas de Estados Unidos están usando la gobernanza de datos como instrumento de soberanía: controlar quién accede a la información sobre sus comunidades equivale, según sus propios marcos conceptuales, a defender territorio digital. El enfoque, documentado por el Banco de la Reserva Federal de Minneapolis, tiene implicancias directas para comunidades originarias de América Latina que hoy carecen de mecanismos formales de control sobre sus propios datos.

La premisa es simple pero políticamente densa: los datos generados por una comunidad indígena —censos, registros de salud, patrones de uso de la tierra, información cultural— son recursos propios. Si esos datos fluyen sin restricciones hacia agencias gubernamentales, empresas farmacéuticas o plataformas de investigación académica, la comunidad pierde control sobre narrativas que la afectan directamente y, con frecuencia, sobre decisiones económicas que dependen de esa información. La gobernanza de datos, en este marco, no es un ejercicio de cumplimiento normativo sino un acto de autodeterminación.

El concepto de “tierra digital” y qué significa en la práctica

La metáfora de la “tierra digital” no es retórica. Las naciones tribales en Estados Unidos tienen reconocimiento jurídico de soberanía sobre su territorio físico; extender ese principio al espacio de los datos implica reclamar derechos equivalentes: decidir qué se recopila, quién puede acceder, bajo qué condiciones y con qué fines. Algunas tribus han formalizado esto a través de políticas propias de gobernanza de datos que incluyen comités de revisión de datos, protocolos de consentimiento comunitario y acuerdos de uso que van más allá de lo que exige la legislación federal estadounidense. En términos de frameworks reconocidos, la estructura se aproxima a lo que el DAMA-DMBOK identifica como data ownership y data stewardship, pero aplicado a un nivel de soberanía colectiva que los marcos corporativos no contemplaron originalmente.

El componente económico es igualmente concreto. Según se informó en el análisis del Banco de la Reserva Federal de Minneapolis, algunas comunidades han utilizado el control de sus datos para negociar mejores condiciones con proveedores de salud, orientar inversiones en infraestructura comunitaria y atraer financiamiento que de otro modo se basaría en estadísticas externas —frecuentemente desactualizadas o metodológicamente cuestionables— sobre sus poblaciones.

Cuándo aplica este modelo / cuándo NO

Este enfoque aplica cuando una comunidad tiene algún grado de reconocimiento jurídico o capacidad organizativa para establecer reglas propias sobre sus datos, y cuando existe una asimetría identificable entre los datos que produce y el beneficio que recibe a cambio de compartirlos. No aplica —o aplica con fricciones significativas— en contextos donde la comunidad depende enteramente de infraestructura de datos administrada por terceros sin cláusulas de acceso negociables, o donde la dispersión poblacional impide constituir un cuerpo de gobierno cohesionado. Tampoco reemplaza la necesidad de marcos legales externos: sin un reconocimiento normativo mínimo, las políticas internas de gobernanza de datos tienen fuerza moral pero no poder de negociación frente a actores estatales o corporativos.

América Latina: pueblos originarios y un vacío normativo que persiste en 2025

En la región, el panorama es fragmentado. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018), que reconoce datos sensibles de origen racial o étnico como categoría especial, pero no establece mecanismos de gobernanza colectiva para comunidades indígenas. La Autoridade Nacional de Proteção de Dados (ANPD) tiene competencia sobre el tratamiento de esos datos, pero la participación comunitaria en las decisiones de gobernanza no está contemplada en la norma. México, con la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), y Argentina, con la Ley 25.326 actualmente en proceso de reforma, presentan vacíos similares. Chile, cuya nueva Ley 21.719 de protección de datos personales entra en vigencia plena en 2026, tampoco incorpora un régimen diferenciado para datos de pueblos originarios, a pesar de que el país reconoce constitucionalmente la existencia de pueblos indígenas.

El principio de soberanía de datos indígenas tiene un antecedente conceptual sólido en el movimiento CARE (Collective Benefit, Authority to Control, Responsibility, Ethics), desarrollado como complemento indígena a los principios FAIR de gestión de datos de investigación. Varias universidades latinoamericanas han comenzado a adoptar estos principios en sus protocolos de investigación con comunidades originarias, aunque su penetración en marcos regulatorios nacionales es todavía marginal.

Un modelo replicable con adaptaciones institucionales

La experiencia de las naciones tribales estadounidenses sugiere que la gobernanza de datos puede ser un instrumento de desarrollo económico comunitario cuando se articula con capacidad institucional propia. Para que eso ocurra en América Latina, se requieren al menos tres condiciones: reconocimiento normativo del derecho colectivo sobre los datos generados por la comunidad, infraestructura técnica mínima para administrar ese control, y marcos de negociación con el Estado y actores privados que hagan ejecutable la política de datos. Ninguna de esas condiciones está completamente satisfecha hoy en ningún país de la región, aunque organizaciones como la COIAB en Brasil o la CONAIE en Ecuador han comenzado a plantear demandas en esta dirección sin usar todavía el lenguaje formal de la gobernanza de datos.

Los principios CARE y los marcos de soberanía de datos indígenas están documentados en el Global Indigenous Data Alliance (www.gida-global.org), punto de partida obligado para cualquier organización que trabaje con datos de comunidades originarias en la región.

La atención centrada en el paciente fracasa cuando el dato clínico no es confiable, no está disponible a tiempo o no tiene un dueño claro dentro de la organización de salud. Expertos del sector coinciden en que la gobernanza de datos no es un proyecto de IT: es infraestructura estratégica para cualquier sistema sanitario que pretenda operar con estándares modernos de calidad asistencial.

El punto de partida es una definición operativa que muchos hospitales y redes de salud todavía eluden: datos clínicos de calidad significa que el dato es exacto, completo, oportuno, consistente entre sistemas y trazable hasta su origen. Ninguna de esas dimensiones se sostiene sola. Un expediente electrónico con campos vacíos, diagnósticos duplicados o fechas inconsistentes no solo es un problema de reporting: puede derivar en errores de prescripción, subdiagnóstico o demoras en tratamientos críticos. El DAMA-DMBOK, marco de referencia global para la gestión de datos, identifica la calidad del dato como una de las once áreas de conocimiento fundamentales, y en el sector salud esa área no admite deuda técnica diferida.

El data steward clínico: un rol que el sector salud aún no nombra

En la industria financiera o en retail, la figura del data steward —responsable de definir, supervisar y defender la calidad del dato en un dominio específico— lleva años institucionalizada. En salud, la misma función existe de facto en médicos jefes, enfermeras coordinadoras o directores de registros médicos, pero sin el reconocimiento formal ni las herramientas de gobernanza que el rol requiere. La consecuencia es predecible: cuando un dato clínico es incorrecto, nadie tiene accountability explícita. El modelo Non-Invasive Data Governance de Bob Seiner propone exactamente lo contrario: formalizar responsabilidades sobre el dato sin crear burocracia adicional, asignando ownership a quienes ya trabajan con ese dato en su operación diaria. Aplicado a salud, significa que el médico tratante es el data steward natural del diagnóstico, y que el sistema debe registrar esa responsabilidad de forma auditable.

Interoperabilidad: el problema técnico con raíz en governance, no en IT

La fragmentación del expediente clínico entre múltiples sistemas —HIS, LIS, RIS, EMR de distintos proveedores— no se resuelve únicamente con integración técnica. Detrás de cada silo de datos hay una decisión de governance no tomada: qué sistema es la fuente de verdad para cada tipo de dato, qué entidad define el catálogo de terminología clínica autorizada (ICD-10, SNOMED CT, LOINC), y quién valida que el dato que sale de un sistema sea el mismo que entra en el siguiente. Sin esas definiciones, el data lineage —la trazabilidad del dato desde su captura hasta su uso en decisión clínica o reporte regulatorio— es imposible de construir. Y sin data lineage, auditar la calidad asistencial o responder a una inspección regulatoria se convierte en una operación manual de días o semanas.

Cuándo aplica la gobernanza de datos en salud y cuándo no es suficiente

La gobernanza de datos clínica aplica en toda organización que genere, procese o comparta datos de pacientes con fines asistenciales, de investigación o de reporte a autoridades sanitarias. Esto incluye hospitales públicos y privados, redes de atención primaria, laboratorios, aseguradoras de salud y plataformas de telemedicina. Lo que la gobernanza de datos no reemplaza es la ciberseguridad: un programa robusto de ownership, calidad y linaje no protege por sí solo contra ransomware o acceso no autorizado. Tampoco suple la protección de datos personales en sentido estricto. Son capas complementarias, no sustitutos.

El marco regulatorio en América Latina: LGPD, Ley 25.326 y resoluciones sectoriales de salud

En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) dedica tratamiento específico a los datos de salud, clasificándolos como datos sensibles en su artículo 11, con restricciones más estrictas para su tratamiento y requisitos de consentimiento diferenciado. La Autoridade Nacional de Proteção de Dados (ANPD) ya ha publicado orientaciones sobre tratamiento en contextos de salud pública. En Argentina, la Ley 25.326 de Protección de Datos Personales clasifica los datos de salud como datos sensibles bajo su artículo 2, y la Agencia de Acceso a la Información Pública (AAIP) es la autoridad de aplicación. A eso se suman las resoluciones del Ministerio de Salud sobre historia clínica electrónica (Resolución 84/2016 y sus modificatorias), que establecen requisitos de integridad, autenticidad y conservación que, en la práctica, demandan capacidades de gobernanza de datos que muchos prestadores todavía no tienen documentadas. En México, la NOM-024-SSA3-2010 regula los sistemas de información en salud y la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares) aplica al sector privado. Un CDO o Chief Data Officer de una red hospitalaria regional debe mapear cuáles de esas obligaciones generan requerimientos concretos de calidad, linaje y ownership en su arquitectura de datos, porque la auditoría regulatoria no pregunta por intenciones: pregunta por registros.

Tres capacidades que un CDO de salud debe tener operativas antes de fin de año

Independientemente del tamaño de la organización, hay un piso mínimo de gobernanza de datos clínicos que el contexto regulatorio latinoamericano ya exige implícitamente. En primer lugar, un catálogo de datos activo que identifique los dominios clínicos críticos —diagnóstico, medicación, identificación del paciente— y el data steward responsable de cada uno. En segundo lugar, un proceso documentado de gestión de calidad del dato que registre reglas de validación, frecuencia de revisión y responsable de resolución de discrepancias. En tercer lugar, trazabilidad básica del dato entre sistemas: al menos poder responder, ante una auditoría, de dónde viene el dato que aparece en el reporte regulatorio y qué transformaciones recibió. Estas tres capacidades equivalen aproximadamente a los niveles 4, 5 y 6 del CDMC (Cloud Data Management Capabilities) del EDM Council, adaptados al contexto clínico.

Para profundizar en los requisitos específicos, el marco DAMA-DMBOK 2 dedica el capítulo 13 a la gestión de datos en contextos regulados, y la ANPD brasileña publicó en 2023 una guía orientativa sobre tratamiento de datos de salud que sirve como referencia para toda la región.

Sin gobernanza de datos robusta, los sistemas de salud no pueden construir una atención centrada en el paciente: los datos clínicos dispersos, sin ownership claro ni calidad verificada, producen decisiones médicas deficientes y exponen a las instituciones a riesgos regulatorios crecientes. El sector salud en América Latina opera con esa deuda técnica acumulada, y el margen para ignorarla se estrecha.

La gobernanza de datos en salud no es un proyecto de TI. Es el conjunto de políticas, roles, procesos y estándares que determinan quién puede acceder a qué datos clínicos, cómo se definen, con qué calidad se capturan y cómo se integran entre sistemas —historias clínicas electrónicas (HCE), laboratorio, farmacia, facturación— para que el médico que atiende al paciente tenga información completa, confiable y oportuna. Sin esa estructura, la atención centrada en el paciente es un objetivo declarado, no operativo.

Por qué los datos clínicos fallan sin un marco de gobierno

El problema más frecuente en hospitales y redes de atención de la región es la fragmentación: cada sistema genera su propio registro, con sus propias definiciones de campo, sin un modelo de datos unificado ni un data steward —responsable de dominio de datos— que arbitre las discrepancias. Un mismo paciente puede tener tres identificadores distintos en tres sistemas, ninguno de los cuales dialoga con los otros. El resultado clínico es medicación duplicada, alergias no registradas o resultados de laboratorio que nunca llegan al médico tratante. El resultado institucional es incapacidad de analizar poblaciones, de cumplir con reportes regulatorios o de alimentar modelos de inteligencia artificial con datos confiables.

El DAMA-DMBOK, referencia estándar en la industria, identifica la calidad del dato como una de las once áreas de conocimiento de la gobernanza. En salud, esa área adquiere carácter crítico: un dato de presión arterial con timestamp incorrecto o una dosis registrada con unidad de medida ambigua no es un error de reporting —es un riesgo clínico directo. Las instituciones que implementan marcos de calidad de datos con reglas de validación en el punto de captura reducen esa categoría de error de forma medible.

Roles críticos: CDO, data steward y el médico como productor de datos

La gobernanza de datos clínicos requiere una estructura de roles que la mayoría de los hospitales latinoamericanos todavía no ha formalizado. El Chief Data Officer (CDO) —o su equivalente funcional— es responsable de la estrategia de datos de la institución. Los data stewards de dominio clínico son los profesionales, frecuentemente médicos o enfermeras con perfil analítico, que definen y custodian los estándares de cada conjunto de datos: qué es un diagnóstico principal, cómo se codifica con CIE-10, cuándo un campo es obligatorio. Sin ese rol, las reglas de negocio quedan implícitas en la cabeza de cada operador y se vuelven ingoberables a escala.

El marco Non-Invasive Data Governance de Bob Seiner ofrece una perspectiva útil para el sector salud: en lugar de imponer capas burocráticas, formaliza las responsabilidades que los profesionales ya ejercen informalmente. Un médico que corrige un diagnóstico ya está haciendo stewardship; la gobernanza lo hace visible, trazable y replicable. Esa lógica es especialmente relevante en hospitales públicos de la región, donde los recursos para estructuras formales son limitados.

Cuándo aplica la gobernanza de datos en salud — y cuándo no es suficiente

La gobernanza de datos clínicos aplica en cualquier institución que centralice registros de pacientes, opere con múltiples sistemas integrados o deba reportar indicadores de calidad asistencial a autoridades regulatorias. En Argentina, los hospitales que reportan al Ministerio de Salud de la Nación bajo el sistema SNVS 2.0 (enfermedades de notificación obligatoria) ya operan en un esquema que exige calidad y completitud del dato; ese requerimiento es, en la práctica, gobernanza de datos aplicada al dominio epidemiológico. En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como datos sensibles y exige tratamiento diferenciado, lo que obliga a las instituciones a mapear sus flujos de datos clínicos con un nivel de detalle que sólo es posible con un programa de gobernanza activo.

La gobernanza de datos, sin embargo, no reemplaza la seguridad de la información ni la ciberseguridad clínica. Un hospital puede tener políticas de acceso bien definidas y aun así ser vulnerable a un ataque si no cuenta con controles técnicos complementarios. Tampoco resuelve por sí sola la interoperabilidad: sin estándares como HL7 FHIR implementados correctamente, la gobernanza documenta silos sin eliminarlos.

El marco regulatorio en LATAM presiona hacia la acción

Más allá de Brasil, otros países de la región están generando presión normativa sobre el manejo de datos clínicos. En Colombia, la Resolución 866 de 2021 del Ministerio de Salud establece lineamientos para la interoperabilidad de datos de salud, lo que implica implícitamente requisitos de calidad y estandarización. En México, la NOM-004-SSA3-2012 regula el expediente clínico electrónico y define qué datos son obligatorios y cómo deben estructurarse —una base normativa para un programa de calidad de datos clínicos. En Chile, la Ley 21.541 de 2023 sobre protección de datos, que moderniza la legislación y clasifica los datos de salud como sensibles, añade otra capa de exigencia para las instituciones del sector.

Para los equipos de datos que trabajan en organizaciones de salud en la región, el punto de partida operativo es concreto: realizar un inventario de los dominios de datos clínicos críticos (paciente, diagnóstico, medicación, resultado de examen), asignar un data steward responsable por dominio, definir las reglas de calidad mínimas para cada campo, y establecer un dashboard de métricas de completitud y consistencia visible para la dirección médica y el área de TI. Sin ese inventario, cualquier iniciativa de analítica clínica o de inteligencia artificial aplicada a salud construye sobre una base que no conoce su propia fragilidad.

Para profundizar en los marcos de referencia, el DAMA-DMBOK 2.0 (disponible en español) y la guía de implementación de HL7 FHIR para América Latina, publicada por la OPS, son los puntos de partida técnicos más sólidos para equipos que inician o maduran un programa de gobernanza de datos en salud.

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.