Como Migrar seu Motor de Decisão: Guia Prático em 7 Etapas

Substituir um motor de decisão de crédito em produção é, sem exagero, um dos procedimentos mais críticos e delicados que uma instituição financeira, fintech ou FIDC pode realizar. Uma migração não é um mero projeto de atualização tecnológica — é uma transformação de negócios sistêmica e de alto risco. O sistema legado, por mais arcaico ou ineficiente que seja, está neste exato momento tomando as decisões reais que ditam o fluxo de caixa, a exposição ao risco e a rentabilidade da sua carteira. Paralisar essa esteira de aprovação é comercialmente inaceitável; realizar uma transição apressada e repleta de falhas pode ser financeiramente catastrófico, resultando em picos de inadimplência (NPL) ou quedas bruscas na taxa de aprovação. A boa notícia é que, utilizando abordagens modernas de engenharia de software e gestão de risco sistêmico, essa transição pode ser orquestrada com zero downtime e total garantia de paridade, preservando o valor do negócio enquanto você destrava a agilidade da próxima geração de tecnologias de crédito.

1. Por que migrar: Os sinais de que o seu motor atual está sufocando o crescimento

A decisão de substituir um motor de decisão de crédito nunca é tomada de ânimo leve. Sistemas legados, muitas vezes hardcoded dentro de monólitos de core banking ou em plataformas engessadas (frequentemente confundidas na dicotomia de motor de crédito vs ERP), criam uma âncora invisível que impede a organização de responder a movimentos rápidos de mercado ou de reguladores, como exigências do Banco Central (por exemplo, a Resolução CMN nº 4.966 sobre provisionamento e classificação de risco).

Os executivos de crédito e diretores de risco (CROs) no Brasil enfrentam desafios singulares — volatilidade de taxas, mudanças abruptas nos índices de inadimplência do consumidor e a explosão de dados alternativos (como o Open Finance). Para operar nesse cenário, a tecnologia precisa ser um facilitador, e não um gargalo. Se a sua instituição reconhece três ou mais dos sintomas abaixo, o custo de oportunidade de manter a infraestrutura legada já ultrapassou os riscos de uma migração:

• Time-to-market em semanas ou meses: Alterar um simples ponto de corte de score, ajustar uma regra de limite ou introduzir uma nova política de prevenção à fraude exige a abertura de tickets para a TI, passando por ciclos de desenvolvimento, Quality Assurance (QA) e deployments completos que atrasam a resposta comercial.
• Falta de Governança e Versionamento: Não existe um histórico auditável (audit trail) claro. Quando o comitê de crédito pergunta "Qual política estava ativa na originação desta safra em março do ano passado, que agora está performando mal?", a equipe não consegue reconstruir o cenário sem horas de engenharia reversa no código ou no banco de dados.
• Déficit de Observabilidade e Explicabilidade: Você acompanha a taxa de aprovação (approval rate) no topo do funil, mas existe uma "caixa preta" estrutural. Não é possível identificar rapidamente por que um subsegmento específico foi reprovado ou qual regra específica causou o gargalo. Isso fere diretamente as exigências de explicabilidade de decisões automatizadas, previstas no Art. 20 da LGPD (Lei Geral de Proteção de Dados).
• Latência Operacional Inaceitável: As decisões demoram mais de 5 a 10 segundos, causando fricção severa no ponto de venda (POS), no e-commerce ou no onboarding digital, resultando em abandono de carrinho e perda de originação valiosa.
• Ausência de Ferramentas de Backtesting: Mudanças de política são colocadas em produção baseadas na "esperança e intuição" ou em planilhas desconectadas da realidade do motor, gerando um risco sistêmico enorme em cada alteração não validada com dados reais históricos.
• Vendor Lock-in Asfixiante: O fornecedor de software atual dita o roadmap da sua empresa. Personalizações são cobradas a peso de ouro, não há suporte a novas linguagens ou frameworks de Machine Learning (como a integração de modelos Python/XGBoost diretamente no fluxo) e o custo de licenciamento corrói o ROI do motor de decisão.

2. A dura realidade: Por que tantas migrações falham de forma espetacular?

Embora a necessidade de modernização seja latente em todo o mercado financeiro, a execução desses projetos carrega um histórico preocupante. Os dados do mercado sobre transformação digital e substituição de sistemas core pintam um quadro desolador que não pode ser ignorado por nenhum CTO ou CRO.

