Como equipes de RH podem implantar apps criados com IA sem expor dados de funcionários

A empresa de segurança RedAccess procurou apps criados com ferramentas de programação com IA e publicados na hospedagem dessas próprias ferramentas, e encontrou mais de 5.000 praticamente sem qualquer segurança ou autenticação. Entre as capturas de tela compartilhadas com a Wired estava o que parecia ser a distribuição de tarefas de um hospital, incluindo informações pessoais dos médicos.

Criar é a parte que as ferramentas de programação com IA tornaram fácil. A exposição nos apps criados com IA para equipes de RH vem depois, quando um controle de ausências ou uma ficha de avaliação de entrevistas entra no ar exatamente como foi demonstrado: um link público, uma conta de administrador e a tabela inteira de funcionários por trás.

TL;DR

• Uma ferramenta que ajuda a decidir quem será contratado ou promovido, ou como as pessoas serão avaliadas, pode ser considerada de alto risco pela Lei de IA da UE. Ela deve passar pela TI e pelo jurídico ou DPO antes de atribuir pontuações a qualquer pessoa.
• Os registros dos funcionários nunca devem ficar na hospedagem da própria ferramenta de programação com IA. A opção padrão é um servidor controlado pela equipe, acessível apenas por uma rede privada, com autenticação corporativa na entrada quando gestores ou todos os funcionários precisarem de acesso.
• As correções passam pela mesma ferramenta de IA que criou o app: reduzir os campos lidos, oferecer visualizações diferentes a administradores de RH, gestores e funcionários, retirar credenciais do código, reduzir o que envia para fora, registrar quem abre cada registro e tratar pedidos de exclusão respeitando os requisitos de retenção. Uma verificação feita por você confirma cada correção; o relatório da própria IA não confirma.
• O acesso à ferramenta deve terminar no dia em que o vínculo de trabalho termina, uma pessoa identificada deve ser responsável por ela e escolher a localização de um servidor não garante conformidade.

Os erros de implantação que expõem dados dos funcionários

Uma ferramenta de RH criada com IA expõe dados de funcionários a quem encontra seu link, a quem possui uma credencial colada em um chat ou no código, a colegas que abrem registros destinados a outra pessoa, a serviços externos para os quais envia dados e a pessoas que já saíram, sem registrar quem consultou. Ler a tabela inteira de funcionários amplia cada uma dessas vias.

A primeira linha é o problema que a RedAccess encontrou em grande escala. Na reportagem da Wired sobre as descobertas da RedAccess, três das quatro empresas de programação com IA contestaram as alegações dos pesquisadores (a quarta não respondeu), mas não negaram que os apps criados por vibe coding encontrados pela RedAccess tinham ficado expostos. Interpreto isso como um problema de configuração e uma etapa de revisão ignorada.

Verifique se a ferramenta ajuda a decidir quem é contratado, promovido ou avaliado

Ter sido criada com uma ferramenta de programação com IA não torna, por si só, uma ferramenta de RH de alto risco pela Lei de IA da UE. O que ela faz determina isso. O Anexo III da Lei de IA da UE lista sistemas de IA usados para recrutar ou selecionar pessoas e tomar decisões sobre promoção, demissão, atribuição de tarefas ou monitoramento e avaliação de desempenho.

Portanto, antes de decidir onde a ferramenta será executada, faça uma pergunta: ela toma ou influencia uma decisão sobre quem é contratado, promovido, dispensado, recebe tarefas ou é avaliado pelo desempenho?

Um controle de ausências, uma lista de integração ou um diretório da organização armazena registros e os mostra, então fica do lado do «não». Uma ficha de pontuação de entrevistas que classifica candidatos, ou uma ferramenta de desempenho que pontua pessoas (principalmente com um modelo de IA calculando a pontuação), pode ficar do lado do «sim». Quando não consigo identificar de que lado está a ferramenta, trato como um sim e deixo que a TI e o jurídico me digam o contrário.

A Lei não se limita a empresas da UE: o Artigo 2 abrange fornecedores e responsáveis pela implantação estabelecidos fora da UE quando o resultado de seu sistema de IA é usado na UE. Pelo Artigo 113, conforme alterado, as obrigações para sistemas de alto risco do Anexo III se aplicam a partir de 2 de dezembro de 2027. Elas incluem sistema de gestão de riscos, governança de dados, documentação técnica, manutenção de registros, transparência para os responsáveis pela implantação e supervisão humana (Artigos 9 a 14), e cabe à TI e ao jurídico avaliá-las.

