Sistema de gestão de compliance: como escolher o seu

Executiva analisando painel holografico de matriz de risco e controles de um sistema de gestao de compliance

Sistema de gestão de compliance: como escolher o seu

Sistema de gestão de compliance: como escolher o seu

Escolher um sistema de gestão de compliance é uma decisão que costuma ser tomada na ordem errada. A empresa identifica uma exigência regulatória, pede demonstração para três fornecedores, compara preço e número de módulos, assina — e seis meses depois descobre que a ferramenta registra política mas não produz a trilha de evidência que o auditor pede. O problema raramente está no software. Está no fato de que a seleção aconteceu antes de existir um desenho de processo para o software sustentar.

Este artigo trata da etapa de escolha: o que a plataforma precisa entregar, quais critérios técnicos separam uma opção viável de uma que gera retrabalho, em que cenário a planilha ainda é a resposta certa, e como validar a decisão antes da assinatura. Não é um comparativo de marcas — é o roteiro de avaliação que deveria anteceder qualquer comparativo.

Se o seu estágio ainda é anterior a esse, vale começar pelo guia completo de implantação de um sistema de compliance, que cobre o que é o sistema e as etapas de implantação. O que vem abaixo assume que a decisão de implantar já foi tomada e o que falta é escolher com o quê.

O que um sistema de gestão de compliance precisa entregar

Um sistema de gestão de compliance não é um repositório de documentos com controle de versão. Ele é a infraestrutura que transforma obrigação regulatória em processo verificável. Isso se traduz em cinco entregas concretas, e vale checar cada uma contra a ferramenta que está na mesa:

Registro de risco vivo. A matriz de risco precisa morar no sistema e ser atualizada por quem opera, não em um arquivo que alguém revisa uma vez por ano. Se a matriz vive fora da ferramenta, o sistema é vitrine.

Vínculo entre política, controle e evidência. Toda política precisa apontar para os controles que a executam, e todo controle precisa acumular evidência de execução com data e responsável. Essa cadeia é o que sustenta uma auditoria. Ferramenta que guarda política sem amarrar controle entrega metade do trabalho.

Trilha de auditoria imutável. Quem alterou o quê, quando, e com qual aprovação. Sem log imutável, a evidência não se sustenta diante de um questionamento externo.

Fluxo de exceção e aprovação. Compliance real convive com exceções — o que não pode existir é exceção sem registro, prazo e aprovador nominal. O sistema precisa tratar isso como fluxo, não como observação em campo de texto.

Indicador operacional, não relatório de atividade. A diferença entre “12 treinamentos realizados” e “87% da população-alvo treinada dentro do prazo, com 3 áreas em atraso” é a diferença entre reportar esforço e reportar cobertura. Só o segundo serve para decisão executiva — e é o mesmo princípio que vale para qualquer indicador de operação, como tratamos em os 7 KPIs operacionais que mudam decisão executiva.

Se a ferramenta avaliada não entrega esses cinco itens, o que está sendo comprado é um gerenciador de arquivos com etiqueta de compliance.

Sete critérios técnicos para comparar plataformas

Demonstração comercial mostra a ferramenta no melhor cenário possível: base limpa, processo ideal, usuário treinado. A avaliação técnica precisa forçar o cenário real. Estes são os sete critérios que mudam a decisão, na ordem em que costumam doer:

1. Modelo de dados aberto ou fechado. A pergunta prática é: consigo extrair 100% dos meus dados, em formato estruturado, sem depender do fornecedor? Se a resposta envolve abrir ticket, a plataforma tem custo de saída alto e isso precisa entrar na conta.

2. Integração com o que já existe. Compliance consome dado de RH (população-alvo de treinamento), de financeiro (pagamentos e terceiros), de jurídico (contratos) e de TI (acessos). Se o sistema não conversa com essas fontes via API, alguém vai alimentar planilha para manter o sistema — o que reintroduz o problema que a ferramenta deveria resolver. É o mesmo raciocínio de arquitetura que discutimos em como escolher o stack certo: o ecossistema de plataformas.

3. Granularidade de permissão. Compliance lida com denúncia, investigação e dado sensível. Permissão por perfil não basta; é preciso permissão por registro, com segregação entre quem investiga e quem é investigado. Ferramenta que só tem “admin, editor, leitor” não atende canal de denúncia.

