Casos de uso publicados no setor de seguros costumam ser desonestos. Os números são apresentados sem contexto, o "antes" é caricaturado, e os problemas que apareceram no meio do projeto somem do narrativo final.
Esse texto é o oposto disso. É uma descrição honesta do primeiro caso de implementação completa da stack WIR em uma operação portfólio Mahway — incluindo as três coisas que não funcionaram de primeira e as duas que tivemos que abandonar.
O ponto de partida
A operação tinha 6 underwriters seniores cobrindo Transportes, Riscos de Engenharia e P&C corporativo médio. Ciclo de cotação médio: 11 dias. Volume mensal: ~800 submissões. Conversão: 19%.
A queixa interna não era falta de competência técnica. Era throughput. O time recusava casos no apetite porque não tinha tempo de cotar — e o que cotava, cotava tarde demais para concorrer com seguradoras que haviam começado a investir em automação dois anos antes.
A diretoria havia tentado três coisas antes: contratar mais um underwriter (bottleneck virou onboarding), implementar um portal (corretoras não usaram), comprar uma ferramenta de OCR (extraiu campos, não decidiu nada).
Nenhuma resolveu, porque nenhuma atacou o que era um problema de modelo operacional, não de capacidade. O contexto desse problema estrutural é a tese central de O underwriter não morre.
A intervenção
Fase 1 (semanas 1-6): Intake estruturado. O primeiro módulo recebeu submissões pelos canais existentes, descompactou anexos, extraiu campos com camada híbrida de OCR + LLM e estruturou em schema normalizado. Sem decidir nada — só preparou. Resultado: o tempo de "submissão chega" → "underwriter tem dados estruturados na mesa" caiu de 4 horas para 6 minutos.
Fase 2 (semanas 5-12): Enriquecimento e classificação por apetite. Em paralelo, ligamos o motor de regras de apetite e o módulo de enriquecimento. Cada submissão passou a chegar pré-classificada em três fluxos: dentro do apetite, borda, ou fora.
Fase 3 (semanas 11-18): Pricing assistido e auditoria. Sugestão de pricing calibrada ao livro histórico, e a infraestrutura de logging que registra cada decisão com modelo, versão, inputs, output, timestamp e justificativa — exatamente a arquitetura descrita em Explicabilidade que vai além do SHAP.
O que funcionou
Resultados na semana 18, comparados à baseline. Ciclo de cotação: 11 dias → 2 horas. Volume processado: 800 → 3.000/mês. Headcount: 6 (mesmo time). Conversão: 19% → 26%. Loss ratio: 64% → 61%. NPS dos corretores: 31 → 67.
A IA isolada não teria movido a agulha — porque o gargalo não era extração de PDF, era operação fragmentada.
O número mais subestimado é o NPS de corretores. A operação não comunicou tecnologia para fora. O que corretores perceberam foi: a seguradora respondia rápido, em formato útil, com explicação quando recusava. Em 6 meses, três corretoras top-30 realocaram volume para frente da fila.
O que não funcionou de primeira
Sugestão de pricing virou "preço final" para UWs juniores. Cotações saíam no número exato sugerido pelo motor — sem ajuste. Os UWs tratavam o número como autoridade. Correção: UX (mais explícito que era sugestão) + treinamento + processo (forçar registro de "ajuste ou aceite" antes do submit).
Recusa automática gerou complaint do canal. Recusas vinham com justificativa técnica precisa, em linguagem que soava fria para corretora. Tivemos que adicionar camada de geração de copy — mesma justificativa, em português comercial.
Override sem registro de motivo. Versão inicial deixava UW pular a sugestão sem registrar por quê. Em 6 semanas, perdemos sinal sobre quando o modelo estava certo e sendo ignorado vs quando estava errado e sendo corrigido. Forçar campo obrigatório de "motivo do override" resolveu — e virou base para retreinar.
O que tivemos que abandonar
Chat com o corretor para completar dados faltantes. Tecnicamente funcionou. Operacionalmente, corretores acharam invasivo. Voltamos para fluxo humano de cobrança.
Sugestão de cross-sell na cotação. Conversão real: 0.4%. Cross-sell em seguro corporativo é construído na relação corretor-cliente, não no momento da cotação. Removemos.
O que importa para quem está pensando
A leitura clássica desse caso seria "implementar IA = ganhar 4× throughput". Está errada. A leitura correta é: redesenhar o modelo operacional, com IA como infraestrutura, ganhou 4× throughput. A IA isolada não teria movido a agulha — porque o gargalo não era extração de PDF, era operação fragmentada.
Para qualquer operação considerando o caminho similar: o primeiro investimento não é em modelo. É em logging, schema unificado e política de aceitação versionada.
Referências e leituras
- Mahway · venture builder Tech & IA (California, EUA)
- O underwriter não morre — a tese estrutural
- Explicabilidade que vai além do SHAP — a arquitetura de auditoria usada nesta implementação
- Por que MGAs são a ponta da lança da IA em seguro