La política dice que los datos de nómina no se comparten por correo.

En la bandeja de entrada de esta semana hay tres archivos de nómina.

Nadie los reenvía por descuido

Esto es lo primero que hay que aceptar, porque explica por qué las políticas de acceso fracasan tan seguido.

La persona que reenvió el Excel necesitaba que su compañero viera una cifra. Pedir un acceso formal implicaba escribirle a sistemas, esperar aprobación y quizá justificar por qué. Reenviar el archivo tomó tres segundos.

Eligió el camino rápido para poder trabajar, no para saltarse la norma.

Ese es el patrón: cuando el camino correcto es más lento que el incorrecto, gana el incorrecto. Y la respuesta habitual —más políticas, más aprobaciones— hace el camino correcto todavía más lento, y empuja a más gente fuera del sistema. El control de acceso diseñado solo como prohibición produce las filtraciones que quiere evitar.

La pregunta útil no es «¿cómo impido que compartan?». Es «¿cómo hago que dar acceso sea más fácil que reenviar un archivo?».

El acceso tiene tres alturas distintas

Meter todo en una sola lista de permisos es lo que vuelve el sistema inmanejable. En la práctica hay tres decisiones distintas, y conviene no mezclarlas.

Quién pertenece a la empresa. Quién puede invitar gente, quién administra los espacios de trabajo, quién toca el plan y la facturación. Es una decisión administrativa, no de datos.

Quién entra a qué espacio. Un espacio de trabajo agrupa los datos de un área o un proyecto. Aquí es donde se decide que finanzas no ve el pipeline comercial. Dentro de cada espacio, la distinción que más rinde es entre editor —sube, transforma, descarga— y visor —solo lee: archivos, resultados e historial—.

Quién puede ejecutar sin poder cambiar el criterio. Es el nivel que casi ningún sistema contempla y el que más falta hace: dejar que alguien corra la limpieza del cierre sin poder editar sus reglas. El trabajo se delega; el criterio no.

En Lorian Analytics esos tres niveles existen por separado: roles de organización, roles por espacio de trabajo, y roles por receta con un permiso de solo ejecución.

La distinción que decide si el sistema se usa

De las tres, la que más impacto tiene en el día a día es editor contra visor.

La razón es aritmética: en cualquier empresa, la mayoría de las personas que necesitan un dato solo necesitan verlo. El gerente que revisa el tablero, el comercial que consulta su cartera, el director que mira el cierre. Ninguno va a transformar nada.

Si para consultar hay que ser editor, pasa una de dos cosas: se le dan permisos de edición a medio mundo —y el gobierno se acabó— o no se le dan a nadie y la gente pide capturas de pantalla por chat —y el dato salió del sistema igual—.

Y aquí hay un factor que rara vez se discute como lo que es, un asunto de gobierno: cuánto cuesta cada persona que solo mira.

Si cada visor cuesta, usted acaba de crear un incentivo económico para no dar acceso.

Cuando sumar a alguien al tablero cuesta, las áreas exportan a Excel y comparten capturas para no sumar licencias. En ese instante el dato salió del entorno gobernado y ya no hay registro de nada. Por eso en Lorian Analytics los visores son ilimitados desde el plan Lorian Bronze: la razón económica para evadir el control simplemente no existe.

Los consumos que no son personas

Un tablero de Power BI, un notebook, la integración de un proveedor. Estos consumen datos todos los días y no son nadie.

La solución perezosa es conectarlos con la cuenta de alguien. Funciona hasta que esa persona sale de la empresa: se desactiva su cuenta y el informe del comité deja de cargar, normalmente el mismo día del comité. La respuesta de emergencia suele ser peor: compartir la contraseña de alguien que sigue.

Un consumo automático necesita identidad propia, y con dos condiciones:

  • Alcance acotado. El token no abre «los datos»: abre exactamente la colección que ese consumo necesita y nada más. Si el informe de ventas se ve comprometido, no expone la nómina.
  • Revocable sin daño colateral. Se corta ese acceso concreto sin cambiarle la contraseña a nadie ni tocar los demás consumos.

Y cada lectura queda registrada. Eso convierte una pregunta que hoy no tiene respuesta —¿quién está usando este dato?— en una consulta.

La pregunta que llega después: qué se rompe si cambio esto

Hay un último aspecto del acceso que casi nunca se piensa hasta que duele: saber quién consume algo es lo que permite cambiarlo sin romper nada.

Cuando alguien va a modificar la definición de un modelo, la pregunta correcta es «¿quién está leyendo esto hoy?». Sin registro de consumo, esa pregunta no tiene respuesta y solo quedan dos opciones malas: no cambiar nada por miedo, o cambiar y esperar el reclamo.

Con el registro, la lista de afectados se consulta antes de tocar nada. El gobierno de acceso no es solo una defensa: es lo que permite que el sistema evolucione.

Lo que cambia

Deja de haber una política que todos incumplen con buena intención.

El compañero que necesitaba ver la cifra la ve, con un permiso de lectura que cuesta un clic y no cuesta dinero. El tablero se conecta con su propia llave, no con la cuenta de alguien que puede irse. Y cuando alguien pregunta quién tiene acceso a la información de clientes, la respuesta es una lista — no una suposición.

Con esto, las seis preguntas del dato confiable tienen respuesta: de dónde viene, quién lo tocó, qué reglas se le aplicaron, qué versión se usó, qué calidad tiene y quién puede consumirlo. Ese conjunto es lo que separa un dato correcto de un dato que se puede defender.

En Lorian Analytics el acceso se administra en tres niveles —organización, espacio de trabajo y receta—, los visores son ilimitados desde Lorian Bronze y los consumos externos usan tokens de alcance acotado por colección, revocables y con cada lectura registrada. Puede ver cómo funcionan los permisos, las vías de consumo, o volver al artículo base de las seis preguntas.