Rules Engine vs ML: Quando Usar Regras e Quando Usar Modelos

O debate entre Rules Engine (Motores de Regras) e Machine Learning (ML) em operações de crédito é frequentemente estruturado como uma falsa dicotomia. Executivos e engenheiros de risco costumam perguntar: "Devemos usar regras ou machine learning?" A resposta honesta, madura e chancelada pelas maiores operações financeiras do mundo é: depende. E, na quase totalidade das arquiteturas modernas, a resposta é: ambos. Compreender quando aplicar cada abordagem — e, mais criticamente, como orquestrá-las em um sistema unificado — é o que separa as fintechs e bancos que escalam com segurança daqueles que sucumbem à rigidez operacional ou ao risco regulatório.

A Falsa Dicotomia: Por que não é "Regras OU ML", mas sim "Regras E ML"

Historicamente, a concessão de crédito dependia exclusivamente de sistemas baseados em regras rígidas. Com o advento do Big Data e da capacidade computacional elástica, o Machine Learning emergiu como a promessa definitiva de precisão preditiva, levando muitos líderes de tecnologia a declararem a morte iminente dos motores de regras. Esta visão, no entanto, provou-se míope.

A realidade do mercado financeiro brasileiro e global exige um equilíbrio delicado entre capacidade preditiva e controle determinístico. Modelos de Machine Learning (como XGBoost e Random Forest) superam consistentemente as regras tradicionais em métricas de performance estatística (AUC-ROC, Gini) para predição de inadimplência (default) ^{[Fonte: Credolab, 2023]}. Contudo, algoritmos de ML operam frequentemente como "caixas pretas" probabilísticas. Eles calculam que um usuário tem 87% de probabilidade de honrar uma dívida, mas não são desenhados para aplicar a regra absoluta e inflexível imposta pelo regulador de que "pessoas politicamente expostas (PEP) exigem due diligence reforçada".

A consultoria Gartner cunhou o termo "Composite AI" para descrever a combinação de diferentes técnicas de inteligência artificial — nomeadamente o uso de Machine Learning para reconhecimento de padrões complexos em conjunto com Rules Engines para o estabelecimento de "guardrails" (barreiras de proteção) de compliance ^{[Fonte: Gartner, 2024]}. O caminho para a excelência em crédito, portanto, não é a substituição de uma tecnologia pela outra, mas a construção de uma esteira de decisão (um decisioning pipeline) onde cada ferramenta opera na dimensão em que é insuperável.

Rules Engine: Anatomia, Funcionamento e Suas Maiores Forças

Um Rules Engine, ou Motor de Regras de Negócio (BRMS - Business Rule Management System), é um componente de software que executa lógica determinística e condicional definida explicitamente por especialistas humanos (analistas de risco, policy managers, advogados de compliance). Sua premissa fundamental é "Se X, então Y" (If-Then-Else).

A Ciência da Decisão Determinística: DMN e Árvores de Decisão

Na prática arquitetural, motores de regras modernos como o oferecido por motores de decisão de crédito operam utilizando padrões globais como o DMN (Decision Model and Notation). O DMN permite que a lógica de negócios seja modelada visualmente através de Tabelas de Decisão (Decision Tables) e Árvores de Decisão (Decision Trees).

Por exemplo, uma matriz de cut-off de crédito pode ser expressa em uma tabela DMN onde:

• Se (Score Serasa > 700) E (Renda Comprometida < 30%), ENTÃO (Aprovar).
• Se (Score Serasa < 500) OU (Apontamentos > 0), ENTÃO (Negar).

As características fundamentais e inegociáveis de um Rules Engine incluem:

• Comportamento Estritamente Determinístico: Sob nenhuma circunstância o motor gerará um resultado diferente caso os inputs sejam idênticos. A mesma combinação de payload de entrada sempre produzirá exatamente a mesma saída.
• Transparência e Explicabilidade Inata: A justificativa para qualquer recusa ou aprovação é imediata, auto-evidente e baseada na regra exata que foi acionada. Isso é vital para a explicabilidade da decisão.
• Imunidade ao "Concept Drift": Ao contrário de modelos de ML que degradam quando o cenário macroeconômico muda (ex: aumento súbito da taxa Selic), as regras permanecem constantes e não sofrem viés de dados não-estacionários.
• Auditabilidade Extrema: Cada regra, sua versão, a data em que entrou em vigor e o usuário que a aprovou são mapeáveis para fins de auditoria do Banco Central.
• Agilidade de Implantação: O ajuste de um parâmetro (ex: alterar a idade mínima de 18 para 21 anos) leva literalmente minutos para ir de staging para produção, sem necessidade de re-treinamento ou validação estatística complexa.

