Blog

Sin datos de calidad, un programa de data governance es una estructura vacía. La relación entre ambos conceptos no es complementaria sino constitutiva: la calidad del dato es la condición de posibilidad de cualquier decisión que el gobierno de datos pretenda respaldar. Para los equipos que lideran iniciativas de gobernanza en América Latina, entender esa relación en términos operativos marca la diferencia entre un framework decorativo y uno que genera valor real.

El error más frecuente que cometen las organizaciones al arrancar un programa de gobernanza es tratar la calidad de datos como un proyecto paralelo o posterior. Se definen políticas, se asignan data stewards, se instala un catálogo de datos, y recién entonces alguien pregunta: ¿pero estos datos son confiables? Para ese momento, las decisiones ya se tomaron sobre cimientos inestables. El DAMA-DMBOK 2 es explícito al respecto: la gestión de la calidad del dato (Data Quality Management) es uno de los once knowledge areas del framework, y su integración con Data Governance no es opcional sino estructural.

Qué significa “calidad” en un contexto de gobernanza

La calidad de datos no se reduce a que los registros estén completos o sin errores tipográficos. En un marco de gobernanza robusto, la calidad se evalúa contra dimensiones precisas: completitud, consistencia, precisión, oportunidad, unicidad y validez. Cada dimensión responde a una pregunta de negocio distinta. Un dato puede ser preciso pero inoportuno —llegar fuera del ciclo de decisión—, o consistente en un sistema pero contradictorio al cruzarse con otro. El modelo de John Ladley en “Data Governance: How to Design, Deploy, and Sustain an Effective Data Governance Program” subraya que las reglas de calidad deben derivarse de los casos de uso del negocio, no de criterios técnicos aislados.

Esto tiene una implicancia directa para el diseño del programa: los data stewards —los responsables funcionales del dato en cada dominio— son quienes deben definir qué significa “buena calidad” para su conjunto de datos, no el equipo de IT. Un steward de datos maestros de clientes en un banco tiene criterios de calidad distintos a los de un steward de datos de riesgo crediticio, aunque ambos trabajen con información del mismo cliente. Esta distinción es central en el enfoque de Non-Invasive Data Governance de Bob Seiner, que propone formalizar roles que ya existen en la organización en lugar de imponer estructuras nuevas.

El costo de ignorarlo: casos concretos en la región

En América Latina, la degradación de la calidad de datos tiene consecuencias regulatorias directas. Las entidades financieras en Brasil que reportan al Banco Central bajo el sistema SCR (Sistema de Informações de Crédito) enfrentan penalidades cuando los datos remitidos presentan inconsistencias. En Argentina, la Comunicación A 7724 del BCRA establece requisitos de integridad de la información para los reportes de gestión de riesgo, lo que obliga a los bancos a mantener controles de calidad que —aunque no se llamen así— son capabilities equivalentes a los que define el CDMC (Cloud Data Management Capabilities) del EDM Council. En México, la CNBV tiene requerimientos similares para la remisión de información regulatoria periódica.

Más allá del sector financiero, organizaciones con grandes volúmenes de datos personales enfrentan un riesgo adicional: datos de baja calidad pueden derivar en tratamientos incorrectos de información personal, lo que en jurisdicciones con leyes activas como la LGPD brasileña o la Ley 25.326 argentina puede traducirse en incumplimientos con consecuencias sancionatorias. Un registro duplicado mal gestionado puede implicar el envío de comunicaciones a personas que ya ejercieron su derecho de supresión.

Qué hace un CDO con esto el lunes

El punto de entrada más práctico es el data quality scorecard por dominio. Antes de expandir el catálogo de datos o incorporar nuevas fuentes al data lineage, un CDO debería poder responder tres preguntas por cada dominio crítico: ¿cuál es la tasa de completitud actual?, ¿existe un SLA de calidad definido y acordado con el negocio?, y ¿hay un data steward asignado con capacidad de escalar issues de calidad? Si alguna de las tres respuestas es “no sé”, ese dominio es el punto de partida.

