Você abriu o notebook para mudar uma regra. Trocar um limite, ajustar uma faixa, incluir uma exceção nova que o negócio pediu. E descobriu que isso vai levar duas semanas, vai precisar de revisão de outra pessoa, e ainda assim ninguém garante que não vai quebrar alguma coisa em produção.

Se essa cena é familiar, o problema não é a mudança. É onde a regra está.

No Databricks, uma regra de decisão costuma estar embutida em um de quatro lugares: numa célula de notebook que faz a transformação, no SQL de uma view Delta, num job agendado que roda o pipeline, ou numa UDF chamada lá no meio do fluxo. Em todos eles, a regra está colada à computação do dado. Mudar a regra significa mexer no código que processa o dado.

Três sintomas indicam que a regra chegou ao lugar errado:

O primeiro: cada mudança leva semanas. O que o negócio enxerga como "trocar um número" exige, na prática, abrir o notebook, entender o encadeamento, alterar, testar contra o pipeline e publicar. Não é uma edição, é um ciclo de engenharia.

O segundo: existe medo de subir para produção. Porque a regra está acoplada à transformação, não dá para garantir que mudar o critério não vai afetar um cálculo a jusante. A operação publica com receio, ou não publica.

O terceiro: só uma ou duas pessoas conseguem mexer. O conhecimento de qual célula faz o quê está concentrado em quem escreveu. Quando essa pessoa sai de férias, a regra congela.

Vale nomear a distinção que está por trás disso, porque ela é a raiz do problema. Existe diferença entre analytics em tempo real e decisão em tempo real. O Databricks é construído para computar sobre dados em escala: agregar, transformar, treinar modelo, gerar score. Isso ele faz muito bem. A decisão sobre o que fazer com o resultado (aprovar, recusar, escalar, aplicar a faixa) é outra carga de trabalho, com outro ciclo de vida. Misturar as duas no mesmo notebook é o que produz os três sintomas acima.

Nada disso é defeito do Databricks. Ele é uma plataforma de dados e ML excelente, e o score que ele gera é genuinamente valioso. O ponto não é tirar trabalho de lá. É tirar de lá apenas a regra que decide o que fazer com aquele resultado, que nunca deveria ter morado junto da computação que a alimenta.

A boa notícia: dá para fazer essa separação sem parar a operação. O caminho que vemos funcionar é incremental, no estilo coexistência paralela (Strangler Fig), e segue mais ou menos esta ordem:

1. Inventarie as regras embutidas. Liste, notebook por notebook e view por view, onde existe decisão de negócio escondida na transformação. Comece distinguindo o que é cálculo (fica) do que é política (sai).

2. Externalize primeiro as regras mais voláteis. As que mudam toda campanha, todo trimestre, toda nova política. São elas que geram mais fila e mais risco. Mova-as para uma camada de decisão própria, fora do lake.

3. Rode em paralelo, em modo sombra. Por um período, a regra antiga (no notebook) e a nova (na camada de decisão) processam as mesmas entradas, e você compara as saídas. Divergência vira ajuste, não incidente.

4. Faça o corte quando as saídas baterem. A operação passa a consumir a decisão da camada externa. O Databricks continua gerando o dado e o score; a camada de decisão consome esse score via API e aplica a regra com versão, autor, critério e timestamp registrados a cada chamada.

O que muda na prática: o analista de negócio passa a alterar a regra em minutos, sem tocar no lake e sem abrir chamado. A decisão ganha trilha auditável, em vez de ficar implícita no código. E o score permanece onde é bem feito, no Databricks. Há ainda um efeito de custo que cresce com o volume: lógica de decisão rodando como compute recorrente dentro do lake escala junto com o consumo; uma camada de decisão dedicada desacopla esse custo do processamento de dados.

Esse padrão se repete fora de um único setor. Uma financeira que recalibra corte de crédito por perfil a cada trimestre. Um varejo que muda regra de elegibilidade de campanha toda semana. Uma seguradora que ajusta o critério de aceitação por ramo. Uma operação de logística que muda regra de roteirização por região. Em todas, o score ou o dado podiam continuar no Databricks; a regra que decide precisava sair de lá.

Sendo honesto sobre o contrário: se a regra é estável, muda raramente, vive colada ao dado por bom motivo e o conhecimento dela está documentado e distribuído, deixe onde está. Externalizar nesse caso é complexidade sem retorno. A conta vira quando a regra é volátil, ramificada e depende de uma ou duas pessoas para mudar.

A pergunta útil não é "como mudo essa regra no notebook". É "essa decisão deveria viver no mesmo lugar que a computação que a alimenta". Quando a resposta é não, o caminho de saída existe e não exige parar a operação.

Aprofundamos o padrão de o dado gerar o score e o motor aplicar a decisão no e-book [Onde mora a regra de negócio](https://cdn.prod.website-files.com/68513c3bb79a0d0bb4b2b6aa/6a3056f50f8f06c475c8ca4d_Abaccus-Ebook-Onde-mora-a-regra-de-negocio.pdf), e mostramos como essa camada opera ao lado de modelos de IA em [IA em decisões críticas](https://abaccus.com.br/ia-em-decisoes-criticas).