Quando a tecnologia falha: lições de um caso de assédio moral para engenheiros de software

Você já parou para pensar no que acontece quando os sistemas que projetamos — e nos quais confiamos — falham justamente na proteção das pessoas mais vulneráveis dentro de uma organização? Um caso recente, que ganhou repercussão no portal piaui.uol.com.br, relata a história de uma funcionária de uma igreja evangélica que, após sofrer assédio moral constante, foi demitida enquanto o agressor permaneceu no cargo. A decisão judicial condenou a instituição, mas o dano — profissional, psicológico e moral — já estava consumado. A pergunta que fica para nós, profissionais de tecnologia, é: que papel os sistemas que construímos desempenham nesse tipo de dinâmica? Será que nossas plataformas de comunicação, ferramentas de registo de ocorrências e dashboards de RH estão realmente ajudando a documentar abusos ou, por omissão de design, permitindo que eles se perpetuem?

Não se engane: o ambiente corporativo de tecnologia não está imune a esses problemas. Muito pelo contrário. Startups de alto crescimento, empresas de software e até mesmo gigantes da nuvem frequentemente enfrentam denúncias de assédio moral e sexual, cultura tóxica e retaliação contra denunciantes. A diferença é que, no setor de tecnologia, temos ferramentas — logs de comunicação, sistemas de ticketing, plataformas de feedback anônimo, políticas de acesso a dados — que poderiam, em tese, fornecer evidências objetivas. Mas a tecnologia, sozinha, não resolve nada se a cultura organizacional a utiliza como um escudo ou, pior, como um instrumento de controle sobre a vítima.

O caso concreto como ponto de partida

Segundo a reportagem da Maitê Silveira, a igreja condenada por assédio moral demitiu a vítima e manteve o agressor. Isso não é um mero erro de gestão de pessoas; é um sintoma de um sistema que privilegia a hierarquia e a lealdade institucional em detrimento da dignidade humana. No mundo corporativo de tecnologia, vemos paralelos inquietantes: funcionários que denunciam assédio são frequentemente isolados, colocados em projetos periféricos ou demitidos sob justificativas de "reorganização". A tecnologia, nesse contexto, muitas vezes é usada para monitorar o desempenho da vítima (número de commits, horas logadas, produtividade) enquanto o comportamento do agressor passa despercebido porque ele está "bem avaliado" ou porque suas comunicações abusivas são informais, em canais não registrados.

Do ponto de vista técnico, isso expõe uma fragilidade fundamental: confiar apenas em métricas quantitativas para avaliar conduta é perigoso. Um engenheiro que assedia pode ter alta produtividade, enquanto a vítima, sob estresse constante, pode ter sua performance reduzida — criando um ciclo vicioso onde os dados parecem justificar a demissão da pessoa que sofreu o abuso. É um viés algorítmico que não vem de um modelo de ML, mas de um desenho de processo que privilegia o que é mensurável em detrimento do que é humano.

Sistemas de denúncia anônima: entre a eficácia e o risco de chilling effect

Muitas organizações investem em plataformas de denúncia anônima, como canais de ética, formulários criptografados ou serviços terceirizados (ex.: EthicsPoint, Resolve). Na teoria, são uma ferramenta poderosa para quebrar o ciclo do silêncio. Na prática, porém, enfrentam dois grandes desafios: a confiança no anonimato e a capacidade de investigação. Se o sistema não for tecnicamente robusto — com logs que preservem o anonimato do denunciante, criptografia de ponta a ponta e políticas claras de retenção de dados — as pessoas não o utilizarão. E mesmo quando utilizam, se a investigação for conduzida por pessoas alinhadas à liderança, a denúncia pode ser arquivada ou, pior, vazar.

