Gobierno de datos: del permiso al registro que se puede consultar.

El gobierno de datos —también llamado gobernanza de datos— es el conjunto de reglas y registros que permiten responder, de cualquier dato de la empresa, de dónde proviene, quién lo modificó, qué reglas se le aplicaron, qué versión se usa, qué calidad tiene y quién puede consumirlo.

Sí. «Gobernanza de datos» es la traducción directa de data governance y «gobierno de datos» es la forma más usada en Latinoamérica. Las dos nombran lo mismo: las reglas y los registros que permiten responder por cada dato. En Lorian Analytics usamos «gobierno de datos» en la interfaz y en el sitio.

No cuando el registro es automático. El error habitual es empezar por la política y dejar el registro para después; el resultado es un documento que nadie consulta. Si cada acción queda registrada cuando ocurre —quién cargó, qué regla se aplicó, quién consumió—, la política se escribe sobre evidencia y el comité, si existe, revisa registros en lugar de reconstruir memoria.

Setenta y seis tipos de acción, agrupados en datos, recetas, colecciones y acceso, tokens y agentes, conexiones y flujos, modelos Gold y tableros, personas y plan. Cada entrada lleva el usuario, la fecha, la dirección IP y el detalle de la acción. Nunca lleva un secreto: ni tokens, ni contraseñas, ni credenciales de conexión. Los inicios de sesión no se registran, por decisión de diseño.

No desde la aplicación: el usuario con el que la plataforma se conecta a la base de datos tiene negados los permisos de modificar y borrar sobre las tablas de auditoría, y esa restricción se verificó con una prueba que intenta hacerlo y falla. Por eso decimos que el registro es append-only por diseño e inmutable ante la aplicación. Lo que no decimos es «retención garantizada»: la política de cuánto tiempo se conserva el registro todavía no está definida.

En la organización, el Propietario administra el plan, invita y crea espacios; el Administrador invita y crea espacios sin tocar el plan; el Miembro solo ve los espacios a los que fue invitado. En cada espacio, el Propietario invita y asigna roles, el Editor carga, configura, ejecuta y descarga, y el Visor solo lee y consulta el registro. Una colección se puede compartir con alguien de la organización que no pertenece al espacio, y ese acceso se revoca en un clic.

Con tokens. Cada token lleva grabado su alcance —todo el espacio o una sola colección—, tiene fecha de vencimiento obligatoria, se muestra una única vez al crearlo y se revoca sin vuelta atrás. Cada lectura queda registrada con fecha, versión leída, formato y dirección. Los administradores ven la tabla de todos los tokens de la organización.

Sí. Cada una de las 82 acciones registradas queda con el usuario, la fecha, la IP y el detalle: cargas, limpiezas, ejecuciones, descargas, cambios de rol, tokens creados o revocados, corridas de conectores y cada tabla ingerida. El registro se consulta por usuario, acción, entidad, espacio y rango de fechas y se exporta en CSV; en la interfaz esa vista con filtros está en construcción y hoy el registro se ve por dataset y por modelo.

Puede asignar y cambiar roles en dos niveles, compartir colecciones por concesión, dar a cada receta su propio rol y emitir tokens con el alcance exacto que necesite, todo desde la aplicación y con registro. Lo que no existe son roles personalizados con permisos definidos por usted: los roles son fijos y se validan en cada operación.

Etiquetas de sensibilidad sobre columnas, un glosario de negocio con dueños de dato, flujos de aprobación y estados de borrador y publicado están en el roadmap. Los filtros y la exportación del registro completo desde la interfaz están en construcción; hoy existen en la API para administradores.