O jurídico encaminha notificação da ANPD: titular contesta recusa de seguro saúde decidida por possível modelo automatizado e invoca o art. 20 da LGPD, direito de revisão de decisão automatizada, com prazo de 15 dias para resposta.

O CTO convoca o arquiteto responsável pelo pipeline. A primeira pergunta é simples: "o que o modelo usou para recusar?" Já resposta não é.

O modelo em produção persiste o score final. As feature importances nunca foram gravadas. A decisão saiu do pipeline como número, não como raciocínio auditável. Reconstruir post-hoc o que influenciou aquela decisão específica, para aquele CPF específico, naquela data específica, exige dois engenheiros seniores e um advogado especialista alocados por semanas. Em implementações similares, esse tipo de remediação consome entre 40 e 80 horas de engenharia e jurídico apenas para produzir uma explicação que deveria custar zero se o pipeline tivesse sido desenhado com auditabilidade desde o início.

A tese é esta: explicabilidade de decisão automatizada não é problema de Data Science. É problema de arquitetura. O passivo já está sendo acumulado a cada decisão não rastreada.

O art. 20 já é obrigação hoje, não uma exigência que está por vir

Existe uma crença operacional disseminada no mercado: enquanto a SUSEP não publicar uma circular específica sobre modelos de ML, não há obrigação formal de explicabilidade. Essa leitura está errada.

O art. 20 da LGPD está vigente. Ele garante ao titular o direito de revisão de decisão tomada unicamente com base em tratamento automatizado que afete seus interesses, e exige que a organização informe os critérios e procedimentos utilizados. Não o resultado. Os critérios. A distinção é cirúrgica: logar o score de saída do modelo não satisfaz o requisito legal. O que a lei exige é a persistência das contribuições por variável, vinculada ao ID da decisão individual.

O art. 18, VI combinado com o art. 20 cria duas obrigações distintas que a maioria das seguradoras trata como uma: o titular pode solicitar revisão humana e pode solicitar explicação dos critérios. São pedidos diferentes, com fluxos de atendimento diferentes, com evidências técnicas diferentes. Seguradoras que têm apenas uma política declarada para os dois casos têm lacuna documentada.

A Resolução CNSP 407/2021 reforça o vetor: exige que a seguradora demonstre adequação técnica dos critérios de aceitação de risco. Modelo caixa-preta é incompatível com o art. 4º, §2º dessa resolução, não como interpretação extensiva, como leitura literal do texto.

O sandbox regulatório da SUSEP de 2023 adicionou explicitamente "auditabilidade de algoritmos" como condição de participação. Editais de sandbox funcionam como rascunho das exigências que chegam ao mercado geral. Quem leu o edital já sabe o que vem.

A causa raiz não está no modelo, está na ausência de event sourcing nas decisões

O diagnóstico técnico preciso: modelos foram integrados como serviços de inferência sem camada de observabilidade. O pipeline produz score, não decisão auditável.

A causa sistêmica é a separação entre o time de Data Science, que treina o modelo e define as features, e o time de Engenharia, que expõe o endpoint em produção, sem ownership claro sobre o contrato de explicabilidade. O modelo vai para produção quando a acurácia passa no threshold. A pergunta "como essa decisão específica será explicada daqui a três anos para a ANPD?" não está no definition of done.

O trade-off que levou a esse padrão é legítimo: adicionar SHAP values em tempo síncrono de inferência aumenta latência em 15 a 40ms por requisição, dependendo do modelo e da profundidade das contribuições calculadas. Para precificação de um seguro de automóvel em tempo real com SLA de 200ms, isso é relevante. Para aceitação de risco de vida ou saúde, onde a latência aceitável é de segundos, não é.

A solução arquitetural que resolve o problema sem impactar SLA é desacoplar a explicabilidade da inferência: o pipeline produz o score de forma síncrona como hoje, e persiste as feature importances de forma assíncrona em event store imutável, Kafka + S3 com retenção configurada, vinculadas ao ID da decisão. O titular que invocar o art. 20 daqui a dois anos recebe uma resposta em horas, não em semanas de remediação de engenharia.

