Gobierno de datos: acuerdos que sostienen decisiones

El término «gobierno de datos» suele asociarse con comités y documentos. Su función real es mucho más concreta: establecer acuerdos que permitan saber qué significa un dato, quién responde por él, qué tan confiable es y quién puede usarlo.

Empecemos por una escena que quizá reconozcas

Imagina una tabla llamada customers en el data warehouse de tu empresa. La usan todos: finanzas para calcular ingresos, marketing para lanzar campañas, el equipo de BI para los dashboards que mira la dirección cada lunes. Un día, alguien nuevo hace una pregunta básica: ¿quién es el dueño de esta tabla?

$ describe table customers

owner:        (sin asignar)
description:  (vacía)
last_updated: hace 11 meses
used_by:      47 dashboards, 12 pipelines

Una tabla crítica sin dueño, sin descripción y con 47 dashboards dependiendo de ella. Más común de lo que parece.

Silencio. La persona que la creó ya no trabaja en la empresa. Nadie sabe con certeza si status = 'A' significa «activo» o «archivado». Finanzas y marketing reportan cifras distintas de clientes activos cada mes, y cada comité de resultados empieza con veinte minutos de discusión sobre cuál es el número verdadero. Hemos visto esta escena, con pequeñas variaciones, en operadoras de telecomunicaciones, bancos y startups. No es un problema de tecnología —todas esas empresas tenían herramientas modernas—. Es un problema de acuerdos.

La definición, sin jerga

El gobierno de datos es, en esencia, ponerse de acuerdo sobre los datos y dejar ese acuerdo por escrito. Cuatro acuerdos, concretamente:

• Quién responde por cada dato. Toda tabla, reporte o métrica importante tiene un dueño con nombre y apellido. Si customers se rompe, no se busca un culpable: se sabe a quién preguntar.
• Qué significa cada cosa. «Cliente activo» tiene una sola definición oficial, escrita y compartida — no cinco versiones que viven en la cabeza de cinco personas.
• Qué tan confiable es. Sabes si los datos llegaron completos, a tiempo y sin duplicados, antes de que un dashboard roto te lo haga saber delante de la dirección.
• Quién puede usar qué. Los datos personales están identificados y protegidos; no cualquier persona con acceso al warehouse puede exportar los teléfonos de tus clientes.

Las definiciones formales —como la del framework DAMA-DMBOK, el cuerpo de conocimiento clásico de la disciplina— hablan de «ejercicio de autoridad y control sobre la gestión de los activos de datos». Es correcto, pero la esencia es la de arriba: acuerdos explícitos en lugar de conocimiento tribal.

¿Qué pasa cuando no existe?

La ausencia de gobierno de datos casi nunca se siente como una catástrofe. Se siente como una fricción permanente que todos terminan normalizando:

• El reporte del lunes amanece roto. Alguien renombró una columna en el sistema fuente el viernes por la tarde. Nadie sabía qué dependía de ella, así que nadie avisó. Se descubre cuando la dirección pregunta por qué el dashboard está vacío.
• Dos áreas, dos verdades. Finanzas dice que hay 1.2 millones de clientes activos; marketing dice 1.5. Ambos tienen razón según su propia definición — y esa es exactamente la falla.
• Los análisis tardan semanas en vez de días. La mayor parte del tiempo de un analista se va en encontrar los datos, entender qué significan y verificar si son confiables. Solo una fracción se dedica a analizarlos.
• Miedo a tocar nada. Nadie borra ni modifica tablas viejas «por si acaso algo las usa». El warehouse acumula capas de sedimento, y cada año todo es un poco más lento y más caro.
• Riesgo regulatorio silencioso. Datos personales copiados en seis tablas distintas, sin que nadie sepa cuáles ni quién accede. Con las leyes de protección de datos que avanzan en toda Latinoamérica, esto ya no es un detalle técnico: es un riesgo legal.

Cómo reconocer una práctica útil de gobierno

Una práctica útil se distingue por cómo asigna decisiones y reduce fricción operativa:

• Responsabilidad cerca del dato. Los dueños resuelven dentro de un marco claro; el comité arbitra excepciones, no cada cambio.
• Operación continua. Las definiciones, controles y responsables se revisan cuando cambian los sistemas o el negocio.
• Alcance proporcional. Se comienza por las decisiones y activos críticos, sin intentar gobernar todo al mismo tiempo.

Por qué importa más que nunca

Durante años, el costo de no tener gobierno de datos fue tolerable: reportes lentos, discusiones de números, algún susto regulatorio. La inteligencia artificial cambió esa ecuación. Un modelo de IA entrenado sobre datos sin definición, sin dueño y sin control de calidad no produce errores tímidos: produce respuestas seguras de sí mismas y equivocadas, a escala, frente a clientes.

Si un analista humano usa una cifra dudosa, alguien puede cuestionarla en la reunión. Si un agente de IA incorpora esa cifra a un flujo automatizado, el error puede propagarse antes de ser revisado. La IA no corrige por sí sola el desorden de los datos. Por eso una iniciativa de IA necesita definiciones, procedencia y controles sobre los datos que utiliza.

¿Por dónde se empieza?

No se empieza creando un comité ni comprando una herramienta. Se empieza pequeño y concreto:

• Inventaría lo crítico. No todo el warehouse: las 20 o 50 tablas y los 10 reportes de los que realmente vive el negocio.
• Asigna dueños. Una persona por activo crítico. No un área, no un equipo: una persona.
• Define las métricas clave por escrito. Qué es un «cliente activo», qué es «ingreso», desde cuándo y con qué excepciones.
• Mide la calidad de lo crítico. Reglas simples al inicio: ¿llegaron los datos de hoy?, ¿hay duplicados?, ¿hay nulos donde no debería haberlos?

Estos cuatro pasos apuntan a tres capacidades que toda práctica de gobierno termina necesitando: un catálogo de datos, lineage (el mapa de dependencias) y calidad de datos. De esos tres pilares hablamos en detalle en el siguiente artículo de esta serie.

El gobierno de datos convierte conocimiento implícito en responsabilidades y controles que la organización puede operar.

Si necesitas definir ownership, métricas, calidad o un operating model, cuéntanos tu caso. Si todavía no sabes dónde está la brecha, el autodiagnóstico de madurez puede ayudarte a ubicarla.