Gobierno del dato: el mínimo viable que sí funciona en una empresa mediana

El gobierno del dato tiene un problema de marca. Cuando alguien lo propone en un comité de dirección, medio equipo escucha «comités», «políticas» y «un año de trabajo antes de ver nada». Y no les falta razón: la mayoría de iniciativas de gobernanza de datos que se lanzan en empresas medianas mueren por sobrepeso, con un catálogo a medio llenar y un documento de 60 páginas que nadie abre desde el kickoff.

Pero el problema que intenta resolver es muy real. Se nota el día que dos informes dan cifras distintas de la misma venta. O cuando nadie sabe si el campo `cliente_activo` significa que compró este año o que tiene contrato vigente. O cuando llega una petición de supresión de un cliente y hacen falta tres semanas para saber en cuántos sistemas está. Esta guía va de eso: cómo montar el mínimo de gobierno del dato que resuelve esos casos, sin construir una burocracia que se cae sola.

¿Qué es el gobierno del dato y por qué se confunde con burocracia?

El gobierno del dato es el conjunto de decisiones sobre quién responde de qué dato, qué significa cada dato y quién puede hacer qué con él. Nada más. Ni herramienta, ni departamento, ni certificación.

La confusión con la burocracia viene de cómo se suele vender. La versión de manual arranca con un marco de referencia completo —dominios, políticas, comités de tres niveles, matrices RACI— y deja el valor para el final. En una empresa de 50 a 500 personas eso no aguanta: nadie tiene una jornada libre a la semana para presidir un comité de calidad del dato.

La versión que sí funciona es la contraria. Se empieza por los tres o cuatro datos que ya están causando dolor, se responde a las tres preguntas de arriba solo para esos, y se amplía cuando el mecanismo demuestra que sirve. Gobernanza de datos como práctica, no como proyecto con fecha de fin.

Si tu documento de gobierno del dato tiene más páginas que datos gobernados, has empezado por el sitio equivocado.

Un ejemplo concreto. Una distribuidora tenía tres definiciones de «pedido servido»: la de logística (salió del almacén), la de finanzas (se facturó) y la de comercial (el cliente confirmó recepción). Ninguna estaba mal. El problema era que los tres informes se llamaban igual y se comparaban en la misma reunión. Gobernar ese dato fue elegir una definición canónica, renombrar las otras dos y dejarlo escrito en un sitio que la gente encontrase. Dos semanas, no un año.

¿Por qué fracasan la mayoría de proyectos de gobernanza de datos?

Los patrones se repiten con una regularidad casi aburrida:

• Empezar por el catálogo completo. Inventariar 4.000 campos antes de decidir nada útil. Cuando se termina, la mitad ya ha cambiado.
• Comprar la herramienta primero. Una plataforma de catalogación es un contenedor. Si no hay nadie que responda de los datos, el contenedor se llena de metadatos automáticos que nadie ha validado.
• Nombrar responsables sin descargarles de trabajo. «Ahora además eres data owner» no es un rol, es una línea más en la firma del correo.
• Separarlo del trabajo real. Si la gobernanza vive en un Confluence aparte y el trabajo pasa en el ERP y el almacén de datos, la gobernanza se queda desactualizada en un trimestre.
• No definir el criterio de éxito. Sin una métrica —tiempo de respuesta a una petición de acceso, número de informes con cifras discrepantes— es imposible saber si aquello va bien.

Hay un sexto, más silencioso: montar gobierno del dato porque «hace falta para la IA», sin ninguna aplicación concreta en el horizonte. Es la ruta corta al proyecto zombi. En por qué fracasan los pilotos de IA contamos el reverso del mismo problema: los pilotos que se estrellan contra datos que nadie había mirado antes.

¿Cuál es el mínimo viable de gobierno del dato?

Cuatro piezas. Ninguna necesita herramienta específica para arrancar; una hoja de cálculo y un repositorio bastan el primer trimestre.

1. Un inventario de dominios, no de campos. Entre seis y diez dominios: clientes, productos, pedidos, facturación, empleados, proveedores, y los que sean propios de tu negocio. Para cada uno: qué sistema es la fuente de verdad, quién responde, qué nivel de sensibilidad tiene. Media página por dominio.

2. Un glosario de las métricas que se discuten. No todas las métricas: las que aparecen en comité y las que alimentan decisiones. Cada entrada lleva definición en una frase, fórmula exacta, sistema de origen y quién la aprueba. Veinte o treinta entradas cubren el 90% de las discusiones.

3. Una matriz de accesos por rol. Quién ve qué, con qué justificación y quién aprueba una excepción. Aquí es donde el gobierno del dato se cruza con el RGPD, y donde conviene tener resuelto el trato a los datos personales antes de mover nada a entornos de análisis o a un modelo — el detalle está en anonimización de datos.

4. Un ciclo de revisión con fecha. Una hora al mes, cuatro personas, tres puntos: incidencias de calidad detectadas, cambios en definiciones, peticiones de acceso pendientes. Si no cabe en una hora, el alcance es demasiado grande todavía.

Con eso ya se puede responder a las preguntas que hoy se quedan en el aire. Lo demás —linaje automático, calidad monitorizada, catálogo federado— llega después y solo si el volumen lo justifica.

¿Qué roles hacen falta de verdad?

Menos de los que dice el manual. En una empresa mediana estos cuatro cubren el terreno, y dos de ellos son a tiempo parcial:

| Rol | Quién suele serlo | Dedicación | De qué responde | |---|---|---|---| | Patrocinador | Dirección general o financiera | 2 h/mes | Que exista presupuesto y que las decisiones se cumplan | | Responsable de dominio | Quien ya usa ese dato a diario (jefe de logística, de facturación) | 2-4 h/mes | Definiciones, calidad y accesos de su dominio | | Referente técnico | Perfil de datos o IT | 20-30% | Fuente de verdad, integraciones, linaje, controles | | Responsable de privacidad | DPO o legal | Por demanda | Base jurídica, retención, derechos del interesado |