4. Configurabilidade sem desenvolvimento. Matriz de risco, taxonomia de controle e fluxo de aprovação mudam. Se cada mudança depende de hora de consultoria do fornecedor, o custo real do sistema não é a licença.

5. Rastreabilidade nativa versus rastreabilidade construída. Peça para ver o log de auditoria de um registro qualquer, ao vivo. Se a demonstração precisa de preparo, o recurso provavelmente é relatório, não log.

6. Capacidade de reportar por área e por prazo. O relatório que a diretoria usa não é “status geral do programa” — é “quais áreas estão fora do prazo e desde quando”. Se isso exige exportar e cruzar no Excel, a plataforma não fecha o ciclo de gestão.

7. Residência e tratamento do dado. Onde o dado fica hospedado, por quanto tempo, com qual política de retenção e como se comporta a exclusão. Em programa que trata dado pessoal, isso não é detalhe de contrato — é requisito.

Um jeito honesto de aplicar os sete critérios é montar uma matriz simples com peso: dê nota de 1 a 5 por critério para cada fornecedor, multiplique pelo peso que o seu contexto exige e compare o total, não a impressão da demonstração.

Critério Peso sugerido em setor fiscalizado Peso sugerido em stack fragmentado
Modelo de dados aberto 2 3
Integração via API 2 3
Granularidade de permissão 3 2
Configurabilidade sem dev 2 2
Trilha de auditoria nativa 3 2
Relatório por área e prazo 3 2
Residência e retenção do dado 3 1

Os pesos não são universais — são o ponto de partida de uma conversa interna. O valor do exercício está menos no número final e mais em forçar jurídico, TI e operação a declararem qual critério cada um considera eliminatório. Divergência descoberta na matriz custa uma reunião; descoberta na implantação custa um trimestre.

Vale um alerta sobre o critério mais negligenciado: a configurabilidade sem desenvolvimento. Programas de compliance mudam de escopo com frequência maior do que o ciclo de contrato do sistema — norma nova, aquisição de empresa, entrada em novo mercado. Se cada mudança de taxonomia depende de hora contratada, o custo total de propriedade em três anos pode superar a licença. Peça ao fornecedor o histórico de mudanças solicitadas por clientes semelhantes e quanto delas foi resolvida em autoatendimento.

Quando planilha e política escrita ainda resolvem

Existe um ponto em que contratar plataforma é antecipação de maturidade, e antecipação custa caro — em licença e em credibilidade interna, porque ferramenta subutilizada vira argumento contra o programa.

Planilha com política escrita e revisão trimestral ainda é resposta adequada quando as quatro condições abaixo são verdadeiras ao mesmo tempo:

  • O escopo regulatório é estável e conhecido, sem norma nova entrando a cada ciclo.
  • Existe um responsável nominal por compliance com tempo alocado — não um acúmulo informal de função.
  • O número de controles ativos é pequeno o suficiente para ser revisado manualmente sem perder rastreabilidade.
  • Não há canal de denúncia formal exigindo sigilo e segregação de acesso.

Quando qualquer uma dessas condições cai, a planilha começa a falhar de um jeito específico: ela continua funcionando para registro e para de funcionar para prova. O sinal mais claro é o tempo de resposta a um pedido de evidência. Se responder “me mostre a evidência de execução deste controle no último trimestre” leva dias e depende de uma pessoa específica, o custo de não ter sistema já é maior que a licença.

O caminho intermediário raramente é considerado e costuma ser o mais racional: estruturar processo, matriz e trilha de evidência primeiro em ferramenta simples, medir volume real de controle e exceção por três meses, e só então comprar com requisito calibrado por dado próprio em vez de por catálogo de fornecedor.

Na prática, esse período de três meses produz quatro números que mudam completamente a conversa com o fornecedor: quantos controles ativos existem de fato, quantas exceções são abertas por mês, quantas pessoas registram evidência com regularidade e quanto tempo leva para responder a um pedido de comprovação. Uma empresa que chega à negociação com esses quatro números compra porte adequado. Uma empresa que chega sem eles compra o pacote que o fornecedor recomenda — e o fornecedor, previsivelmente, recomenda o maior que couber no orçamento.