• Mapear los dominios de datos críticos para el negocio y asignar un data steward con mandato explícito sobre calidad.
• Definir al menos tres dimensiones de calidad medibles por dominio, con umbrales acordados con stakeholders de negocio.
• Integrar los controles de calidad en el pipeline de datos, no como paso posterior sino como gate de ingesta.
• Establecer un proceso de escalamiento claro cuando un dataset no alcanza el umbral mínimo de calidad para ser usado en decisiones.
• Revisar si los controles de calidad actuales cubren los requisitos de reporte regulatorio aplicables en la jurisdicción.

Herramientas como Great Expectations, Monte Carlo o los módulos nativos de calidad en plataformas como Collibra o Alation permiten automatizar buena parte de este monitoreo, pero la automatización sin ownership humano reproduce el problema a mayor velocidad. La tecnología es el habilitador; el data steward es el responsable.

Gobernanza sin calidad es solo burocracia

Los programas de data governance que no resuelven el problema de calidad generan uno nuevo: una capa de procesos y documentación que le da a la organización la ilusión de control sin el control real. Los comités se reúnen, las políticas se aprueban, el catálogo crece, y las decisiones siguen tomándose sobre datos que nadie confía del todo. Esa desconexión entre la estructura de gobernanza y la realidad del dato es, según el Data Governance Institute, una de las causas principales de abandono de iniciativas de este tipo en los primeros dos años.

Un programa de gobernanza se mide, en última instancia, por si los datos que produce son usados con confianza. Todo lo demás es arquitectura.

El gobierno de datos acumula años de promesas y frameworks bien documentados, pero en la mayoría de las organizaciones sigue siendo un ejercicio de diseño más que de ejecución. La brecha no está en el conocimiento teórico — está en la distancia entre la política aprobada por el comité y la decisión que toma un analista a las 9 de la mañana del lunes. Cerrar esa brecha es el verdadero desafío operativo para los equipos de datos en 2025 y 2026.

El problema de fondo: governance como artefacto

Durante años, muchas organizaciones construyeron su programa de gobierno de datos alrededor de entregables: un glosario de negocio, un mapa de data lineage —la trazabilidad que permite saber de dónde viene un dato y cómo se transforma a lo largo de su ciclo de vida—, un catálogo de activos, políticas de clasificación. El problema no es que esos artefactos estén mal; el problema es que se actualizan trimestralmente, viven en herramientas que pocos consultan y no están conectados a los flujos de trabajo diarios. En la práctica, el dato se procesa igual con o sin ellos. El DAMA-DMBOK, en su segunda edición, ya advertía sobre esta trampa: un programa de governance que no se integra en los procesos operativos es, a efectos prácticos, decorativo.

Bob Seiner, referente de la corriente Non-Invasive Data Governance, lleva más de dos décadas argumentando que el gobierno de datos debería operar sobre las responsabilidades que ya existen — no crear burocracia nueva — sino formalizar quién ya toma decisiones sobre los datos y hacer eso visible, medible y repetible. La operacionalización no implica agregar pasos; implica incrustar controles donde el trabajo ya ocurre.

Qué significa “operativo” en la práctica

Hablar de gobierno de datos operativo tiene al menos tres dimensiones concretas que vale distinguir. La primera es la integración en pipelines: las reglas de calidad, clasificación y ownership no se definen fuera del pipeline — se ejecutan dentro de él. La segunda es la asignación de data stewards —responsables de dominio de datos con mandato formal— que participan en las decisiones técnicas, no solo en las revisiones de política. La tercera es la medición continua: dashboards de calidad de datos vinculados a KPIs de negocio, no reportes mensuales en PDF.

• Reglas de calidad y clasificación embebidas en los pipelines de ingesta y transformación.
• Data stewards con capacidad de bloquear o escalar issues en tiempo real, no solo en reuniones de comité.
• Métricas de governance como parte del scorecard del CDO, no en un reporte separado de compliance.
• Catálogo de datos activo, vinculado al entorno de desarrollo, no a un portal que nadie visita.

El contexto regulatorio empuja la urgencia en LATAM

