# Simular a política no próprio histórico, sem cobrar, sem consultar ninguém e sem abrir uma foto Guia · UNIFOKAL · 24 de setembro de 2026 · 6 min de leitura · Produto e integração Como testar uma mudança na regra de decisão da verificação sobre o que já foi decidido, o que dá para simular com honestidade e o que o placar não pode esconder. Mudar uma regra de decisão da verificação costuma ser um salto no escuro. A equipe decide aceitar pessoas politicamente expostas, tolerar o impedimento de apostas ou tirar um módulo do fluxo, publica a mudança e só descobre o efeito quando os clientes reais já estão passando por ela. Se a mudança aprovou gente demais, o prejuízo já aconteceu. Se reprovou gente demais, a conversão caiu antes de alguém perceber. Existe um jeito melhor: perguntar ao histórico. As verificações que já foram decididas carregam a evidência que decidiu cada uma. Refazer a decisão sobre essa evidência com a regra candidata mostra, antes de qualquer cliente real, o que teria mudado. Este artigo trata de como fazer essa simulação com honestidade: o que dá para simular, o que não dá, e o que o resultado nunca pode esconder. ## Decisão informada é exigência, não luxo A série SP 800-63-4, as Digital Identity Guidelines publicadas pelo National Institute of Standards and Technology (NIST) em 2025, descreve o ajuste de controles de identidade como uma decisão informada por risco, e pede às organizações um programa de avaliação contínua, com métricas e com os dados necessários para avaliar o desempenho do sistema de identidade e agir a tempo. A mesma norma lembra que funcionalidades novas, mudanças no uso de dados e mudanças no cenário de ameaça podem exigir revisitar controles já escolhidos. Uma simulação sobre o histórico é a forma mais barata de transformar essa exigência em rotina. Ela troca a pergunta genérica, se a mudança parece boa, por uma pergunta com resposta: quantas das verificações que já passaram mudariam de desfecho, e em que direção. ## O que dá para simular, e o que não dá A regra de ouro é simples: só é simulável o que pode ser recalculado a partir da evidência guardada, pela mesma lógica que decide em produção. Tudo o mais é palpite apresentado como número. - A política de pessoa politicamente exposta e a de impedimento de apostas costumam ser simuláveis, porque o resultado da consulta já está guardado e a mudança é só de como ele é julgado. - Tirar um módulo do fluxo é simulável quando o conjunto que sobra continua coerente com as dependências entre módulos. - Acrescentar um módulo nunca é simulável: exigiria rodar uma análise que não aconteceu, com uma consulta que não foi feita. - Ajustes que mudam o que é capturado do titular, como o tamanho do desafio da prova de vida, também não são: a captura já aconteceu sob a regra antiga. Uma boa ferramenta mostra os ajustes não simuláveis desligados, com o motivo escrito, em vez de fingir que simula. Pior que não saber o efeito de uma mudança é achar que sabe. ## Sem cobrança, sem consulta e sem abrir foto A simulação não precisa, e não deve, repetir o que a verificação fez de caro ou de sensível: - Nada de consultar fonte externa de novo. A consulta custa dinheiro, e a resposta já está guardada. - Nada de abrir imagem. A decisão depende dos resultados já registrados, e não das fotos. Abrir selfie e documento para simular uma regra seria tratar dado pessoal sensível sem necessidade. - Nada de cobrança. Uma pergunta de configuração não é uma verificação. A Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) sustenta a mesma direção: o art. 6º, inciso III, limita o tratamento ao mínimo necessário para a finalidade, e o art. 46 exige medidas de segurança contra tratamento inadequado. Uma simulação que só lê resultados e nunca reabre mídia cumpre as duas coisas por construção. A lógica é a mesma da [minimização antes do subprocessador](https://unifokal.com/blog/minimizar-dado-antes-do-subprocessador): o dado que não precisa sair do lugar não sai. ## O placar que não esconde nada O número que todo mundo quer ver é quantas verificações mudariam. Ele só é honesto com três cuidados. Primeiro, a taxa se calcula sobre o que foi de fato reproduzido. Nem toda verificação do período pode ser refeita: algumas nem passaram pelo motor de decisão (uma recusa de consentimento, por exemplo), outras não têm evidência suficiente guardada, e em outras o ajuste não se aplica. Somar essas linhas no denominador diluiria a taxa. Segundo, as linhas que ficaram fora aparecem ao lado da taxa, com o motivo. Uma taxa de mudança de 2% sobre as reproduzidas significa pouco se metade do período ficou fora da conta, e quem decide precisa ver as duas coisas juntas. O artigo sobre [comparar taxa de aprovação](https://unifokal.com/blog/comparar-taxa-de-aprovacao-de-kyc) mostra como um número sem o recorte engana. Terceiro, a direção importa mais que o total. Uma mudança pode tornar a decisão mais rígida (aprovada vira revisão), mais permissiva (revisão vira aprovada) ou mudar de outro jeito. Cem verificações que ficariam mais permissivas pedem uma conversa bem diferente de cem que ficariam mais rígidas. ## Um roteiro de uso Uma simulação útil costuma seguir esta ordem: 1. Escolha uma janela recente e representativa, sem ser longa demais. Janelas curtas respondem rápido e refletem o tráfego atual. 2. Mude um ajuste por vez. Dois ajustes juntos produzem um efeito que ninguém consegue atribuir. 3. Leia primeiro as linhas que ficaram fora da conta. Se elas forem muitas, a taxa diz pouco. 4. Abra algumas verificações que mudariam de desfecho e confira se a mudança faz sentido caso a caso. 5. Só então decida, e registre a decisão com o resultado da simulação ao lado. Um cuidado final: a simulação mostra o passado sob a regra nova, e não prevê fraude que ainda não aconteceu. Uma política mais permissiva que parece inofensiva no histórico pode atrair justamente o tipo de ataque que o histórico não tem. O artigo sobre [falso positivo em verificação](https://unifokal.com/blog/falso-positivo-em-verificacao) trata do outro lado dessa balança. Na UNIFOKAL, por exemplo, a simulação fica na tela Motor do painel e segue essas regras, descritas na [documentação do painel de operação](https://unifokal.com/docs/painel-de-operacao). ## Perguntas frequentes ### A simulação pode rodar ao mesmo tempo que a produção? Pode, e deve rodar sem disputar recurso com ela. Uma simulação sobre milhares de verificações não cabe numa resposta de tela: o jeito seguro é processar em lotes, em segundo plano, com a tela acompanhando o progresso. Uma simulação por vez por ambiente evita que duas rodadas concorrentes confundam quem está lendo o resultado. ### Por quanto tempo o histórico serve para simular? Enquanto a evidência que decidiu cada verificação ainda estiver guardada. Quando a política de retenção apaga os resultados e a mídia de uma verificação, ela deixa de poder ser refeita, e a simulação precisa dizer isso em vez de contá-la como igual. Por isso a janela da simulação costuma caber dentro do prazo de guarda. ### E se a regra nova mudar só casos raros? Então o número absoluto importa mais que a taxa. Três verificações que passariam a ser aprovadas podem ser justamente as três que a regra antiga existia para barrar. Nesses casos, abra cada uma antes de decidir. ## Fontes citadas - National Institute of Standards and Technology (NIST). SP 800-63-4, Digital Identity Guidelines, 2025. - Brasil. Lei nº 13.709, de 14 de agosto de 2018 (Lei Geral de Proteção de Dados Pessoais), art. 6º, inciso III, e art. 46.