La trampa habitual es nombrar responsables de dominio en TI. El responsable tiene que ser quien sufre las consecuencias de que el dato esté mal, no quien administra la base de datos. Si el jefe de facturación no puede cerrar el mes por un maestro de clientes sucio, es él quien tiene que poder decidir cómo se limpia.

¿Cómo se implanta en 90 días sin parar el negocio?

Un calendario realista para una primera vuelta, asumiendo que nadie deja su trabajo para esto:

| Semanas | Qué se hace | Qué queda hecho | |---|---|---| | 1-2 | Entrevistas cortas con 6-8 personas: qué dato les hace perder tiempo | Lista priorizada de dolores reales | | 3-4 | Mapa de dominios y fuentes de verdad | Media página por dominio, con responsable nombrado | | 5-7 | Glosario de las 20-30 métricas de comité | Definiciones aprobadas y publicadas | | 8-9 | Matriz de accesos y revisión de datos personales | Quién ve qué, y qué hay que anonimizar | | 10-11 | Primer ciclo de calidad sobre un dominio | Reglas de validación y errores corregidos | | 12-13 | Comité de revisión y plan del siguiente trimestre | Rutina mensual funcionando |

Dos condiciones para que este calendario no sea ficción. La primera: elegir un solo dominio para la vuelta de calidad —normalmente clientes o productos, que es donde más duele— y no tocar los demás hasta el trimestre siguiente. La segunda: publicar el glosario donde la gente ya trabaja. Un enlace fijo en la herramienta de informes convierte el glosario en algo vivo; un PDF en una carpeta compartida lo mata.

¿Cómo se sabe si el gobierno del dato está funcionando?

Con señales observables, no con porcentajes de avance del proyecto:

• Discrepancias en comité. Cuántas veces al trimestre dos informes contradicen al otro sobre la misma cifra. Debe bajar.
• Tiempo de respuesta a una petición de acceso o supresión. De semanas a días.
• Tiempo de arranque de un análisis nuevo. Cuánto tarda alguien en encontrar el dato correcto sin preguntar a tres personas.
• Incidencias de calidad reabiertas. Si el mismo error de maestro vuelve cada mes, el arreglo fue cosmético.
• Peticiones de excepción de acceso. Muchas excepciones significan que la matriz de roles está mal diseñada, no que la gente sea indisciplinada.

Ninguna de estas métricas necesita instrumentación sofisticada. Se cuentan a mano en la revisión mensual, y esa fricción es sana: obliga a mirarlas.

¿Qué relación tiene el gobierno del dato con la IA?

Directa y poco romántica. Un modelo hereda la calidad, los sesgos y los problemas legales de los datos con los que se construye. Si no está claro qué significa un campo, el modelo aprenderá esa ambigüedad. Si nadie sabe de dónde salió el histórico, no hay forma de justificar una decisión automatizada ante un cliente o un regulador.

En la práctica, hay tres cosas del mínimo viable que se vuelven críticas en cuanto entra IA: saber qué datos personales hay en cada conjunto, saber quién autorizó su uso para ese fin, y poder reconstruir con qué versión de los datos se entrenó o se alimentó el sistema. Sin eso, cualquier despliegue serio se atasca en la revisión legal. Es la misma idea que desarrollamos en datos antes que IA: el orden no es un capricho metodológico, es lo que evita rehacer el trabajo.

Lo que no hay que hacer es usar la IA como excusa para inflar el alcance. Gobernar los cinco conjuntos de datos que va a tocar el primer caso de uso es suficiente para arrancar. Gobernar los cuarenta que quizá se toquen algún día es cómo se pierde el año.

Preguntas frecuentes

¿Cuánto cuesta implantar gobierno del dato en una empresa mediana?

El coste real no es de licencias, es de horas de las personas que ya conocen el negocio. Una primera vuelta como la descrita consume entre 150 y 250 horas repartidas en un trimestre, la mayoría en dedicaciones de 2-4 horas mensuales. La herramienta, si acaba haciendo falta, llega después y con un requisito claro.

¿Hace falta una herramienta de catálogo de datos?

No para empezar. Un glosario y un mapa de dominios funcionan en hoja de cálculo o en el wiki interno mientras hablemos de decenas de métricas y menos de diez dominios. La herramienta aporta cuando hay que automatizar linaje, controles de calidad recurrentes o accesos sobre muchas fuentes.

¿Gobierno del dato y gobernanza de datos son lo mismo?

Sí, son dos traducciones del mismo término inglés. En España se usan indistintamente; «gobierno del dato» es algo más común en entornos corporativos y «gobernanza de datos» en documentación técnica y académica. No hay diferencia de contenido.

¿Por dónde empiezo si mis datos están en cinco sistemas distintos que no se hablan?

Por decidir cuál es la fuente de verdad de cada dominio, antes de integrar nada. Integrar cinco sistemas sin haber decidido cuál manda solo produce cinco versiones sincronizadas del mismo desacuerdo. La decisión es de negocio, no técnica.

El gobierno del dato no se vende bien porque su resultado es la ausencia de problemas: reuniones donde nadie discute de qué cifra es la buena, análisis que arrancan en horas, peticiones legales que se resuelven sin drama. Si reconoces alguno de los dolores de esta guía en tu empresa y quieres saber por dónde empezar con tus datos concretos, la auditoría es un buen primer paso: sale de ahí un mapa de dominios, fuentes de verdad y prioridades. Y si prefieres contarlo antes en voz alta, hablemos.