Se a resposta for sim, pare antes de a ferramenta pontuar um único candidato ou funcionário real. Leve-a à TI e ao responsável jurídico ou de proteção de dados (o DPO, onde houver). Esta verificação não determina se uma ferramenta específica está no escopo; ela indica quem precisa decidir. Alguns estados dos EUA também regulam decisões automatizadas de contratação, e essas regras aparecem na tabela mais adiante.

Você pode adiantar essa revisão. Eu pediria à ferramenta de IA para argumentar contra a própria pontuação em vez de defendê-la:

Este app pontua ou classifica candidatos a vagas ou funcionários. Liste todos os campos de dados e todas as etapas de cálculo que contribuem para a pontuação ou classificação. Para cada um, diga se pode refletir direta ou indiretamente uma característica protegida: idade, raça, sexo, nacionalidade, origem étnica, deficiência, gravidez, religião ou orientação sexual. Quando não tiver certeza, diga isso em vez de adivinhar. Depois aponte qualquer questão sobre a equidade dessa pontuação que eu não tenha perguntado, mas deveria ter perguntado.

Verificação: trate a resposta como uma lista inicial para as pessoas que revisam a ferramenta, não como um veredito, e entregue-a junto com a ferramenta. Executar esse prompt não é uma auditoria de vieses e não atende a nenhum requisito legal.

Onde uma ferramenta de RH deve ser executada

Mantenha os registros dos funcionários fora da hospedagem da própria ferramenta de IA. Para uma ferramenta usada apenas pela equipe de RH, a opção padrão é um servidor controlado pela equipe, acessível somente por uma rede privada, com autenticação corporativa na entrada quando gestores ou funcionários precisarem dela. Uma ferramenta que não passou na verificação sobre decisões de contratação, ou sem alguém responsável pelo servidor, vai para a TI.

Publicar na hospedagem de uma ferramenta de programação com IA coloca o app em um endereço no domínio do fornecedor e, a menos que sua visibilidade esteja configurada como privada, qualquer pessoa que encontre esse endereço pode acessá-lo. A RedAccess identificou milhares de apps criados dessa forma com pesquisas comuns no Google e no Bing por esses domínios. Uma rede privada funciona ao contrário, pois a ferramenta só responde a dispositivos que entraram nela. A autenticação corporativa (single sign-on) permite que colegas abram a ferramenta com a conta empresarial que já usam, verificada por um provedor de identidade, o serviço que administra essas contas.

Até que a ferramenta seja executada no servidor da equipe, crie e teste com dados sintéticos: nomes, salários e datas de ausência inventados no mesmo formato dos reais. Um túnel gratuito de um notebook para um endereço público é público da mesma forma que a hospedagem do fornecedor, então também pertence à etapa de demonstração.

Por que uma rede privada em vez da página de login que o app já tem? Uma rede privada significa que a ferramenta não responde de fora, então ninguém externo pode carregá-la, sondá-la ou adivinhar senhas. Uma página de login escrita pela ferramenta de IA não basta sozinha. Qualquer pessoa pode acessá-la, e sua segurança depende do código gerado por trás. O relatório da Veracode de 2025 sobre segurança de código GenAI descobriu que 45% das amostras de código testadas, de mais de 100 modelos, falharam nos testes de segurança por uma vulnerabilidade OWASP Top 10 (uma de uma lista muito usada dos riscos mais críticos de segurança de aplicações web). Por isso prefiro colocar um cadeado na frente do app a depender daquele escrito pela IA.

Para a entrega, a ferramenta é executada em um VPS (um servidor alugado que a equipe controla totalmente) sob uma ferramenta de implantação como Coolify ou Dokku, que executa o app a partir do código; o Coolify também pode reverter uma atualização ruim para uma versão anterior pelo painel. Escolher entre Coolify e Dokku depende principalmente de quantos apps o servidor executará e de o suporte de TI preferir um painel. A rede privada vem do Tailscale ou WireGuard. O Tailscale é o mais rápido de configurar, mas seu serviço de coordenação é operado pelo Tailscale, enquanto o WireGuard é totalmente auto-hospedado. A autenticação corporativa vem de um provedor de identidade como Authentik ou Keycloak. Um proxy reverso como Caddy ou Nginx Proxy Manager adiciona HTTPS onde o login fica exposto à web. Essa é a parte a entregar ao suporte de TI, junto com a lista de verificação no final.

As correções, como prompts para sua ferramenta de IA

