Si dos áreas utilizan definiciones distintas para el mismo indicador, ¿quién tiene autoridad para decidir cuál es la correcta?
Para mí, esa pregunta revela más sobre la madurez del gobierno de datos que la cantidad de políticas, comités o herramientas implementadas.
Porque el problema aparece cuando una discrepancia importante termina en una cadena de correos, reuniones y escalamiento hasta encontrar a alguien capaz de resolverla.
No necesariamente faltan roles. Faltan derechos de decisión claros.
Data Owner vs. Data Steward: el problema no es el cargo, es la autoridad
La distinción básica es simple.
El Data Owner responde por las decisiones asociadas a un dominio de datos.
El Data Steward convierte esas decisiones en definiciones, reglas de calidad, metadatos y seguimiento operativo.
El Data Custodian o equipo técnico implementa los controles, accesos y procesos necesarios para que esas reglas funcionen en producción.
Y una función transversal de gobierno debería intervenir cuando la decisión supera un dominio y afecta a otras áreas, riesgos o políticas corporativas.
El problema empieza cuando esos nombres existen en un organigrama, pero nadie puede responder con claridad qué puede aprobar cada uno.
Por eso, cuando diseño un modelo operativo de gobierno de datos, prefiero partir por decisiones reales, no por cargos.
¿Quién debería decidir qué en un modelo de gobierno de datos?
Un ejercicio sencillo permite detectar zonas grises rápidamente.
La matriz no es el objetivo.
El valor está en eliminar una frase que todavía aparece demasiado en organizaciones complejas:
“No sé quién tiene que aprobar esto.”
Cuando esa respuesta no está clara, la decisión termina cayendo sobre quien necesita hacer avanzar el proyecto.
Y muchas veces ese alguien está en Tecnología.
Cuando una decisión de negocio termina escondida en el código
Pensemos en una métrica ejecutiva con dos definiciones diferentes.
El equipo necesita construirla. Ambas versiones se utilizan. Nadie tiene autoridad claramente establecida para decidir cuál debe prevalecer.
Pero el dashboard o pipeline tiene fecha de entrega.
Alguien termina escogiendo.
El riesgo no es que Tecnología participe. El riesgo es que una decisión de negocio quede incorporada dentro del código y con el tiempo pase a ser aceptada como la definición oficial sin haber sido realmente gobernada.
Ahí es donde capacidades como catálogo, calidad, linaje y controles centralizados empiezan a tener valor.
Por ejemplo, ACL trabaja gobierno técnico sobre Databricks mediante Unity Catalog, con políticas consistentes de acceso, linaje y compliance. Pero la plataforma puede ejecutar y hacer trazable una decisión; no puede determinar por sí sola cuál debería ser la definición de negocio correcta.
Qué cambia cuando el ownership deja de ser nominal
DataArt enfrentó un problema muy parecido en una firma financiera que operaba con múltiples versiones, ligeramente diferentes, de cálculos clave.
El trabajo no se limitó a modernizar la plataforma. DataArt implementó mecanismos de gobierno para establecer ownership de los elementos de datos, linaje y accountability.
El resultado fue una reducción de discrepancias entre cálculos, procesos más consistentes y trazables, menor tiempo para descubrir e integrar información y una mayor confianza del negocio en sus datos.
Para mí, la lección es bastante concreta:
una arquitectura puede consolidar información; no puede decidir quién responde por su significado.
Ese ownership debe diseñarse.
Gobernar no significa centralizar todas las decisiones
El problema contrario también existe.
Cuando cada decisión debe pasar por un equipo central de datos, el gobierno puede convertirse en otro cuello de botella.
En una transformación para un neobanco británico, DataArt ayudó a evolucionar desde un modelo centralizado hacia Data Mesh y estableció ownership claro de los data products dentro de cada equipo de dominio.
Eso permitió que los equipos administraran y utilizaran sus datos con mayor autonomía, reduciendo dependencias del área central, pero manteniendo prioridades como gobierno, privacidad, seguridad y controles de acceso.
La conclusión que extraigo de ese caso es importante para organizaciones que necesitan escalar:
centralizar estándares no obliga a centralizar todas las decisiones.
Un modelo operativo puede distribuirlas:
Dominio: el Data Owner resuelve definiciones, prioridades y reglas dentro de su ámbito.
Operación: el Data Steward mantiene calidad, metadatos, excepciones y seguimiento.
Transversal: gobierno central interviene cuando existen conflictos entre dominios, regulación o políticas que afectan a toda la organización.
El objetivo es que las decisiones se resuelvan en el nivel correcto sin convertir al gobierno central en un cuello de botella.
Cómo detectar una zona gris en menos de una hora
Yo tomaría un dato realmente importante para el negocio: cliente, producto, margen, riesgo, inventario o una métrica que llegue al comité ejecutivo.
Y preguntaría:
- ¿Quién puede modificar su definición?
- ¿Quién responde cuando su calidad cae?
- ¿Quién implementa y monitorea los controles?
- ¿Quién tiene la última palabra si dos áreas discrepan?
Si para responder hay que buscar un correo antiguo, preguntarle a una persona específica o convocar una reunión para determinar quién decide, el modelo todavía depende demasiado de conocimiento informal.
Y esa debilidad se vuelve más visible cuando la organización intenta escalar analytics, automatización o IA.
Cómo lo aterrizo desde ACL Data Practice
Desde ACL powered by DataArt, mi punto de partida no sería crear más documentación.
Primero buscaría dónde existen decisiones sin dueño, definiciones en conflicto y controles que todavía dependen de coordinación manual.
Desde ahí puedo estructurar un modelo de Data Owner y Data Steward por dominio y conectarlo con capacidades como catálogo, linaje, calidad y gobierno técnico. ACL Data Practice contempla precisamente un Data Owner · Steward framework, junto con catálogo, linaje, calidad y Unity Catalog dentro de su propuesta de gobernanza.
Y no siempre es necesario comenzar con un programa corporativo de varios meses.
El modelo de Data Practice permite partir con un diagnóstico de gobernanza de 2–4 semanas, identificar brechas y construir un roadmap priorizado. Desde ahí se puede avanzar a una implementación end-to-end y, cuando tiene sentido, sostener la operación mediante un esquema fraccionado con perfiles como Governance Officer como servicio.
Eso convierte una conversación abstracta sobre Data Governance en preguntas mucho más útiles:
¿Dónde están hoy nuestras decisiones sin dueño?
¿Qué definiciones críticas siguen dependiendo de acuerdos informales?
¿Tenemos los mecanismos técnicos para demostrar que las reglas acordadas realmente se cumplen?
Un buen gobierno de datos debería reducir zonas grises
No mediría la madurez por la cantidad de políticas aprobadas.
La mediría por lo que ocurre cuando aparece un problema real.
Si una métrica tiene dos definiciones, ¿quién decide?
Si la calidad cae, ¿quién responde?
Si una regla cambia, ¿quién la lleva a producción?
Si dos dominios entran en conflicto, ¿quién tiene la última palabra?
Cuando esas respuestas son claras, el gobierno deja de ser una capa administrativa y pasa a cumplir una función mucho más relevante:
hacer que las decisiones sobre datos sean más rápidas, trazables y ejecutables.
Si hoy esas respuestas todavía presentan zonas grises, el punto de partida puede ser mucho más acotado que una transformación completa: elegir un dominio crítico, mapear sus decisiones y definir responsables reales.
👉 Conoce cómo trabajamos datos, arquitectura, gobernanza e IA en ACL powered by DataArt.
Preguntas frecuentes sobre los roles del gobierno de datos
¿Cuál es la diferencia entre Data Owner y Data Steward?
El Data Owner tiene autoridad sobre las decisiones asociadas al dato dentro de un dominio. El Data Steward lleva esas decisiones a la operación, manteniendo definiciones, reglas de calidad, metadatos y seguimiento.
¿El Data Owner debe pertenecer a TI?
No necesariamente. Cuando el dato representa una definición de negocio, el ownership debería estar en el área que tiene autoridad sobre ese dominio. Tecnología puede custodiar e implementar técnicamente los datos sin ser quien determine su significado.
¿Para qué sirve una matriz RACI en gobierno de datos?
Sirve para hacer explícito quién decide, quién ejecuta, quién participa y quién debe ser informado frente a situaciones concretas. Su valor está en eliminar zonas grises, no simplemente en documentar cargos.