Machine Learning: O Motor Preditivo do Crédito Moderno

Em contraste diametral à lógica codificada por humanos, o Machine Learning opera por indução. Em vez de dizermos ao sistema quais são as regras que diferenciam um bom de um mau pagador, nós fornecemos ao algoritmo de ML uma vasta base de dados históricos (milhões de transações, faturas pagas, calotes, metadados comportamentais) e delegamos à máquina a tarefa de descobrir a função matemática (o modelo) que melhor mapeia esses dados às suas respectivas classes (adimplente vs. inadimplente).

Supervised Learning, Feature Engineering e Modelos de Árvore

Para scoring de crédito e substituição de scorecards tradicionais, a indústria orbita majoritariamente em torno de algoritmos de Supervised Learning (Aprendizado Supervisionado) e, mais especificamente, algoritmos baseados em Gradient Boosting (como XGBoost, LightGBM ou CatBoost) e Random Forests. Redes neurais profundas (Deep Learning) são excelentes para visão computacional, mas frequentemente perdem para XGBoost em dados tabulares — que compõem 99% dos dados de bureaus de crédito.

A força motriz por trás do desempenho estratosférico do ML no crédito é o Feature Engineering (Engenharia de Variáveis). Enquanto uma regra de negócios só consegue lidar com algumas dezenas de variáveis simultaneamente sem explodir a complexidade cognitiva do analista humano, um modelo de ML avalia centenas ou milhares de features interligadas simultaneamente, capturando não-linearidades.

Por exemplo: um cliente que gasta 80% do limite do cartão pode ser considerado de alto risco por uma regra genérica. Contudo, o ML pode descobrir que "Gastar 80% do limite" E "Fazer compras recorrentes de supermercado às segundas-feiras" E "Acessar o app do banco via iOS" correlaciona-se com altíssima adimplência. Tais micro-padrões e interações hiper-complexas são invisíveis aos motores de regras.

Estudos indicam que a inclusão de dados comportamentais alternativos (alternative data) processados por ML reduz substancialmente os índices de NPL (Non-Performing Loans - empréstimos não performados) em carteiras de fintechs e bancos digitais ^{[Fonte: RJWAVE, 2023]}.

Comparativo Estrutural: Rules Engine vs. Machine Learning vs. Híbrido

Para sistematizar a arquitetura de crédito de uma instituição financeira, é imperativo mapear como essas abordagens se comparam nas dimensões operacionais, de risco e de ciclo de vida do software.

Dimensão Estratégica	Rules Engine (Motor de Regras)	Machine Learning (Modelos Preditivos)	Abordagem Híbrida ("Composite AI")
Capacidade Preditiva (Accuracy)	Baixa a moderada. Limitada à capacidade humana de observar correlações simples (modelos lineares e recortes simples).	Altíssima. Captura interações não-lineares, micro-comportamentos e tendências hiper-dimensionais (XGBoost, etc).	Máxima. O ML otimiza a predição probabilística, enquanto as regras garantem que anomalias bizarras do modelo sejam bloqueadas ("guardrails").
Explicabilidade (Explainability)	Total e intrínseca. O sistema retorna o ID exato da regra de recusa.	Requer técnicas de XAI post-hoc complexas, como SHAP (Shapley Additive exPlanations) ou LIME. [Fonte: MDPI, 2023]	Controlada. Regras geram explicabilidade direta para recusas hard; decisões guiadas por ML usam SHAP para justificar variação de taxa.
Tempo de Desenvolvimento e Deploy	Horas ou dias. Um analista edita uma árvore DMN, faz o teste de regressão e implanta em produção instantaneamente.	Semanas ou meses. Requer extração de dados, feature engineering, split de treino/teste, backtesting, tuning de hiperparâmetros, empacotamento MLOps e monitoramento de drift.	Balanceado. As regras são alteradas agilmente, permitindo que o risco reaja hoje, enquanto a equipe de Data Science treina o novo modelo ML para o próximo mês.
Manutenção e Adaptabilidade	Manual. Requer intervenção humana constante. Se a economia muda, o analista deve reescrever as matrizes de corte.	Automatizada/Semi-automatizada através de pipelines de CI/CD para retreino periódico com novos dados (MLOps).	Resiliente. Usa arquitetura Champion/Challenger: a política híbrida testa novos modelos e regras simultaneamente, sem interrupção.
Compliance Regulatório e Auditoria	Simples. Auditoria direta. Políticas de PLD e KYC são implementadas exatamente como a lei ou o compliance exigem.	Complexo. Difícil provar para o BACEN de forma determinística que não houve recusa por viés implícito não mapeado nos dados (discriminação indireta).	Ideal. Camadas de regras "hard" lidam com obrigações legais estritas, blindando a instituição; ML atua apenas no que não é tocado pela regulação (score livre de viés).
Requisitos de Dados para Setup	Nenhum dado histórico é necessário. Pode operar baseado puramente no conhecimento prévio, leis e "senso comum" de risco (Cold Start).	Extensos. Exige dezenas de milhares de amostras de safras antigas consolidadas para que o treinamento tenha validade estatística e não sofra de overfitting.	Escalável. A operação nasce 100% regras e gradativamente os modelos de ML são adicionados às etapas da esteira à medida que a volumetria de dados históricos amadurece.

