Menu

Dados RH retenção: como tratar com cuidado

Dados de RH têm prazos e regras de descarte que variam conforme a jurisdição e quem opera o serviço. Veja as categorias de registro, por que a exclusão completa é difícil e o que fazer em ambiente de teste.

Publicado em

  • dados de teste
  • carreira
  • privacidade

Dados RH retenção é assunto de estrutura, não de número: as regras de guarda e descarte mudam conforme a jurisdição e ficam a cargo de quem opera o serviço. O que se pode discutir com proveito é como classificar o que existe, o que significa apagar de verdade e por que ambiente de teste não é lugar para registro de pessoal. Aqui percorremos essas três frentes sem apresentar prazo algum.

Quais categorias de registro precisam ser distinguidas?

O primeiro passo de qualquer política de guarda é separar o material por natureza, porque categorias diferentes seguem caminhos diferentes. Tratar tudo como uma massa única de registros de pessoal é o que produz tanto retenção excessiva quanto descarte precipitado.

As categorias que costumam aparecer:

  • Perfil profissional. Cargo, experiências e formação, que descrevem a trajetória e podem ser reaproveitados em processos futuros.
  • Documentos de candidatura. Formulários preenchidos, anexos e informações declaradas em um processo específico.
  • Avaliações e anotações. Registros produzidos durante a seleção, que raramente são criados pelo próprio titular.
  • Contato e comunicação. Mensagens, convites e confirmações trocadas com a pessoa.
  • Registros de acesso. Quem consultou qual ficha e quando, que servem para auditoria.

Cada uma dessas categorias tem finalidade própria. A finalidade é o que autoriza a guarda, e quando ela se esgota, o registro perde a razão de existir. Um sistema que não consegue responder para que uma categoria serve dificilmente conseguirá decidir quando descartá-la.

Como aplicar os princípios gerais de privacidade?

Os princípios que orientam o tratamento de dados pessoais são conhecidos e valem aqui sem adaptação especial: finalidade determinada, coleta mínima, exatidão, limitação da guarda, integridade e confidencialidade, e responsabilidade demonstrável.

Traduzidos para o trabalho do dia a dia, eles viram decisões concretas. Finalidade determinada significa que cada campo tem uma justificativa registrada. Coleta mínima significa não pedir informação que o processo não usa. Exatidão significa permitir que a pessoa corrija o que declarou. Limitação da guarda significa que todo conjunto tem uma data de revisão. Integridade significa que o descarte é registrado, e não apenas executado.

Nenhum desses princípios determina prazos por si. Eles determinam que alguém decida os prazos com base na finalidade, e que essa decisão possa ser explicada depois.

Por que apagar completamente é mais difícil do que parece?

Quando alguém pede a exclusão de um registro, a operação no sistema principal é a parte simples. O problema são as outras cópias.

Uma candidatura costuma deixar rastro em vários lugares: a base do processo seletivo, o anexo em repositório de arquivos, a exportação que alguém gerou para um relatório, a tabela analítica que consolidou os dados, os registros de acesso, os backups periódicos e até os arquivos de e-mail que notificaram o time. Excluir o registro principal sem tocar nessas cópias produz a pior situação possível: um sistema que afirma ter apagado e uma cópia que continua existindo.

Duas medidas ajudam a enfrentar isso com honestidade. A primeira é manter um inventário de onde cada categoria é armazenada, porque não se apaga o que não se sabe que existe. A segunda é separar o descarte imediato, aplicável às bases ativas, do descarte diferido, que depende do ciclo dos backups e precisa ser registrado com uma data prevista.

Vale lembrar ainda que retirar o nome não torna um registro anônimo. Um conjunto com cargo, empregador, cidade e período pode identificar alguém com facilidade, mesmo sem nome nenhum.

Como tratar os participantes não selecionados?

Os dados de quem participou de um processo e não foi selecionado costumam ser o ponto mais delicado da política, porque a pessoa não passou a fazer parte da organização e, ainda assim, deixou material.

A discussão gira em torno de três decisões. A primeira é a finalidade de manter o perfil para oportunidades futuras, que só se sustenta com consentimento e com um caminho claro de descarte. A segunda é a duração da guarda, que varia conforme a jurisdição e a natureza do processo. A terceira é o que fazer com as anotações de avaliação, que são as menos úteis a longo prazo e as mais sensíveis.

Em qualquer desses caminhos, o registro precisa deixar claro o que foi prometido à pessoa na hora da coleta, porque a política interna não pode contradizer a informação dada no formulário.

Por que ambiente de teste não deve receber dado real?

Este é o ponto em que a discussão de retenção se encontra com a de engenharia. Uma cópia de produção em ambiente de homologação está fora do alcance da política: ninguém lembra que ela foi feita, ela não aparece em inventário nenhum e sobrevive a qualquer revisão de prazo.

Os motivos são sempre os mesmos: controle de acesso mais frouxo no ambiente de teste, mais pessoas com permissão de leitura, menos registro de consulta, e uma tendência conhecida de reaproveitar o ambiente de teste em capturas de tela, relatórios de erro e conjuntos de exemplo.

A saída prática é a mesma em qualquer organização: ambiente de teste trabalha com dados sintéticos, gerados com a mesma forma dos reais e sem correspondência com pessoas. Quando o time precisa de distribuição realista, ajusta-se o gerador, e não a política de privacidade.

Para quem desenvolve: como levar a política para o código

Uma política de guarda só existe de fato quando o sistema consegue executá-la. Do ponto de vista técnico, isso pede quatro capacidades: marcar cada registro com sua categoria e sua data de origem, saber onde as réplicas vivem, executar o descarte de forma verificável e registrar o que foi descartado.

Capacidade Para que serve Sinal de que falta
Categoria no registro Aplicar regra por tipo Descarte por tabela inteira
Data de origem Calcular prazo Prazo estimado por aproximação
Inventário de réplicas Alcançar exportações e análises Exclusão que não surte efeito
Trilha de descarte Demonstrar o que foi feito Afirmação sem registro

Um cuidado final vale para o ambiente de teste: os dados sintéticos também precisam de rotina de descarte. Um conjunto antigo que ninguém sabe de onde veio não é um risco de privacidade, mas é uma fonte de confusão garantida quando alguém tenta usá-lo como referência.

Onde gerar registros que não são de ninguém

Se o seu objetivo é popular um ambiente com material de aparência realista, o gerador de currículo e dados de emprego produz perfis completos, com cargo, experiências, formação, habilidades e certificações, sem correspondência com pessoas existentes. É o tipo de insumo que permite testar sem arrastar a discussão de retenção para dentro do ambiente de desenvolvimento.

Dois textos vizinhos aprofundam pontos específicos: dados de currículo para teste explica por que dado real não deve entrar em ambiente de teste, e salário, moeda e período trata do campo mais sensível de qualquer ficha de pessoal.

Próximos passos

Monte o inventário das categorias de dados de RH que a sua aplicação guarda e anote, para cada uma, a finalidade e quem decide o prazo — sem inventar números, apenas registrando quem responde. Em seguida, use o gerador de currículo para substituir qualquer amostra de origem desconhecida que esteja circulando em ambiente de teste.

Aviso: as orientações desta página descrevem práticas de organização de dados em ambientes de teste e demonstração. Nenhum registro citado aqui vem de uma pessoa real, e o conteúdo não constitui parecer jurídico nem garante conformidade com qualquer norma específica de um país.

Continue lendo

Artigos sobre Gerador de currículo e dados de emprego falsos