Imagine uma situação onde uma pessoa denuncia seu gestor. Embora não relacione a denúncia ao ID interno, mantém comunicação por protocolo anônimo. Essa pessoa passa a deixar de participar de reuniões importantes, perder um projeto importante e receber uma avaliação muito abaixo do histórico. Embora nenhum desses eventos provem retaliação, ignorar a sequência também não parece uma boa ideia. A pergunta técnica interessante passa a ser: como detectar possíveis sinais de retaliação sem transformar o denunciante em alguém permanentemente monitorado? O modelo mais simples seria também o mais perigoso. Uma implementação ingênua poderia fazer algo assim: permitir acompanhar qualquer mudança, criar um belo sistema de vigilância e aumentar muito o número de pessoas e serviços capazes de descobrir quem fez a denúncia. Para proteger o anonimato, o sistema passaria a criar mais vínculos com a identidade, o que é exatamente o oposto do que queremos. Talvez o objeto monitorado não deva ser a pessoa. Uma alternativa é inverter o modelo. Em vez de acompanhar continuamente o funcionário, o sistema acompanha eventos organizacionais relevantes. E os sistemas internos podem produzir eventos como: um mecanismo de regras verifica apenas se existe um contexto de proteção ativo relacionado àquele evento. O evento gera uma revisão, não uma conclusão. Correlação temporal não é causalidade. Esse provavelmente seria um dos maiores erros de implementação. A análise humana ainda precisaria responder coisas como: a avaliação já estava em preparação antes da denúncia? Existiam problemas anteriores documentados? Essa pessoa estava envolvida no caso? Outras pessoas receberam avaliações semelhantes? Portanto, eu evitaria até usar internamente algo como: Isso pode passar uma falsa sensação de precisão para algo extremamente contextual. Talvez seja melhor trabalhar com sinais de risco. E deixar a conclusão para quem estiver conduzindo a análise. O vínculo entre denúncia e identidade é o ponto mais sensível. A partir do momento em que existe acompanhamento pós-denúncia, surge um problema inevitável: em algum lugar o sistema precisa saber quem deve ser protegido. Se isso for modelado de forma ruim: acabamos destruindo parte da separação que o canal anônimo deveria oferecer. Uma abordagem melhor pode envolver armazenamento separado. O sistema de investigação não necessariamente precisa acessar a identidade. O serviço responsável por verificar eventos também não precisa conhecer o conteúdo da denúncia. Cada componente sabe apenas o que precisa saber. Não resolve todos os problemas reduz bastante a superfície de exposição. O administrador da empresa deveria conseguir ver isso? Aqui aparece outro problema interessante de SaaS B2B. Normalmente existe uma tendência de implementar: para esse tipo de produto, isso pode ser perigoso. Imagine que o diretor de uma área seja administrador da conta. Agora imagine que exista uma denúncia contra ele. Se tenant_admin significa “pode ver qualquer coisa”, toda a separação anterior deixa de servir. Permissão baseada somente em papel: a autorização precisa considerar contexto. Quem você é não deveria ser a única variável. Também importa sua relação com aquele caso específico. E quem pode acessar o contexto de proteção? Talvez nenhuma pessoa diretamente, na maior parte do tempo. Esse tipo de dado pede algo próximo de um mecanismo de break glass . Idealmente, cada acesso deveria deixar rastros suficientes para responder posteriormente: porque existe outro vetor de risco aqui: o próprio funcionário com acesso privilegiado pode ser a origem do vazamento. Audit log não deveria registrar somente alterações. Em muitos sistemas, o log guarda ações como: Mas em dados extremamente sensíveis, visualização também é um evento relevante. Claro que o próprio log não deve copiar o dado sensível: Senão resolvemos um problema criando outro. O prazo de acompanhamento também deveria ser parte do modelo. Outro ponto interessante é evitar que esse contexto fique ativo indefinidamente. Uma organização pode definir uma janela de acompanhamento, por exemplo: 60, 90 ou outro número de dias dependendo da política. O sistema também pode permitir extensão manual se houver uma justificativa. Evento relevante não significa evento negativo: isso também muda bastante a arquitetura. Talvez não seja necessário copiar todos os dados de RH para dentro do sistema de denúncias. O HRIS pode simplesmente emitir um evento: o serviço de proteção verifica se existe algum contexto relacionado. O produto de denúncias não precisa virar um espelho do banco de RH inteiro. Isso ajuda bastante com minimização de dados. O caso de retaliação deveria ser separado da denúncia original: depois surge uma possível retaliação. Só que são duas investigações diferentes. Alguém tomou uma medida prejudicial em razão da denúncia? Inclusive, a denúncia original pode ser considerada improcedente e ainda assim existir retaliação. Quanto mais um sistema tenta proteger alguém contra retaliação, maior a tentação de coletar informações sobre essa pessoa. Só que cada novo dado também aumenta o risco de identificação, vazamento e abuso. Então talvez a arquitetura certa não seja a que “monitora melhor”. Talvez seja a que consegue detectar o mínimo necessário sem centralizar informação demais. Para mim, o princípio ficaria próximo disso: o formulário anônimo é provavelmente a parte mais simples desse sistema. O problema realmente interessante aparece quando tentamos preservar a confiança depois que alguém apertou Enviar . Contexto: trabalho como CTO e cofundador da Sigilo, onde desenvolvemos sistemas de denúncia e feedback organizacional com foco em privacidade. Esse tipo de problema aparece quando tentamos transformar uma regra de governança — “proteja quem denunciou” — em algo que o software consiga apoiar sem criar uma nova superfície de vigilância. Tenho curiosidade sobre como vocês modelariam isso: vocês manteriam algum vínculo técnico entre identidade e contexto de proteção ou tentariam tornar essa correlação possível apenas em situações excepcionais?
