Equipes que sobem o primeiro modelo de IA para produção em uma seguradora costumam montar um dashboard inicial focado nas métricas que aprenderam a importar durante desenvolvimento: acurácia no test set, AUC, F1.
Esse dashboard funciona durante o primeiro mês. Depois, ele para de ser útil.
As perguntas que importam quando você tem IA decidindo riscos reais não são "qual a acurácia no test set". São perguntas operacionais sobre comportamento ao longo do tempo, sobre divergência entre o que o modelo decide e o que humano decidiria, e sobre custo por unidade de valor entregue. É exatamente o tipo de problema que ferramentas como Arize AI, Fiddler, WhyLabs e Evidently AI atacam — cada uma com ângulos um pouco diferentes.
Construir observabilidade é caro. Não revisar a observabilidade que se construiu é mais caro.
Por que observabilidade de IA é diferente
Sistemas tradicionais têm comportamento determinístico — quando funcionam, funcionam igual; quando quebram, quebram de jeito reproduzível. Observabilidade clássica (logs, métricas, traces) lida bem com isso.
Sistemas de IA têm camada adicional: comportamento estatístico. Eles podem estar funcionando perfeitamente em termos de software — sem erros, latência boa, throughput estável — e ainda estar produzindo decisões progressivamente piores ao longo do tempo. Essa degradação não dispara alerta em monitoramento clássico. Aparece em loss ratio meses depois.
As 6 métricas do dashboard mínimo
1. Latência por tipo de decisão (p50, p95, p99). Não basta latência média. Para decisões automatizadas que afetam experiência de canal, p99 importa tanto quanto p50 — porque é o caso de uma submissão em 100 que demora 12 segundos que vira complaint do corretor. Quebra por tipo: extração, classificação, scoring, geração.
2. Taxa de override humano. A fração de decisões automáticas alteradas pelo underwriter. É o termômetro mais direto de qualidade do modelo em produção. Override tendendo para baixo significa concordância crescente. Tendendo para cima significa que algo está mudando — drift de dados, drift de política, ou modelo errando onde antes acertava.
3. Distribuição de features e drift detection. Para cada feature relevante, monitore distribuição (média, std, percentis) ao longo do tempo. Compare com a distribuição de treino. Quando diverge significativamente, o modelo está operando fora do que viu — ainda funciona, mas com confiança decrescente. Evidently AI tem boa documentação aberta sobre os testes estatísticos típicos (KS, PSI, Wasserstein).
4. Custo por decisão. Inclui chamadas de API LLM, infraestrutura de inferência, retrieval de bases externas. Em sistemas híbridos, custo por decisão pode variar 10× entre tipos de caso. Sem essa métrica, custo total balona sem explicação.
5. Loss ratio segmentado por automação. Book observável separado por nível de envolvimento humano: 100% automático, parcialmente automático, integralmente humano. Diferenças significativas sinalizam algo — qualidade do modelo, viés de seleção, ou diferença de produto.
6. Divergência humano-vs-modelo amostral. Fração das decisões automáticas (1% a 5%) submetida a revisão humana cega após o fato. Calcula-se a concordância. Em sistemas saudáveis, tende a 80%-90%, com discordância concentrada em casos genuinamente ambíguos.
O que NÃO basta
Acurácia no test set. Útil durante desenvolvimento. Em produção, a única acurácia que importa é a operacional, medida pela divergência humano-vs-modelo amostral.
AUC, F1. Métricas de modelo, não de sistema. Importantes para troubleshooting; insuficientes para monitoramento contínuo.
Volume e throughput. Importante para capacity planning. Não diz nada sobre qualidade.
Confidence score isolado. Útil para roteamento, não como métrica de saúde. Modelo overconfident ou underconfident tem distribuição enviesada.
Cadência de revisão
Diário, alerta-driven: latência, custo, drift de features.
Semanal, equipe técnica: taxa de override, divergência humano-vs-modelo.
Mensal, executivo: loss ratio segmentado, custo total, comparação modelo-vs-humano agregada.
Trimestral, auditoria estendida: simulações contrafactuais, revisão de overrides com motivo livre, análise de viés por segmento.
Onde a maioria trava
O ponto de trava mais comum não é técnico — é organizacional. O dashboard existe ou pode ser construído com esforço razoável. O que falta é dono claro e cadência.
Operações onde "alguém da TI olha o dashboard quando há queixa" não capturam drift. Operações onde a equipe de subscrição vê o dashboard junto com a equipe de modelo, semanalmente, em reunião curta, capturam.
A trilha completa que alimenta esse dashboard é a mesma descrita em Explicabilidade que vai além do SHAP, e a divisão entre LLM e regras que precisa ser monitorada em separado está em LLMs não substituem motores de regras.
Construir observabilidade é caro. Não revisar a observabilidade que se construiu é mais caro — é pagar pela infraestrutura sem extrair o sinal.
Referências e leituras
- Arize AI · ML observability platform
- Fiddler AI · model monitoring + explainability
- WhyLabs · open-source data and ML monitoring
- Evidently AI · ML monitoring open-source
- Explicabilidade que vai além do SHAP · arquitetura de auditoria
- LLMs não substituem motores de regras · arquitetura híbrida que precisa ser monitorada