Datos RRHH retención: cómo tratarlos

Los datos RRHH retención plantean una pregunta que no tiene una única respuesta: durante cuánto tiempo tiene sentido conservar la información de una persona empleada o candidata. La respuesta depende de la jurisdicción y del proveedor del servicio, y por eso este artículo no ofrece plazos. Lo que sí puede explicarse es la estructura del problema, porque la mayoría de los sistemas que gestionan personal fallan no por desconocer los plazos, sino por no saber qué están conservando, dónde y por qué.

¿Qué significa conservar un expediente de personal?

Significa mantener disponible, a lo largo del tiempo, un conjunto de información que describe la relación entre una persona y una organización. Ese conjunto incluye cosas muy distintas entre sí: datos identificativos, condiciones contractuales, registros de formación, evaluaciones, incidencias y correspondencia.

La primera dificultad es que ese conjunto no se definió de una vez. Se fue formando por acumulación, a medida que distintas áreas incorporaron sus propios registros, y cada una con su criterio. El resultado es que el expediente no es una entidad única, sino una federación de conjuntos repartidos por varios sistemas.

La segunda dificultad es que conservar no es una acción, sino un estado que se mantiene. Un expediente se conserva mientras nadie lo borra, y esa inercia hace que la pregunta por el plazo se plantee tarde, cuando el volumen ya es grande y las dependencias entre sistemas ya existen.

La tercera es que el expediente suele contener datos de terceros. Una evaluación puede mencionar a un responsable, una incidencia puede citar a un compañero, una nómina puede incluir a un familiar. Borrar el expediente de una persona no borra necesariamente lo que otras conservan sobre ella.

¿Por qué borrar es más difícil de lo que parece?

Porque el dato rara vez está en un solo lugar. Una misma información aparece en el sistema de personal, en las copias de seguridad, en los registros de acceso, en las exportaciones que alguien hizo para un informe y en los ficheros que se enviaron por correo. Eliminarla del sistema principal no la elimina del resto.

A eso se añade que la identidad no siempre está expresada de la misma forma. Un expediente puede estar asociado a un identificador interno, a un número de documento, a una dirección de contacto o a un nombre. Si un sistema borra por un criterio y otro conserva el vínculo por un criterio distinto, la información sobrevive sin que nadie lo pretenda.

La consecuencia práctica es que la eliminación hay que planificarla como un proceso que recorre todas esas superficies, y no como una operación sobre una tabla. También conviene distinguir entre borrar el dato y dejar de poder asociarlo a una persona, que son objetivos distintos con costes distintos.

En qué se diferencian los tipos de datos de personal

No todos los datos de un expediente tienen el mismo tratamiento. Agruparlos ayuda a decidir qué se conserva y qué no.

Los datos identificativos y de contacto sirven para operar la relación laboral y pierden utilidad cuando esa relación termina. Las condiciones contractuales, en cambio, pueden conservarse durante más tiempo porque documentan hechos con relevancia posterior. Los registros de formación y las credenciales describen capacidades y conservan valor aunque la relación haya concluido.

Las evaluaciones y los datos de desempeño son un caso aparte. Son opiniones estructuradas sobre una persona y su utilidad futura es discutible, mientras que su impacto potencial sigue siendo alto. Los datos de salud y los relativos a circunstancias protegidas merecen una consideración específica en cualquier diseño.

La lección es que no existe un expediente con un único plazo, sino varios conjuntos con tratamientos distintos. Un sistema que solo sabe conservarlo todo o borrarlo todo no puede aplicar esa distinción cuando alguien se la pida.

Qué ocurre con las candidaturas no seleccionadas

Son el conjunto que más se descontrola, por una razón sencilla: no llegaron a formar parte de la organización, de modo que nadie tiene la responsabilidad funcional de revisarlas. La mayoría de esos datos se acumula sin que exista una decisión explícita de conservarlos.

Al mismo tiempo, hay razones legítimas para mantenerlos durante cierto tiempo: demostrar que un proceso de selección fue equitativo, atender una reclamación posterior o contactar de nuevo con una persona para otra vacante. El problema no es conservar, sino conservar sin haber decidido hacerlo.

Un tratamiento razonable pasa por separar la candidatura del resto del sistema de personal, aplicar un criterio de revisión periódica y ofrecer a quien se postula información clara sobre qué se guarda y por qué. La duración concreta vuelve a depender de la jurisdicción y del proveedor del servicio.

