Model governance não responde quem autorizou o critério. Entenda por que decision governance é a camada que falta nas arquiteturas de IA em operações reguladas.
Compliance
# Governança de IA começa antes do modelo: a camada de decisão que ninguém implementa
MLOps maduro. Drift detection configurado. Pipeline de retraining documentado. Registro de modelo versionado com hash, data e responsável. Tudo isso existe, funciona, e é insuficiente.
A pergunta que a fiscalização vai fazer em 2026 não é "você monitora o modelo?". É "qual regra foi aplicada nessa decisão, quem autorizou, e desde quando essa regra está vigente?". São perguntas diferentes. Exigem respostas de camadas diferentes. A segunda camada, na maioria das arquiteturas de IA em seguradoras brasileiras hoje, não existe.
Model governance governa o artefato. Versiona o modelo, detecta degradação de performance, controla o ciclo de retraining, registra quem fez o deploy e quando. Feito bem, responde perguntas sobre o modelo: qual versão estava em produção, qual era a acurácia, houve drift no período.
Não responde perguntas sobre a decisão.
Um modelo de subscrição pode estar perfeitamente governado no nível do artefato e ainda assim produzir uma recusa de apólice que nenhum atuário consegue explicar. O modelo aprendeu o padrão com dados históricos. Esse padrão implícito nos pesos não é uma regra explícita, não tem vigência, não tem autor, e não foi submetido a aprovação de produto ou conformidade. Existe como comportamento emergente.
Suficiente para operar. Insuficiente para auditar.
A Resolução CNSP 395/2020 e a Circular SUSEP 667 movem o setor na direção de explicabilidade de decisões automatizadas. O que os reguladores querem não é o log do modelo, e sim a lógica da decisão: critério aplicado, base normativa, versão vigente, autorização. Histórico de commit não serve. Registro de deploy não serve. Esses artefatos documentam quem mexeu no código. A fiscalização pergunta quem autorizou o critério de negócio.
O termo "decision governance" raramente aparece nos roadmaps de IA de seguradoras. MLOps está nos slides. Data governance tem comitê. Model risk cresce como disciplina. Decision governance, a camada que define explicitamente o que o modelo pode e não pode decidir, e como essas decisões são documentadas, ainda é tratada como consequência natural das outras três.
Não é. É uma camada separada, com requisitos próprios.
O que decision governance exige, operacionalmente:
O modelo faz parte disso. Governa o inference, a extração, a classificação. Mas a decisão final em processos regulados precisa de uma camada que o modelo, por definição, não fornece: determinismo auditável.
O custo de implementar decision governance depois que o modelo está em produção é ordens de grandeza maior do que implementar antes. Esse argumento raramente aparece no planejamento de arquitetura. Deveria aparecer primeiro.
Quando o modelo entra em produção sem essa camada, três problemas se instalam simultaneamente.
O primeiro é técnico. A lógica de decisão passa a viver implicitamente nos pesos do modelo e na lógica hardcoded em volta dele. Separar isso depois exige reverter engenharia de decisão, descobrir onde estão os critérios, reescrever regras explícitas que o time nem sabe mais articular porque "o modelo aprendeu". Times que fizeram essa separação pós-deployment reportam esforço 4 a 6 vezes maior do que teria sido fazer antes.
O segundo é organizacional. Com o modelo em produção gerando decisões, qualquer mudança de critério passa a exigir tanto a alteração da regra explícita quanto retraining ou ajuste do modelo. O negócio perde autonomia sobre o próprio critério, porque critério e modelo estão acoplados. Uma mudança de política de subscrição vira um projeto de data science.
O terceiro é regulatório. Cada mês que o modelo opera sem audit trail de decisão é um mês de passivo regulatório acumulado. Se a SUSEP solicitar explicação de decisões tomadas nos últimos 24 meses e a resposta for "o modelo fez isso e não conseguimos rastrear o critério exato", a conversa fica muito mais difícil do que teria sido com a camada adequada desde o início.
Regra muda. Retraining começa. Auditoria chega.
Essa arquitetura tem uma fronteira clara quando você para para traçá-la.
IA faz bem o que BRMS não faz: interpreta input não-estruturado, extrai informação de texto livre, classifica situações ambíguas com base em padrões históricos, opera em volume alto com latência baixa. Um modelo de processamento de sinistros que lê o relato do cliente, identifica cobertura acionada, detecta inconsistências e classifica o risco de fraude está fazendo exatamente o que a IA foi construída para fazer.
BRMS faz bem o que IA não faz: executa regra determinística, versiona com autor e data, garante que duas instâncias em servidores diferentes tomem a decisão idêntica, responde "qual critério foi aplicado e quem autorizou" com precisão de auditoria, permite que o negócio altere um critério em 10 minutos sem abrir ticket para engenharia.
O erro arquitetural que se repete é usar o modelo para fazer as duas coisas: extrair e decidir. Funciona enquanto não há auditoria. Quando há, a camada de extração está protegida por model governance, e a camada de decisão não tem resposta.
O padrão correto: IA extrai, classifica e sumariza. BRMS recebe esse output estruturado e decide com regras explícitas e auditáveis. As duas camadas versionadas, com fronteira clara, cada uma governada pelos instrumentos certos para o que faz.
Uma seguradora de médio porte com a qual atuamos na separação dessas camadas em subscrição residencial saiu de um estado onde qualquer ajuste de critério passava por TI e levava semanas para um modelo onde o negócio tem controle total sobre as regras de subscrição e precificação, com audit trail completo conforme SUSEP. A separação das camadas foi o que tornou isso possível, não o modelo de IA em si.
Decisores estratégicos avaliam arquitetura pelo impacto no ciclo de entrega, e essa camada tem impacto direto.
Sem decision governance, cada mudança de critério de negócio percorre o caminho completo: especificação, desenvolvimento, QA, aprovação, produção. Para alterações simples, isso consome de 3 a 5 dias úteis. Para mudanças com dependências, semanas. O negócio fica esperando enquanto o mercado se move.
Com a camada externalizada, mudança de critério não é desenvolvimento. O negócio altera diretamente, com aprovação documentada no próprio sistema e versão publicada em produção em minutos. O ciclo de release de regra deixa de ser o mesmo ciclo de release de feature.
O impacto no backlog é concreto. Em implementações que acompanhamos de perto, cerca de 40% dos tickets de engenharia eram, na prática, mudanças de regra de negócio disfarçadas de desenvolvimento. Separar as camadas libera esse espaço para trabalho real.
Uma fintech de serviços financeiros que passou por esse processo saiu de 200 tickets de TI por mês para manutenção de critérios de precificação para menos de 20, redução de 90%. O tempo de aprovação de alterações caiu de 15 dias úteis para 2. O modelo de IA continuou operando. O que mudou foi a camada de decisão em volta dele.
Há uma janela específica em que implementar decision governance é relativamente simples: antes do modelo entrar em produção, ou nas primeiras semanas de operação, quando a lógica de decisão ainda está explícita na cabeça do time que a construiu.
Depois que o modelo opera por 6, 12, 18 meses, a lógica começa a viver nos outputs do modelo, não no conhecimento articulado do time. Atuários e product owners passam a validar se o modelo "está se comportando bem" em vez de verificar se as regras explícitas estão corretas. A camada de decisão vira implícita por inércia.
O custo de voltar atrás não é só técnico. É organizacional: reconstruir qual era o critério de elegibilidade do ramo 11 em março do ano passado, quando ninguém documentou porque "o modelo sabia". É o passivo regulatório de não ter o audit trail que a SUSEP vai pedir. E é o custo de oportunidade de um time de engenharia que vai passar semanas reconstruindo em código explícito o que estava implícito em pesos.
Quem está implementando modelo de IA agora, seja em subscrição, sinistros, precificação ou score de fraude, está no momento de menor custo para colocar essa camada no lugar. Não depois do primeiro incidente regulatório. Não quando o backlog de regra estiver fora de controle.