Do ponto de vista de engenharia, projetar um sistema de denúncia anônima seguro exige considerações complexas de privacidade e segurança da informação. Por exemplo: como garantir que metadados (IP, timestamp, padrão de digitação) não revelem a identidade do denunciante? Como evitar que o administrador do sistema possa acessar o conteúdo das denúncias sem autorização judicial ou aprovação do conselho? Já implementei sistemas similares para clientes corporativos, e cada um desses pontos é um trade-off delicado. Um sistema excessivamente seguro (com criptografia que impede qualquer acesso mesmo em investigações legítimas) pode inviabilizar a apuração; um sistema muito acessível expõe denunciantes a retaliação. O equilíbrio ideal envolve criptografia assimétrica com chaves separadas para diferentes áreas (ex.: compliance, jurídico, RH), auditoria de acesso e logs imutáveis — mas sempre com a ressalva de que a segurança do processo depende tanto da tecnologia quanto da governança.

Logs de comunicação: a faca de dois gumes

Em ambientes de tecnologia, toda comunicação deixa rastros: e-mails, mensagens em Slack/Teams, comentários em Jira, gravações de reuniões. Esses logs podem ser evidências cruciais em casos de assédio, mas também podem ser usados para monitorar e punir a vítima. A história de Fernanda* (nome fictício usado na reportagem) mostra que muitas vezes o assédio moral não deixa provas digitais claras — ele ocorre em conversas presenciais, em ligações telefônicas ou em mensagens informais que são apagadas. A ausência de logs favorece o agressor e dificulta a defesa da vítima.

Isso levanta uma questão ética para engenheiros de software: devemos projetar sistemas que gravem toda comunicação? Além dos óbvios problemas de privacidade (LGPD, leis trabalhistas), a gravação massiva pode criar um ambiente de vigilância sufocante, onde as pessoas se sentem inibidas mesmo em interações legítimas. Por outro lado, a ausência de registros permite que abusos fiquem impunes. A solução não é radical, mas sim pragmática: políticas claras de retenção de dados, gravação apenas de canais formais (e-mails, reuniões agendadas) com consentimento informado, e acesso restrito a esses dados apenas mediante processo de investigação formal.

Em um projeto que liderei para uma fintech, implementamos um sistema de gravação automática de chamadas de voz para compliance regulatório, mas com criptografia que impedia que gestores diretos acessassem as gravações de seus subordinados sem aprovação do jurídico. O trade-off foi alto: custo de armazenamento, complexidade de gerenciamento de chaves e atrito na usabilidade (pedidos de acesso demoravam dias). Mas reduziu significativamente o risco de retaliação. Não é uma bala de prata, mas é um desenho consciente.

O papel dos engenheiros na prevenção de assédio moral

Engenheiros de software, arquitetos e líderes técnicos têm um poder silencioso na definição das normas de conduta dentro das organizações. Quando projetamos sistemas de avaliação de desempenho (como o famoso stack ranking), métricas de produtividade individual ou dashboards de RH, estamos moldando incentivos que podem tanto proteger quanto expor pessoas a abusos. Um exemplo concreto: um sistema que exibe publicamente o número de tarefas fechadas por desenvolvedor pode criar uma competição tóxica, onde a pressão por resultados justifica comportamentos agressivos. Já vi times onde o assédio moral era encoberto porque o agressor era um "top performer" — e nenhum dado no sistema apontava para seu comportamento abusivo.

Minha recomendação: ao desenhar qualquer ferramenta de gestão de pessoas, inclua indicadores qualitativos (feedback 360 anônimo, pesquisas de clima, registros de interações) tanto quanto os quantitativos. E mais importante: garanta que o sistema permita que a vítima registre incidentes sem medo de retaliação técnica (como bloqueio de acesso, alteração de permissões ou exclusão de dados). Isso pode ser feito com workflows de denúncia que preservem o anonimato e que só sejam acessíveis por um comitê independente.

Privacidade e proteção de dados: o que a LGPD tem a ver com isso

A Lei Geral de Proteção de Dados (LGPD) brasileira impõe restrições ao tratamento de dados pessoais de funcionários, incluindo registros de comunicação e avaliações de desempenho. Em um caso de assédio, a vítima pode solicitar acesso aos seus próprios dados (artigo 18) para usar como prova. Mas o agressor também pode exigir a exclusão de dados (artigo 18, inciso IV) que o incriminem — gerando conflitos legais. Como engenheiros, precisamos projetar sistemas que implementem políticas de retenção e exclusão de forma granular, permitindo que dados relevantes para investigações sejam preservados mesmo diante de solicitações de exclusão por parte de outros titulares.

