Plataforma de canal de denúncias: o que ela precisa ter

A empresa decide ter um canal de denúncias. Alguém cria um endereço do tipo etica@empresa.com.br, coloca no rodapé do site e no mural do refeitório, e o assunto parece resolvido. Seis meses depois, a caixa tem três mensagens: uma reclamação de cliente, um spam e um relato sério sobre um gerente, enviado de um e-mail pessoal com nome e sobrenome. Quem leu foi justamente uma pessoa da equipe desse gerente.

O problema não é falta de boa vontade. É que um canal de denúncias é um sistema com regras de segurança próprias: precisa receber relatos sem expor quem relata, permitir conversa com alguém que não se identificou, mostrar cada caso só para quem pode vê-lo e registrar cada passo da apuração. E-mail, formulário genérico e planilha não fazem nada disso.

Há também um lado regulatório. A Lei 14.457/2022 exige que empresas com CIPA tenham procedimentos para receber e acompanhar denúncias de assédio, garantido o anonimato de quem denuncia, e o Decreto 11.129/2022, que regulamenta a Lei Anticorrupção, lista canais de denúncia entre os parâmetros de avaliação de programas de integridade.

Este texto descreve o que uma plataforma de canal de denúncias precisa ter, do ponto de vista do sistema. As exigências legais e de programas de integridade mudam com o porte, o setor e a norma aplicável, e devem ser validadas com o jurídico; aqui o foco é o que o software precisa suportar para que essas exigências sejam cumpridas na prática.

O que uma plataforma de canal de denúncias precisa ter

Para quem está avaliando o tema agora, este é o resumo. Uma plataforma que funciona tem, no mínimo:

1. Recebimento anônimo de verdade, sem coletar dado que identifique quem relata, a menos que a pessoa decida se identificar.
2. Protocolo e senha de acompanhamento, para que o denunciante volte, veja o andamento e responda a perguntas sem revelar quem é.
3. Segregação de acesso: cada caso visível apenas para quem tem papel na apuração, com regra para quando o denunciado está na própria linha de tratamento.
4. Fluxo de apuração com prazos, etapas definidas e alertas quando um caso fica parado.
5. Trilha de auditoria de tudo o que acontece com cada relato: quem abriu, quem leu, quem alterou, quem encerrou.
6. Relatórios agregados para diretoria e comitê, sem expor detalhes que identifiquem pessoas.
7. Múltiplas portas de entrada (site, link interno, QR code, telefone transcrito) caindo no mesmo fluxo.

Por que um e-mail não serve como canal de denúncias

Um endereço de e-mail falha em quase todos os itens da lista anterior:

• Não há anonimato. O remetente aparece no cabeçalho. Quem quer se proteger precisa criar uma conta nova, e a maioria desiste antes disso.
• Não há conversa com anônimo. Se o relato chega incompleto, não existe forma de pedir mais detalhes a quem escreveu de um endereço descartável que nunca mais será aberto.
• O acesso é tudo ou nada. Quem tem a senha da caixa vê todos os relatos, inclusive os que envolvem a própria pessoa ou seu chefe.
• Não há prazo nem etapa. O e-mail lido vira e-mail esquecido. Ninguém sabe quantos casos estão abertos nem há quanto tempo.
• Não há registro confiável. Mensagens podem ser apagadas ou encaminhadas sem rastro, e numa eventual disputa a empresa não consegue mostrar o que fez com cada relato.

Formulário genérico e planilha de controle não mudam o quadro: o relato costuma cair no mesmo e-mail.

Anonimato de verdade: o que o sistema precisa garantir

Anonimato não é esconder o campo "nome" do formulário. É garantir que nenhuma parte do sistema guarde algo que permita chegar a quem relatou. Os pontos técnicos que fazem diferença:

• Não registrar IP nem identificadores do dispositivo associados ao relato. Muitos servidores e serviços de hospedagem gravam o IP de cada acesso por padrão; o canal precisa ser configurado para não fazer isso nas rotas de envio e acompanhamento.
• Não exigir login corporativo. Se o colaborador precisa entrar com o usuário da rede para relatar, o anonimato acabou. O canal deve ser acessível de fora da rede da empresa, inclusive pelo celular pessoal.
• Limpar metadados de anexos. Foto tirada no celular carrega data, hora, modelo do aparelho e, às vezes, localização. Documento de texto carrega o nome do autor. A plataforma deve remover esses metadados ao receber o arquivo.
• Não usar ferramentas de rastreamento nas páginas do canal. Scripts de análise de tráfego, pixels de anúncio e mapas de clique não têm lugar ali.
• Orientar quem escreve. Um aviso curto antes do envio ("evite detalhes que só você saberia, como o horário exato em que estava sozinho na sala") protege mais do que qualquer criptografia.
• Permitir identificação opcional. Algumas pessoas querem se identificar. O sistema deve aceitar as duas formas e tratar o dado de identificação com acesso ainda mais restrito.