A maior parte do trabalho para implantar com segurança um app de RH criado com IA passa pela ferramenta que o criou, mas só quando solicitado. Como o pesquisador de segurança Joel Margolis disse à Wired, as ferramentas de programação com IA «fazem o que você pede. E, a menos que você peça para fazer com segurança, elas não vão se esforçar especialmente para isso».

Trate cada prompt abaixo como ponto de partida e ajuste os nomes dos campos e as funções à sua ferramenta. Vejo a ferramenta de IA como o engenheiro e a mim como o revisor, então seu relatório de que uma alteração foi concluída é um rascunho. A verificação sob cada prompt é a prova, e nenhuma exige que você leia código. Quando uma verificação falha, a correção volta à ferramenta de IA e a lição vai para um arquivo de regras da sua ferramenta de IA, para que a próxima sessão comece a partir dela. Cada prompt também pede que a ferramenta destaque suas incertezas; um assistente que admite uma lacuna é mais útil que um que parece seguro. Execute os prompts com o código e registros fictícios, nunca com registros reais ou senhas colados no chat.

Encontre os campos de funcionários usados pela ferramenta e bloqueie os demais

Você não pode bloquear um campo que não sabe que a ferramenta contém, então o primeiro prompt é uma auditoria:

Examine o banco de dados, o código, as telas e as exportações deste app. Liste cada campo que possa conter dados pessoais de um funcionário ou candidato: nomes, IDs de funcionários, SSNs ou números de identificação nacional, identificadores fiscais, datas de nascimento, endereços residenciais, informações de saúde, condição de deficiência, registros de adaptações no trabalho, documentos de imigração ou autorização de trabalho, salário, bônus, participação acionária, avaliações de desempenho e notas disciplinares. Para cada campo, diga qual tela ou recurso o utiliza e se a função principal do app precisa dele. Se não conseguir determinar, marque como incerto em vez de adivinhar.

Verificação: abra as telas principais e as exportações da ferramenta e confira se todo campo de dados pessoais visível aparece na lista. Um campo que você vê, mas a lista não menciona, significa que a auditoria deixou algo passar, então pergunte novamente.

O segundo prompt retira o que a ferramenta não precisa. Ele depende de uma conta de banco de dados (a conta que o app usa para se comunicar com o banco), que pode ser limitada a campos específicos.

Altere este app para ler somente estes campos: [liste os campos necessários à ferramenta]. Remova todos os demais campos de dados pessoais da cópia dos dados do app, do código, de cada tela e de cada exportação. Depois crie uma conta de banco de dados separada para o app que possa ler apenas esses campos e alterar somente os dados que a própria ferramenta grava, como pedidos de ausência. Mude o app para usar essa conta. Relate exatamente o que alterou, arquivo por arquivo, e diga tudo que não conseguiu fazer.

Alterar apenas as telas não basta. Se a conta de banco de dados do app não consegue ler a coluna de salário, um bug em outra parte do código escrito pela IA também não consegue mostrá-la. Saber se os dados estão criptografados em repouso é uma questão para a TI, pois isso depende da configuração do servidor e do disco, que um assistente lendo o código não consegue ver com confiança.

Verificação: entre como usuário comum e abra cada tela e cada exportação; nenhum campo removido deve aparecer. Depois peça ao suporte de TI que administra o servidor (ou à ferramenta de IA, com a saída mostrada a você) para solicitar um campo removido usando a conta de banco de dados do app. Um erro de permissão negada ou dizendo que o campo não existe é aprovação. Um erro de conexão, sintaxe ou outro sem relação não é. Uma coluna vazia ou um valor real é reprovação. Guarde a lista da auditoria, porque a ferramenta de exclusão a utiliza.

Ofereça visualizações diferentes a administradores de RH, gestores e funcionários

É aqui que os dados dos funcionários vazam internamente, para o colega que abre o salário de outro ou a nota de adaptações no trabalho de alguém da equipe. O controle de acesso baseado em funções corrige isso, e o prompt abaixo define onde a verificação precisa acontecer:

Adicione controle de acesso baseado em funções com três funções, verificadas no servidor em cada requisição, não apenas ocultando botões ou links na página.

- Administrador de RH: pode ler e editar todos os registros dos funcionários.

- Gestor de pessoas: pode ler somente os registros de seus subordinados diretos e nunca vê campos de salário, saúde, adaptações no trabalho, disciplina ou imigração.

- Funcionário: pode ler somente seu próprio registro.