Há ainda um sinal de maturidade que costuma ser confundido com sinal de necessidade: pressão de cliente ou de parceiro pedindo comprovação de programa. Isso justifica formalizar política e trilha de evidência com urgência, mas não necessariamente comprar plataforma no mesmo trimestre. O que o cliente audita é a existência de controle e prova, não a marca do software que a hospeda.

Erros de seleção que viram retrabalho na implantação

Os erros abaixo aparecem com frequência e todos têm o mesmo efeito: a implantação vira projeto de correção de escopo.

Comprar por módulo e não por processo. Lista de módulos não é lista de capacidade. A pergunta útil não é “tem módulo de terceiros?”, é “como esse módulo trata um terceiro que já está contratado, sem due diligence, e com pagamento recorrente em curso?”.

Definir o dono do sistema depois da compra. Sem dono nomeado antes da assinatura, a configuração acontece por consenso e o resultado atende a todos parcialmente. Compliance sem dono único de decisão configura ferramenta genérica.

Ignorar quem alimenta. O gestor de área é quem vai registrar evidência. Se a interface dele exige treinamento longo, a adesão cai e o sistema passa a refletir uma realidade que não existe — o que é pior que não ter sistema, porque cria falsa segurança.

Tratar migração como detalhe técnico. Política antiga, matriz herdada e histórico de treinamento precisam entrar com estrutura, não como anexo. Migração sem desenho de dados é a razão mais comum de um sistema novo nascer com base suja.

Não definir critério de sucesso. Sem meta explícita — cobertura de controle, tempo de resposta a pedido de evidência, percentual de exceção com prazo vencido — não existe como afirmar em 12 meses se a compra funcionou. Definir isso antes é o que separa investimento de despesa. Esse é o mesmo teste de retorno que aplicamos em quando contratar consultoria de governança de dados: sinais e ROI.

Existe um teste de dez minutos que revela se algum desses erros já está em curso. Peça a três pessoas envolvidas na decisão — jurídico, TI e a área que vai operar o sistema — para escrever, separadamente e em uma única frase, qual problema a plataforma vai resolver. Se as três frases descreverem problemas diferentes, o escopo ainda não existe: comprar nesse estado significa configurar a ferramenta para a média de três expectativas divergentes, e é assim que nasce um sistema que ninguém considera adequado.

O mesmo teste tem uma segunda pergunta, mais desconfortável: quem vai perder autonomia quando o controle entrar em produção? Toda implantação de compliance retira alguma liberdade de decisão de alguém — aprovação que passa a exigir registro, contratação que passa a exigir due diligence. Se ninguém consegue nomear quem perde autonomia, a conversa ainda não chegou ao processo real, e a seleção está sendo feita sobre uma versão idealizada da operação.

Como validar a escolha antes de assinar contrato

A validação final não é uma reunião — é um teste com o seu dado e o seu processo. Um roteiro que cabe em duas semanas:

Prova de conceito com um processo real. Escolha um controle que já existe, com histórico, e configure de ponta a ponta na ferramenta: política, controle, evidência, exceção, relatório. Um processo real revela mais que dez demonstrações.

Teste de extração. Peça a exportação completa do que foi configurado, em formato estruturado, feita por você e não pelo fornecedor. É o teste de custo de saída.

Teste de permissão. Crie um caso de denúncia fictício e verifique se o perfil investigado consegue enxergar qualquer rastro. Se conseguir, o canal não é utilizável.

Teste de relatório executivo. Gere, sem ajuda, o relatório que a diretoria vai receber. Se ele precisa de tratamento externo, a plataforma não fecha o ciclo.

Teste de mudança. Altere um item da matriz de risco e uma etapa de fluxo. Cronometre. Esse número é o custo de manutenção do sistema ao longo dos anos.

Fechando o raciocínio: um sistema de gestão de compliance só entrega valor quando existe processo desenhado antes dele, dono nomeado, integração com as fontes de dado que já operam e critério de sucesso declarado. Os sete critérios técnicos servem para comparar; a prova de conceito serve para decidir; a matriz de peso serve para justificar a decisão internamente. E quando as quatro condições de estabilidade estiverem presentes, a resposta correta pode ser simplesmente não comprar agora — e usar os três meses seguintes para gerar o dado que vai calibrar a compra.

Próximo passo

A Better Consultoria estrutura o ecossistema de plataformas que sustenta operação, dado e decisão — do diagnóstico à implantação. Solicite o contato de um especialista para mapear o processo antes de escolher a plataforma.