Por Pablo Adrián Mlynkiewicz – http://www.datagovernancelatam.com
La brecha entre intención y realidad
Recibí una llamada de un director de compliance de un banco importante hace seis meses. Estaban en crisis. El BCRA les había notificado hallazgos sobre la Comunicación 7724. El banco había invertido casi 2 millones de pesos en un proyecto de «gobernanza de datos» durante el año anterior.
«¿Saben qué pasó?» me preguntó, con una mezcla de frustración y desconcierto. «Gastamos dinero, documentamos procesos, asignamos personas, implementamos un sistema… pero el BCRA encontró exactamente los mismos problemas que teníamos hace 12 meses.»
Le pregunté cuándo fue la última vez que alguien usó los procedimientos que documentaron.
«Honestamente,» contestó después de una pausa incómoda, «no sabría decirte.»
Ese banco es más común de lo que piensas. He auditado instituciones financieras que tienen carpetas completas de políticas de gobernanza de datos—hermosamente formateadas, estratégicamente construidas, regulatoriamente «correctas»—que nadie lee, nadie sigue, y que no cambiaron nada operativamente.
La gobernanza de datos no falla por deficiencia técnica. Falla porque es implementada como proyecto administrativo cuando debería ser implementada como transformación cultural.
El mapa de errores fatales
He visto programas de gobernanza de datos fracasar de maneras predecibles. Existen exactamente seis fallos que, si ocurren, garantizan que tu programa será superficial:
Error 1: Delegación sin empoderamiento
Este es el más común y el más destructivo.
El CEO dice: «Hagan gobernanza de datos.» La responsabilidad va a Data. Data crea un documento. El documento dice quién es responsable por qué. Pero «responsable por qué» no significa que esa persona tenga presupuesto, autoridad, o tiempo.
He encontrado bancos donde el propietario de datos asignado tiene una dedicación de «15% de su tiempo» mientras gestiona sus tareas operativas de tiempo completo. Obviamente, la gobernanza de datos ocupa el 5% restante.
La diferencia entre «responsabilidad designada» y «responsabilidad con capacidad de ejecución» es enorme. En el primer caso, tienes documentación. En el segundo, tienes cambio real.
He trabajado con instituciones donde designaron un «Chief Data Officer» con presupuesto, equipo dedicado, acceso directo a CEO. Esa misma institución, seis meses después, estaba eliminando datos innecesarios, reduciendo riesgos, respondiendo a reguladores con precisión.
La diferencia fue empoderamiento real, no solo título.
Error 2: Separación entre Negocio, Data y Tecnología
Muchos bancos crean un comité de «gobernanza de datos» que consiste en: un coordinador de Data Governance, alguien de Tecnología, un abogado, y alguien de compliance.
¿Sabes quién no está? Las personas que realmente usan datos. Los que dicen «necesito esta información para análisis de riesgo». Los que responden «sin estos datos de cliente no puedo hacer underwriting». Los que toman decisiones de retención.
La gobernanza de datos sin propietarios de negocio se vuelve ejercicio burocrático. Es «Data documenting what Data thinks business needs.»
Cuando integras propietarios de negocio desde el inicio—cuando el Vice Presidente de Retail, el head de Operaciones, el director de Riesgos están en la sala—todo cambia. De repente, las políticas de clasificación tienen sentido operativo. Las decisiones de retención responden a necesidades reales. Los ciclos de vida de datos son diseñados por quienes viven con sus consecuencias.
El gobierno efectivo es bimodal, siempre. Negocio que define, Data que impulsa, IT que habilita, todos responsables.
Error 3: Implementación como proyecto con fecha final
Aquí está el gran error conceptual: tratar gobernanza de datos como proyecto.
Los proyectos tienen inicio, medio, y fin. Gobernanza de datos no tiene fin. Porque tus datos no paran de cambiar. Tus necesidades de negocio evolucionan. La regulación se modifica. Los riesgos emergen.
He visto bancos que dijeron: «Vamos a implementar gobernanza en seis meses.» Estupendo plan. A los seis meses, entregaron resultados. Documentación hermosa. Políticas definidas. Clasificaciones establecidas.
Doce meses después, esas políticas eran obsoletas. Los datos de clientes nuevos no estaban clasificados. Los responsables asignados se habían ido de la institución. Las excepciones superaban las reglas.
Gobernanza de datos es programa permanente, no proyecto temporal.
Las instituciones que funcionan entienden esto. Tienen oficina de gobernanza de datos con presupuesto anual recurrente. Tienen procesos de revisión semestral de políticas. Tienen gobernanza de cambios integrada. Tienen capacitación continua.
Es costo permanente porque es beneficio permanente.
Error 4: Confundir documentación con implementación
Este error es sutil pero fundamental.
Muchos bancos creen que si documentan algo, existe. «Tenemos política de clasificación de datos» significa que existe un documento de política. No significa que los datos estén clasificados. «Tenemos proceso de eliminación» significa que existe un procedimiento en papel. No significa que alguien lo ejecute.
He auditado bancos que tenían:
- 47 políticas documentadas de gobernanza
- Un documento maestro de «Guía de Gobernanza de Datos»
- Roles asignados formalmente
- Un repositorio central de «Políticas Aprobadas»
Y sin embargo: datos sin clasificar, accesos sin autorizar, eliminaciones no ejecutadas, cambios sin gobernar.
La documentación es necesaria, pero es cimiento, no construcción.
La implementación real es: cambios en sistemas, cambios en procesos, cambios en comportamientos. Es automatización donde sea posible. Es capacitación donde sea necesario. Es auditoría para verificar cumplimiento. Es mejora iterativa cuando encuentras desvíos.
Un banco con una política implementada imperfectamente tiene más gobernanza real que un banco con 50 políticas documentadas pero no ejecutadas.
Error 5: Ausencia de auditoría y retroalimentación
He encontrado bancos que implementaron gobernanza de datos hace tres años y nunca han auditado si realmente funciona.
Diseñaron procesos. Capacitaron gente. Implementaron sistemas. Y luego… dejaron que funcionara.
Sin supervisión, los procesos se erosionan. Los responsables se retiran. Las nuevas personas nunca escucharon de gobernanza. Los datos nuevos entran al sistema sin clasificación porque nadie está verificando.
La gobernanza que no se audita es gobernanza que no existe.
Instituciones efectivas hacen auditoría interna trimestral: ¿cuál es el porcentaje de datos correctamente clasificados? ¿Cuál es el promedio de edad de datos no clasificados? ¿Hay alertas de acceso anómalo? ¿Los responsables asignados revisaron sus datos recientemente?
Métricas concretas. Verificación periódica. Escalada si se detectan desvíos. Mejora documentada.
Sin esto, tu programa es aspiracional.
Error 6: Falta de alineación con presiones comerciales reales
Este es el que quizás sea más crítico.
Muchos bancos diseñan gobernanza de datos sin considerar presiones comerciales reales. Tecnología dice: «Clasificamos todos los datos como ‘Confidencial’ porque es más seguro.»
Pero entonces el área de Marketing dice: «Necesito datos de clientes para campañas, ¿por qué todo está bloqueado?» Y el área de Análisis de Riesgos dice: «Sin datos históricos de clientes no puedo construir modelos.» Y Operaciones dice: «Si restringimos acceso, triplicamos tiempos de respuesta.»
De repente, gobernanza de datos se convierte en fricción comercial. Genera deuda técnica (excepciones que no deberían existir). Reduce velocidad de negocio.
Los bancos que funcionan diseñan gobernanza que dice: «Sí a acceso, pero controlado. Sí a datos, pero con propósito claro. Sí a eficiencia, pero con responsabilidad auditable.»
Integran controles con facilidad de uso. Reducen fricción mientras aumentan seguridad. Entienden que gobernanza no es cárcel de datos. Es sabiduría sobre datos.
La diferencia entre fracaso y éxito
He visto dos instituciones que implementaron gobernanza de datos simultáneamente hace 18 meses.
Institución A:
- Contrató consultor, gastó 6 meses en diagnóstico
- Documentó políticas hermosas
- Capacitó a 200 personas
- Implementó sistema de clasificación
- Entregó proyecto
- Hoy: 40% de datos tienen clasificación correcta, 60% no tiene clasificación actualizada, responsables reportan «no tenemos tiempo para gobernanza»
Institución B:
- Designó Chief Data Officer con presupuesto real
- Integró propietarios de negocio desde inicio
- Implementó gobernanza por etapas, no «big bang»
- Diseñó procesos que se integraban con flujos existentes
- Capacitación continua, no puntual
- Auditoría interna periódica
- Ajustes iterativos basados en feedback
- Hoy: 87% de datos clasificados correctamente, nuevos datos clasificados automáticamente, responsables reportan «es parte de cómo operamos»
¿Diferencia de costo? Probablemente similar.
¿Diferencia en resultados? Abismal.
La diferencia fue mentalidad: uno vio gobernanza como proyecto de Data, otro como transformación operativa.
Señales de alerta que tu programa de gobernanza está en riesgo
Si reconoces cualquiera de estas en tu institución, tienes problema:
- Responsables asignados que no están en las juntas de toma de decisión. Si el propietario de datos no se sienta a la mesa cuando se decide qué nuevos datos recolectar, no tiene verdadera responsabilidad.
- Políticas que nadie lee. Si tu documento de gobernanza tiene 80 páginas y nadie lo abrió en los últimos 6 meses, no es útil. Probablemente sea contraproducente.
- Auditoría inexistente o infrecuente. Si no medís cumplimiento, no sabés si funciona. No puedes mejorar lo que no medís.
- Responsables que dicen «es complicado» cuando les preguntas estado de sus datos. Si una persona designada no puede responder «¿qué datos administras?» y «¿están todos clasificados?», tienes brecha de capacidad.
- Sistema de gobernanza separado de sistemas operativos. Si la clasificación vive en una herramienta que nadie usa, y los datos viven en sistemas operativos, siempre estarán desincronizados.
- Presupuesto que disminuye año a año. Gobernanza no es proyecto: es programa. Si presupuesto disminuye, es porque la institución la ve como gasto, no como inversión.
Cómo hacerlo bien
Basándome en las instituciones que tienen gobernanza de datos verdadera, estos son los cinco requisitos no negociables:
1. Liderazgo ejecutivo real
No es suficiente que el CEO «apoye» gobernanza. Debe designar a alguien con suficiente seniority para que propietarios de negocio lo tomen en serio. Chief Data Officer, Director de Gobernanza, algún título que comunique que esto importa.
Esa persona debe reportar a nivel C-suite. Debe tener presupuesto independiente. Debe tener acceso a reguladores, a CEO, a directores.
Sin esto, es cosmético.
2. Integración real con operaciones
Gobernanza no vive en una oficina separada. Vive integrada en cómo opera negocio.
Los procesos de clasificación de datos deben estar integrados en el flujo de obtención de datos. Debe ser imposible traer datos nuevos sin clasificar porque el sistema no lo permite.
Los procesos de eliminación deben automatizarse en los sistemas donde viven datos.
Las excepciones a políticas deben requerir aprobación con trazabilidad.
Cuando gobernanza está integrada operativamente, ocurre automáticamente. No requiere disciplina humana constante.
3. Propietarios de negocio empoderados
No puedes implementar gobernanza si los únicos en la sala son Data, IT y Compliance.
Los VP de líneas de negocio deben estar definiendo qué datos necesitan, por cuánto tiempo, para qué propósito. Deben ser responsables de esa decisión.
Cuando el propietario de negocio es responsable de «retención de datos de clientes inactivos», de repente entiende que retención innecesaria multiplica riesgo. Actúa diferente.
4. Automatización donde sea posible
Gobernanza manual no escala. Si requiere trabajo humano constante, se va a desviar.
Invierte en tecnología que:
- Clasifique datos automáticamente donde sea posible
- Alerte sobre acceso anómalo
- Ejecute retención/eliminación automáticamente
- Reporte cumplimiento periódicamente
Esto no reemplaza supervisión humana. Pero reduce la fricción de ser gobernado.
5. Auditoría continua y mejora iterativa
No audites una sola vez. Audita constantemente.
Métricas: % de datos clasificados correctamente, edad promedio de datos no clasificados, velocidad de respuesta a nuevos datos, número de excepciones a políticas.
Cuando mides, mejoras. Cuando no mides, se desgrada.
La mejora debe ser iterativa, no puntual. Si tu programa de gobernanza es exactamente igual a hace 12 meses, probablemente esté degradándose.
El costo real de no hacerlo bien
He visto bancos gastar entre más de 250 millones de pesos en «programas de gobernanza de datos» que no generaron cambio operativo real.
Ese dinero se perdió porque fue gastado en proyecto, no en transformación.
En comparación, una institución que lo hace bien invierte menos de 100 millones de pesos anuales recurrentes, pero logra:
- Reducción de 35-40% en ciclos de respuesta a auditorías regulatorias
- Reducción de 25-30% en costos de almacenamiento de datos innecesarios
- Reducción de 60%+ en tiempo de respuesta a solicitudes de clientes (acceso, rectificación)
- Visibilidad real sobre riesgos informáticos
- Capacidad demostrable de compliance
ROI: mensurable, positivo, recurrente.
Una pregunta para reflexionar
Si implementaste gobernanza de datos hace 12 meses, contesta honestamente:
¿Las cosas operan diferente ahora? ¿Las personas clasifican datos diferente? ¿Los accesos están diferentes? ¿La velocidad de eliminación es verificable? ¿Los responsables pueden responder preguntas sobre sus datos?
Si la respuesta es «en teoría, sí, pero en práctica no estoy seguro,» tienes fracaso disfrazado de proyecto.
Si la respuesta es «sí, mediblemente diferente, porque revisamos continuamente y mejoramos,» tienes transformación real.
La diferencia determina todo.
Lo que verdaderamente importa
Después de dos décadas en data governance, entiendo que gobernanza de datos no es de Data o de IT.
No es de Compliance.
No es de Regulación.
Es de cultura. Es de cómo una institución decide manejar información. Es de responsabilidad integrada en operaciones. Es de liderazgo que entiende que datos bien gobernados son ventaja competitiva, no costo administrativo.
Cuando una institución lo entiende, todo cambia. De repente, gobernanza de datos no es «tarea de Data.» Es «cómo operamos.»
Y cuando eso ocurre, el cambio es irreversible. Porque el cambio no fue en documentos. Fue en comportamiento.
En Data Governance Latam ayudamos a instituciones financieras a implementar gobernanza de datos como transformación, no como proyecto. Diagnosticamos dónde está la brecha entre intención y realidad. Diseñamos programas considerando factores humanos, organizacionales, y comerciales. Acompañamos implementación iterativa. Medimos, auditamos, mejoramos continuamente.
No entregamos documentos. Entregamos cambio operativo real, medible, sostenible.
Si implementaste gobernanza en los últimos 12 meses y no estás seguro si verdaderamente funciona, o si estás a punto de iniciar un programa y quieres evitar errores comunes, contáctanos en www.datagovernancelatam.com.
El diferencia entre gobernanza que documenta y gobernanza que transforma es enorme. Y está completamente dentro de tu control.