Recuse todo o resto com uma resposta «acesso negado» (403). Obtenha a função de cada usuário da conta com que entrou, nunca de algo que ele possa digitar ou alterar na página ou na barra de endereços. Liste cada local onde adicionou uma verificação e destaque qualquer página ou exportação sobre cuja cobertura tenha dúvidas.

Algumas empresas permitem que gestores vejam salários durante revisões de remuneração; se a sua permite, altere essa linha da função de gestor.

Verificação: crie um gestor e um funcionário de teste. Entrando como gestor, abra o registro de um subordinado direto, copie o endereço, mude o número do registro para alguém fora da equipe e carregue: você deve receber «acesso negado». Repita como funcionário com o número do registro de um colega. Depois confirme que a visualização do gestor nunca mostra campos de salário, adaptações no trabalho ou imigração.

Retire as credenciais do código e do chat

Uma senha de banco de dados ou token de API do HRIS ou da folha de pagamento (a chave longa que um sistema usa para entrar em outro) pode ser removida do código atual e continuar nas versões anteriores salvas do projeto; por isso o prompt também pergunta sobre o histórico. Uma variável de ambiente resolve a parte do código. É um valor que o servidor entrega ao app quando ele inicia, então o código o referencia pelo nome sem conter esse valor.

Encontre todas as senhas, chaves de API, tokens de acesso e strings de conexão de banco de dados neste projeto, incluindo os dos nossos sistemas HRIS, de folha de pagamento ou email. Substitua cada um no código por uma variável de ambiente e me forneça a lista dos nomes das variáveis. Garanta que arquivos que contêm os valores reais, como .env, sejam excluídos do repositório de código. Depois liste cada local em que um valor antigo ainda aparece no histórico do projeto, para eu saber quais credenciais substituir.

O prompt não consegue realizar a etapa mais importante. No console de administração do HRIS ou do banco de dados, emita uma credencial nova para cada uma que já apareceu em um chat ou no repositório e desative a antiga.

As cópias dessas senhas mantidas pela equipe devem ficar em um gerenciador de senhas, como um servidor Vaultwarden auto-hospedado (qual opção serve para uma equipe é uma decisão à parte). Ele armazena credenciais para pessoas e não fornece valores a um app em execução, que os recebe da ferramenta de implantação. Para segredos que o próprio app em execução lê, HashiCorp Vault é a opção mais complexa, com políticas centralizadas e rotação para equipes que precisam delas.

Verificação: peça à ferramenta de IA para procurar os valores antigos nos arquivos atuais e leia os resultados que ela mostra, não o resumo. Os arquivos atuais não devem ter correspondências. Correspondências no histórico são esperadas e não precisam ser apagadas; elas são a lista de credenciais a substituir. A prova de que cada uma foi desativada está no console de administração do HRIS ou do banco de dados: toda credencial antiga aparece como revogada, ou a TI confirma que o sistema a recusa.

Veja quais dados de funcionários saem da ferramenta

Depois que uma chamada envia as notas de entrevista de um candidato a um serviço externo, excluir o registro na sua ferramenta não alcança a cópia que esse serviço pode guardar. A solução é enviar menos dados desde o início.

Audite cada chamada externa que este app faz: para OpenAI, Anthropic ou qualquer outra API de IA, para sistemas de RH como HRIS ou ATS, para ferramentas de análise ou rastreamento de erros e para qualquer webhook. Para cada chamada, liste exatamente quais campos de funcionários ou candidatos estão no que é enviado. Destaque qualquer serviço que possa armazenar ou registrar o que recebe e diga quais chamadas poderiam funcionar com menos dados. Marque qualquer incerteza.

Verificação: crie um funcionário ou candidato fictício com um nome inventado e marcante, depois use cada recurso que faz uma chamada externa (gere o resumo da entrevista, acione o webhook, abra a página que carrega o script de análise). Abra o painel de cada serviço externo, como a ferramenta de análise, o rastreador de erros, o log de webhooks recebidos pelo ATS ou o log de uso do fornecedor de IA onde mostra requisições, e procure esse nome. Ele deve aparecer apenas onde a chamada precisa dele. Se aparecer em outro lugar, devolva essa chamada à ferramenta de IA com menos dados e repita a verificação. Alguns painéis não mostram o que receberam. Para esses, e para qualquer serviço que precise continuar recebendo dados de funcionários, leve os termos de retenção de dados à pessoa que assina contratos com fornecedores na sua empresa.

Registre quem abriu cada registro de funcionário

