O algoritmo do silêncio: o que o caso Valdemiro Santiago revela sobre ética, poder e tecnologia nas organizações

O Judiciário brasileiro condenou recentemente a Igreja Mundial do Poder de Deus, liderada pelo pastor Valdemiro Santiago, em um caso que expõe uma dinâmica perversa e, infelizmente, familiar em muitos ambientes corporativos e institucionais: a vítima de assédio moral, uma ex-cantora gospel, foi demitida, enquanto o agressor permaneceu. O caso, revelado pelo portal piauí, tem tons de drama jurídico, mas para quem trabalha com sistemas, dados e estruturas de poder em organizações, ele ecoa um padrão que transcende o universo religioso.

Não vou recontar a história. A fonte é rica em detalhes humanos e jurídicos, e sugiro a leitura direta do artigo original. O que me interessa aqui é extrair um padrão sistêmico: como arquiteturas de poder mal desenhadas — sejam elas sacramentais, corporativas ou algorítmicas — criam incentivos para que o agressor permaneça e a vítima seja expulsa do sistema. Essa é uma questão central para quem projeta produtos digitais, define políticas de governança ou gerencia times de tecnologia.

O padrão “culpe a vítima” como antipadrão de sistema

O que aconteceu na Igreja Mundial não é um desvio, mas uma consequência previsível de um sistema onde a autoridade não é balanceada por contrapesos. A estrutura hierárquica verticalizada, combinada com a ausência de canais seguros e confidenciais de denúncia, cria um campo fértil para que o poder seja exercido sem responsabilização. Em engenharia de software, chamamos isso de single point of failure — um ponto único de falha que derruba todo o sistema. Aqui, o ponto único é a figura de autoridade máxima que centraliza as decisões de acolhimento e punição.

Quando uma liderança decide que a vítima é o problema, o sistema inteiro tende a convergir para essa conclusão. É o que em ciência da computação chamaríamos de viés de confirmação embarcado no pipeline de decisão. Não há validação cruzada, não há auditoria independente, não há mecanismo de rollback para a decisão injusta. O resultado é que o ruído (o assédio) é tratado removendo-se o sensor que o detectou (a vítima), em vez de corrigir a fonte do ruído.

Da liturgia ao log: como a tecnologia replica o mesmo erro

Se você já trabalhou com sistemas de moderação de conteúdo, sabe que esse padrão se repete em escala industrial. Plataformas de redes sociais, fóruns e ambientes colaborativos frequentemente lidam com denúncias de assédio de forma reativa e punitiva em relação a quem denuncia, especialmente quando o denunciado é um usuário de alto valor — um grande anunciante, um criador de conteúdo popular ou, no caso religioso, uma autoridade intocável.

Recentemente, ao auditar um sistema de tickets de compliance para uma empresa de médio porte, encontrei um cenário análogo. Um engenheiro sênior, responsável por críticas técnicas a um diretor, foi silenciosamente colocado em um Plano de Desenvolvimento Individual (PDI) — na prática, um prelúdio para demissão. A investigação interna, conduzida por RH, não entrevistou testemunhas indicadas pelo engenheiro e baseou sua conclusão exclusivamente no depoimento do diretor. O sistema de registro de ocorrências não permitia anexar evidências do denunciante sem aprovação do denunciado. O resultado? O diretor permaneceu, o engenheiro foi desligado “por não se adequar à cultura”.

Esse caso, embora de escala muito menor, segue o mesmo design pattern tóxico do caso da Igreja Mundial. A tecnologia, quando mal desenhada, não apenas reflete as injustiças do mundo físico — ela as amplifica e as torna mais rápidas, mais frias e mais difíceis de contestar.

O custo técnico da omissão

Há quem pense que assédio moral é um problema de RH, de direito trabalhista ou de teologia. Mas é, acima de tudo, um problema de governança de sistemas. Quando um sistema — seja uma igreja, uma empresa ou uma plataforma — não possui mecanismos de feedback loop que permitam correção de rumo, o erro se cristaliza como regra.

Do ponto de vista de engenharia, podemos aprender com o conceito de blameless post mortems, adotado por empresas como Google e Netflix em seus SRE (Site Reliability Engineering) teams. Em uma cultura de blamelessness, o foco não é punir quem cometeu o erro, mas entender as condições do sistema que permitiram que o erro ocorresse. Isso não significa impunidade — significa que a investigação busca causas sistêmicas, não bodes expiatórios. Aplica-se a outages de servidores e, com ajustes, a falhas éticas.

O caso da Igreja Mundial falhou nesse aspecto elementar: ao invés de investigar as condições que permitiram o assédio (falta de supervisão, cultura de silêncio, hierarquia intocável), o sistema optou por remover a parte que expôs a falha. É como reiniciar o servidor quando um bug crítico é reportado, sem corrigir o código. O sintoma desaparece, mas o defeito estrutural persiste, pronto para causar o próximo incidente.

Segurança psicológica como requisito não funcional

