No dia 28 do mês, o diretor financeiro de uma seguradora de vida descobre que o capital regulatório dele saiu do trilho em 8%. Ninguém sabe por quê. O cálculo vive em catorze abas de Excel e três notebooks, cada qual na mão de um atuário diferente. O regulador espera uma explicação em 48 horas. Ninguém consegue dar.
O problema não é atuarial. É industrial. E é exatamente aí que Python no dbt deixa de ser assunto de engenheiro para virar uma decisão de governança financeira.
Por que o SQL não basta para fechar o Solvency II
Dois números estruturam a solvência de uma seguradora. O Best Estimate of Liabilities, ou seja, o valor esperado de tudo o que se terá de pagar aos segurados no futuro. E o capital de solvência requerido (o SCR), a reserva de capital próprio que o regulador impõe para absorver um choque.
Nenhum dos dois se parece com um cálculo que o SQL sabe fazer bem. Numa carteira de cinco milhões de contratos, projetar os fluxos ao longo de quarenta anos com mil cenários econômicos produz dezenas de bilhões de linhas. O SQL filtra e agrega isso sem dificuldade.
O que ele não sabe fazer com precisão é o núcleo do cálculo atuarial: gerar milhares de cenários aleatórios para estimar uma distribuição de resultados, o que se chama uma simulação de Monte Carlo, ou ajustar modelos estatísticos sobre a mortalidade e as curvas de juros. Esses cálculos pedem bibliotecas científicas como NumPy ou SciPy, e uma lógica que não tem nada de declarativa.
O resultado, na maioria das seguradoras: a cadeia atuarial vive fora do data warehouse. Os dados de entrada vêm do sistema de gestão. Os cálculos são feitos em outro lugar, no Excel ou no notebook. As saídas são reinjetadas à mão nos painéis e nos demonstrativos regulatórios. Três rupturas de cadeia, e nenhuma rastreabilidade entre o dado bruto e o capital publicado.
É esse buraco de governança que Python no dbt vem fechar. Para um diretor de riscos, isso não é um detalhe técnico. Um desvio sem explicação entre dois fechamentos dispara uma conversa com o regulador que mobiliza uma equipe de risco durante três semanas. Multiplicado por todos os relatórios regulatórios do ano, esse custo oculto representa facilmente dois atuários em tempo integral. Dois postos que não produzem análise nenhuma: refazem cálculos já feitos, porque ninguém sabe provar que a primeira passagem estava correta.
Na prática, o que muda no pipeline
Um modelo Python no dbt é um arquivo .py no projeto, tratado como qualquer outro nó do grafo. Ele referencia as entradas, se documenta e se testa com os mesmos comandos dos modelos SQL. Produz uma tabela consumível como qualquer outra. Se a ideia de orquestrar SQL e Python na mesma cadeia é nova para você, nosso guia sobre dbt como camada de transformação estabelece as bases.
A diferença está na execução. O código Python não roda num laptop. Ele é compilado pelo dbt e executado pelo motor da plataforma de destino (na Snowflake, é o Snowpark). A simulação roda onde o dado vive. Sem transferência massiva. Sem notebook que a gente relança na segunda de manhã porque ninguém se lembra da última passagem.
Uma cadeia Solvency II industrializada se parece com isto. Os primeiros modelos fazem o trabalho de SQL: limpar os contratos, juntar os referenciais de produto, importar os cenários econômicos. Os modelos intermediários em Python fazem o cálculo atuarial: projeção dos fluxos, agregação por módulo de risco. Os últimos modelos retomam o controle em SQL para produzir as tabelas de reporting. Uma só cadeia, um só orquestrador, uma só rastreabilidade, do dado de entrada até o capital final. É o mesmo princípio de camadas da arquitetura Medallion, aplicado ao cálculo regulatório.
A dose certa não é Python em tudo
O erro clássico, quando se descobrem os modelos Python, é querer migrar tudo. Direção errada.
A regra que a gente aplica: 90% do projeto continua em SQL. O motor SQL de um warehouse moderno é imbatível em joins de carteira, agregações massivas e filtros por data. Colocar Python aí só atrasaria a execução e embaralharia a leitura do código.
Os 10% que merecem Python são a complexidade algorítmica pura. A gente a reconhece em três famílias de cálculo. As simulações, quando é preciso gerar milhares de cenários para estimar uma distribuição de resultados. A calibração, quando se ajusta um modelo matemático a dados de mercado observados. E os cálculos iterativos, aqueles que percorrem o dado etapa por etapa, cada etapa dependendo da anterior. Todo o resto se trata melhor em SQL.
É essa mistura que torna o projeto legível para os analistas e para os atuários. E é ela que separa uma industrialização de verdade de um notebook que a gente simplesmente teria renomeado para .py. A lógica é a mesma da qualidade do código: não é a ferramenta que a produz, é a disciplina de recorte. Se você quiser aprofundar essa disciplina, nosso relato de experiência sobre como refatorar modelos dbt manuteníveis detalha o método.
Por que isso é assunto de CFO, e não só de TI
Para o diretor financeiro e o diretor de riscos, isso se mede em três números.
Primeiro, a auditabilidade. Cada passagem é versionada, e a rastreabilidade sobe do dado bruto até o capital publicado. Quando o regulador pede para reconstituir um cálculo de um trimestre anterior, a resposta leva horas, não semanas. Numa seguradora que a gente opera, o prazo de resposta aos controles passou de três semanas para seis horas.
Em seguida, a reprodutibilidade. Mesmas entradas, mesmas saídas, garantidas. Acabou o Excel em que um atuário mudou uma célula em março sem anotar. Os testes validam, a cada passagem, que as fórmulas-chave dão o resultado esperado num conjunto de referência. Se alguém quebra uma fórmula, a cadeia não entrega em produção. Essa lógica de controle automático se encontra com a dos padrões de qualidade e data contracts.
Por fim, o prazo de fechamento. O fechamento trimestral passa de várias semanas para alguns dias, não porque o cálculo fique magicamente mais rápido, mas porque se eliminam as manipulações manuais entre sistemas e porque os cálculos que rodavam em série numa máquina passam a rodar em paralelo no warehouse.
Enquanto isso, a pressão regulatória sobe, o custo dos atuários experientes aumenta, e os volumes de dados dobram a cada revisão do referencial. Manter a cadeia atuarial no Excel vira uma escolha que custa mais caro a cada trimestre.
O que a gente observa em campo
A gente opera esse tipo de migração em várias seguradoras e mútuas há dois anos. A armadilha recorrente nunca é técnica. É organizacional.
Os atuários detêm uma expertise regulatória que ninguém sabe replicar. Os data engineers detêm a industrialização. Colocá-los na mesma cadeia impõe um quadro claro: quem valida uma fórmula, quem pode alterar um modelo crítico, como se testa um cálculo regulatório antes da produção. Sem esse quadro, o projeto termina em notebooks renomeados, e o problema de partida não se moveu um milímetro.
O ponto de entrada certo nunca é a grande virada. É identificar três ou quatro cálculos em que Python traz valor imediato. A gente industrializa esses no dbt, mantém o resto em SQL por enquanto e expande por ondas. Primeiro resultado em produção em 6 a 8 semanas, mensurável e auditado.
Python no dbt não substitui o SQL. Ele tira o financeiro quantitativo do purgatório do Excel e o coloca onde sempre deveria ter estado: no data warehouse, sob governança, com rastreabilidade e testes. Para um diretor financeiro de seguradora, isso justifica plenamente a leitura de uma documentação técnica.