Quando as Regras Vencem: O Reino do Compliance e dos Limites Rígidos

Apesar de toda a capacidade preditiva da Inteligência Artificial, há domínios na gestão de crédito onde o uso exclusivo de Machine Learning é não apenas ineficiente, mas frequentemente ilegal, criando risco de conformidade inaceitável.

O Rules Engine é indiscutivelmente superior e obrigatório nos seguintes cenários operacionais:

• Regulação Explícita (Compliance, PLD, KYC e AML): Resoluções do Banco Central e políticas do COAF sobre Lavagem de Dinheiro (PLD) ou Prevenção ao Financiamento do Terrorismo (AML) não são sugestões probabilísticas. Se um CPF consta na lista OFAC ou é uma Pessoa Politicamente Exposta (PEP) sancionada, a recusa ou bloqueio deve ser imediato, binário e rastreável. Não há espaço para o modelo de ML dar um "score favorável". Para aprofundar-se, leia sobre compliance automatizado e onboarding.
• Parâmetros Fixos de Produto ("Hard Filters"): Se o FIDC estipula que a idade mínima para o crédito é 21 anos, ou que operações na região Norte estão temporariamente suspensas devido a um limite de concentração geográfica do fundo, uma regra simples resolve a questão. Tentar ensinar a um algoritmo de ML que ele deve negativar pessoas de 20 anos é desperdiçar poder de processamento.
• Fast-Reject ("Filtro de Funil"): A consulta a bureaus de crédito avançados ou APIs de open finance custa dinheiro. Motores de regras operam como o "leão de chácara", executando validações gratuitas ou ultra-baratas (ex: formato de CPF, consistência de renda) para rejeitar CPFs obviamente inelegíveis (fast-reject) antes de gastar recursos computacionais acionando APIs de dados caros para o motor de ML.
• Operações "Cold Start": Lançou um produto de crédito inédito hoje? Você não tem dados de safra (vintages) para treinar um modelo de ML. Você terá que rodar sua operação puramente no Rules Engine (baseado no julgamento de especialistas) durante os primeiros 6 a 12 meses, até acumular os vetores de default necessários.

Quando o Machine Learning Vence: Padrões Ocultos e Scoring Comportamental

Enquanto as regras se destacam no bloqueio determinístico, elas são catastroficamente ineficientes para entender as gradações sutis do risco financeiro. Se você baseia todo o seu comitê de crédito em matrizes DMN gigantescas com milhares de ramificações, sua manutenção se torna um pesadelo e sua assertividade cai exponencialmente. É aqui que o Machine Learning destrói qualquer competidor baseado em regras.