Um funcionário pergunta quem exportou a planilha de salários no trimestre passado. Sem um log de auditoria (um registro contínuo de quem fez o quê em qual registro), ninguém consegue responder.

Adicione um log de auditoria. Sempre que um usuário visualizar, editar, exportar ou excluir um registro de funcionário, adicione uma linha com o ID do usuário, o ID do registro do funcionário, a ação, os campos alterados e o horário. Configure o banco de dados para que a conta do app possa adicionar linhas ao log, mas não editar nem excluir. Somente administradores de RH podem ler o log no app. Diga como e onde a proibição de edição e exclusão é aplicada.

A propriedade «somente acrescentar» precisa vir das permissões da conta de banco de dados, não da promessa do app de se comportar. O log também é dado pessoal por si só, pois mostra quem consultou o registro de quem; por isso apenas administradores de RH o leem.

Verificação: como administrador de RH, abra um registro, depois veja o log e confirme que a entrada está lá. Peça à TI ou à ferramenta de IA (com a saída mostrada a você) para tentar excluir uma linha do log usando a conta de banco de dados do app; você deve ver o próprio erro de permissão.

Trate pedidos de exclusão sem violar as regras de retenção

O que acontece quando um funcionário pede exclusão e alguns de seus registros são arquivos de folha de pagamento que a empresa precisa guardar? O prompt óbvio («exclua todos os dados pessoais deste funcionário em todas as tabelas») os exclui mesmo assim, causando dois problemas. Empregadores frequentemente precisam guardar alguns registros, como arquivos de folha de pagamento, impostos e autorização de trabalho, e o direito de exclusão do GDPR não se aplica na medida em que o tratamento é necessário para cumprir uma obrigação legal ou para pretensões jurídicas (Artigo 17(3)(b) e (e)). Um botão de excluir tudo também é uma função perigosa para deixar disponível. A versão mais segura separa «excluir mediante solicitação» dos registros sujeitos a retenção obrigatória, ou seja, aqueles que a empresa precisa guardar independentemente do pedido, e mostra o plano antes de excluir qualquer coisa:

Crie uma ferramenta de pedidos de exclusão que somente administradores de RH possam abrir. Dado um ID de funcionário, ela primeiro mostra cada tabela e campo com os dados dessa pessoa, agrupados nas categorias da auditoria dos campos. Cada categoria tem uma configuração de retenção definida por um administrador de RH: «excluir mediante solicitação» ou «manter: retenção obrigatória». Após a confirmação de um administrador de RH, a ferramenta exclui somente as categorias configuradas como «excluir mediante solicitação». Ela registra apenas o ID do funcionário, o horário, quem confirmou e quais categorias foram excluídas ou mantidas, e nada mais sobre a pessoa. Quem não é administrador de RH recebe «acesso negado».

As configurações de retenção vêm do responsável por conformidade ou do DPO, não da ferramenta de IA nem do melhor palpite do criador. Informe que o log de auditoria mantém o ID do funcionário após uma exclusão, para que decidam por quanto tempo esse identificador deve permanecer. Backups e cópias mantidas por serviços externos precisam de seus próprios processos de retenção ou exclusão.

Verificação: crie um funcionário de teste com registros em duas categorias, uma configurada como «excluir mediante solicitação» e a outra como retenção obrigatória. Execute a ferramenta como administrador de RH e confirme que apenas a primeira categoria desapareceu. Depois abra a ferramenta com uma conta de gestor e espere «acesso negado».

Regras trabalhistas para discutir com seu DPO ou responsável por conformidade

As regras trabalhistas que uma ferramenta de RH precisa observar dependem do que ela faz e de quem são os dados que contém, não de como foi criada. Esta é uma lista de regras para discutir com seu DPO ou responsável por conformidade, não aconselhamento jurídico, e não determina se alguma se aplica a você.

Um controle de ausências com notas de adaptações no trabalho de pessoas na Alemanha e na Califórnia observa regras diferentes de um planejador de pessoal que contém apenas títulos de cargos. A questão da Lei de IA da UE fica na verificação sobre decisões de contratação.

A localização do servidor determina onde os registros ficam fisicamente; por si só, não atende a nenhuma regra acima. Para funcionários fora desses lugares, comece pelo regulador nacional, estadual ou local de privacidade ou trabalho correspondente, ou pelo seu responsável jurídico ou de conformidade.

O acesso termina quando o vínculo de trabalho termina