Vale la pena añadir un caso que suele olvidarse: las candidaturas que nunca se completaron. Un formulario abandonado a medias puede contener datos identificativos y de contacto, y no suele pasar por ninguno de los procesos de revisión previstos.

Cómo se construyen entornos de prueba sin datos reales

La forma más simple de no tener un problema de retención es no llegarlo a crear. Para eso sirven los datos sintéticos: conjuntos generados para pruebas que no describen a ninguna persona.

Un perfil sintético bien construido tiene tres propiedades. Es internamente coherente, de modo que los campos se sostienen entre sí y el sistema se prueba en condiciones realistas. Es reconocible como ficticio, para que nadie lo confunda con un registro auténtico. Y es irrelevante para la privacidad, porque no existe la persona de la que habla y por tanto no hay nada que retener ni que borrar.

La coherencia es la propiedad que más trabajo cuesta y la que más valor aporta. Un conjunto en el que las fechas de formación no preceden a la experiencia, o en el que el nivel declarado no corresponde al puesto, dispara errores en las pruebas que no tienen nada que ver con el código que se está validando.

Conviene además tener perfiles incompletos y perfiles con datos extraños: campos vacíos, valores en el límite, caracteres especiales. Ahí es donde aparecen los fallos que un conjunto de ejemplos uniformes nunca revela.

En el generador de este sitio

El generador de currículums y datos de empleo falsos construye perfiles completos de forma coherente: la experiencia encaja con la formación, el puesto con la industria y la retribución con el nivel. Todo el material es sintético y sirve para pruebas de software, demostraciones de formularios y carga de datos.

Ese material no describe a ninguna persona real y no proviene de ningún expediente auténtico. Los nombres, las fechas y los importes son valores de ejemplo, y por eso su uso en pruebas no genera obligaciones de conservación.

Si lo que necesitas es entender la estructura del perfil antes de generar conjuntos, el artículo sobre datos de currículum para pruebas recorre campo por campo. Y para el componente retributivo, que es uno de los que más cuidado exige, la guía sobre salario, moneda y periodo explica cómo anotarlo sin ambigüedad.

Para quien programa

• Clasifica los datos antes de decidir los plazos. Sin una clasificación por tipo no se puede aplicar un tratamiento diferenciado, y cualquier regla que se implemente acabará siendo un plazo único disfrazado. La clasificación es el trabajo previo que hace posible todo lo demás.
• Documenta las superficies donde vive el dato. Sistema principal, copias, registros, exportaciones y datos derivados. Un proceso de eliminación que solo cubre la base operativa deja el problema intacto y da una falsa sensación de cumplimiento.
• Distingue entre borrar y anonimizar. Son objetivos distintos con costes distintos. Eliminar la información es definitivo; romper el vínculo con la persona puede bastar para muchos usos, pero exige comprobar que el vínculo no se pueda reconstruir por combinación.
• No implementes plazos concretos en el código sin una fuente. La duración depende de la jurisdicción y del proveedor del servicio. Si el sistema tiene que aplicarlos, esos valores deberían ser configurables y estar documentados con su origen.
• Trata las copias de seguridad como parte del problema. Una restauración puede reintroducir información ya eliminada. Conviene decidir qué ocurre en ese caso antes de que suceda, y no después.

Una nota sobre el diseño de pruebas: usa siempre perfiles generados. Probar un entorno con un volcado de producción crea exactamente el problema que este artículo describe, y lo crea en un sistema que probablemente no tiene los mismos controles.

Siguientes pasos

Si estás montando un entorno de pruebas, empieza por el conjunto de datos y no por el código. El generador de perfiles profesionales permite obtener perfiles coherentes y variados sin usar información de personas reales, y ese es el punto de partida más seguro.

Para un caso relacionado, el artículo sobre los desajustes entre direcciones y códigos postales ilustra qué sucede cuando un registro se interpreta sin el contexto que le da sentido, algo que en retención ocurre cuando un dato sobrevive en un sistema porque otro ya lo había copiado.

Y conviene cerrar con la idea central: los datos de personal se acumulan por inercia y solo se reducen por decisión. Todo lo que aparece en esta guía se apoya en información sintética para pruebas de software y carga de datos, ajena a cualquier expediente laboral real.