• Scoring Transacional e Comportamental Contínuo: A detecção de risco de crédito deixou de ser um evento estático no momento do onboarding. O ML avalia vetores contínuos: como a velocidade de digitação no app, as categorias de gastos PIX em tempo real e a variação do balanço médio, consolidando centenas de micro-sinais em uma única pontuação probabilística.
• Precificação Dinâmica Baseada em Risco (Risk-Based Pricing): Motores de regras definem tabelas tarifárias (grids) engessadas (ex: Score A = 2%, Score B = 3%). O ML calcula a elasticidade da demanda e a superfície exata de probabilidade de default para retornar a taxa percentual de juros (APR) ideal e hiperpersonalizada para aquele indivíduo específico em milissegundos (ex: 2.37%), maximizando a margem (LTV) e minimizando o risco.
• Combate à Fraude Complexa ("Fraud Rings"): Quadrilhas de fraudadores testam ativamente e aplicam engenharia reversa nas políticas baseadas em regras de bancos. Se a regra diz "bloquear tentativa de login às 3h da manhã", a fraude ocorre às 7h. Algoritmos de ML não-supervisionados (Clustering/Anomaly Detection) e supervisionados detectam padrões de interligação de dispositivos e anomalias dimensionais invisíveis ao analista de fraudes tradicional.
• Propensão e Upsell (Coleções e Recuperação): Em cenários de renegociação de dívidas ativas, modelos preditivos de ML estimam a propensão de o cliente aceitar um acordo de quitação com x% de desconto, algo virtualmente impossível de calibrar em um DMN estático de regras.

A Abordagem Híbrida ("Composite AI"): O Padrão Ouro da Indústria

Chegamos, portanto, à arquitetura corporativa definitiva, amplamente advogada pelo Gartner e praticada por conglomerados financeiros de ponta: o Hybrid Decisioning. Em vez de uma luta armada onde um lado deve vencer, a inteligência é roteada através de um pipeline estratificado e orquestrado.

"Regras ditam O QUE o sistema é permitido fazer; O Machine Learning calcula a PROBABILIDADE associada à oportunidade. Juntos, eles entregam decisões que são, simultaneamente, preditivas, lucrativas e invulneravelmente auditáveis."

Uma esteira de decisão moderna que faz uso de "Composite AI" não roda os sistemas em paralelo sem coordenação; ela os empilha. Cada requisição de crédito viaja por um grafo (ou DAG - Directed Acyclic Graph) de decisão perfeitamente orquestrado. A saída de um modelo ML pode servir como insumo para a variável de entrada de um motor de regras de negócio, e vice-versa.

Implicações Regulatórias: BACEN, LGPD e a Necessidade do Híbrido

O mercado brasileiro opera sob um dos frameworks regulatórios mais estritos e sofisticados do globo, monitorado de perto pelo Banco Central do Brasil (BACEN) e supervisionado sob a ótica da Lei Geral de Proteção de Dados (LGPD). O uso exclusivo de Machine Learning padece gravemente sob o peso destas normas, tornando a adoção de um pipeline híbrido não apenas uma vantagem tática, mas uma obrigação legal de sobrevivência sistêmica.

A LGPD (Artigo 20) e as Decisões Automatizadas:
A legislação brasileira concede ao titular dos dados o direito incontestável de solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses — inclusive aquelas destinadas a definir seu perfil de crédito. Além disso, as instituições são obrigadas a fornecer informações claras e adequadas a respeito dos critérios e dos procedimentos utilizados para a decisão automatizada.

Explicar que "a rede neural, multiplicando os pesos dos tensores nas camadas ocultas da árvore XGBoost, deduziu um score baixo com base nas suas últimas 5.000 transações" não satisfaz o requisito legal de transparência, nem é inteligível ao consumidor médio ou ao Procon. Além disso, órgãos reguladores (Gartner adverte sobre legislações iminentes globais, como o EU AI Act ^{[Fonte: Gartner, 2023]}) punem severamente o bias (viés) discriminatório implícito, mesmo que acidental.

Como o Híbrido Resolve a Exigência Legal:

• Camada de Regras (Guardrails Anti-Viés): O motor de regras garante, a priori, que variáveis protegidas (raça, gênero, religião) ou proxies diretos dessas variáveis sejam bloqueadas de ingressar no cálculo. Se houver recusa em decorrência de política (ex: "tempo de emprego inferior a 3 meses"), o sistema gera um "Reason Code" claro, determinístico e perfeitamente legível pelo consumidor, aderente à LGPD.
• Camada de ML Explicável (XAI - Explainable AI): Para a camada que efetivamente avalia a probabilidade de default baseada em comportamento volumétrico, a plataforma aplica SHAP (Shapley Additive exPlanations) para extrair do modelo a contribuição exata de cada feature na decisão, traduzindo um algoritmo altamente não-linear em uma tabela de pesos relativos documentável. Para aprofundar no rigor metodológico de auditoria de algoritmos e IA, consulte nossa página de decisioning hub unificado.