"Estudos indicam que impressionantes 83% dos projetos de migração de dados falham em algum aspecto — seja excedendo o orçamento, ultrapassando o cronograma planejado ou sofrendo com degradação severa na qualidade da operação" ^{[Fonte: Forbes/Industry Benchmarks, 2021]}.

As projeções continuam cautelosas: o Gartner estima que, até 2027, mais de 70% das iniciativas de substituição de software corporativo (ERP, CRM, Core Banking, Motores de Risco) não atingirão os objetivos de negócios originais ^{[Fonte: Gartner, 2023]}. Se 70% a 80% das migrações de infraestrutura legada fracassam, quais são os vetores fundamentais dessa taxa de mortalidade em projetos de crédito?

• Subestimação da dívida técnica: As regras de negócio reais raramente estão apenas nos manuais de crédito. Elas residem como "gambiarras" no código de integração, stored procedures obscuras no banco de dados, ou scripts que ninguém sabe quem escreveu em 2014. Quando o projeto não faz o discovery adequado, essas regras se perdem.
• A ilusão do "Big Bang": Desligar o sistema antigo na sexta-feira e ligar o novo na segunda-feira. Essa abordagem maximiza o raio de explosão e impede qualquer reversão estruturada se os dados começarem a divergir na segunda de manhã.
• Desvios de escopo (Scope Creep): A equipe tenta "consertar" processos quebrados, refatorar modelos de machine learning e mudar a lógica de aprovação simultaneamente à migração tecnológica. Isso viola um princípio de engenharia: introduzir múltiplas variáveis desconhecidas ao mesmo tempo impede o diagnóstico preciso de problemas.
• Perda de dados de auditoria: A migração foca no fluxo de decisão futuro e negligencia a migração dos logs de decisão passados, inviabilizando calibrações de modelos (retraining) e criando um passivo de conformidade com o Banco Central e auditorias independentes.

3. Estratégias de Arquitetura de Migração: O comparativo técnico

Para navegar por essas estatísticas sombrias, a arquitetura da decisão durante a fase de transição é o diferencial entre um desastre e um sucesso invisível para o usuário final. Existem três padrões de adoção predominantes, cada um com diferentes perfis de risco operacional e complexidade de orquestração.

4. Deep Dive: O Padrão "Strangler Fig" aplicado a Motores de Risco

Introduzido pelo engenheiro de software Martin Fowler, o padrão Strangler Fig (inspirado na figueira que cresce ao redor e gradualmente substitui a árvore hospedeira) é o mecanismo definitivo de mitigação de risco para migrações corporativas ^{[Fonte: Martin Fowler, 2004]}. Em vez de uma migração monolítica, você constrói uma camada fina de roteamento de API.

Na prática do mercado de crédito, isso significa colocar um API Gateway na frente de todas as requisições de decisão. O Gateway analisa a carga útil (payload). Se a requisição pertencer a um produto específico (ex: "Cartão de Crédito Universitário"), o Gateway roteia a solicitação para o Novo Motor de Decisão. Se não, continua enviando para o Motor Legado. À medida que você ganha confiança e mapeia novos produtos no sistema novo, você altera a configuração do Gateway para rotear mais tráfego, até que o sistema antigo não receba mais nenhuma chamada e possa ser comissionado.

5. Shadow Scoring: O teste definitivo de fogo

A transição de arquitetura exige mais do que apenas rotear tráfego; exige a certeza matemática de que o novo motor produz o mesmo resultado que o legado (paridade). A técnica mais robusta para isso é o Shadow Scoring (ou Shadow Mode), uma extensão lógica da execução paralela adaptada para a inteligência de negócios.

No Shadow Mode, a requisição de crédito de um cliente, digamos "João da Silva, solicitando R$ 5.000 via WhatsApp", entra no sistema. O API Gateway duplica o evento. A requisição vai para o Motor Legado — que executa as regras reais, cobra as consultas nos bureaus, e retorna "Aprovado com Limite de R$ 4.000". Esse é o resultado devolvido ao João. Simultaneamente, a requisição em shadow é enviada ao Novo Motor. Mas há um detalhe crucial: para não pagar duas vezes a consulta do bureau, o Gateway precisa injetar o payload do bureau já consumido pelo Legado (mocking de dados externos).