En América Latina, la presión externa para operacionalizar el gobierno de datos ya no es solo una buena práctica — empieza a ser una exigencia implícita en marcos regulatorios sectoriales. En Brasil, la ANPD ha orientado sus primeras resoluciones hacia la demostración de controles efectivos sobre datos personales, no solo sobre la existencia de políticas escritas: las empresas que no puedan mostrar evidencia operativa de su programa corren riesgo en cualquier proceso de fiscalización bajo la LGPD. En Argentina, la Comunicación A 8073 del BCRA exige a las entidades financieras capacidades de gestión del ciclo de vida del dato que, en el marco del EDM Council (CDMC), corresponden a niveles de madurez 7 y 8 — aunque la mayoría de los bancos locales aún no ha formalizado esa equivalencia ni la certifica. En México, el INAI ha intensificado la expectativa de que los responsables de tratamiento puedan demostrar, con evidencia, los controles aplicados sobre datos personales sensibles.

“La governance que no se puede demostrar en producción no existe desde el punto de vista regulatorio. Una política aprobada en un comité no es un control.”

— Principio operativo, EDM Council CDMC Framework

Qué hace un CDO con esto el lunes

La pregunta concreta para cualquier Chief Data Officer o Data Governance Manager es cómo avanzar sin necesidad de un proyecto de transformación de 18 meses. Una ruta práctica parte de identificar los tres o cuatro dominios de datos con mayor impacto regulatorio o de negocio — clientes, productos, proveedores, transacciones — y mapear quién toma decisiones sobre esos datos hoy, aunque no tenga título formal de data steward. Formalizar ese ownership es el primer paso hacia un control operativo real. El segundo es revisar si las reglas de calidad definidas en el glosario o en el catálogo están efectivamente implementadas en algún punto del pipeline, o solo existen en un documento Word. Si la respuesta es “solo en el documento”, ese es el gap prioritario. El tercer paso es conectar al menos una métrica de calidad de datos a un indicador de negocio que el área usuaria ya monitoree — eso cambia la conversación de compliance a valor.

El ISO/IEC 38505, marco de governance de datos para órganos de dirección, refuerza este enfoque: la responsabilidad final sobre los datos no recae en el equipo de TI ni en el equipo de datos, sino en quienes toman decisiones de negocio. Operacionalizar governance es, en último término, hacer esa responsabilidad visible y exigible en el día a día.

Un programa de gobierno de datos que no se puede demostrar en producción no es un programa — es una presentación de PowerPoint con fecha de vencimiento.

Nigeria endureció sus reglas de gobierno de datos para agencias del sector público, según se informó a comienzos de agosto de 2025. La medida establece requisitos formales de gestión, clasificación y responsabilidad sobre los datos que producen y custodian los organismos estatales, y coloca al país africano en una trayectoria que varios gobiernos de América Latina todavía no terminan de recorrer.

El marco regulatorio nigeriano, impulsado desde la Nigeria Data Protection Commission (NDPC), apunta a que cada agencia gubernamental designe responsables formales del dato, implemente políticas de ciclo de vida de la información y reporte con periodicidad el estado de sus activos de datos. La lógica es la misma que sostiene el DAMA-DMBOK en su área de conocimiento de Data Governance: sin ownership claro, ningún programa de calidad o seguridad puede sostenerse en el tiempo. Lo notable es que Nigeria lo está aplicando de manera top-down sobre el Estado, no solo sobre el sector privado.

El problema de fondo: datos públicos sin dueño

Uno de los patrones más documentados en auditorías de gobierno de datos del sector público es la ausencia de data stewards formalmente designados. En la práctica, los registros administrativos —padrones, bases tributarias, historiales clínicos, datos catastrales— circulan entre dependencias sin un modelo claro de ownership. El resultado es duplicación, inconsistencia y, cuando ocurre un incidente, incapacidad de reconstruir el data lineage para determinar qué se expuso y desde cuándo. La iniciativa nigeriana ataca exactamente ese nodo: fuerza a cada agencia a mapear sus activos y asignar responsabilidades concretas.

El modelo de referencia más cercano a lo que Nigeria está construyendo es el Data Management Capability Assessment Model (DCAM) del EDM Council, que estructura las capacidades de gobierno de datos en niveles de madurez medibles. En el contexto de gobierno, el nivel 3 del DCAM —donde los procesos de governance están definidos, documentados y medidos— sigue siendo aspiracional para la mayoría de los organismos públicos globales. Nigeria está intentando saltear los niveles informales e instalar ese piso de manera regulatoria.