Uma abordagem que adoto em projetos é o uso de "data lakehouses" com camadas de tempo real e camada de arquivamento, onde logs de comunicação são mantidos por período legal mínimo (ex.: 5 anos para ações trabalhistas) mas com criptografia que só pode ser quebrada por um comitê multidisciplinar (jurídico+RH+segurança). Isso atende à LGPD (pois limita o acesso ao estritamente necessário) e ao mesmo tempo preserva evidências para casos de assédio. É caro, é complexo, mas é o tipo de sofisticação que organizações sérias precisam adotar.

O viés de confirmação das lideranças técnicas

Outro ponto que merece reflexão: muitas vezes os líderes técnicos (CTOs, VPs de Engenharia) são relutantes em acreditar em denúncias de assédio contra engenheiros seniors ou arquitetos que eles mesmos contrataram ou mentoraram. O viés de confirmação faz com que busquem dados que justifiquem inocentar o profissional. Isso é agravado quando os logs de comunicação mostram apenas um lado da história (ex.: a vítima respondeu com irritação a uma provocação, e o sistema registra a resposta mas não a provocação). Projetar sistemas que capturem o contexto completo — como gravação de reuniões inteiras, não apenas fragmentos — é tecnicamente desafiador, mas eticamente necessário. No entanto, é preciso balancear com privacidade e custo.

Já atuei como consultor em um caso onde um engenheiro sênior foi acusado de assédio moral verbal, mas as únicas evidências eram relatos de colegas (sem gravação). O sistema de chat corporativo mantinha logs por apenas 30 dias, e as mensagens incriminadoras já haviam expirado. A vítima foi demitida meses depois por "baixa performance". A tecnologia não impediu a injustiça — pelo contrário, a política de retenção curta favoreceu o apagamento das provas. Essa lição me fez defender prazos de retenção mais longos para canais de comunicação formais, combinados com notificações claras aos funcionários sobre a gravação.

Implicações para o mercado de trabalho em tecnologia

Para profissionais de tecnologia, o caso da igreja condenada serve como um alerta sobre a fragilidade dos mecanismos de proteção em qualquer tipo de organização — secular ou religiosa. Em empresas de tecnologia, onde a cultura é frequentemente celebrada como "progressista", os abusos podem ser ainda mais insidiosos porque são mascarados por discursos de meritocracia e flexibilidade. A ausência de sindicatos fortes e a alta rotatividade tornam mais fácil para as empresas demitirem silenciosamente quem denuncia.

Do ponto de vista de carreira, sugiro que engenheiros e líderes técnicos se envolvam ativamente na definição das políticas de compliance digital de suas organizações. Isso inclui: participar da escolha de ferramentas de denúncia (exigindo transparência sobre logs e acesso), questionar métricas de produtividade que possam ser usadas como arma, e defender prazos de retenção de dados que não prejudiquem vítimas. Em startups, onde o time de RH é enxuto, são os engenheiros que muitas vezes implementam esses sistemas — e com isso carregam a responsabilidade moral de fazê-lo corretamente.

Uma perspectiva pessoal sobre o que muda

Se você, leitor(a), trabalha com desenvolvimento de software, infraestrutura ou produto, tenho um convite: na próxima vez que projetar uma funcionalidade que armazena ou processa dados de pessoas, pergunte-se: "Esse sistema tornaria mais fácil ou mais difícil para uma vítima de assédio provar sua história? Ele protege o denunciante ou o agressor?" A resposta muitas vezes revela vieses implícitos no design — e corrigi-los é uma contribuição silenciosa, mas profunda, para um ambiente de trabalho mais justo. Não existem soluções tecnológicas perfeitas, mas existem escolhas conscientes. E como engenheiros, temos o dever de fazer essas escolhas com os olhos abertos para as consequências reais, dentro e fora da tela.

*Nome fictício conforme reportagem original da piauí UOL.