# Machine learning ou regras de negócio: quando usar cada um

> Machine learning ou regras de negócio? O critério é saber se dá para escrever a regra e se existe histórico confiável. Veja quando usar cada um e como combinar.

Fonte: https://pervian.tech/blog/machine-learning-ou-regras-de-negocio · Pervian Tech · publicado em 2026-10-01

A conversa costuma começar assim: "queremos colocar inteligência artificial na aprovação de crédito" ou "dá para o sistema aprender sozinho qual desconto conceder?". A pergunta é legítima, e a resposta às vezes é sim. Mas muitas vezes o que a empresa precisa é de uma regra bem escrita, guardada num lugar só, que qualquer gestor consiga ler e mudar.

Machine learning e regras de negócio resolvem o mesmo tipo de problema, que é tomar uma decisão repetitiva com base em dados, mas de jeitos opostos. Na regra, alguém diz ao sistema como decidir. No machine learning, o sistema descobre um padrão a partir de decisões e resultados do passado. Cada caminho tem custo, risco e manutenção diferentes, e escolher errado sai caro dos dois lados: modelo onde bastava uma tabela de alçadas, ou uma regra com tantas exceções que ninguém mais entende.

Abaixo, o critério que usamos para separar os dois casos e por que os melhores sistemas combinam as duas abordagens.

**Resposta curta:** se um especialista da empresa consegue explicar a decisão em condições claras e auditáveis, como limite de crédito por faixa, desconto por alçada ou roteamento por região, escreva a regra. Ela é mais barata de manter e fácil de justificar. Se a decisão depende de muitos sinais combinados que ninguém consegue enunciar e existe histórico rotulado em quantidade e qualidade, como previsão de demanda, risco de churn ou detecção de fraude, machine learning entrega o que regra nenhuma alcança. Sem histórico, não há modelo, por melhor que seja a ideia.

## A diferença entre programar a regra e aprender com os dados

Uma regra de negócio é uma instrução explícita: "pedido acima de determinado valor precisa de aprovação do gerente", "cliente com título vencido há mais de 30 dias fica bloqueado para nova venda a prazo", "chamado de cliente da região Sul vai para a equipe de Porto Alegre". Quem escreve a regra sabe exatamente por que ela existe, e o sistema só executa.

Machine learning inverte a ordem. Em vez de escrever a condição, você entrega ao algoritmo muitos exemplos do passado com o resultado conhecido: clientes que cancelaram e clientes que ficaram, transações que eram fraude e transações legítimas, semanas de venda com tudo o que aconteceu ao redor. O algoritmo encontra combinações de sinais que se associam ao resultado e devolve uma probabilidade ou uma estimativa, não uma certeza.

Isso tem três consequências práticas:

- **Regra é determinística.** A mesma entrada gera sempre a mesma saída, e o porquê está escrito.
- **Modelo é probabilístico.** Ele vai errar uma parte dos casos, e o trabalho é decidir quanto erro é aceitável e o que acontece quando ele erra.
- **Regra nasce do conhecimento; modelo nasce do histórico.** Se a empresa não tem o histórico, o modelo não tem de onde aprender.

Teste rápido: peça ao especialista que explique a decisão em voz alta. Se ele responde com poucas condições e lista as exceções, é regra. Se responde "depende, eu olho o conjunto", provavelmente há um padrão que um modelo pode capturar, desde que os dados existam.

## Explicabilidade e auditoria: quando é preciso justificar a decisão

Algumas decisões precisam ser explicadas para alguém de fora: o cliente que teve o crédito negado, o auditor que revisa a concessão de descontos, o fiscal que pergunta por que uma operação foi classificada de determinado jeito. Nesses casos, "o modelo indicou" não é resposta.