O Novo Motor avalia as políticas reimplementadas e gera sua própria resposta silenciosa. Você armazena ambos os resultados em um Data Lake ou banco analítico. Diariamente, analistas cruzam os dados calculando a Taxa de Concordância (Match Rate).

• Concordância Exata: Ambos os motores disseram "Aprovado, R$ 4.000". (O ideal é mirar >99,5%).
• Falsos Positivos Legados: O legado aprovou, o novo motor negou (a investigar: bug no legado que foi corrigido no novo, ou regra muito restrita no novo?).
• Diferenças de Limite (Limit Discrepancies): A aprovação ocorreu em ambos, mas os valores de corte de limite (Credit Line Assignment) deram centavos ou milhares de reais de diferença devido a arredondamentos matemáticos distintos entre sistemas.

O Shadow Scoring separa o erro de sistema do erro de negócio antes que um único real seja provisionado no balanço da empresa.

6. O Cronograma: As 4 Fases Práticas de uma Migração Blindada

Baseado nas melhores práticas das fintechs unicórnios no Brasil, desenhamos o playbook de execução que minimiza sobressaltos e garante governança de TI em conformidade com as diretrizes de risco.

Fase 1 — Assessment, Discovery e Mapeamento (Semanas 1-3)

O objetivo desta fase não é codificar, mas exorcizar os demônios do sistema legado. É necessário levantar um inventário exhaustivo e doloroso de toda a operação.

• Árvore de Políticas e Regras: Mapear todas as matrizes de aprovação vigentes, scorecards (tabelas de pontos), matrizes de precificação (APR) baseadas em risco e regras de knock-out (políticas de corte rígido como "idade < 18", "restritivo ativo BACEN").
• Mapeamento de Fontes de Dados (Data Dictionary): Quais campos (features) alimentam a política? São necessários os mesmos inputs? Qual formato o legado esperava? (ex: `income` era Float, agora será Integer em centavos?). Identifique todas as chamadas síncronas a bureaus externos (Serasa Experian, Quod, SPC, SCR do BACEN).
• Modelos de Risco (Machine Learning/Estatística): Listar todos os modelos preditivos em produção (Regressão Logística, Random Forest, XGBoost). Eles estão hospedados no motor ou são consumidos via API externa? Como eles serão migrados?
• Integrações Downstream: Quem consome o resultado? O CRM, o ERP financeiro, a esteira de cartões (Processadora). Quais SLAs de tempo e formato de JSON eles exigem?

Fase 2 — Design da Arquitetura Alvo e Implementação (Semanas 4-8)

Com o inventário em mãos, inicia-se a etapa de design e replicação. A regra de ouro (golden rule) dessa fase é: Paridade Funcional Estrita, sem Refatoração de Negócios. Não aproveite a migração para "apertar a política e reduzir inadimplência". Se você mudar a tecnologia e a regra ao mesmo tempo, não saberá qual causou as variações no pipeline.

• Reimplementação visual ou em código (usando Python, JSON, ou DMN) das regras no novo motor, utilizando o inventário como checklist de cobertura.
• Implementação do API Gateway e da lógica de roteamento condicional (Strangler Fig).
• Criação de mocks e stubs para garantir que o ambiente de homologação não gere custos adicionais de consultas a birôs.
• Elaboração do plano de migração de banco de dados (ETL de históricos de logs de decisão antigos para o novo ambiente, se exigido por conformidade regulatória).

Fase 3 — Execução: Rollout Incremental e Canary Deployments (Semanas 9-12)

É a fase de virar a chave, operando a política de tráfego de forma clínica, similar à liberação de medicamentos em testes clínicos.

1. Shadow Mode Puro (2 semanas): 100% de tráfego sendo espelhado silenciosamente. As análises diárias focam no fechamento dos "deltas" de concordância até atingir >99% de correspondência.
2. Canary Release — 1% a 5% (Dias 1 a 3): Tráfego de uma região geográfica pequena ou de uma safra de clientes com baixo LTV (Life Time Value) é ativamente redirecionada ao novo motor de decisão. Monitoramento em tempo real (Datadog/Grafana) de erros 500 ou timeouts da API.
3. Ramp-up (Dias 4 a 14): Se as métricas estiverem estáveis, o roteador de tráfego abre o funil: 20%, 50%, até alcançar 100%. Nesse ponto, o sistema novo tornou-se o sistema master de produção.