LATAM: el sector público va a distintas velocidades

En América Latina, el panorama es heterogéneo. Brasil avanza con la LGPD (Ley 13.709/2018) y la Autoridade Nacional de Proteção de Dados (ANPD) ha publicado orientaciones específicas para el tratamiento de datos por parte de organismos públicos, pero la implementación interna de programas de data governance al interior de las agencias sigue siendo desigual. En Argentina, la Ley 25.326 de Protección de Datos Personales regula el tratamiento estatal, pero no existe un mandato equivalente al nigeriano que exija a cada ministerio o ente descentralizado tener un programa de gobierno de datos con ownership documentado. México, a través del INAI, ha avanzado en criterios de seguridad para datos personales en posesión del Estado, pero la dimensión de governance —más allá de privacidad— carece de un marco homogéneo entre dependencias federales y estatales.

El caso nigeriano es relevante porque muestra que es posible legislar sobre data governance sectorial con exigencias operativas concretas: designación de roles, inventario de activos, políticas de retención y mecanismos de reporte. No es solo una declaración de principios.

Qué puede hacer un CDO del sector público esta semana

Para un Chief Data Officer o responsable de gobierno de datos en una agencia pública latinoamericana, el movimiento nigeriano es una señal de tendencia que conviene anticipar. Hay tres acciones concretas con bajo costo de arranque:

• Levantar un inventario mínimo de activos de datos críticos — al menos los que se comparten con otros organismos o que tienen obligaciones legales de reporte — y asignar un data steward nominal a cada uno, aunque sea con dedicación parcial.
• Documentar, aunque sea en una planilla, el flujo entre sistemas de origen y sistemas de consumo para los tres o cuatro procesos de datos más sensibles del organismo. Eso es data lineage básico, y habilita cualquier análisis de impacto posterior.
• Mapear qué normativa sectorial ya exige, implícitamente, capacidades de governance: BCRA Comunicación A 8073 en Argentina para entidades financieras, resoluciones de la ANPD en Brasil, o lineamientos del INAI en México. Muchos organismos tienen obligaciones de facto sin un programa formal que las sostenga.

La experiencia comparada —desde la estrategia de datos del gobierno del Reino Unido hasta iniciativas más recientes en Singapur y ahora Nigeria— muestra que los marcos de data governance en el sector público no surgen de la cultura organizacional espontánea. Requieren mandato explícito, roles formales y métricas de cumplimiento. Sin esos tres elementos, los programas se disuelven con el cambio de gestión.

El riesgo de no actuar

Cuando una agencia pública no tiene governance formal sobre sus datos, los problemas no aparecen en el día a día: aparecen cuando se necesita responder a una auditoría, cruzar bases con otro organismo, o —peor— cuando ocurre un incidente y no hay manera de determinar qué datos estaban en riesgo, quién era el responsable y cuál era la política de retención aplicable. En ese momento, la ausencia de data lineage y de ownership documentado se convierte en un problema legal, no solo operativo.

Nigeria acaba de poner el estándar sobre la mesa. La pregunta para los organismos públicos de la región no es si van a necesitar programas formales de data governance, sino cuánto van a esperar para construirlos.

El precio de perder el control sobre los datos sigue subiendo en América Latina. Según se informó, el costo promedio de una brecha de datos en la región alcanzó cifras récord en el último período medido, presionando a las organizaciones a repensar sus modelos de gobierno del dato desde la raíz, no solo su postura de ciberseguridad.

Durante años, la conversación sobre brechas de datos en LATAM se concentró casi exclusivamente en el vector técnico: el parche que faltaba, el firewall mal configurado, el endpoint desprotegido. Ese encuadre subestimó sistemáticamente una dimensión que los números ahora vuelven imposible de ignorar: el costo económico y reputacional de no tener gobernanza sobre el dato antes de que ocurra el incidente. Cuando no se sabe qué datos existen, dónde viven, quién es su owner y cuál es su nivel de clasificación, la superficie de exposición crece de manera silenciosa hasta que alguien la cuantifica en dólares.

