El primer error al implementar un gobierno de datos suele ocurrir antes de seleccionar una herramienta o definir roles: comenzar sin acordar qué problema de negocio justifica la iniciativa.
Cuando el objetivo es simplemente “gobernar los datos de la organización”, el alcance puede crecer durante meses sin reducir un riesgo, eliminar una ineficiencia o mejorar una decisión concreta.
El punto de partida debe ser una brecha observable: conciliaciones que retrasan un cierre, indicadores con definiciones distintas, incidentes sin responsable o información crítica cuyo origen no puede reconstruirse.
A partir de ahí, la implementación debe resolver tres preguntas: quién decide, qué se controla y cómo se medirá el resultado.
Para profundizar en conceptos y componentes, puedes revisar también nuestra guía sobre gobierno de datos. Aquí nos concentraremos en cómo llevarlo a la práctica.
Antes de implementar: tres acuerdos ejecutivos
Qué problema justifica la inversión. “No tenemos gobierno de datos” no es todavía un caso de negocio. Que dos áreas utilicen criterios distintos para calcular un indicador y deban conciliarlo antes de cada cierre sí permite identificar un proceso afectado, un costo y una línea base.
Quién tiene autoridad. El patrocinador ejecutivo debe tener capacidad de incidir en el resultado y resolver conflictos entre áreas. Si las decisiones continúan dependiendo de negociaciones informales, sumar un comité difícilmente cambiará la operación.
Dónde comenzar. El primer alcance debe tener impacto visible y límites claros. Puede ser un dominio —clientes, productos o proveedores— o un proceso como el cierre financiero, la gestión de siniestros o un reporte regulatorio. Diseñar con una visión transversal no implica desplegar el modelo en toda la organización desde el primer día.
Seis fases para implementar un gobierno de datos
%2011.10.44%E2%80%AFa.m..png)
Fase 1: convertir el problema en un caso de negocio
La brecha elegida necesita una línea base.
Si existen conciliaciones manuales, por ejemplo, conviene conocer su frecuencia, cuánto tiempo consumen y qué procesos retrasan. Si el problema está en la calidad, interesa saber cuántos incidentes se repiten y qué consecuencias generan.
Sin esa referencia, el programa puede aumentar políticas, reuniones o activos catalogados sin demostrar impacto.
Fase 2: diagnosticar con evidencia
Un diagnóstico no debería limitarse a entrevistar a personas o comprobar que existen políticas. Debe contrastar lo que la organización declara con lo que puede demostrar: quién toma las decisiones, qué controles funcionan, cómo se resuelven los incidentes y qué trazabilidad existe sobre los datos críticos.
El modelo DCAM v3 de EDM Association puede utilizarse como referencia para estructurar una evaluación de este tipo. Su valor está en ordenar capacidades y evidencia, no en convertir la aplicación completa del marco en un objetivo por sí mismo.
Una implementación documentada por DataArt muestra esta secuencia. Durante el análisis de una arquitectura de reporting se detectaron distintas versiones de cálculos críticos. La solución evolucionó posteriormente hacia un diseño basado en metadatos, con responsabilidades definidas sobre los datos y linaje trazable.
La arquitectura respondió al problema identificado, no al revés.
Fase 3: priorizar qué datos gobernar primero
No todos los datos requieren el mismo nivel de control. Conviene comenzar por aquellos que intervienen en decisiones relevantes, procesos críticos, obligaciones regulatorias o modelos analíticos con impacto en el negocio.
Para ese conjunto debe quedar claro qué significa cada dato, cuál es su fuente autorizada, quién responde por él y qué reglas deben aplicarse.
En Chile existe, además, un plazo concreto de preparación. La Ley 21.719, que modifica el régimen de protección de datos personales, entra en vigencia el 1 de diciembre de 2026.
La ley no prescribe un modelo de gobierno de datos, pero refuerza la necesidad operativa de identificar información personal, responsables y evidencia sobre su tratamiento. Las obligaciones específicas deben validarse jurídicamente.
Fase 4: definir quién decide
El modelo operativo debe establecer quién decide, quién ejecuta y cómo se escala una excepción. Las denominaciones pueden variar entre organizaciones; la autoridad, no.
Un Data Owner que no puede resolver una definición, priorizar un incidente o exigir una corrección es un nombre en el organigrama, no un mecanismo de gobierno.
Algo similar ocurre con comités que pueden revisar un problema, pero no resolverlo. El diseño debe asignar suficiente autoridad al negocio y establecer qué decisiones corresponden a tecnología, seguridad, privacidad, riesgo u otras funciones.
No todas las responsabilidades requieren dedicación exclusiva. Sí necesitan mandato, capacidad y continuidad.
Fase 5: convertir las reglas en controles
Una política describe qué debería ocurrir. Un control permite prevenir, detectar o corregir una desviación.
Una regla de calidad, por ejemplo, solo se vuelve operativa cuando establece qué se controla, qué nivel se acepta, quién responde y qué ocurre frente a una excepción.
Con esas decisiones claras, la organización puede determinar qué capacidades de su arquitectura actual son suficientes y dónde necesita automatización o nuevas herramientas.
Automatizar una decisión ambigua no elimina la inconsistencia: permite que se propague con mayor velocidad.
La regulación sectorial ofrece ejemplos de esta lógica. Como referencia, la NCG N.º 569 de la Comisión para el Mercado Financiero establece para determinados participantes del Sistema de Finanzas Abiertas pruebas de calidad y acciones frente a deficiencias significativas. Es un ejemplo concreto de cómo un criterio debe traducirse en controles, responsables y evidencia.
Fase 6: medir antes de ampliar el alcance
Las métricas deben volver al problema que justificó la inversión.
Si el objetivo era reducir inconsistencias entre reportes, la cantidad de tablas catalogadas dice poco sobre el resultado. Es más relevante saber si disminuyeron las conciliaciones, cuánto tardan en resolverse los incidentes o si los controles redujeron la recurrencia del problema.
%2011.12.07%E2%80%AFa.m..png)
Tres errores que encarecen la implementación
Tecnología antes que decisiones. Una plataforma puede automatizar controles o representar linaje, pero no decidir quién tiene autoridad sobre un dato.
Alcance empresarial desde el primer día. Diseñar con una perspectiva transversal no obliga a intervenir simultáneamente todos los dominios. Un alcance acotado permite demostrar valor antes de ampliar el modelo.
Responsabilidades sin mandato. Nombrar Data Owners o constituir comités aporta poco si las decisiones continúan dependiendo de acuerdos informales. Cada responsabilidad necesita autoridad y una vía clara de escalamiento.
El criterio ejecutivo: demostrar que algo cambió
Una implementación madura no se reconoce por la cantidad de documentos que produce.
Se reconoce porque la organización puede demostrar qué definición utilizó, quién tomó una decisión, qué control se ejecutó y si el problema que originó la iniciativa comenzó a mejorar.
La pregunta, entonces, es simple:
¿Qué decisiones sobre nuestros datos todavía no podemos explicar, ejecutar o demostrar?
Responderla permite dimensionar la brecha y priorizar un primer alcance sin sobredimensionar la iniciativa.
Desde ACL Data Practice abordamos este desafío conectando diagnóstico, implementación y operación continua, junto con capacidades de gobierno, calidad, linaje y roles especializados.
Una evaluación inicial debería permitir responder tres preguntas concretas: qué brechas requieren intervención, qué dominio conviene abordar primero y qué resultado debe medirse.
Evaluemos las brechas de tu gobierno de datos
Preguntas frecuentes sobre implementación de gobierno de datos
¿Es necesario implementar gobierno de datos en toda la organización al mismo tiempo?
No. El modelo puede diseñarse con una perspectiva transversal y desplegarse gradualmente. Comenzar por un dominio o proceso relevante permite comprobar si las responsabilidades, controles y métricas funcionan antes de ampliar el alcance.
¿Es necesario comprar una plataforma para comenzar?
No necesariamente. El punto de partida es identificar el problema, definir responsabilidades y establecer qué decisiones requieren control. El diagnóstico también debe revisar la arquitectura existente para determinar qué capacidades pueden reutilizarse y dónde realmente se necesita nueva tecnología.
¿Cómo saber si un gobierno de datos está funcionando?
El principal indicador es que comience a mejorar el problema que justificó la iniciativa. Dependiendo del caso, esto puede observarse en menos conciliaciones y reprocesos, menor recurrencia de incidentes, mejores tiempos de resolución, mayor trazabilidad o menos excepciones sin responsable.