Fase 4 — Validação e Decomissionamento (Semanas 13-16)

Com 100% da esteira de crédito passando pelo novo motor, a operação entra em monitoramento de eficácia e validação pós-migração contínua. Aqui, entra o uso intensivo de estratégias de Champion/Challenger.

• Auditoria de KPIs de Negócio: Comparar as safras pré-migração (antigas) com as pós-migração. As taxas de aprovação geral caíram? O ticket médio de aprovação mudou? O tempo de ciclo diminuiu de 8s para 800ms?
• Testes Retrospectivos Ativos: Agora que a tecnologia foi provada, a equipe de risco usa o novo ambiente de backtesting em lote (batch processing) sobre dados dos últimos 12 meses para validar novas estratégias e começar a "melhorar" de fato as regras, aproveitando a agilidade conquistada.
• Sunset do Legado: O sistema antigo é mantido "na geladeira" (cold standby) por 30 a 60 dias para o caso improvável de uma regressão regulatória grave exigir um rollback tardio. Passado esse período de quarentena, corta-se o cabo do banco de dados, encerram-se os contratos do fornecedor antigo e desliga-se a máquina. O projeto está tecnicamente completo.

7. As 3 Armadilhas (Pitfalls) Mais Letais em Projetos de Migração

A experiência da indústria relata incidentes repetidos em três frentes durante essas reestruturações profundas de arquitetura de decisão.

• Armadilha da Deriva Política (Policy Drift): Ocorre quando, durante os 3 a 6 meses de transição tecnológica, a área comercial ou de risco continua pedindo "ajustes urgentes" na política de decisão no sistema legado, devido a necessidades do mercado. Se esses ajustes não forem replicados manualmente e imediatamente na base de código do novo motor (que está em construção), os dois sistemas "derivam" logicamente. A migração ocorrerá para um alvo desatualizado. A mitigação é instituir um rigoroso "Code Freeze" ou "Policy Freeze" na plataforma legada algumas semanas antes do cut-over.
• Armadilha da Perda de Contexto Analítico (Data Loss & Lineage Breach): Quando as respostas da API downstream mudam de estrutura (de XML antigo para um JSON moderno), as equipes de Data Science que treinam modelos de machine learning perdem a linhagem das variáveis. O motor novo pode retornar o mesmo "Aprovado", mas a feature chamada "score_risco_v1" desapareceu, quebrando pipelines inteiros no ambiente de Model Ops. A arquitetura decision architecture deve mapear contratos de dados restritos.
• Armadilha do "Aproveitando a Viagem" (Scope Creep Funcional): A diretoria solicita: "Já que estamos mudando o motor, vamos implementar também reconhecimento facial com biometria no fluxo". Esse é o atalho para as estatísticas nefastas de 83% de falhas. A migração técnica deve ser um evento puro de Lift and Shift lógico; a inovação funcional só começa no "Day 2", após o tráfego 100% consolidado.

8. Como a Sinky redefiniu a Engenharia de Migrações Críticas

A Sinky construiu sua plataforma com um profundo entendimento das dores agudas que CTOs e CROs enfrentam ao tentar mover alicerces sem derrubar o edifício operacional. A arquitetura moderna da plataforma simplifica radicalmente as Fases de Transição.

Nossa plataforma dispõe de funcionalidade nativa de Shadow Mode no Decision Stack™. Sem precisar que seu time de engenharia passe meses construindo gateways de roteamento e serviços de orquestração assíncrona, a Sinky aceita replicação de carga diretamente via webhook, executa os pipelines concorrentes utilizando os mesmos mocks externos, e gera nativamente dashboards de concordância (Match Rate) linha a linha, variável por variável.

Quando chegar o momento do Traffic Split (Canary Release), a interface permite gerir dinamicamente a exposição da base de produção em degraus controlados (5%, 20%, 50%), assegurando que você valide as melhorias em tempo de latência (nossas execuções médias operam em frações de milissegundo, muito abaixo do mercado legado) e consolide a confiança no pipeline de observabilidade antes da mudança definitiva.