Quando regras de negócio críticas vivem dentro de notebooks e views do data lake, três problemas aparecem juntos: cada mudança leva semanas, ninguém quer aprovar a subida para produção, e apenas um ou dois engenheiros entendem o que está rodando. A literatura técnica do próprio ecossistema Databricks vem reconhecendo esse padrão. Veja o que está em jogo e a separação que faz sentido em 2026.
Tecnologia
Nos últimos meses, duas operações enterprise brasileiras nos procuraram com a mesma descrição. Setores diferentes, equipes diferentes. O cenário era idêntico: o Databricks tinha entrado na empresa para resolver analytics, ciência de dados e treinamento de modelos. Cumpriu bem esse papel. Mas em algum ponto da jornada, regras de negócio críticas, lógica de elegibilidade, cálculos de precificação, decisões operacionais que rodam centenas de milhares de vezes por dia, acabaram dentro de notebooks ou em views do data lake.
E em ambas as conversas, o CTO descreveu três sintomas que pareciam um espelho. Cada mudança em uma regra crítica levava no mínimo duas semanas para ficar pronta. Subir para produção gerava ansiedade real no time, porque não havia como garantir que a mudança ia funcionar como esperado. E apenas um ou dois engenheiros conseguiam mexer com confiança no que estava lá.
Esse artigo não é sobre sair do Databricks. Databricks continua sendo uma das melhores plataformas de dados e ML do mundo, com mérito reconhecido. O artigo é sobre uma separação arquitetural que o próprio ecossistema técnico Databricks tem discutido cada vez mais abertamente em 2025 e 2026: a separação entre plataforma de dados e plataforma de decisão.
São coisas diferentes. Vamos olhar por quê.
Antes de qualquer crítica, vale dimensionar o que está em jogo. Databricks é a plataforma líder de lakehouse no mundo, fundada pelos criadores do Apache Spark, com mais de 25 mil clientes globais incluindo Shell, Comcast, AT&T e uma base relevante de empresas brasileiras nos setores financeiro, varejo, indústria e saúde. A plataforma cresceu para faturar mais de 3 bilhões de dólares em receita anual recorrente.
A força do Databricks está em três frentes específicas: processamento distribuído de grandes volumes de dados (Spark), unificação de data engineering, ciência de dados e SQL analytics na mesma camada (lakehouse), e ciclo completo de ML com MLflow, Unity Catalog, feature store e governança de dados. Para essas funções, é uma das ferramentas mais sofisticadas que existem.
O ponto deste artigo começa quando a operação, naturalmente, passa a usar Databricks para algo que não é gestão de dado ou treinamento de modelo. Passa a usar para decidir. E aí o ecossistema técnico Databricks tem reconhecido limites específicos que merecem atenção.
Há uma distinção sutil mas crítica que toda operação enterprise deveria entender, e que a Confluent articulou bem em material técnico publicado em março de 2026:
"Real-time analytics e real-time decisioning têm propósitos fundamentalmente diferentes: informação versus ação. Real-time analytics foca em visualização e monitoramento, mantendo o humano informado. Real-time decisioning foca em outcome e execução, mantendo o negócio rodando."
Databricks é uma plataforma de analytics. Excepcional para o primeiro caso, manter humanos informados, gerar insights, treinar modelos. Para o segundo caso, executar decisões operacionais em alta frequência com governança, plataformas de analytics raramente são a melhor escolha. Não é falha do produto. É confusão de categoria.
Quando uma operação coloca regras de aceitação, cálculo de comissão, política de precificação dinâmica dentro de notebooks Databricks ou de views SQL do data lake, está usando uma plataforma desenhada para análise e ML como motor de execução de decisão. Funciona. Por um tempo. Até o volume crescer, a regra mudar, ou alguém precisar auditar.
Os mesmos três problemas que os CTOs brasileiros descreveram nas conversas que mencionamos no início aparecem repetidamente na literatura técnica internacional do ecossistema Databricks. Edwin Lisowski, co-fundador da consultoria Addepto especializada em Databricks, escreveu em outubro de 2025 um artigo chamado "Why Most Databricks Deployments Fail Before They Scale" que vale a referência direta. As três armadilhas que ele descreveu, baseadas em projetos reais em finanças, varejo e manufatura, são:
1. Experimentos vazando para produção. Cientistas de dados querem mover rápido, ajustar modelos, explorar dados, testar hipóteses. Mas quando esses "testes rápidos" começam a viver em produção, o caos segue. Sem fronteiras claras entre sandbox e sistema, notebooks frágeis se tornam gargalos operacionais. Uma dependência não documentada pode derrubar um fluxo inteiro.
2. Cientistas de dados e DevOps não falam a mesma língua. Cientistas de dados pensam em modelos, não em pipelines. Times DevOps pensam em CI/CD, não em feature stores. Quando os dois mundos não se alinham, colocar em produção vira um processo manual e propenso a erros. O resultado: semanas de atraso entre "regra pronta" e "regra rodando".
3. Provas de conceito que não sobrevivem ao volume real. O notebook que rodou lindamente com 5 GB engasga com 5 TB. Sem planejamento para computação distribuída específica para decisão, particionamento de dados pensado para acesso individual e gestão de workload em alta concorrência, esses primeiros experimentos não suportam o tráfego de produção.
Lisowski conclui com uma observação que captura o problema: "Databricks não falha porque é um software ruim. Falha porque equipes tratam como mais uma ferramenta, não como um modelo operacional." Acrescentamos: especialmente quando o modelo operacional pedia outra ferramenta.
Esse é o sintoma mais doloroso e o mais reconhecível. Em conversas com diretores de tecnologia em operações brasileiras, esse número é praticamente um padrão: duas semanas é o piso, não a média. Vamos quebrar por que.
Mudar uma regra em um notebook Databricks crítico envolve uma sequência que tem várias estações:
Cada uma dessas estações é onde o tempo escapa. E como o trabalho é manual e a documentação raramente está atualizada, o tempo total nunca é menor que duas semanas em operações enterprise.
A literatura técnica reconhece esse problema. A consultoria Qubika, em material publicado em abril de 2026 sobre Databricks Asset Bundles, descreveu o padrão observado: "se você trabalhou com Databricks tempo suficiente, provavelmente já viu o ciclo: a maior parte dos projetos começa em notebooks; passar para produção sem perder velocidade ou controle é o maior desafio."
O segundo sintoma, "ninguém quer aprovar a subida porque não dá para garantir que vai funcionar", também tem explicação técnica clara. E em geral, o medo é racional. Cinco fatores convergem:
Notebooks misturam o que deveria estar separado. A mesma célula que extrai dados, transforma, aplica regra de negócio e grava resultado é, simultaneamente, código de pipeline, código de lógica de negócio e código de persistência. Mudar uma coisa pode quebrar outra de formas não óbvias.
Testes determinísticos raramente existem. Notebooks em produção tipicamente são validados por "rodar e olhar o output". Não há suite de testes que valide "se eu mudar essa regra, ela continua funcionando como esperado em todos os casos". É validação artesanal.
Rollback de regra é rollback de notebook inteiro. Se a mudança da regra de aceitação quebra alguma coisa, o caminho de volta é restaurar a versão anterior do notebook. Não tem volta granular da regra específica. Tem volta de todo o estado do código.
Audit trail é limitado. Quem mudou a regra, quando, por quê, em qual versão exata. Notebooks têm git, mas a granularidade da regra de negócio dentro do código é difícil de extrair em formato consultável para auditoria.
Custo de uma decisão errada é alto. Em operações que tomam centenas de milhares de decisões por dia, uma regra mal calibrada pode gerar milhares de aprovações ou recusas erradas antes de alguém perceber. O risco financeiro de subir mal compensa o custo de testar exaustivamente.
Essa combinação produz a cultura de cautela que os CTOs descreveram: prefere-se demorar duas semanas a errar. E a alternativa, demorar uma hora porque a regra mora em um motor com simulação, versionamento, audit trail e rollback granular, simplesmente não existe nessa arquitetura.
O terceiro sintoma é o mais perigoso para o negócio em médio prazo. Quando regras de negócio críticas vivem dentro de notebooks Databricks, três coisas se acumulam: complexidade da plataforma, especificidade do código e ausência de interface para o time de negócio.
Databricks é uma plataforma técnica sofisticada. Operar bem exige conhecimento de Spark, SQL avançado, Python, Delta Lake, Unity Catalog, MLflow e CI/CD específico para o ecossistema. No Brasil em 2026, essa combinação de skills é escassa e cara. As consultorias especializadas confirmam isso, e a regra "data scientists e DevOps não falam a mesma língua" amplifica o problema.
Quando a regra de negócio vive nesse ambiente, mexer nela exige todas essas competências combinadas com entendimento do domínio (aceitação de risco em seguros, política de comissão em varejo, cálculo de preço em logística). A interseção de profissionais que dominam tudo isso é minúscula. Tipicamente: um engenheiro sênior de dados que está há tempo suficiente na empresa para conhecer as regras, e um ou dois colegas que ele treinou.
Quando essa pessoa entra em férias, o ritmo de mudanças cai a zero. Quando essa pessoa pede demissão, o conhecimento sai junto. Esse é risco operacional grave, e nenhum CTO sério dorme tranquilo com essa concentração.
Há um detalhe específico do modelo de cobrança do Databricks que merece atenção do CFO. O preço é calculado em DBUs (Databricks Units), unidade de consumo de computação. Conforme documentação pública da própria Databricks e múltiplas consultorias especializadas, em 2026 as taxas começam em torno de $0,15 por DBU para Jobs Compute (workloads automatizadas) e sobem para $0,65 ou mais por DBU para All-Purpose Compute (uso interativo, notebooks rodando em produção). Ou seja, manter notebooks ativos custa 3 a 4 vezes mais por DBU do que rodar jobs agendados.
Acima do custo de DBU, há o custo de infraestrutura cloud (AWS, Azure ou GCP), tipicamente similar em valor ao próprio custo de DBU. Em operações enterprise processando volumes relevantes, a conta mensal escala para faixa de seis dígitos em dólares com facilidade. Múltiplas referências documentam empresas gastando $500 mil ou mais por mês sem perceber, porque clusters ficam ativos, workloads são oversized, e times tratam DBUs "like infinite candy", como descreveu uma consultoria especializada.
Especificamente para o caso de regras de negócio, o problema fica concentrado: como a regra crítica precisa estar disponível em tempo real para responder a transações, o time mantém clusters interativos ativos, que consomem o tipo mais caro de DBU. E cada chamada à regra puxa recursos computacionais que faturam por segundo de uso.
Plataformas de motor de regras gerenciadas como a Abaccus operam em modelo diferente. A cobrança é por motor de regras ativo, com mensalidade fixa. O volume de decisões processadas não influencia o preço. Para operações que precisam responder a 10 milhões de decisões por mês hoje e 50 milhões no próximo ano, a conta não muda. Em três anos de operação enterprise, essa diferença é ordem de grandeza.
A separação que recomendamos, e que a literatura técnica de arquitetura de dados tem reconhecido cada vez mais, é simples no conceito.
Databricks continua sendo a plataforma de dados. Ingestão de dados brutos, ETL para Delta Lake em camadas bronze/prata/ouro, treinamento de modelos ML, geração de features, analytics e BI. Tudo isso fica onde está e funciona muito bem.
Um motor de regras gerenciado fica fora. Regras de aceitação, política de precificação, cálculo de comissão, lógica de elegibilidade, decisões operacionais determinísticas. Tudo isso vive numa plataforma dedicada, com interface visual para o time de negócio, versionamento granular, simulação de impacto, audit trail completo.
A integração é por API e feature store. Quando o motor de regras precisa de um score, uma feature ou um dado consolidado, ele consulta o Databricks via API. Quando o Databricks (ou qualquer outro sistema) precisa de uma decisão, consulta o motor de regras e recebe a decisão pronta com o motivo.
O resultado é que cada plataforma faz o que faz bem. O time de dados volta a gerir o ciclo de vida do dado e modelos ML sem o peso da regra de negócio operacional. O time de negócio recupera autonomia para ajustar regras sem entrar na fila de desenvolvimento. E o ciclo de mudança de uma regra crítica cai de duas semanas para o que sempre deveria ter sido: alguns minutos.
Vamos ser honestos sobre os cenários em que separar não faz sentido, porque eles existem.
Quando a regra é, de fato, um modelo ML. Se a "regra" é um score gerado por um modelo treinado, com dezenas de features de entrada e probabilidade de saída, o lugar dela é Databricks mesmo. Modelo ML é trabalho de plataforma de dados. Onde a decisão fica é depois: o score do modelo entra como input em uma regra de negócio determinística ("se score ML maior que X, aprova automático; se entre X e Y, aprovação manual; se menor que Y, recusa"), e essa regra de negócio sim deveria estar fora.
Quando a "regra" é cálculo intensivo em volume. Cálculo atuarial sobre milhões de apólices, agregações financeiras sobre histórico longo, processamento de feature engineering pesado. Esses são trabalhos de Databricks. O resultado do cálculo pode virar input de uma regra de negócio, mas o cálculo em si fica onde tem o poder computacional.
Quando o volume de mudanças na regra é muito baixo. Se a regra muda uma ou duas vezes por ano e a equipe técnica dá conta da cadência sem fricção, separar é overhead. Mantenha onde está.
Fora desses três cenários, a separação entre Databricks e motor de regras costuma valer cada centavo, não pela tecnologia, mas pela autonomia que ela devolve ao negócio.
Depois de ter essa conversa com diretores e CTOs em duas operações brasileiras, a pergunta que separa as decisões claras das ambíguas é uma só:
Quanto tempo leva, hoje, para sua operação mudar uma regra crítica que vive no Databricks, e quem precisa estar envolvido?
Se a resposta envolve coordenação entre engenheiro de dados, DevOps, validação manual, janela de deploy e duas semanas no melhor cenário, você já tem o diagnóstico. A regra não está onde deveria estar.
Se sua operação está nesse ponto, vale uma conversa estruturada de 45 minutos com nosso time. Em uma sessão é possível mapear quais regras fazem sentido sair do Databricks primeiro, qual a arquitetura de integração mais simples para a sua realidade (Databricks continua gerando features e scores, o motor consome via API), e qual o impacto financeiro real em três anos. Sem compromisso, com um número concreto para levar para o Comitê.
.svg)
