El problema
Cuando preguntás quién es el dueño de una tabla o de un dataset, la respuesta típica es "el área de ventas", "el equipo de finanzas", "sistemas". Un área, no una persona.
El problema aparece cuando hay un error de calidad. Supongamos que estás tomando datos de un sistema transaccional, tenés todas las cuentas cargadas ahí, y resulta que viene duplicado el account_id. Eso hace que un reporte de suscripciones dé mal.
Si no hay claro un owner de esa tabla (o de la base completa), es muy difícil que el problema se solucione. Nadie se va a hacer cargo. Y lo más probable es que el problema quede adosado al área de ingeniería de datos, cuando en realidad ingeniería no tiene nada que ver con el origen del error.
Por qué el owner tiene que ser una persona
La definición de quién es el dueño de un dato es fundamental para el gobierno. Y está bueno que sea a nivel persona, no a nivel área.
El dueño es tal persona. Si esa persona se va de la empresa, pasará a ser otra persona. Pero siempre hay alguien identificable que responde por ese dato.
Cuando el owner es difuso ("el área de..."), no hay a quién escalar. No hay quién tome la decisión de priorizar la corrección. No hay quién defina si el problema es aceptable o crítico. Y mientras tanto, el equipo de datos sigue recibiendo tickets por reportes que no cierran, aunque el error venga de origen.
Ownership del dato vs ownership del pipeline
Hay una distinción importante que suele confundirse.
En general, los datos de origen deberían tener dueños de negocio. Un dato que viene de un CRM debería tener como owner al área de ventas. Ingeniería de datos lo ingesta, lo transforma, lo cruza con otras fuentes, genera modelos nuevos. Pero eso no convierte a ingeniería en dueña del dato de origen.
Lo que sí es responsabilidad de ingeniería es el pipeline: asegurar que el dato llegue en tiempo y forma, que las transformaciones sean correctas, que la calidad se valide en cada etapa. Ese ownership es técnico y operativo.
Pero el dato en sí mismo tiene que tener un dueño que no sea el área de ingeniería. Si esa responsabilidad no está clara, termina cayendo en datos por defecto. Y datos no puede (ni debería) hacerse cargo de corregir problemas que vienen de sistemas que no controla.
El rol del steward
A veces vas a escuchar sobre el owner y el steward (o custodio) de los datos. Generalmente son dos personas distintas.
El owner es quien responde por el dato a nivel de negocio: qué significa, para qué se usa, qué calidad debería tener.
El steward es quien vela por esa calidad en el día a día. Puede ser alguien más técnico, o alguien del área de negocio con perfil más operativo. Si hay un problema de duplicidad de cuentas, el steward puede detectarlo, cuantificarlo, informarle al owner, y buscar la manera de que se corrija.
Pero si no hay owner definido, el steward no tiene a quién escalar. Y si no hay steward, nadie está mirando.
Qué pasa con datos sensibles
Cuando empezás a ingestar datos de pagos, información personal, números de tarjeta de crédito, la cosa se pone más seria. Esos datos están alcanzados por regulaciones, y el gobierno tiene que estar recontra claro.
Gobierno, en este contexto, es primero saber qué datos tenés. Después clasificarlos: este dato es sensible, este otro no. Y a partir de ahí, definir quién puede acceder, bajo qué condiciones, con qué controles.
Si no está claro el owner de esos datos, es muy difícil gobernar el acceso. Tranquilamente podés estar dando acceso a datos personales o sensibles a usuarios que no corresponde.
Desde el lugar de ingeniería, aunque no te asignen formalmente el rol de steward, hay cosas que podés hacer: etiquetar la información sensible, avisar al owner si detectás que te están mandando datos que no deberían llegar crudos, proponer que ciertos campos vengan enmascarados desde origen.
No es tomar todo por dado. Es levantar la mano cuando detectás algo que puede generar un problema.
Cómo se construye esto
El gobierno se construye dataset por dataset, tabla por tabla. No hay otra manera de hacerlo. Es incremental, es iterativo, no se puede hacer de un día para otro.
El punto de partida es entender qué datos tenés, dónde están, qué contienen. Después, documentar eso de forma que sirva: de dónde viene cada tabla, quién es el owner, qué significa cada campo.
Una vez que tenés eso claro, podés empezar a definir quién consume, quién puede consumir, bajo qué condiciones. Pero sin el paso previo (saber qué tenés y quién responde por eso), cualquier política de gobierno queda en el aire.
En resumen
Para que el gobierno funcione, el dato tiene que tener un dueño. Y ese dueño tiene que ser una persona, no un área.
Si el owner es difuso, cuando hay problemas de calidad nadie se hace cargo. El problema termina en el inbox de ingeniería, aunque ingeniería no tenga nada que ver con el origen del error.
Ingeniería es responsable del pipeline: que el dato llegue en tiempo y forma, que las transformaciones sean correctas, que la calidad se valide. Pero el dato en sí mismo tiene un owner de negocio. Esa distinción es fundamental para que el gobierno funcione.