No material de vendas, todo motor de decisão parece igual: configurável, auditável, rápido de implantar, integrado a dezenas de fontes. A diferença aparece na operação, seis meses depois, quando a régua precisa mudar e "configurável" se revela um chamado aberto com o fornecedor.
Este material reúne 17 perguntas para fazer a qualquer fornecedor de motor de decisão antes de assinar. Elas saíram de conversas reais de avaliação em instituições financeiras brasileiras. Cada pergunta vem com três informações: por que ela importa, o que uma boa resposta contém e qual resposta deveria acender um alerta.
Para quem é este conteúdo: times de risco, crédito, compliance, PLD/FT, produto e tecnologia que estão montando ou revisando um processo de avaliação de plataformas de decisão — RFP, comitê ou renovação de contrato.
|
Bloco |
Perguntas |
Quem faz |
|---|---|---|
|
1 a 6 |
Quem vai operar |
|
|
7 a 10 |
Quem aprova o orçamento |
|
|
11 a 14 |
Compliance e auditoria |
|
|
15 |
SI e encarregado de dados |
|
|
16 e 17 |
Você |
|
|
— |
Todos |
Não existe fonte neutra para essa comparação. A cobertura de analistas no Brasil é rasa e cada fornecedor publica a matriz de critérios em que vence. O resultado é previsível: o comitê avalia plataformas usando o material de quem as vende.
As perguntas abaixo servem para inverter isso. Nenhuma delas depende de benchmark externo. Todas se respondem com demonstração, cláusula contratual ou uma declaração que você registra em ata e cobra depois.
Este bloco pertence a quem vai operar a régua no dia a dia. São as perguntas que definem se, daqui a seis meses, sua equipe muda uma política de risco sozinha ou entra na fila de outra empresa.
Por que importa. É a pergunta que revela se a autonomia é real ou de folheto. Se cada mudança de régua depende do fornecedor, você trocou a fila da sua engenharia pela fila da engenharia dele.
Boa resposta. Em minutos, em tempo real, com um analista demonstrando ao vivo. Junto com clareza sobre o que exige ajuda: integração com fonte nova quase sempre exige; condição nova sobre dado que já existe no fluxo não deveria.
Alerta. "Depende da complexidade", sem exemplo. Ou prazo contado em dias úteis, o que indica um chamado no meio do caminho.
Por que importa. Em uma avaliação real, um comprador relatou deploys que apagavam rascunhos de regra. A credencial usada para publicar era compartilhada e pertencia a uma pessoa da diretoria de tecnologia.
Boa resposta. Separação entre ambiente oficial e ambiente de teste, versionamento com histórico de publicações, acessos nominais com SSO e reversão para a versão anterior.
Alerta. Ambiente único. Ou a recomendação de "testar fora do horário de pico", que é a forma educada de dizer que não existe sandbox.
Por que importa. Autonomia para mudar regra não serve de nada se a plataforma engasga no volume real da sua operação. É uma pergunta que costuma ficar de fora da avaliação porque parece "óbvia demais" — até a operação escalar e o motor virar o gargalo.
Boa resposta. Um número de transações por segundo com contexto (em que tipo de fluxo, com quantos birôs acionados), e a oferta concreta de um teste de carga ou de estresse no seu cenário antes da assinatura — não só a declaração da capacidade.
Alerta. Resposta sem número, ou número sem contexto ("aguenta bastante"). Recusa em fazer teste de carga antes de assinar é sinal de que ninguém testou aquilo no cenário que você precisa.
Por que importa. É diferente de poder reverter uma versão depois que ela quebrou (pergunta 2). Aqui a questão é rodar a regra nova em paralelo, sobre casos reais, e comparar o resultado com o que está em produção — antes de expor qualquer cliente à mudança.
Boa resposta. Um modo de "sombra" (shadow mode): a regra nova roda sobre o tráfego real, gera resultado, mas não decide nada — só é comparada com a regra vigente para validar impacto antes do go-live.
Alerta. "A gente publica e monitora depois." Monitorar depois é reagir ao erro, não evitá-lo. Se o fornecedor não tem shadow mode nem meio-termo parecido, toda mudança de regra é um risco não testado.
Por que importa. Rapidez em publicar regra é ótimo até um erro de configuração ir para produção sem ninguém revisar. A pergunta 2 já cobre reversão de versão; esta cobre o que acontece antes de precisar reverter.
Boa resposta. Um fluxo de aprovação configurável — quem pode editar, quem precisa validar antes de publicar, e isso registrado por pessoa, não por login compartilhado.
Alerta. "Depende de vocês organizarem isso internamente." Se o controle de quem publica é um acordo verbal da sua equipe e não uma trava da plataforma, ele vai ser furado na primeira urgência.
Por que importa. As duas respostas extremas são ruins. "Só vocês" significa dependência permanente do fornecedor. "Só nós" significa que você precisa de um recurso dedicado que talvez não tenha no orçamento.
Boa resposta. Um modelo declarado: o que o cliente mantém sozinho no editor, o que exige suporte, como funciona o treinamento do time e o nome de quem sustenta cada parte.
Alerta. "É tudo no-code, qualquer pessoa faz." Interface no-code que exige consultor para qualquer condição não trivial é a promessa que mais frustra depois da assinatura.
Este bloco pertence a quem assina o orçamento. Em plataformas de decisão, o custo relevante raramente é a licença — é o consumo de dado, e ele é sensível a decisões de arquitetura que ninguém discute na fase de venda.
Por que importa. É a diferença entre pagar pelo motor e pagar pelo motor mais um markup em cada consulta. Em uma avaliação, o comprador tinha referência de custo por consulta e comparou linha a linha com o que já pagava aos birôs.
Boa resposta. Separação explícita entre o que é plataforma e o que é dado. E a possibilidade de plugar a sua própria credencial de birô, se você já tem contrato, sem markup.
Alerta. Preço único por consulta, sem abertura. Você não consegue comparar com o que paga hoje, e é exatamente por isso que vem fechado.
Por que importa. Se todas as fontes são consultadas em paralelo para todo proponente, você compra dado premium para casos que um critério de centavos já resolveria. Em uma operação que recusa metade dos proponentes, isso é metade da fatura gasta sem chance de gerar cliente.
Boa resposta. Consulta em cascata configurável, do dado mais barato ao mais caro, com escalonamento apenas quando o caso exige. E você definindo a ordem, sem depender do fornecedor.
Alerta. "Consultamos tudo para garantir a melhor decisão." Garante também a fatura mais alta.
Por que importa. É outra alavanca de custo que fica escondida atrás do "preço por consulta". Numa operação com reconsultas frequentes do mesmo alvo — reanálise, monitoramento, jornadas que se cruzam —, sem cache você paga o birô mais de uma vez pela mesma informação.
Boa resposta. Cache configurável por tipo de dado (prazos diferentes para dado cadastral, que muda rápido, e dado de processo judicial, que muda devagar), e não um cache único e genérico para tudo.
Alerta. "Não trabalhamos com cache" ou cache fixo e não configurável. Nos dois casos, você paga o preço cheio do birô toda vez que o mesmo alvo aparece de novo no fluxo.
Por que importa. Fornecedores globais costumam ser fortes em listas internacionais de sanções e em bases de pessoas politicamente expostas. No dado brasileiro — societário, judicial, cadastral — há fontes locais melhores. Quantidade de integrações não diz nada sobre curadoria.
Boa resposta. Critério declarado de qualidade e custo por tipo de dado, com fallback quando a primeira fonte não responde. E honestidade sobre onde a cobertura é mais fina.
Alerta. Número grande de integrações apresentado como diferencial, sem explicar como a melhor fonte é escolhida para cada caso.
Este bloco pertence a compliance e auditoria. A instituição pode ter decidido corretamente e ficar exposta por não conseguir demonstrar como decidiu.
Por que importa. É a pergunta que separa registro por construção de reconstrução por esforço. Quando o pedido chega com prazo, a diferença entre as duas coisas custa semanas.
Boa resposta. Dossiê da decisão com as regras acionadas, os pesos aplicados, as fontes consultadas e o histórico de versões do fluxo, mostrando qual régua estava no ar naquele dia.
Alerta. Log de sistema. Log mostra que algo aconteceu; não mostra por que a decisão foi aquela.
Por que importa. É diferente de reconstruir a justificativa de uma decisão de meses atrás (pergunta 11). Aqui o problema é operacional: uma análise está presa, o resultado não chegou, e ninguém sabe em que etapa do workflow ela parou — se foi barrada numa regra, se está esperando um birô responder, se caiu numa fila.
Boa resposta. Uma visualização do fluxo que mostra, passo a passo e em tempo real, por onde a análise passou e onde ela está agora — não só o resultado final.
Alerta. "Para saber isso, abre um chamado com a gente." Sem rastreabilidade própria, cada análise travada vira um ticket, e ticket tem fila.
Por que importa. O art. 20 da LGPD (Lei nº 13.709/2018) garante ao titular o direito de solicitar revisão de decisão tomada unicamente com base em tratamento automatizado. O §1º do mesmo artigo obriga o controlador a fornecer informações claras sobre os critérios e procedimentos usados. Modelo que devolve pontuação sem justificativa estruturada transfere para a instituição o problema de explicar o inexplicável.
Boa resposta. Separação clara de papéis: a IA lê documento, extrai campo, classifica mídia. O cálculo da decisão é determinístico, roda no motor, com a regra visível. Alçada humana definida para o que exige julgamento.
Alerta. "Nossa IA aprende e decide sozinha." Em ambiente regulado, decisão que não se explica é passivo.
Por que importa. A obrigação de retenção documental é da instituição, não do fornecedor. Se a trilha vive apenas na plataforma dele, sua conformidade de períodos passados fica hospedada em um contrato vigente.
Boa resposta. Exportação completa em formato aberto, sem custo de saída, com prazo definido de disponibilidade após o encerramento.
Alerta. Silêncio. Ou "nunca ninguém pediu isso".
Por que importa. Sua área de SI e o encarregado de dados vão fazer essas perguntas de qualquer forma. Fazer antes evita descobrir um impedimento na última semana do processo, com a proposta já aprovada.
Boa resposta. Ambiente exclusivo por cliente, logs e trilha de auditoria, versionamento de configurações, acessos nominais com autenticação centralizada. E clareza de que a responsabilidade legal como controlador de dados permanece com a instituição, com o fornecedor atuando como operador.
Alerta. Fornecedor que assume responsabilidade que legalmente não é dele. Se ele erra nisso, provavelmente erra em mais coisas.
As duas últimas não têm resposta certa. Elas medem outra coisa: se o fornecedor conhece a própria plataforma bem o suficiente para descrever onde ela não serve.
Por que importa. É a pergunta mais informativa da lista e a que mais fornecedores não conseguem responder. Não por falta de fraqueza, mas por falta do hábito de nomeá-la.
Boa resposta. Uma limitação concreta, com o contorno. Exemplo real: painéis nativos de análise costumam ser o ponto fraco de plataformas de decisão, porque o desenvolvimento se concentra no motor, não no BI — muitas vezes por causa da própria dinâmica de multi bureaus de dados, que dificulta padronizar um dashboard nativo. A resposta honesta recomenda exportação via API para a ferramenta de BI que a instituição já usa, em vez de vender um dashboard fraco como se fosse forte.
Alerta. "Não vejo fraquezas." Ou uma fraqueza convenientemente irrelevante. Se ele não sabe onde é fraco, você descobre na implantação.
Por que importa. Todo fornecedor apresenta case de sucesso. O padrão de churn diz mais sobre onde a plataforma não serve.
Boa resposta. Um perfil de cliente para quem não funcionou, com o motivo. Operação pequena demais para justificar a plataforma, política de risco simples demais, exigência de instalação local — todos são motivos legítimos e todos são informação útil.
Alerta. "Nunca perdemos cliente."
Ordene por quem pergunta. As perguntas 1 a 6 são de quem vai operar. As 7 a 10, de quem aprova custo. As 11 a 14, de compliance e auditoria. A 15 é de segurança da informação. As 16 e 17 são suas.
Peça demonstração, não resposta. Das dezessete, oito podem ser verificadas ao vivo:
|
# |
O que pedir na tela |
Prova o quê |
|---|---|---|
|
1 |
Publicar uma regra nova |
Autonomia real |
|
2 |
Reverter para a versão anterior |
Segurança de mudança |
|
4 |
Rodar uma regra em shadow mode sobre dado real |
Autonomia com segurança |
|
8 |
Mostrar a ordem de consulta das fontes |
Controle de custo |
|
9 |
Mostrar a configuração de cache por tipo de dado |
Controle de custo |
|
11 |
Abrir o dossiê de uma decisão antiga |
Defensabilidade |
|
12 |
Mostrar o trace de uma análise em andamento |
Rastreabilidade operacional |
|
14 |
Exportar o histórico de decisões |
Portabilidade |
As outras nove são declarações, e declaração é o que se confere depois, na proposta e no contrato.
A pergunta que resume as dezessete é uma só: quando a régua precisar mudar na semana que vem, quem consegue mudar e o que fica registrado?
Motor de decisão é a camada onde a política de risco de uma instituição vira execução. Ele consulta as fontes de dados, aplica as regras que a instituição definiu e devolve uma decisão — aprovar, recusar ou encaminhar para análise humana — junto com o registro do que foi avaliado.
Ele se distingue de um motor de regras, que executa lógica condicional sobre dados que já chegam prontos. O motor de decisão inclui o motor de regras e resolve o que vem antes e depois: de onde vem cada dado, em que ordem consultar as fontes, o que fazer quando uma delas não responde e como registrar a decisão.
Pedindo demonstração em vez de resposta. Das dezessete perguntas deste material, oito podem ser verificadas ao vivo: publicar uma regra nova, reverter para a versão anterior, rodar uma regra em shadow mode sobre dado real, mostrar a ordem em que as fontes são consultadas, mostrar a configuração de cache, abrir o dossiê de uma decisão antiga, mostrar o trace de uma análise em andamento e exportar dados.
As outras nove são declarações, e declaração se confere na proposta e no contrato, não na reunião. A pergunta que mais separa fornecedores parecidos é a mais simples: quanto tempo leva para colocar uma regra nova em produção sem abrir chamado.
Depende muito menos da plataforma do que da instituição. O que costuma determinar o prazo é a disponibilidade de acesso às bases internas, a existência de uma política de risco escrita e testável, e quem, do lado do cliente, pode validar o resultado.
Ao avaliar um prazo proposto, verifique se ele inclui as dependências do seu lado. Cronograma em que o fornecedor faz tudo sozinho normalmente esconde uma etapa que volta para você depois.
Se o objetivo for reduzir incerteza, sim, desde que o critério de sucesso esteja acordado antes de começar. Prova de conceito sem critério definido tende a não terminar, ou a terminar sem decisão.
Antes de pedir, verifique quanto da dúvida se resolve com demonstração e leitura de contrato. Boa parte das dezessete perguntas se responde sem PoC nenhuma. O que a prova de conceito realmente prova é o resultado da régua sobre os seus casos, não a capacidade da plataforma.
Ambiente exclusivo por cliente, logs e trilha de auditoria, versionamento de configurações e acessos nominais com autenticação centralizada.
E um ponto de responsabilidade que costuma passar batido: em tratamento de dados pessoais, a instituição contratante permanece como controladora e o fornecedor atua como operador. Fornecedor que assume responsabilidade que legalmente não é dele deveria levantar dúvida sobre o resto. Envolver o time de segurança e o encarregado de dados desde a fase de avaliação evita descobrir um impedimento no fim do processo.
Não. A Circular BCB nº 3.978, de 23 de janeiro de 2020, em vigor desde 1º de julho de 2020 e alterada pelas Resoluções BCB nº 119/2021 e nº 282/2022 — não determina ferramenta, arquitetura nem fornecedor.
O que ela exige são capacidades: abordagem baseada em risco própria da instituição e proporcional à sua exposição, documentação de parâmetros, variáveis, regras e cenários, e sistemas de monitoramento passíveis de verificação quanto à adequação e à efetividade.
É possível atender a isso com regras escritas no código da aplicação, desde que a instituição consiga demonstrar qual condição estava vigente em cada decisão. A questão prática é o custo de demonstrar isso quando o pedido chega com prazo.
Depende do que estiver no contrato, e por isso a pergunta precisa ser feita antes de assinar. A obrigação de retenção documental é da instituição, não do fornecedor. Se a trilha de decisões vive apenas na plataforma contratada, a conformidade de períodos passados fica condicionada a um contrato vigente.
O que procurar: exportação completa em formato aberto, sem custo de saída, com prazo definido de disponibilidade após o encerramento.
Fornecedores de motor de decisão são difíceis de comparar porque descrevem a si mesmos com o mesmo vocabulário. Essas 17 perguntas não medem o discurso; medem o que acontece quando a régua muda, quando a fatura chega, quando o volume aumenta e quando alguém pede a justificativa de uma decisão antiga.
Comece pelas oito que podem ser demonstradas ao vivo. Se o fornecedor consegue publicar uma regra, testá-la em shadow mode, reverter uma versão e abrir um dossiê antigo na sua frente, as outras nove perguntas mudam de tom — você deixa de avaliar promessa e passa a negociar contrato.
Próximo passo: leve o checklist acima para a próxima reunião de avaliação e marque quem, do seu lado, é dono de cada bloco de perguntas.
Cada critério levantado aqui é padrão de operação na VAAS. O dado consultado na ordem que a instituição define, os agentes de IA lendo documentos não estruturados e trilha de evidências registrada em cada decisão.
A régua fica com quem entende do risco, e cada decisão continua auditável quando a fiscalização perguntar.
Quer trazer essas perguntas para uma demonstração? Fale com a gente ou acesse nosso site 👇
Fontes: Circular BCB nº 3.978/2020 — Banco Central do Brasil · Lei nº 13.709/2018 (LGPD), art. 20 — Planalto