WIR Innovation
Distribuição, subscrição e inteligência operacional conectadas ao crescimento da sua operação.
Inteligência operacional
Três perguntas que um time de TI faz antes de aprovar um piloto — e como respondemos cada uma.
Integração, dado e porta de saída: as três perguntas que decidem um piloto de IA em seguradora, corretora, MGA ou operadora de saúde — e a resposta escrita que a WIR dá para cada uma.
Em resumo
As três perguntas que um time de TI faz antes de aprovar um piloto de IA são: o que isso toca nos meus sistemas, o que acontece com os dados e com a decisão, e como eu desligo se não funcionar — e um piloto só é aprovável quando as três têm resposta escrita antes do início.
- Três perguntas, não trintaIntegração, dado e porta de saída decidem a aprovação do piloto antes de qualquer demonstração.
- Cinco por cento chegamPesquisa do MIT NANDA estimou que apenas 5% dos projetos de GenAI passam da fase exploratória para valor consistente [1].
- Baseline antes de ligarSem medir o tempo atual da tarefa, não existe antes e depois para comparar [2].
- Reversível por desenhoA camada de IA roda por cima dos sistemas atuais via API; desligar é reverter uma integração, não uma migração.
O que a TI está realmente perguntando.
Quando um time de TI de seguradora, corretora, MGA ou operadora de saúde recebe a proposta de um piloto de IA, a conversa se reduz a três perguntas: o que isso toca nos meus sistemas, o que acontece com os dados e com a decisão, e como eu desligo isso se não funcionar. Nossas respostas são curtas e as mesmas em toda reunião: a camada de IA se integra por API e não substitui o core; cada saída carrega trilha de auditoria para o subscritor; e o desligamento é a reversão de uma integração, não a reversão de uma migração.
O risco de um piloto quase nunca é técnico — é de desenho. Pesquisa do MIT NANDA sobre adoção corporativa de IA generativa estimou que apenas 5% dos projetos passam da fase exploratória para geração consistente de valor, e o padrão dos que morrem é conhecido: começam sem critério explícito de sucesso, sem dono da decisão e sem plano para desligar [1]. Na nossa leitura, um piloto bem definido é o contrário disso: escopo controlado e métricas claras, combinados antes da primeira integração. É uma recomendação que também aparece em guias de contratação de TI [5] — não um padrão consolidado do mercado segurador, e por isso cada contrato precisa escrever o seu.
Pergunta 1: você encosta no meu core?
Não. A resposta precisa ser dada nesses termos, porque a TI já viu o filme do outro caminho. Trocar o core é anos de implantação, orçamento que só cresce e a operação dependendo de uma migração dar certo. Seguir como está também cobra: a cotação chega por e-mail, PDF e planilha, o subscritor passa o dia transcrevendo dado em vez de avaliar risco, e para cotar mais só contratando mais.
A terceira via é a camada de IA. Ela roda por cima dos sistemas atuais, via API, de forma aditiva e reversível. Integra-se aos seus sistemas; não os substitui. Na prática, isso significa endpoints definidos, contrato de integração por escrito e nenhum campo novo obrigatório no core legado — e a TI consegue desenhar o fluxo em uma folha antes de aprovar.
É também o que encurta o tempo de cotação. A camada lê a submissão que chegou em e-mail e anexo, extrai os campos, confronta com o apetite e os critérios de risco da casa e devolve indicação em segundos, não em dias. Quem cota mais rápido, ganha mais: é o mesmo mecanismo por trás de automatizar a cotação de seguros sem mexer na emissão nem no cadastro. O piloto ataca a fatia de transcrição manual na mesa do subscritor — não o sistema legado que a sustenta.
Pergunta 2: para onde vai o dado?
A segunda pergunta tem três camadas, e vale responder as três separadamente: quais dados entram, quem pode vê-los e quem audita a decisão depois. Entra o escopo acordado do piloto — um ramo, uma fila de submissões, um conjunto de campos — com acesso mínimo e credenciais revogáveis pela própria TI. Nada de base inteira replicada para "ver o que sai".
Antes disso, uma pergunta de controle que todo conselho deveria fazer: os dados que o modelo precisa existem hoje, com qualidade auditada? Alguém já mediu a taxa de preenchimento, de duplicidade e de erro nessa base? "Temos os dados" quase nunca sobrevive à segunda pergunta [3]. Quando a base está suja, o piloto vira um projeto de dado disfarçado de projeto de IA — e isso precisa estar no escopo, não na surpresa do terceiro mês.
A terceira camada é a decisão. O custo de erro determina o nível de instrumentação necessária: saída que vira rascunho interno tolera revisão leve; saída que vira preço, recusa ou pagamento exige outra régua [1]. Por isso a camada entrega preço e decisão com trilha completa para o subscritor, e o threshold de quando o sistema escala para humano em vez de seguir sozinho é definido por um nome, não pelo cientista de dados que estava com o teclado [1]. É esse desenho que permite aumentar a taxa de straight-through processing sem perder a explicabilidade que o regulador e o comitê de risco vão cobrar.
Pergunta 3: como eu desligo isso?
Quem opera infraestrutura aprova mais rápido quando a saída está desenhada. Como a camada é aditiva, desligar significa cortar a integração: os sistemas atuais continuam fazendo o que faziam antes, com os mesmos processos e as mesmas telas. Não há dado órfão no core, não há migração a desfazer, não há janela de parada.
Junto com o desligamento vem a conta que raramente está na apresentação: quanto custa manter isso em pé no terceiro ano. TCO é o custo total de propriedade — tudo o que a empresa continua pagando depois da mensalidade: integração, suporte, ajuste de modelo e hora de time interno. Não há referência pública confiável desse número para projetos de IA em seguros no Brasil; por isso tratamos o cálculo como entrega do piloto, contrato a contrato, com o que a integração garante por escrito. Peça esse número antes de aprovar; ele muda a comparação inteira.
Duas perguntas fecham o filtro, e nós respondemos as duas em proposta: qual é a alternativa mais barata que resolveria 70% disso, e o que acontece se não fizermos nada por 12 meses [3]. Se uma mudança de processo captura a maior parte do valor, dizemos isso. Se a resposta honesta ao "nada por 12 meses" for "pouco", o piloto não é o mais importante da fila — e um piloto fora de ordem é o que a TI menos quer na agenda.
Piloto não morre por tecnologia.
As três perguntas são necessárias, não suficientes. O que separa o piloto que vira produção do piloto que vira apresentação é a parte que ninguém discute na sala técnica: quem decide, o que se mede e quando se encerra.
- Sem dono da decisãoPilotos sem dono identificado morrem por consenso — três áreas opinam, ninguém decide e o piloto roda sem critério até o orçamento acabar [1].
- Sem baselineExemplo ilustrativo de outro setor (SaaS de vendas): antes de ligar a ferramenta, o tempo da tarefa foi medido em 47 minutos por pessoa por dia, com média de 8 representantes ao longo de duas semanas [2]. Em seguros o recorte é outro — uma fila de submissões, um ramo —, mas a regra não muda: sem medida inicial, não existe antes e depois.
- Sem marco de leituraTodo projeto deveria carregar uma leitura precoce em 90 dias; sem ela, o primeiro sinal de fracasso chega junto com a fatura final [3].
Piloto sem dono, sem baseline e sem data de desligamento não é teste: é despesa com narrativa.
Como a WIR responde, por escrito.
Nossa proposta de piloto chega com as três respostas no papel: o desenho da integração por API sobre os sistemas atuais, o escopo de dado com trilha de auditoria por decisão, e o critério de desligamento com a conta do terceiro ano. O objetivo declarado é uma camada de IA sobre a operação de seguros, com resultado em semanas — não anos de implantação.
A camada atende quem já está na operação: seguradoras, MGAs, agências e corretoras no Smart Sales; pequenos e médios corretores no Broker2You, em um mercado pulverizado de distribuição; e planos de saúde, por onde começa o Agente de Vendas por WhatsApp. Em todos, o movimento é o mesmo: do e-mail de entrada à decisão, em segundos.
Se o seu time de TI quiser checar lastro antes da primeira reunião, nossos números de mercado ficam públicos com fonte declarada no dashboard SUSEP, e o restante da tese está em wirinnovation.ai. Leve as três perguntas para a próxima proposta que chegar à sua mesa — a nossa ou a de qualquer outro. Piloto que não responde às três não deveria ser aprovado.
FAQ
Quanto tempo deve durar um piloto de IA em seguros?
O suficiente para medir um antes e um depois no mesmo recorte de tarefa, com baseline coletado antes de ligar a ferramenta [2]. Nós trabalhamos com resultado em semanas, não em anos, e com um marco de leitura precoce para saber cedo se o caminho está certo ou errado — sem ele, o primeiro sinal de fracasso chega junto com a fatura final [3].
Quem deve ser o dono da decisão no piloto?
Não o dono do projeto técnico: o dono da decisão. É a pessoa que define o que conta como saída certa, qual o threshold em que o sistema escala para um humano e quem audita se as decisões automatizadas continuam batendo com a realidade ao longo do tempo. Se essa pergunta não tem resposta com nome, o piloto não está pronto para começar [1].
Aprovar o piloto significa trocar o core?
Não. A camada de IA se integra aos sistemas atuais via API e não os substitui. É aditiva e reversível: o desligamento corta a integração e a operação segue como estava, sem migração a desfazer.
Como calcular o custo real do piloto?
Some o que a empresa continua pagando depois da mensalidade até o terceiro ano — o TCO: integração, suporte, ajuste de modelo e hora de time interno — e exija por escrito o que a integração garante. Pergunte também qual é a alternativa mais barata que resolveria 70% do problema: se ninguém avaliou essa alternativa, o comparativo apresentado é retórico [3].
Como a IA reduz o tempo até a cotação?
A camada lê a submissão que chega em e-mail e anexo, extrai os campos, confronta com o apetite e os critérios de risco da casa e devolve a indicação com trilha de auditoria. O ganho vem de tirar transcrição manual da mesa do subscritor e devolver a decisão em segundos, não em dias.