Qué está detrás del incremento

Los factores que elevan el costo de una brecha van más allá del rescate o la remediación técnica. Los componentes que más peso tienen incluyen la notificación obligatoria a titulares y reguladores, las sanciones por incumplimiento normativo, el daño reputacional medido en pérdida de clientes, los costos legales derivados de demandas y, crecientemente, el tiempo de detección y contención. Precisamente este último indicador —cuánto tarda una organización en descubrir que fue comprometida— depende en gran medida de qué tan maduro es su programa de data governance: sin un catálogo de datos actualizado y sin data lineage formal, identificar qué registros fueron expuestos puede llevar semanas.

El DAMA-DMBOK, estándar de referencia en gestión de datos, establece que la clasificación de datos y la definición de data stewards —los responsables formales de cada dominio de datos dentro de la organización— son capacidades habilitadoras para cualquier programa de respuesta a incidentes. Sin esa base, la organización llega tarde a la notificación, activa procesos de remediación incompletos y multiplica su exposición legal.

El marco regulatorio que amplifica el riesgo financiero

América Latina tiene hoy un ecosistema normativo que convierte cada brecha en una amenaza financiera concreta. Brasil opera bajo la LGPD (Lei Geral de Proteção de Dados), que habilita multas de hasta el 2% de la facturación de la empresa en Brasil, con tope de 50 millones de reales por infracción. Argentina actualiza progresivamente la aplicación de la Ley 25.326 bajo supervisión de la Agencia de Acceso a la Información Pública (AAIP), que ha intensificado sus requerimientos de notificación de incidentes. México, a través del INAI, aplica la LFPDPPP con sanciones que pueden escalar significativamente en casos de negligencia manifiesta. Colombia y Chile completan un cuadro regional donde ya no existe jurisdicción de escala sin exposición regulatoria real ante un evento de este tipo.

Este entorno normativo transforma lo que antes era un costo técnico en un pasivo legal activo. Las organizaciones que no pueden demostrar ante la autoridad que tenían controles adecuados —políticas de retención, control de acceso basado en roles, registros de tratamiento— enfrentan el escenario más costoso: la sanción máxima sin atenuantes.

Lo que un CDO debería revisar esta semana

Para un Chief Data Officer o Data Governance Manager, el incremento en el costo de las brechas no es una señal de alarma abstracta: es un argumento de negocio con número. El modelo de madurez CDMC (Cloud Data Management Capabilities) del EDM Council identifica en su capability 8 —Data Protection and Privacy— los controles mínimos que una organización debe operar para limitar su exposición ante un incidente. Los bancos y aseguradoras de la región que ya reportan bajo marcos regulatorios locales (como la Comunicación A 8073 del BCRA en Argentina o las circulares de la CNBV en México) tienen parte de esa infraestructura construida, aunque rara vez la han conectado formalmente con su programa de gobierno del dato.

• Auditar el inventario de datos sensibles: ¿existe un catálogo activo con clasificación por nivel de sensibilidad y con data owner asignado por dominio?
• Revisar los SLA de detección y notificación: la LGPD exige notificar a la ANPD en un plazo razonable; la AAIP argentina tiene criterios similares. ¿Cuánto tarda hoy la organización en saber qué fue comprometido?
• Mapear el data lineage de los activos más críticos: sin trazabilidad formal, la evaluación del impacto de una brecha es manual, lenta y costosa.
• Conectar el programa de DG con el equipo legal: las multas más altas en la región se explican, en parte, por la desconexión entre quienes gestionan datos y quienes gestionan el riesgo regulatorio.

El argumento para invertir en gobierno del dato solía ser la eficiencia operativa o la calidad analítica. Hoy, con los costos de brecha en máximos históricos para la región, el argumento más directo es la gestión del riesgo financiero y reputacional. Ese cambio de encuadre abre conversaciones en el C-suite que antes eran difíciles de sostener.

Cuando una brecha de datos cuesta más que el programa de gobierno que la hubiera prevenido, la discusión sobre prioridades presupuestarias debería ser, al menos, más sencilla.