Drools é gratuito. Operar Drools em produção não é. Um levantamento honesto do custo total que aparece depois do go-live (folha de engenharia Java, manutenção de upgrades, tooling para o time de negócio, downtime entre filings) e quando faz sentido pagar por uma plataforma gerenciada.
Regras de negócio
Em quase todas as conversas que temos com CTOs avaliando motor de regras, o Drools entra na pauta. Faz sentido. É a referência da categoria há vinte anos, tem comunidade ativa, integração madura com Java e custo de licença zero. Em RFP enterprise, ele aparece na coluna "open source consolidado" como peso na decisão.
O que raramente entra na mesma planilha é o custo de operar Drools em produção depois que a euforia do "é gratuito" passa. E aí mora a diferença entre a decisão que parece certa no Comitê e a que o CFO vai cobrar no fim do segundo ano.
Esse artigo é uma tentativa de colocar essa conta inteira em cima da mesa. Não para vender migração. Em alguns cenários Drools continua sendo a escolha mais inteligente, e vamos falar de quais. O objetivo é que a decisão entre open source e plataforma gerenciada deixe de ser feita comparando licença zero com licença paga, e passe a ser feita comparando TCO real contra TCO real.
A primeira pergunta que CTO experiente faz quando ouve "BRMS pago" é a certa: por que pagar por algo que existe gratuitamente?
A resposta honesta é: você não está pagando pelo motor. O motor está incluído em ambos os lados. Você está pagando, ou deixando de pagar, pelo conjunto operacional que cerca o motor.
Drools entrega o engine de execução de regras. Excelente engine, diga-se. O que ele não entrega de fábrica e você precisa montar:
Cada um desses itens é solucionável. Nenhum deles é trivial. E todos eles aparecem na folha de pagamento, no orçamento de infra, ou no calendário do CTO que vai dedicar trimestres a montar internamente o que uma plataforma gerenciada já oferece pronto.
Em projetos com seguradoras, financeiras e empresas de logística enterprise no Brasil ao longo do último ano, a faixa de custo total para operar Drools em produção fica entre R$ 1,2 milhão e R$ 2,5 milhões nos primeiros cinco anos para um caso de uso típico, algo na ordem de duzentos a oitocentos rules em produção, com mudanças mensais e SLA de quatro noves.
Esse intervalo varia bastante. Tem operação enxuta que fica perto do piso. Tem caso de seguradora de grande porte com Drools rodando pricing crítico que estoura o teto. O que importa é entender o que compõe a conta.
1. Folha de engenharia Java sênior
O componente dominante. Mid-market enterprise no Brasil precisa de 1,5 a 2 FTEs de engenheiro Java sênior dedicados a Drools (isso considera autoria de DRL, manutenção da decision table customizada, integração de novos sistemas, debug de produção e gestão de upgrade).
CLT carregado com encargos, benefícios e provisão sai entre R$ 220 mil e R$ 360 mil por ano por engenheiro. Em 5 anos, com inflação salarial considerada, esse item sozinho fica entre R$ 1,1 milhão e R$ 2 milhões.
E não é qualquer engenheiro. Drools senior é uma especialização específica, você não tira de qualquer pool. A escassez de talento sobe o custo de aquisição e o tempo de ramp-up para 4 a 8 meses por novo engenheiro.
2. Upgrades maiores
Drools 6 → 7 → 8 → 9 não é compatível para frente automaticamente. Cada major version exige tipicamente entre 6 e 14 semanas de trabalho de migração, regressão e validação. Não é tempo opcional. É a única forma de continuar recebendo patches de segurança e ficar elegível para componentes mais novos do ecossistema.
Custo médio por major upgrade no contexto brasileiro: R$ 80 mil a R$ 180 mil em horas de engenharia, sem contar o atraso que isso impõe no roadmap de regras novas.
3. Ferramenta para o time de negócio
Aqui mora o item mais subestimado da conta. Drools oferece editores DRL para engenheiros e decision tables planilhadas para casos simples. Para uma operação enterprise onde o analista de negócio realmente precisa autonomia (editar a regra de comissão sem abrir ticket, simular o impacto antes de subir, ver o histórico de quem mexeu), você vai construir esse layer.
Empresas que vimos construindo internamente investem entre R$ 250 mil e R$ 600 mil em desenvolvimento inicial, mais um custo recorrente de manutenção. Ou aceitam que toda mudança de regra continue passando por TI, o que basicamente anula o motivo de ter BRMS.
4. Trilha de auditoria e replay de decisão
Para operação regulada (seguradora, financeira, processador de dados sensíveis), conseguir reconstruir qualquer decisão tomada nos últimos 5 anos com a regra exata aplicada não é nice-to-have. É requisito.
Drools registra execução. Não registra automaticamente versão da regra ativa, autor da última edição, snapshot do contexto de entrada, e replay determinístico daquela decisão específica. Esse pipeline também é construído. Custo de implementação razoável: R$ 150 mil a R$ 350 mil, mais infra de armazenamento que cresce com o volume.
5. Downtime entre filings e regras
O custo invisível. Cada mudança de regra que precisa de PR, code review, deploy e janela de manutenção é tempo em que a operação roda com a regra antiga.
Em pricing de seguros, isso é caro. Quando o competidor sobe preço numa categoria e seu time precisa esperar 2 semanas para reagir, a perda de margem ou de mix está ali, escondida no fechamento mensal. Em comissionamento, mudança que demora vira atrito com canal. Em aceitação de risco, é taxa de aprovação que não converge com a estratégia atual.
É difícil colocar número exato porque depende muito do caso de uso, mas em projetos onde medimos, o impacto financeiro do "time-to-rule" longo costuma ser maior do que todos os outros custos somados. Só não aparece no orçamento de TI, aparece no resultado da unidade de negócio.
Não é honesto fingir que open source perdeu. Tem três cenários onde apostar em Drools continua fazendo sentido, e queremos ser claros sobre eles.
Cenário 1: você já tem 2-3 engenheiros Java sênior dedicados, e eles estão sub-utilizados.
Se a folha já existe e a operação já tem expertise interna em Drools, o custo marginal de continuar é baixo. A conversa muda: a pergunta deixa de ser "open source vs. pago" e vira "o que faria essa equipe ganhar tempo para se dedicar a outras prioridades".
Cenário 2: poucos rules, mudanças raras, sem analista de negócio na cadeia.
Operação com menos de 50 regras, mudança bimestral ou trimestral, sem expectativa de autonomia para área não-técnica. Drools entrega isso bem e o overhead operacional fica diluído.
Cenário 3: filosofia técnica de "tudo open source".
Empresa cuja stack inteira é open source, cuja cultura técnica é forte, e que prefere arcar com complexidade operacional em troca de zero dependência de fornecedor. Decisão legítima, desde que feita com olhos abertos sobre o trade-off de TCO.
Fora desses três cenários, a conta começa a virar.
A proposta de uma plataforma BRMS gerenciada (Abaccus, IBM ODM, FICO Blaze, InRule) é colocar todo aquele conjunto operacional dentro do produto. O motor continua sendo motor. O que vem junto é:
O custo de licença varia. Plataformas como IBM ODM cobram em PVU e ficam entre R$ 400 mil e R$ 1,5 milhão por ano em operação enterprise. FICO Blaze fica em faixa similar, com a complicação adicional de parceiros terceirizados para implantação no Brasil. Plataformas brasileiras de nova geração como Abaccus operam em modelo PaaS com mensalidade fixa por motor de regras ativo, geralmente entre R$ 180 mil e R$ 500 mil por ano para casos enterprise, independente do volume de decisões processadas.
Esse detalhe do modelo comercial costuma passar despercebido na fase de avaliação, mas é o que mais impacta o TCO em três e cinco anos. A maior parte das plataformas internacionais (FICO, IBM ODM, DecisionRules, GoRules) cobra por transação processada. Em operações com volume crescente, o custo de licença escala junto com o sucesso da automação. Em modelo de mensalidade fixa por motor, o volume cresce e a conta não muda. Para operações que esperam aumentar volume de decisões nos próximos anos, essa diferença vira ordem de grandeza na conta de TCO. Vale fazer a simulação antes de assinar.
Implantação típica de um caso de uso novo numa plataforma gerenciada brasileira: 4 a 12 semanas, com a primeira regra rodando em produção em torno da semana 4. Para uma equipe partindo do zero em Drools, o mesmo escopo costuma demandar 4 a 9 meses até atingir maturidade equivalente, considerando o tempo de construir o tooling em torno.
Tirando licença da equação para começar, e olhando só para o custo operacional em 5 anos de um caso enterprise típico no Brasil:
A faixa de Drools costuma ficar acima da faixa de plataforma gerenciada quando você inclui os componentes que ninguém quer incluir na planilha inicial.
A faixa também esconde uma diferença de risco. Custo de Drools tende a ser mais alto na média e mais imprevisível. Depende muito de quem sai da equipe, qual major version aparece, qual auditoria pede o quê. Plataforma gerenciada tem custo mais alto no piso, mas previsível e contratualmente fixado.
Para CFO que prefere certeza orçamentária ao "talvez mais barato", essa previsibilidade muitas vezes vale mais do que o delta de TCO em si.
Vale mencionar um vetor novo que ainda não estava na conta há dois anos.
Em 2026, a maior parte das empresas enterprise está integrando agentes de IA (Claude, GPT, Gemini) em fluxos operacionais. E o consenso técnico que emergiu nos últimos meses é claro: o agente não deve ser quem aplica a regra de negócio determinística. O agente raciocina, interpreta, orquestra. A regra fica num motor determinístico que ele consulta, geralmente via MCP Server ou tool call.
Plataformas BRMS gerenciadas modernas já expõem MCP nativamente. Drools não, e a comunidade ainda está nos primeiros passos para implementar esse padrão. Para empresas planejando arquitetura de IA agêntica para os próximos 24 meses, ter o motor de regras já preparado para esse padrão deixa de ser feature e vira pré-requisito de roadmap.
Depois de fazer essa conta com vários CTOs no último ano, a pergunta que faz a diferença na decisão não é "Drools ou plataforma gerenciada".
É "qual é o custo real de não ter autonomia de negócio para mudar regra rapidamente, e em quanto tempo eu vou ter isso pronto se construir tudo dentro de casa".
Quando essa pergunta entra na pauta com honestidade, a discussão deixa de ser sobre licença e passa a ser sobre time-to-value, previsibilidade orçamentária e maturidade do tooling.
Em alguns casos, a resposta continua sendo Drools, pelos cenários que listamos acima. Na maioria dos casos que acompanhamos, não.
Se você está nesse momento de decisão, vale uma conversa estruturada. Em 45 minutos é possível estimar o TCO real do seu caso e ter um número concreto pra levar pro Comitê, não importa qual seja a resposta. E se quiser ver como uma plataforma BRMS construída pra operação brasileira se compara ao Drools no seu cenário, veja a página de alternativa ao Drools com os critérios objetivos lado a lado.