Vale dizer com clareza: o sistema garante que ele próprio não identifica o denunciante. O conteúdo do relato ainda pode identificar, e isso só se resolve com orientação e com cuidado de quem apura.

Protocolo e acompanhamento pelo denunciante

Ao enviar o relato, a pessoa recebe um número de protocolo e uma senha gerados pelo sistema. Com eles, volta ao canal quando quiser para:

• ver em que etapa o caso está (recebido, em análise, em apuração, concluído);
• responder perguntas de quem apura, numa conversa dentro da plataforma;
• enviar documentos ou informações novas;
• receber um retorno sobre o encerramento, no nível de detalhe que a política da empresa permitir.

Três decisões de desenho evitam dor de cabeça:

Protocolo e senha não podem ser recuperados. Se houvesse "esqueci minha senha" por e-mail, haveria um e-mail ligado ao relato. A tela final precisa deixar isso claro e oferecer a opção de salvar ou imprimir os dados.

A senha não fica guardada em texto aberto. O sistema armazena só uma versão cifrada de forma irreversível, como se faz com qualquer senha bem tratada.

A conversa é o recurso que mais melhora a apuração. Boa parte dos relatos chega incompleta. Sem canal de retorno, o caso é arquivado por falta de informação; com ele, uma pergunta simples ("em qual unidade isso aconteceu?") destrava a análise.

Quem vê o quê: segregação de acesso

Esse é o ponto em que a plataforma mais se diferencia de uma ferramenta genérica de chamados. A regra de partida é: ninguém vê um caso só por ter acesso ao sistema. O acesso nasce da atribuição.

Duas situações precisam de regra explícita no sistema, não só na política escrita:

• Conflito de interesse. Se o relato menciona alguém da linha de apuração, o caso precisa ser desviado para outra pessoa ou instância, e quem foi citado não pode sequer ver que o caso existe.
• Administrador sem acesso ao conteúdo. Quem cuida da parte técnica não deve conseguir ler relatos pela tela nem pelo banco de dados. Isso se resolve com cifragem do conteúdo e chaves controladas fora do alcance da equipe técnica do dia a dia.

Esse desenho de papéis e registros é o mesmo princípio de qualquer sistema com informação sensível, e está detalhado em controle de acesso e trilha de auditoria. No canal de denúncias, ele deixa de ser boa prática e passa a ser o que sustenta a confiança no canal.

Fluxo de apuração, prazos e registros

Um relato percorre etapas, e cada etapa precisa de dono e de prazo configurável. Um fluxo típico, como ponto de partida:

1. Recebimento. O sistema confirma o envio e gera o protocolo.
2. Triagem. Classificação por tema (assédio, fraude, conflito de interesse, segurança, outros), gravidade e pertinência. Relatos que não são denúncia, como reclamação de cliente, são encaminhados ao canal certo e encerrados com registro.
3. Atribuição. Definição de quem apura, com checagem de conflito de interesse.
4. Apuração. Registro de entrevistas, documentos analisados e perguntas ao denunciante, sempre dentro da plataforma.
5. Conclusão. Parecer com resultado (procedente, improcedente, inconclusivo) e medidas recomendadas.
6. Deliberação e encerramento. Decisão do comitê, quando aplicável, e retorno ao denunciante.

Prazos e alertas

Os prazos de cada etapa são definidos pela política interna e devem ser parametrizáveis, não fixos no código. O sistema calcula o vencimento, avisa o responsável antes do fim e escala para o nível acima quando o prazo passa. Casos graves podem ter prazo menor e notificação imediata a um grupo restrito.

O que registrar

Tudo que acontece com o caso fica no histórico, sem possibilidade de apagar: quem abriu, quem leu, quem mudou a classificação, quem anexou o quê, quem encerrou e com qual justificativa. Anotações podem ser corrigidas, mas a versão anterior permanece registrada.

Guarda e descarte

Relatos contêm dados pessoais, às vezes sensíveis, de denunciantes, denunciados e testemunhas. O sistema precisa suportar prazos de retenção por tipo de caso, descarte ou anonimização ao fim desse prazo e atendimento a pedidos de titulares dentro do que a lei permite. Os princípios de LGPD no desenvolvimento de sistemas se aplicam integralmente aqui; os prazos concretos devem ser definidos com o jurídico.

Relatórios para a diretoria e para o comitê

A diretoria precisa saber se o canal funciona, não ler denúncias. Os relatórios devem ser agregados e pensados para não identificar ninguém:

• volume de relatos por período, por tema e por canal de entrada;
• tempo médio em cada etapa e casos fora do prazo;
• distribuição de resultados (procedente, improcedente, inconclusivo);
• medidas adotadas por tipo;
• proporção de relatos anônimos e de relatos com conversa ativa.

Um cuidado frequentemente esquecido: recortes pequenos identificam. Se uma unidade tem oito pessoas e o relatório mostra "um relato de assédio na unidade X em março", o anonimato se perdeu. A plataforma deve agrupar categorias com poucos casos ou omitir o detalhe abaixo de um volume mínimo.

Para o comitê, além dos números, o sistema pode gerar a pauta da reunião com os casos que exigem deliberação e registrar as decisões tomadas, ligadas a cada caso.

Plataforma própria ou de terceiros

Existem serviços prontos de canal de denúncias, alguns com equipe externa que faz a triagem. Para muitas empresas, eles resolvem bem. A tabela abaixo ajuda a decidir:

A plataforma própria costuma fazer sentido quando a empresa já tem um portal interno e quer o canal integrado a ele, quando o grupo tem várias empresas com comitês separados, quando há exigência de manter os dados em infraestrutura específica ou quando o fluxo de apuração tem particularidades que os produtos prontos não cobrem.

Se o canal for integrado à intranet, o ponto de entrada pode estar no portal do colaborador, mas o canal em si deve continuar acessível sem login e por fora da rede, para não perder o anonimato.

Checklist antes de colocar o canal no ar

• O relato pode ser enviado sem login, de fora da rede e pelo celular?
• O sistema deixa de registrar IP e dados do dispositivo nas rotas do canal?
• Anexos têm metadados removidos no recebimento?
• Existe protocolo com senha e conversa com o denunciante anônimo?
• Cada caso é visível só para quem foi atribuído?
• Há regra de desvio quando o denunciado está na linha de apuração?
• O administrador técnico consegue ler relatos? (A resposta certa é não.)
• Prazos por etapa são configuráveis e geram alertas?
• O histórico de cada caso é completo e não pode ser apagado?
• Os relatórios agregam categorias pequenas para não identificar ninguém?
• A política de retenção e descarte foi validada com o jurídico?

Se alguma resposta for "não" ou "não sei", o canal ainda não protege quem precisa dele.

Perguntas frequentes

Canal de denúncias é obrigatório?

Depende da empresa. A Lei 14.457/2022 exige que empresas com CIPA tenham procedimentos para receber e acompanhar denúncias de assédio, com anonimato garantido a quem denuncia. Para programas de integridade, o Decreto 11.129/2022 lista o canal de denúncias entre os parâmetros de avaliação. As exigências variam com porte, setor e norma aplicável, e devem ser validadas com o jurídico.

O canal de denúncias pode ser terceirizado?

Sim. Existem serviços prontos de canal de denúncias, alguns com equipe externa que faz a triagem dos relatos, e para muitas empresas eles resolvem bem. A plataforma própria costuma fazer sentido quando o grupo tem várias empresas com comitês separados, quando o canal precisa ser integrado ao portal interno ou quando há exigência específica sobre onde os dados ficam.

Como o denunciante anônimo acompanha a denúncia?

O denunciante anônimo acompanha a denúncia com o número de protocolo e a senha gerados pelo sistema no envio do relato. Com esses dados, a pessoa volta ao canal, vê a etapa do caso, responde perguntas de quem apura e envia novos documentos. Protocolo e senha não podem ser recuperados por e-mail, para não criar vínculo com a identidade.

Quem deve receber as denúncias dentro da empresa?

As denúncias devem chegar primeiro a uma triagem, feita pela área de compliance ou por uma empresa externa, que classifica o relato e atribui um responsável pela apuração. Cada caso fica visível só para quem tem papel nele, e o sistema precisa desviar o relato para outra instância quando o denunciado está na própria linha de apuração.

Como a Pervian Tech trabalha canais de denúncia

Na Pervian Tech, um projeto de canal de denúncias começa pelo desenho de governança, antes de qualquer tela: quem faz a triagem, quem apura cada tipo de caso, como se trata conflito de interesse, quais prazos a política interna define e o que a diretoria precisa enxergar. Com isso fechado, desenvolvemos a plataforma como parte do nosso trabalho de desenvolvimento web, com anonimato tratado na infraestrutura, acesso por atribuição, cifragem do conteúdo e trilha de auditoria completa.

Quando a empresa já usa um serviço pronto e quer apenas integrá-lo ao portal interno ou aos relatórios de gestão, fazemos esse recorte menor. Outros projetos da mesma linha estão na categoria plataformas web.

Cada canal é desenhado sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito em que entendemos a estrutura da empresa e o fluxo de apuração desejado. Se o canal de vocês hoje é um e-mail no rodapé, vamos conversar.