Arquitetura do Mundo Real: Integrando Regras e ML no Pipeline de Decisão

Em uma esteira de decisão corporativa projetada para alta disponibilidade (milhares de transações por segundo), a arquitetura "Composite AI" se traduz em um fluxo sequencial em camadas ou em um grafo de decisão orquestrado.

Veja como é a anatomia de um Pipeline Híbrido Completo em 6 Estágios para originações e concessão de crédito complexo (como cartões ou BNPL - Buy Now Pay Later):

1. Camada 1 — Data Ingestion & Validação Estrutural (Rules):
   O motor de regras recebe a chamada da API (o payload). Ele checa a sintaxe (CPF estruturalmente válido, data de nascimento coerente, ausência de campos nulos críticos). Benefício: Custo zero, latência de microsegundos, protege o backend.
2. Camada 2 — Hard Policy & Compliance (Rules):
   As regras consultam bureaus e bancos de dados institucionais restritos. Bloqueiam menores de 18 anos, residentes fora da jurisdição, clientes falidos com a própria instituição anteriormente, indivíduos sancionados pelo OFAC, ou PEPs não autorizados. Benefício: Risco regulatório mitigado a zero de imediato. Não se gasta 1 centavo com Data Science em requisições já condenadas a falhar por imposição legal.
3. Camada 3 — Enriquecimento de Dados (APIs & Feature Store):
   Para os sobreviventes dos filtros, a plataforma invoca dados alternativos via APIs (Open Finance, telemetria mobile, bureaus premium) e calcula agregações históricas complexas em tempo real via Feature Store.
4. Camada 4 — O Coração Preditivo (Machine Learning Scoring):
   O payload enriquecido com centenas de features entra no modelo XGBoost. O modelo cospe três outputs críticos em 20 milissegundos: Probabilidade de Fraude (PD-F), Probabilidade de Default (PD) e a Matriz de Explainability (XAI-SHAP) com as top 5 variáveis influenciadoras.
5. Camada 5 — Tradução Tática ("Policy Layer" via Rules):
   Temos a probabilidade (ex: Default = 3,4%), mas o negócio precisa da decisão. O Motor de Regras reassume o controle para aplicar as políticas comerciais vigentes:
   • Se (Probabilidade de Default > 5%), ENTÃO (Negar e salvar os reason codes do SHAP).
   • Se (Probabilidade de Fraude > 95%), ENTÃO (Enviar para esteira manual de análise de documentos).
   • Se (Probabilidade de Default < 2%) E (Renda Comprovada > 10k), ENTÃO (Prosseguir).
6. Camada 6 — ML Pricing & Limite Dinâmico (ML + Rules):
   Um segundo modelo de ML menor cálcula a otimização de taxa (Risk-Based Pricing). O Motor de Regras aplica as travas de limite de carteira ou caps de juros do regulador sobre o modelo matemático, garantindo que o teto da taxa de juros do produto nunca fure limites legais (como o teto recente imposto pelo BACEN aos cartões rotativos).

Como a Sinky Implementa o Modelo Híbrido

Enquanto bancos legados lutam por anos conectando bases de dados SQL de 1990 a scripts Python soltos em notebooks, a arquitetura moderna demanda que a fusão entre regras e modelos aconteça nativamente, na mesma plataforma visual e com observabilidade centralizada.

A plataforma Sinky resolve este problema de integração tecnológica de forma brilhante através do seu motor unificado. Dentro do ecossistema Sinky, você desenha Grafos de Decisão (Decision Graphs). Esses grafos permitem orquestrar nós heterogêneos na mesma interface, "arrastando e soltando" o risco. A equipe de Produto desenha um nó DMN de Regras de Compliance (sem escrever código), conectando-o em seguida a um nó de Execução de Modelo de Machine Learning, treinado pela equipe de Data Science e exposto via API.

Ambos os mundos — regras determinísticas estritas e scores probabilísticos complexos — herdam a mesma governança corporativa, os mesmos controles de acesso (RBAC), o mesmo pipeline de testes via backtesting massivo retroativo e shadow mode. O resultado é a capacidade inigualável de testar um novo modelo de IA para o seu produto de empréstimos sem jamais abdicar dos filtros estruturais de compliance que mantêm a operação dentro da lei.