En GalacticaIA llevamos más de 15 años trabajando con datos —en Telecom y Fintech, en varios países de Latinoamérica— y todavía nos pasa: decimos «gobierno de datos» y la mitad de la sala piensa en burocracia, comités y documentos que nadie va a leer. Es una lástima, porque detrás del nombre solemne se esconde una de las ideas más prácticas de toda la disciplina de datos.

En este artículo queremos explicarlo como nos habría gustado que nos lo explicaran cuando empezábamos: sin jerga, con ejemplos concretos y sin intentar venderte nada.

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.

Lo que el gobierno de datos NO es

Buena parte del rechazo que genera el término viene de malas implementaciones. Vale la pena separar la idea de sus caricaturas:

No es un comité que aprueba todo. Si cada cambio necesita la firma de un consejo, eso no es gobierno: es un cuello de botella con otro nombre. El buen gobierno asigna responsabilidades claras justamente para no tener que reunirse por todo.
No es un proyecto con fecha de fin. El gobierno de datos no se «termina» en un trimestre, igual que no se «termina» la seguridad informática. Es una práctica continua que madura con la organización.
No es solo para bancos. Cualquier empresa que tome decisiones con datos —es decir, cualquier empresa— sufre los problemas de arriba. El tamaño solo cambia la escala del dolor.

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 en la reunión la cuestiona. Si un agente de IA la usa, la repite mil veces con total confianza. La IA no arregla el desorden de los datos: lo amplifica. Por eso las organizaciones que hoy avanzan más rápido con IA son, sin excepción, las que hicieron primero el trabajo aburrido de ponerse de acuerdo sobre sus datos.

¿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 no es el departamento del «no». Es la infraestructura de confianza que hace posible todo lo demás: reportes que nadie discute, análisis que llegan a tiempo y una IA que no inventa.

¿Quieres saber en qué punto está tu organización? Una evaluación de madurez de datos es la forma más rápida y de menor compromiso de averiguarlo.

¿Qué es el gobierno de datos? (explicado sin jerga)