Login Agendar reunião
Voltar para o blog
Destaques

17 perguntas para fazer a qualquer fornecedor de motor de decisão

Sep 17, 2026, 12:00:00 AM · 19 min de leitura · Paulo Tesman
<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >17 perguntas para fazer a qualquer fornecedor de motor de decisão</span>

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.

Principais pontos

  • 8 das 17 perguntas podem ser verificadas ao vivo. As outras 9 são declarações, e declaração se confere na proposta e no contrato.
  • A pergunta que mais separa fornecedores parecidos é a primeira: quanto tempo leva para colocar uma regra nova em produção sem abrir chamado.
  • Volumetria e cache não aparecem no material de vendas, mas aparecem na fatura. Duas das perguntas novas existem justamente para trazer essas alavancas de custo e capacidade para a mesa antes da assinatura.
  • Ordene as perguntas por quem pergunta. Operação, custo, compliance e segurança da informação enxergam riscos diferentes na mesma plataforma.
  • Nenhuma norma exige um motor de decisão. A Circular BCB nº 3.978/2020 exige capacidades — abordagem baseada em risco, documentação e monitoramento verificável.
  • A pergunta que resume as dezessete: quando a régua precisar mudar na semana que vem, quem consegue mudar e o que fica registrado?

Índice

Bloco

Perguntas

Quem faz

Autonomia e velocidade

1 a 6

Quem vai operar

Custo e dado

7 a 10

Quem aprova o orçamento

Defensabilidade

11 a 14

Compliance e auditoria

Segurança da informação

15

SI e encarregado de dados

Honestidade

16 e 17

Você

Como usar no comitê

Todos

Por que comparar motores de decisão é difícil

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.

Autonomia e velocidade

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.

1. Quanto tempo leva para colocar uma regra nova em produção, sem abrir ticket para vocês?

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.

2. Se eu mexer na configuração, o que está em produção quebra?

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.

3. Qual é a capacidade de processamento da plataforma, e como isso é testado?

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.

4. Eu consigo testar uma mudança de regra com dado real de produção antes de publicá-la, sem afetar quem já está no fluxo?

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.

5. Existe checagem dupla antes de uma versão ir para produção, ou qualquer pessoa com acesso publica sozinha?

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.

6. Quem customiza depois do go-live: nós ou vocês?

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.

Custo e dado

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.

7. O preço inclui o dado ou vocês revendem o dado com margem?

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.

8. Em que ordem as fontes são consultadas?

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.

9. Existe cache configurável para não pagar de novo por uma consulta recente ao mesmo birô?

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.

10. Quantas fontes Bureaus vocês têm no Brasil, e como escolhem qual usar para cada tipo de dado?

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.

Defensabilidade

Este bloco pertence a compliance e auditoria. A instituição pode ter decidido corretamente e ficar exposta por não conseguir demonstrar como decidiu.

11. Se um fiscal pedir a justificativa de uma decisão de oito meses atrás, o que vocês me entregam?

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.

12. Eu consigo ver, em tempo real, por qual caminho do fluxo uma análise específica passou?

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.

13. O que a IA decide e o que ela apenas extrai?

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.

14. Se eu sair, o que acontece com o histórico das minhas decisões?

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".

Segurança da informação

15. Como funciona a segurança da informação, e quem responde pelo quê?

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.

Honestidade

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.

16. O que vocês fazem mal?

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.

17. Quem, na sua base, deixou de ser cliente, e por quê?

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."

Como usar no comitê

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.

Checklist para levar à reunião

  • Cada uma das 17 perguntas tem um dono nomeado no comitê
  • As 8 perguntas demonstráveis foram pedidas ao vivo, na tela, e não por slide
  • As 9 declarações foram registradas em ata com nome de quem respondeu
  • Prazo de publicação de regra e escopo de autonomia estão na proposta, por escrito
  • Capacidade de processamento e cache foram testados ou comprovados com número, não só declarados
  • Separação entre custo de plataforma e custo de dado está aberta linha a linha
  • Cláusula de exportação de histórico, formato e prazo pós-encerramento está no contrato
  • SI e encarregado de dados foram envolvidos antes da fase final, não depois
  • O fornecedor nomeou uma fraqueza concreta e um perfil de cliente que perdeu

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?


Perguntas frequentes

O que é um motor de decisão?

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.

Como avaliar um motor de decisão se todos os fornecedores dizem a mesma coisa?

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.

Quanto tempo leva para implantar um motor de decisão?

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.

Vale pedir uma prova de conceito antes de contratar?

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.

O que precisa entrar na avaliação de segurança da informação?

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.

Um motor de decisão é obrigatório pela Circular BCB nº 3.978?

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.

O que acontece com o histórico das decisões se a gente trocar de fornecedor?

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.


Conclusão

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

Continue lendo