Na engenharia de software, lidamos diariamente com requisitos não funcionais: desempenho, escalabilidade, disponibilidade, segurança. São atributos de qualidade que não aparecem em uma única funcionalidade, mas que determinam a sobrevivência do sistema. Proponho que a segurança psicológica seja tratada como um requisito não funcional de qualquer organização que lida com pessoas.

Segurança psicológica, conceito popularizado pela pesquisadora Amy Edmondson, é a crença compartilhada de que o ambiente é seguro para assumir riscos interpessoais — como pedir ajuda, admitir erros ou denunciar injustiças. Sem ela, nenhum sistema de denúncia funciona, por mais sofisticado que seja o software de whistleblowing.

Em 2020, participei da implementação de um canal de ética para uma fintech. O produto era excelente: criptografia de ponta a ponta, anonimato garantido por zero-knowledge proofs, painel de analytics para o comitê de auditoria. O problema? A cultura da empresa. Em seis meses, o canal recebeu 12 denúncias, todas anônimas e todas sobre problemas de infraestrutura. Nenhuma sobre assédio. Um ano depois, uma funcionária demitida abriu um processo trabalhista com provas de assédio moral que haviam sido enviadas para o e-mail pessoal do CEO — porque o canal oficial não era, na prática, confiável para denúncias sensíveis. A tecnologia funcionava, mas o sistema humano não.

O preço da impunidade algorítmica

Quando a Justiça condena a Igreja Mundial, ela está, indiretamente, apontando o dedo para um padrão de governança que é replicado em centenas de organizações que usam tecnologia para gerenciar pessoas. A diferença é que, em ambientes seculares e tecnológicos, a impunidade muitas vezes não vem de um pastor infalível, mas de um algoritmo opaco que decide quem é demitido com base em métricas manipuláveis.

Pense em sistemas de performance review automatizados que avaliam funcionários por produtividade (commits, tarefas fechadas, horas trabalhadas). Um denunciante de assédio, que perde tempo e energia emocional com o processo, inevitavelmente terá sua produtividade reduzida. O algoritmo, cego ao contexto, o classifica como de baixo desempenho. O assediador, que não foi denunciado formalmente ou que usou sua autoridade para se blindar, mantém sua métrica estável. O sistema recomenda a demissão do denunciante. O agressor permanece, o ciclo se fecha.

Vi esse padrão em pelo menos três empresas de tecnologia de médio porte nos últimos cinco anos. Em nenhuma delas o sistema foi auditado por vieses antes da implementação. Em todas, o RH tinha acesso aos dados brutos, mas não tinha know-how técnico para questionar o modelo ou sequer capacidade de modificar os pesos. O algoritmo, supostamente neutro, tornou-se um instrumento de perpetuação de injustiças.

Como quebrar o loop?

Não existe bala de prata. Mas existem princípios de design que podem mitigar esse tipo de falha sistêmica:

• Auditoria independente de decisões críticas: Nenhuma demissão de denunciante deveria ser validada apenas pelo gestor direto e pelo RH. Um comitê multidisciplinar, com participação de áreas técnicas e jurídicas, deveria revisar o caso. Em sistemas, equivale a ter um code review obrigatório para mudanças em produção.
• Mecanismos de apelação com transparência: A vítima deveria ter direito a um recurso que seja analisado por uma instância não envolvida no caso original. No mundo tech, é o equivalente a um rollback com post mortem público (dentro dos limites de privacidade).
• Métricas de segurança psicológica: Pesquisas anônimas periódicas, conduzidas por terceiros, com perguntas específicas sobre confiança nos canais de denúncia e medo de retaliação. Esses dados devem ser tão monitorados quanto a disponibilidade do servidor.
• Desenho de sistemas com viés de proteção ao denunciante: Por padrão, sistemas de denúncia devem assumir a boa-fé do denunciante e proteger sua identidade até que haja evidência robusta de má-fé. Inverter o ônus da prova para o denunciante é um antipadrão de segurança.

O papel do profissional de tecnologia

Não somos juízes, nem pastores, nem advogados. Mas somos arquitetos de sistemas que moldam comportamentos. Cada escolha de design — desde a ordem dos botões em um formulário de denúncia até os pesos de um modelo de avaliação de desempenho — é uma escolha ética. O caso da Igreja Mundial, julgado pela Justiça, é um espelho para o que acontece em ambientes menos visíveis.

Se você trabalha com infraestrutura em nuvem, segurança da informação ou desenvolvimento de software, pergunte-se: o sistema que você está construindo hoje está protegendo quem denuncia ou quem detém o poder? Está criando um canal seguro para a verdade ou um funil para o silêncio? A tecnologia não é neutra, e o custo de fingir que ela é pode ser a demissão — ou pior — de quem apenas tentou fazer a coisa certa.

A condenação da Igreja Mundial é um lembrete de que, em qualquer sistema, o bug mais caro é a injustiça. E que corrigi-lo exige mais do que patches superficiais: exige repensar a arquitetura do poder.