Una intranet conforme al RGPD: qué vigilar con los datos de los empleados

Por su naturaleza, una intranet trata datos personales: nombre, puesto, datos de contacto, departamento, solicitudes de vacaciones, a veces fecha de nacimiento y fotografía. Esos datos están sujetos al RGPD — y al KVKK para empresas con actividad en Turquía —, lo que convierte la elección de una intranet en una decisión tan jurídica como técnica.

Este artículo es información general; consulta a tu asesoría legal para las obligaciones concretas de tu empresa.

Empieza por la minimización

La estrategia de cumplimiento más sólida son los datos que no tratas. La pregunta durante la implantación es simple: ¿hace falta de verdad este campo? Si la fecha de nacimiento sirve para felicitar, basta con día y mes, sin el año. Un móvil personal no debería recogerse mientras exista una línea corporativa.

El mismo principio vale para los canales de notificación: los que exigen un número personal deben estar apagados por defecto y basarse en consentimiento, mientras que los canales corporativos pueden funcionar con un modelo de baja voluntaria.

Información y control de versiones

Los empleados deben saber qué datos suyos se tratan y con qué finalidad. Se espera que la intranet lo respalde de dos formas: el texto debe ser accesible dentro de la aplicación y debe estar versionado. Cuando se actualiza, hay que registrar quién vio qué versión; de lo contrario no puede probarse que se informó.

Solicitudes de los interesados

Los empleados tienen derecho a acceder y rectificar sus datos y, en ciertos supuestos, a solicitar su supresión. Para que esas solicitudes no se pierdan en un buzón, un canal trazable dentro de la intranet es una necesidad práctica: registro de la solicitud, responsable, estado y plazo de respuesta deben verse.

Permisos de acceso: ocultar no basta

El error técnico más común es ocultar un campo solo en la interfaz. La restricción real corresponde a la capa de datos; si no, un usuario sin permiso alcanza esa información con una consulta directa. Ante un proveedor la pregunta es precisa: «¿Quién no puede ver este campo y dónde se aplica esa restricción?». Si la respuesta solo señala la interfaz, es insuficiente. Describimos nuestro enfoque en la página de seguridad.

La misma lógica vale para el aislamiento entre empresas: en un producto multiempresa, la imposibilidad de alcanzar los datos de otra debe garantizarse a nivel de base de datos.

Flujos que exigen anonimato

En piezas como un canal de denuncias, el anonimato no es una preferencia sino una condición de uso. El detalle crítico: el anonimato no puede dejarse al cliente. Si la decisión de «no enviar la identidad» se toma en el navegador, el registro puede llegar igualmente con identidad. En un diseño correcto la identidad se elimina en el servidor, en el momento de la escritura.

Un umbral parecido se aplica a los pulsos y encuestas de clima: los resultados solo deberían mostrarse agregados por encima de un mínimo de participantes, para que en equipos pequeños no puedan deducirse respuestas individuales.

Plazos de conservación y salida

Cuánto tiempo se conservan los datos debe estar por escrito. Cuando se cierra la cuenta de quien se marcha, ¿qué queda: sus anuncios, los reconocimientos recibidos, los equipos asignados? Esas respuestas pertenecen al proceso de salida, y la intranet debería poder seguir esos pasos.

Alojamiento y subencargados

Dónde se guardan los datos, qué subencargados intervienen y si hay transferencia internacional debe obtenerse por escrito antes de la compra. Esa información es parte inseparable de las preguntas de seguridad de nuestra guía de selección.

La prueba: el registro de auditoría

La dimensión de cumplimiento más olvidada es que el trabajo debe poder demostrarse. En una inspección no basta con «publicamos la información»; hay que mostrar quién vio qué versión y cuándo, cuándo llegó una solicitud y en cuántos días se respondió.

Por eso importa el alcance del registro: cambios de permisos, accesos a datos sensibles, exportaciones con datos personales y borrados deberían quedar registrados como mínimo. Del propio registro se espera que las alteraciones sean detectables; un diario editable a posteriori no tiene valor probatorio.

La función de exportación merece atención aparte: un permiso que permite descargar toda la lista de empleados es en la práctica un riesgo de fuga y solo debería abrirse a los roles que lo necesitan.

Lista de comprobación

• ¿Cada campo recogido tiene una justificación?
• ¿La información al empleado está versionada y accesible?
• ¿Hay un canal trazable para las solicitudes de los interesados?
• ¿Las restricciones se aplican en la capa de datos?
• En los flujos anónimos, ¿se elimina la identidad en el servidor?
• ¿Están definidos los plazos de conservación y el proceso de salida?

Escríbenos con cualquier duda de cumplimiento.