Há uma segunda abordagem arquitetural que merece atenção específica no contexto de seguros: o uso de um BRMS como camada de decisão auditável por design. Em vez de delegar a decisão final exclusivamente ao modelo de ML, o pipeline pode usar o score como input para um motor de regras que aplica critérios de aceitação de risco explícitos, versionados e rastreáveis. Cada regra disparada fica registrada no log da decisão com sua justificativa legível: "score de risco acima de 0,72 combinado com histórico de sinistros nos últimos 24 meses resultou em recusa pelo critério X, versão Y, vigente desde a data Z." O BRMS não substitui o modelo, ele encapsula a decisão final em lógica auditável, transformando o output do ML em insumo de um processo que já nasce explicável.

Para o art. 20, isso é estruturalmente superior a reconstruir post-hoc as contribuições de um modelo caixa-preta: a explicação não precisa ser gerada, ela já existe como registro nativo da execução.

O que isso exige na prática: que explainability seja requisito no design review do pipeline, não feature de backlog. O modelo só entra em produção se o contrato de observabilidade estiver definido, quais features são persistidas, em que formato, com qual retenção, vinculadas a qual ID de negócio. Onde um BRMS estiver na arquitetura, o versionamento das regras e o log de execução por decisão são parte do mesmo contrato.

O custo de não resolver tem linha no balanço

A multa por violação do art. 20 pode chegar a 2% do faturamento no Brasil, limitado a R$ 50 milhões por infração. Para uma seguradora mid-market com faturamento de R$ 400-750 milhões, a exposição por processo individual está na faixa de R$ 8-15 milhões. Esse número não é hipotético. É o teto legal para uma não-conformidade que já existe hoje em cada decisão automatizada sem rastreabilidade.

O custo operacional de remediação após auditoria tem padrão observado: seguradoras que passaram por auditoria com modelos não rastreáveis relatam entre 6 e 18 meses de remediação, com equipes parcialmente alocadas. O custo operacional desse ciclo fica entre R$ 1,2 e R$ 3,5 milhões, sem contar o custo de oportunidade das squads que não entregaram produto durante esse período.

O retrabalho para adequar um modelo sem explainability já em produção é tipicamente quatro a sete vezes mais caro do que implementar a camada de observabilidade na fase de desenvolvimento. O momento mais barato de resolver é antes do primeiro deploy. O segundo momento mais barato é agora.

O que a seguradora preparada tem que as demais não têm

Uma seguradora de médio porte com 22 ramos ativos passou pelo seguinte processo ao receber pedido de revisão de decisão automatizada de aceitação de risco de vida: acessou o event store, consultou o registro vinculado ao ID da apólice, gerou o relatório de contribuições por feature em menos de quatro horas. O time jurídico respondeu dentro do prazo de 15 dias com documentação técnica completa. Nenhum engenheiro foi alocado na resposta. O processo foi conduzido pelo time de compliance usando um painel de consulta pré-configurado.

O que diferenciou essa organização não foi o modelo. Era uma Random Forest convencional, sem nada de excepcional em termos de arquitetura de ML. O que diferenciou foi que explainability estava no definition of done desde o design do pipeline. As contribuições por feature foram persistidas desde o primeiro deploy. A retenção foi configurada para cinco anos no momento da implementação.

Em organizações que adotaram BRMS como camada de decisão, o cenário é ainda mais direto: o registro de quais regras foram executadas, em qual versão e com quais parâmetros já está disponível como log nativo da plataforma. Não há reconstrução, não há SHAP calculado retroativamente, não há engenheiro alocado para explicar o que o modelo fez. A resposta ao titular é uma consulta ao histórico de execução do motor de regras, legível por compliance sem intermediação técnica.

Auditoria regulatória deixou de ser evento de crise. Virou procedimento rotineiro de duas a quatro horas.

---

Cada decisão automatizada que entra em produção sem rastreabilidade de contribuições é uma não-conformidade potencial com CPF e data. O passivo não está no código do modelo, está na ausência de event sourcing.

Pega os modelos em produção que tomam decisões que afetam titulares, recusa, precificação diferenciada, liquidação parcial. Pergunta qual deles tem as contribuições por feature persistidas e vinculadas ao ID da decisão, e, onde há BRMS, qual deles tem o log de execução de regras versionado e consultável.