Quando a conta corporativa de alguém que sai é desativada no último dia, seu email, calendário e arquivos ficam inacessíveis em uma única etapa. A ferramenta de RH deve encerrar o acesso nessa mesma etapa e, por trás da autenticação corporativa, pode fazer isso, desde que o desligamento também revogue sessões ativas. Qualquer ferramenta sem essa autenticação entra na lista de desligamento como um item próprio, para alguém remover a conta manualmente.

O criador também sairá algum dia. Quando a pessoa que criou a ferramenta sai ou muda de função, a responsabilidade passa para um sucessor identificado, capaz de entrar como administrador e que saiba onde está o servidor, e a conta de administrador do criador é encerrada. Eu nomearia esse sucessor antes da entrada em produção, pois o período de aviso prévio é uma hora ruim para procurar alguém.

Em uma periodicidade definida, revise quem tem cada função e se a ferramenta ainda está em uso. Quando o acesso precisar crescer, amplie um nível de cada vez (primeiro a equipe de RH, depois gestores, depois todos os funcionários) e repita o teste da barra de endereços em cada nível. Quando a ferramenta não for mais usada, retire-a de serviço: desative sua conta de banco de dados e credenciais, exclua seus dados conforme as configurações de retenção da ferramenta de exclusão, pare a execução e remova-a da rede privada ou do sistema de autenticação.

O sucessor identificado herda um servidor que alguém precisou configurar, com uma ferramenta de implantação, uma rede privada e, para acesso mais amplo, autenticação corporativa. Nosso VPS Linux oferece acesso root, e Coolify, Tailscale e Authentik são implantados como apps de um clique, para que o suporte de TI dedique suas horas às verificações. As localidades incluem Frankfurt e Amsterdã na UE, Londres no Reino Unido e várias cidades dos EUA. Isso define em qual país o servidor está, uma informação para a conversa com o DPO, não um substituto dela.

A lista de verificação para entrar em produção

Cada item abaixo está concluído ou não está antes de inserir registros de funcionários; esta é a lista a entregar a quem configura o servidor.

1. A pergunta sobre decisões de contratação está respondida, e todo «sim» foi encaminhado à TI e ao jurídico.
2. A ferramenta é executada em um servidor controlado pela equipe, não na hospedagem da ferramenta de IA.
3. Ela só é acessível pela rede privada ou por autenticação corporativa.
4. A conta de banco de dados do app lê somente os campos listados.
5. Um gestor e um funcionário de teste recebem ambos «acesso negado» no teste da barra de endereços.
6. Toda credencial que passou por um chat ou pelo código foi substituída, e a antiga foi revogada.
7. A auditoria dos dados de saída está concluída e os campos desnecessários foram removidos.
8. O log de auditoria registra visualizações, e a conta do app não pode editá-lo nem excluí-lo.
9. As configurações de retenção e as regras trabalhistas passaram pelo DPO ou pelo responsável por conformidade.
10. Há um responsável identificado e um substituto identificado.

Perguntas frequentes

O que é Shadow AI no RH?

Shadow AI no RH é o uso de ferramentas de IA, ou apps criados com elas, sobre dados de RH sem conhecimento ou aprovação da TI. A Sapient Insights 2026 Annual HR Systems Survey, conforme relatado pela Cornerstone OnDemand, descobriu que mais de 80% dos profissionais de RH usam ferramentas pessoais de IA diariamente, enquanto 3% usam a IA integrada em seus sistemas de RH.

Posso usar registros reais de funcionários enquanto crio a ferramenta?

Não. Mantenha registros reais fora do chat enquanto cria uma ferramenta de RH por vibe coding. Colá-los em um assistente de chat é um risco separado da implantação do app e surge no momento em que você cola, independentemente de a ferramenta entrar no ar. Desenvolva com registros fictícios até que a ferramenta seja executada em um servidor controlado pela equipe.

Os funcionários precisam consentir com o uso de seus dados por uma ferramenta de RH?

Em geral, o consentimento é a base errada. As diretrizes sobre consentimento do EDPB afirmam que «considera problemático que empregadores tratem dados pessoais de funcionários atuais ou futuros com base em consentimento, pois é improvável que ele seja dado livremente». Qual base legal se aplica pelo Artigo 6 do GDPR é uma questão para seu DPO.

A HIPAA abrange as notas médicas de uma ferramenta de RH?

Em geral, não. A definição de informação de saúde protegida da HIPAA exclui informações em registros de emprego mantidos por uma entidade abrangida em seu papel de empregador (45 CFR 160.103). Isso não torna essas notas desreguladas, então pergunte ao responsável por conformidade quais regras as abrangem.