Es habitual ver empresas con un framework de gobierno de datos bien diseñado en un documento, un catálogo comprado, roles definidos en un organigrama — y prácticamente nadie usándolo seis meses después. El problema casi nunca es técnico. Es que montar un programa de gobierno es un cambio organizacional como cualquier otro, y como cualquier otro, requiere gestión del cambio explícita, no solo un buen diseño de proceso.
Dos modelos que sí sirven, aplicados a gobierno de datos
No hace falta inventar un modelo propio de adopción para gobierno de datos: los dos modelos de gestión del cambio más usados en el mundo corporativo se aplican directamente.
ADKAR (Prosci), aplicado a Data/AI Governance
| Fase ADKAR | Qué significa | Acción concreta en gobierno de datos |
|---|---|---|
| Awareness | Entender por qué el cambio es necesario | Explicar el problema real (un incidente, una multa evitable, una decisión mal tomada por dato erróneo), no solo "hay que cumplir el AI Act" |
| Desire | Querer participar y apoyarlo | Mostrar qué gana cada equipo, no solo qué se le exige — menos tiempo buscando datos, menos retrabajo por errores |
| Knowledge | Saber cómo hacerlo | Formación práctica y corta, no un manual de 80 páginas que nadie lee |
| Ability | Poder aplicarlo de verdad | Plantillas y herramientas ya construidas, no pedir que cada equipo invente su propio proceso |
| Reinforcement | Que el cambio no se revierta | KPIs visibles y revisión periódica en el comité de gobernanza, no una iniciativa que se lanza y se olvida |
Kotter, para el arranque del programa
El modelo de 8 pasos de John Kotter encaja especialmente bien en la fase de lanzamiento, cuando el programa todavía no tiene tracción: crear sentido de urgencia, formar una coalición con poder de decisión real (no solo el equipo de datos), construir una visión clara, comunicarla de forma constante, eliminar obstáculos que bloquean a quien quiere adoptar el cambio, generar victorias visibles a corto plazo, consolidar esas victorias para seguir avanzando, y anclar el nuevo comportamiento en la cultura antes de dar el programa por "terminado".
Errores de adopción más comunes
- Mandato desde arriba sin explicación — un email de dirección diciendo "a partir de ahora hay que documentar en el catálogo" sin contexto genera cumplimiento superficial, no adopción real.
- Tratarlo como un proyecto solo de IT o del equipo de datos — el gobierno de datos afecta a cómo trabaja marketing, ventas, operaciones; si esos equipos no participan en el diseño, no lo van a adoptar.
- No mostrar ningún resultado visible en los primeros 90 días — sin una victoria temprana y concreta, el apoyo interno se erosiona antes de que el programa tenga oportunidad de madurar.
- Confundir "tener el proceso documentado" con "tener adopción" — un procedimiento que existe en un documento pero que nadie sigue en la práctica no es gobierno de datos, es papeleo.
Cómo medir si la adopción está funcionando
La adopción no se mide con "¿hicimos el kickoff?" — se mide con indicadores de uso real:
- % de sistemas/procesos nuevos que pasan por el proceso de gobierno desde el primer día, no retroactivamente.
- % de equipos que usan el catálogo o las plantillas sin que alguien se lo tenga que recordar.
- Tiempo medio de respuesta cuando alguien pregunta "¿podemos usar este dato para esto?" — si tarda semanas, el proceso no está integrado en el día a día.
- Participación real en el comité de gobernanza — asistencia, decisiones tomadas, no solo la existencia del comité en el organigrama.
Si el programa ya tiene patrocinio de dirección pero le falta el órgano que sostenga la fase de refuerzo, cómo crear un comité de gobernanza desde cero cubre exactamente eso — quién debe estar en la sala y con qué cadencia reunirse.