Regras escritas são naturalmente auditáveis. Dá para registrar qual regra disparou, em qual versão, com quais valores de entrada. É o que se faz num [workflow de aprovação por alçada](https://pervian.tech/blog/workflow-de-aprovacao-por-alcada): a faixa, o aprovador e a trilha ficam documentados, e qualquer pessoa consegue reconstruir por que um pedido subiu para a diretoria.

Modelos também podem ser explicados, com mais esforço. Há técnicas que indicam quais sinais mais pesaram numa previsão, e modelos simples, como árvores de decisão rasas e regressões, são mais fáceis de interpretar. Ainda assim, a explicação é uma aproximação do comportamento do modelo, não a lógica exata.

A LGPD (Lei 13.709/2018) prevê que o titular dos dados pode pedir revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses, e pede clareza sobre os critérios usados. Isso não proíbe modelos, mas obriga a pensar desde o início em como a decisão será explicada e como um pedido de revisão será atendido. A lei não exige que essa revisão seja feita por uma pessoa, mas, em decisões que afetam o cliente, ter alguém responsável por reavaliar o caso costuma ser o caminho mais seguro.

Quanto mais a decisão afeta um cliente ou precisa resistir a auditoria, mais peso a explicabilidade deve ter.

## Dados históricos: quanto e com que qualidade

É a pergunta que mais derruba projetos de machine learning, e deve vir antes de qualquer conversa sobre algoritmo.

Para aprender, o modelo precisa de **exemplos rotulados**: o histórico precisa registrar não só o que aconteceu antes da decisão, mas também o resultado. Para prever churn, é preciso saber quais clientes saíram e quando. Para detectar fraude, é preciso ter as transações confirmadas como fraude, não só as suspeitas. Para prever demanda, é preciso ter vendas por item e período com os eventos que as distorceram, como ruptura de estoque e promoções.

Não existe número mágico de registros: depende de quantos sinais entram e de quão raro é o evento. Mas há sinais de alerta confiáveis:

- **O evento é raro e há poucos casos registrados.** Se a empresa teve um punhado de fraudes confirmadas em anos, não há base para um modelo aprender o padrão.
- **O rótulo não existe ou é inconsistente.** Se cada vendedor marca o motivo de perda do cliente de um jeito, o modelo aprende o ruído.
- **O processo mudou no meio do histórico.** Troca de sistema, mudança de política comercial ou de mix de produto podem tornar o passado pouco representativo.
- **Os dados de sistemas diferentes não batem.** Se vendas e financeiro chegam a números diferentes, o problema vem antes do modelo. Vale ler [por que seu relatório não bate](https://pervian.tech/blog/qualidade-de-dados-relatorios-nao-batem) antes de pensar em algoritmo.

Muitas vezes o primeiro entregável de um projeto de IA é organizar e medir. O texto sobre [como medir churn de clientes](https://pervian.tech/blog/como-medir-churn-de-clientes) mostra isso bem: antes de prever quem vai sair, é preciso definir o que é sair, registrar quando acontece e identificar os sinais disponíveis. Essa organização já permite regras simples de alerta enquanto o histórico para um modelo amadurece.

## Manutenção: regra que muda por decisão x modelo que envelhece

As duas abordagens exigem manutenção, mas de naturezas diferentes.

### Regra muda quando o negócio decide

A regra fica correta até alguém mudar a política, e a mudança é deliberada, tem data e tem dono. O risco da regra é outro: o acúmulo. Com os anos, exceções sobre exceções transformam uma lógica simples num emaranhado que ninguém tem coragem de mexer. Isso se evita com regras centralizadas num só lugar do sistema, parametrizadas quando fizer sentido (valores e faixas em tabela, não no código) e documentadas, com testes automatizados que garantem que uma mudança não quebra outra.

### Modelo envelhece sem ninguém mexer

O modelo aprende com o mundo como ele era. Quando o comportamento dos clientes muda, quando entra um concorrente novo ou quando a empresa muda o mix, o modelo continua aplicando o padrão antigo, e a qualidade cai em silêncio. Por isso, colocar um modelo em produção inclui:

- **Monitorar o acerto ao longo do tempo**, comparando o que foi previsto com o que aconteceu.
- **Retreinar periodicamente** com dados recentes, com um processo repetível, não uma planilha na máquina de alguém.
- **Versionar o modelo**, para saber qual versão tomou cada decisão.
- **Ter um dono**, alguém que acompanha os indicadores e decide quando o modelo precisa de ajuste.

Um modelo sem monitoramento é uma regra que ninguém escreveu e que ninguém sabe quando parou de funcionar.

## O modelo combinado: regras de proteção ao redor do modelo

Em sistemas bem desenhados, a pergunta não é "regra ou modelo", e sim onde termina um e começa o outro. O desenho que recomendamos coloca o modelo no meio e as regras nas bordas:

1. **Regras de elegibilidade antes do modelo.** Casos que a política já resolve não passam pelo modelo. Cliente já bloqueado por inadimplência não precisa de score; pedido abaixo do valor mínimo não precisa de análise de fraude.
2. **O modelo pontua o que sobra.** Ele devolve uma probabilidade ou uma estimativa, não a decisão final.
3. **Regras de decisão sobre a pontuação.** Faixas definidas pelo negócio transformam a pontuação em ação: aprovar automaticamente, mandar para revisão humana ou recusar.
4. **Limites de proteção depois do modelo.** Nenhuma sugestão de compra acima de um teto sem aprovação, nenhum desconto fora da alçada, nenhuma recusa automática para determinado perfil sem revisão.
5. **Registro de tudo.** Entrada, pontuação, regra aplicada e versão do modelo, para auditoria e para medir o acerto.

O modelo contribui com o que enxerga nos dados, e o negócio mantém o controle sobre o que é aceitável. É o mesmo princípio que usamos para [reduzir alucinação em sistemas com IA generativa](https://pervian.tech/blog/alucinacao-de-ia-como-reduzir): a saída do modelo passa por validação antes de virar ação.

A [previsão de demanda com machine learning](https://pervian.tech/blog/previsao-de-demanda-com-machine-learning) é um bom exemplo: o modelo estima a venda, mas a sugestão de compra respeita estoque mínimo, lote do fornecedor e teto aprovado pelo comprador, que são regras.

## Tabela comparativa: regras de negócio x machine learning

| Critério | Regras de negócio | Machine learning |
|---|---|---|
| Origem da lógica | Conhecimento de especialistas, escrito explicitamente | Padrões aprendidos do histórico |
| Pré-requisito principal | Alguém consegue descrever a decisão | Histórico rotulado em quantidade e qualidade |
| Tipo de saída | Determinística: sim, não, faixa, destino | Probabilidade ou estimativa, com margem de erro |
| Explicabilidade | Direta: qual regra disparou e por quê | Aproximada, exige técnicas e cuidado na comunicação |
| Auditoria | Simples, com versão e trilha | Possível, exige registrar versão do modelo e entradas |
| Quantidade de sinais | Funciona bem com poucos | Lida bem com muitos sinais combinados |
| Tempo até a primeira entrega | Curto, quando a regra é conhecida | Mais longo, inclui preparo de dados e validação |
| Manutenção | Mudança deliberada quando a política muda | Monitoramento contínuo e retreino |
| Risco típico | Acúmulo de exceções e regras espalhadas | Degradação silenciosa e erro sem explicação |
| Exemplos clássicos | Alçada de aprovação, limite de crédito por faixa, roteamento por região, bloqueio por inadimplência | Previsão de demanda, risco de churn, detecção de fraude, priorização de leads |

## Quando escolher cada um

### Sinais de que regras de negócio resolvem

- O especialista explica a decisão em poucas condições e as exceções cabem numa página.
- A decisão precisa ser justificada a cliente, auditor ou órgão regulador com precisão.
- A política muda por decisão da diretoria, não pelo comportamento do mercado.
- Não existe histórico com o resultado registrado, ou ele é curto e inconsistente.
- Errar um caso tem custo alto e o negócio prefere previsibilidade a otimização.

### Sinais de que machine learning vale o investimento

- A decisão depende de muitos sinais combinados e nenhum especialista consegue enunciar a lógica completa.
- Existe histórico com o resultado registrado, com volume suficiente e definição consistente.
- O volume de decisões é alto, então pequenos ganhos de acerto somam muito.
- O padrão muda com o tempo e uma regra fixa ficaria desatualizada rápido.
- O negócio aceita uma margem de erro e há um processo para tratar os casos duvidosos.

### Quando a solução pronta é a melhor escolha

Nem tudo precisa ser construído. Se a regra é de aprovação, o ERP ou a ferramenta de fluxo que a empresa já usa provavelmente permite configurar alçadas e faixas, e isso costuma bastar. Para fraude em pagamento online, gateways e serviços antifraude especializados oferecem análise de risco como serviço, em geral apoiada num volume de transações muito maior do que o de uma empresa média. Para previsão de demanda em operações padrão, alguns sistemas de gestão e ferramentas de planejamento já trazem recursos de previsão. Plataformas de nuvem também oferecem serviços gerenciados de machine learning que reduzem o trabalho de infraestrutura. Os recursos variam e mudam com frequência, então confirme com o fornecedor o que está disponível hoje e se atende ao seu caso.

O sob medida faz sentido quando a decisão depende de dados que só a sua empresa tem, quando a regra é parte do diferencial do negócio ou quando é preciso integrar a decisão a vários sistemas internos com controle e trilha próprios.

Se este é o primeiro projeto de IA da empresa, os critérios de escolha do caso estão em [primeiro projeto de IA na empresa](https://pervian.tech/blog/primeiro-projeto-de-ia-na-empresa). Outros textos da categoria estão em [inteligência artificial](https://pervian.tech/blog/categoria/inteligencia-artificial).

## Perguntas frequentes

### Preciso de muitos dados para usar machine learning?

Depende de quantos sinais entram e de quão raro é o evento a prever, e não existe número mágico de registros. O essencial é ter histórico rotulado, com o resultado registrado de forma consistente. Se a empresa teve poucos casos do evento ou o processo mudou no meio do histórico, o modelo ainda não tem de onde aprender.

### Machine learning é a mesma coisa que inteligência artificial?

Não exatamente. Machine learning é uma parte da inteligência artificial em que o sistema aprende padrões a partir de exemplos do passado, em vez de seguir regras escritas por alguém. Nem todo sistema chamado de inteligente usa machine learning, e muitas automações apresentadas como IA funcionam, na prática, com regras de negócio bem escritas.

### A LGPD permite decisões automatizadas por machine learning?

Sim, com obrigações. A LGPD garante ao titular o direito de pedir revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses, e pede clareza sobre os critérios usados. Por isso, um modelo de machine learning que decide sobre clientes precisa registrar entradas, pontuação e versão para explicar cada decisão.

### Um modelo de machine learning precisa de manutenção depois de pronto?

Sim. Um modelo de machine learning perde qualidade em silêncio quando o comportamento dos clientes, o mercado ou o mix da empresa mudam. Colocar o modelo em produção inclui monitorar o acerto comparando previsão e resultado, retreinar periodicamente com dados recentes, versionar cada modelo e ter um responsável acompanhando os indicadores.

### Quanto tempo leva um projeto de machine learning?

Um projeto de machine learning costuma levar mais tempo que uma regra de negócio, porque inclui preparo dos dados, treino e validação antes da primeira entrega. Muitas vezes o primeiro passo é organizar e medir o histórico, e o projeto avança por fases de diagnóstico, protótipo, piloto e operação, com prazos definidos depois de conhecer os dados.

## Como a Pervian Tech ajuda a decidir e escolher a abordagem certa

Começamos com um diagnóstico inicial gratuito: entendemos a decisão que se quer automatizar, conversamos com quem a toma hoje e verificamos quais dados existem e com que qualidade. Desse diagnóstico sai uma recomendação clara, que pode ser regra, modelo ou a combinação dos dois, e, muitas vezes, o recurso que o sistema atual ou um produto de mercado já oferece.

Quando o produto pronto atende, recomendamos o produto pronto. Quando a decisão depende de dados e regras que só a sua empresa tem, desenhamos a solução sob medida com o trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software): regras centralizadas e testadas, modelo com monitoramento e retreino, limites de proteção e trilha de auditoria. Os projetos de [inteligência artificial para empresas](https://pervian.tech/solucoes/inteligencia-artificial-para-empresas) seguem fases de diagnóstico, protótipo, piloto e operação, e o investimento é definido sob consulta, depois de entender o caso e os dados disponíveis.

Se a sua empresa está em dúvida entre escrever a regra ou treinar um modelo, [fale com a gente](https://pervian.tech/#contato).