5 perguntas que a sua plataforma de decisão não consegue responder (mas deveria)

A maioria das plataformas de decisão consegue dizer o que aconteceu. Poucas conseguem explicar por quê, e menos ainda dizem o que fazer a seguir. Essa diferença raramente aparece em uma demonstração. Ela aparece seis meses depois, quando um regulador pede uma explicação, uma mudança de política gera um resultado inesperado ou uma equipe de risco passa uma semana reconstruindo uma decisão que deveria ter levado trinta segundos e uma barra de busca.

As cinco perguntas a seguir surgem o tempo todo em conversas com equipes de risco e fraude que avaliam sua configuração atual. São simples de fazer e, para muitas plataformas, surpreendentemente difíceis de responder. Se a sua plataforma não consegue respondê-las, vale olhar mais de perto, não porque ela esteja com defeito, mas porque pode ter sido construída para executar decisões, e não para oferecer visibilidade e controle sobre elas.

1. Por que esta decisão específica foi tomada?

Não apenas qual regra foi acionada, mas o quadro completo: quais dados, qual modelo, qual versão da política e qual override, se houver, produziram exatamente esse resultado para esse cliente. Se a resposta honesta exige um ticket de suporte e dois dias de reconstrução, isso não é um problema de explicabilidade que se resolva a posteriori. É uma lacuna de governança embutida na arquitetura.

Imagine uma solicitação de auditoria sobre uma decisão tomada há oito meses. A equipe que recebeu o pedido precisa recuperar a versão da política em vigor na época, os dados de entrada disponíveis naquele momento e qualquer override manual aplicado ao longo do caminho, muitas vezes em três sistemas diferentes que nunca foram projetados para ser consultados em conjunto. Esse esforço de reconstrução é o sinal revelador. Uma plataforma construída para a governança responde à pergunta no momento em que ela é feita, e não depois de uma semana de trabalho forense.

2. O que aconteceria se ajustássemos esta política, antes de alterá-la?

A maioria das equipes descobre o efeito de uma mudança de política ao implementá-la e observar a movimentação dos números. É um experimento ao vivo, conduzido com clientes reais e exposição real a risco. Uma plataforma construída para o controle permite simular antes uma mudança de estratégia com dados de produção, para que a decisão de implantar se baseie em evidências, e não em convicção.

Ajustar um limite de detecção de fraude é um bom exemplo. Se você fizer isso em ambiente de produção, descobrirá em tempo real se também acabou bloqueando uma leva de clientes legítimos — geralmente, só depois que as reclamações começam a chegar. Se, em vez disso, você realizar uma simulação utilizando o tráfego real de produção, conseguirá entender o equilíbrio entre aprovações e detecção de fraudes antes mesmo que um único cliente real seja afetado pela mudança.

3. Qual é o grau de consistência desta decisão em todos os canais e produtos?

Se crédito, fraude e cobranças operam em sistemas separados, a resposta honesta costuma ser “não temos certeza”. Uma política endurecida em um sistema não aparece automaticamente nos demais, o que significa que o mesmo cliente pode receber tratamentos inconsistentes, dependendo de qual sistema acabou analisando o caso dele. A consistência ao longo do ciclo de vida não é um exercício de relatórios. É uma propriedade estrutural, que depende de a tomada de decisão operar em um único ambiente governado ou em vários ambientes desconectados.

4. Qual é o desempenho deste modelo agora, e não no trimestre passado?

O monitoramento de modelos com periodicidade mensal ou trimestral significa que uma queda no desempenho pode passar despercebida por semanas. O monitoramento contínuo elimina essa lacuna e resolve, ainda, um desafio mais complexo: não apenas identificar que o desempenho caiu, mas entender o que mudou e o que deve ser feito a respeito — permitindo agir em tempo hábil, em vez de apenas oferecer explicações após o ocorrido.

5. As equipes de negócio conseguem fazer esta mudança, ou precisam esperar pela equipe de TI?

Esse costuma ser o verdadeiro gargalo. Uma equipe de risco identifica uma mudança necessária e depois espera semanas ou meses por capacidade de engenharia para implementá-la. Se todo ajuste de estratégia exige um ciclo de desenvolvimento, a velocidade da tomada de decisão fica limitada pela capacidade de entrega da TI, e não pelo apetite de risco ou pela oportunidade de mercado. Uma plataforma que permite às equipes de negócio configurar e implantar mudanças de estratégia elimina esse teto, sem abrir mão da governança que precisa permanecer.

Uma equipe de risco que identifica um padrão de fraude de rápida evolução em uma segunda-feira, mas não consegue colocar a correção em produção antes que um ciclo de desenvolvimento (sprint) de TI seja concluído — o que pode levar três semanas —, não está diante de um problema de apetite ao risco. Trata-se, na verdade, de um problema na fila de desenvolvimento, disfarçado de questão de apetite ao risco. O intervalo entre o momento em que uma equipe sabe o que precisa ser alterado e o momento em que essa mudança efetivamente chega aos clientes costuma ser o indicador mais claro de onde, de fato, reside o controle.

Onde a sua equipe se posiciona?

Se a sua organização consegue responder a todas essas cinco questões sem demora, sem precisar de soluções paliativas e sem dar de ombros, é provável que a sua plataforma de tomada de decisão já esteja cumprindo o seu papel. Caso contrário, a lacuna costuma ser de natureza arquitetural, e não uma questão de treinamento: é o que acontece quando a lógica de tomada de decisão está dispersa por sistemas que nunca foram projetados para funcionar como um todo integrado.