Un número creciente de organizaciones está abandonando el enfoque policial del gobierno de datos —basado en restricciones, aprobaciones y comités de control— para adoptar un modelo orientado a capacidades: habilitar a los equipos para trabajar con datos de forma autónoma, con calidad y con contexto. El programa de data governance de York University en Canadá es uno de los casos más citados recientemente como referencia de este cambio de paradigma, y sus principios tienen aplicación directa para los CDOs de la región.
Durante años, el gobierno de datos fue sinónimo de fricción. Políticas que nadie leía, flujos de aprobación que demoraban semanas, y equipos de negocio que terminaban creando sus propias sombras de datos para esquivar los procesos formales. El resultado fue paradójico: más governance en el papel, menos calidad real en la práctica. El enfoque de York University invierte esa lógica: en lugar de preguntar “¿quién tiene permiso para tocar este dato?”, pregunta “¿qué capacidad necesita este equipo para usarlo bien?”
Capabilities primero: qué significa en la práctica
El modelo de capacidades en data governance no es nuevo en la teoría —el DAMA-DMBOK lo contempla dentro de su área de Data Governance como habilitador de las demás disciplinas—, pero su adopción práctica ha sido lenta. La diferencia clave está en el punto de partida: en lugar de construir una estructura de control y luego intentar que el negocio la adopte, se identifican primero las decisiones que los equipos necesitan tomar con datos, y se construye el andamiaje de governance para habilitarlas. Esto incluye definir data ownership operativo (no nominal), instrumentar data lineage —la trazabilidad del origen, transformación y uso de un dato— y asegurar que los data stewards, los custodios funcionales del dato en cada dominio, tengan herramientas reales y no solo responsabilidades en papel.
Bob Seiner, referente del enfoque Non-Invasive Data Governance, ha argumentado consistentemente que la resistencia al gobierno de datos no es cultural sino de diseño: cuando governance se percibe como burocracia adicional, fracasa. Cuando se percibe como soporte para hacer el trabajo mejor, se adopta. El caso de York ilustra exactamente eso: los equipos de datos comenzaron a comprometerse con el programa cuando vieron que les resolvía problemas concretos —como saber quién es el dueño de una definición de negocio o cómo rastrear por qué un reporte y otro arrojan cifras distintas.
El lunes a la mañana: qué hace un CDO con esto
El modelo de capacidades exige una revisión honesta del estado actual del programa de governance. Una forma concreta de empezar es mapear las decisiones de datos más frecuentes en los dominios críticos —finanzas, clientes, operaciones— e identificar dónde el proceso actual agrega latencia sin agregar valor. Si un equipo de analítica tarda más en obtener acceso a un dataset que en analizarlo, hay un problema de diseño, no de cultura. Los indicadores a revisar incluyen: tiempo promedio de resolución de un data issue, cobertura de data ownership documentado sobre activos críticos, y porcentaje de datasets con lineage instrumentado en el catálogo.
- Auditar qué porcentaje de los data stewards designados tienen capacidad real de decisión sobre sus dominios versus un rol meramente formal.
- Revisar si el catálogo de datos corporativo es consultado activamente o solo se actualiza para cumplir con auditorías internas.
- Identificar los tres flujos de aprobación de datos con mayor tiempo de ciclo y evaluar si pueden rediseñarse como habilitación en lugar de control.
- Alinear el roadmap de governance con los OKRs de las áreas de negocio, no con los del equipo de TI.
El contexto LATAM: entre el compliance y la madurez
En América Latina, el gobierno de datos enfrenta una tensión adicional: muchos programas nacieron como respuesta a requisitos regulatorios —la Resolución 4793 de la Superintendencia Financiera de Colombia, la Comunicación A 8073 del BCRA en Argentina, o las exigencias de la LGPD en Brasil para mapeo de datos personales— y quedaron atrapados en una lógica de compliance reactivo. Eso es governance para el regulador, no governance para el negocio. El riesgo es construir capacidades de reporte hacia afuera mientras los equipos internos siguen operando con hojas de cálculo sin linaje y definiciones de negocio inconsistentes entre áreas.
El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), ofrece un camino para cerrar esa brecha: sus 14 capabilities permiten evaluar el nivel de madurez de forma objetiva y priorizar inversiones. Varios bancos de la región ya operan con prácticas equivalentes a las capabilities 7 y 8 del CDMC —gestión de calidad y clasificación de datos— impulsados por exigencias regulatorias, pero sin la certificación formal ni la articulación de un programa cohesivo. Formalizar eso es, precisamente, el tipo de quick win que un CDO puede mostrar en el corto plazo.
El riesgo de confundir madurez con complejidad
Uno de los errores más comunes al escalar un programa de governance es agregar capas de proceso bajo la suposición de que más estructura equivale a más madurez. El modelo de capacidades invierte esa ecuación: mide la madurez por el impacto habilitado, no por la cantidad de políticas aprobadas o comités activos. Un programa con tres políticas claras, data ownership real y un catálogo activo genera más valor que uno con veinte políticas que nadie aplica. La pregunta que debería guiar cada decisión de diseño es simple: ¿esto le facilita o le complica la vida al equipo que trabaja con el dato?
El governance que no habilita termina siendo eludido — y los datos que no tienen dueño real no tienen calidad real.
Deja un comentario