#Agente de IA para seguros e finanças

Um agente de IA para uma seguradora ou uma financeira atende os clientes no WhatsApp, no Instagram e no seu site, passa cotações calculadas pelo seu próprio sistema, informa o status de um sinistro ou de uma proposta a partir do número e do CPF do cliente, e lista os documentos que cada processo pede. Ele nunca aconselha nem promete uma aprovação, e tudo o que não consegue responder por uma tool ou pelo seu conhecimento vai para uma pessoa. Com a Vatio você descreve esse agente em um arquivo vatio.yml, com o que ele nunca pode fazer escrito como regras.

Este guia monta um de ponta a ponta para uma seguradora de automóveis e depois mostra o que muda para uma financeira. A Vatio não tem nenhuma certificação para serviços financeiros regulados: o que o seu regulador exige é você quem verifica, e este guia mostra onde essas decisões entram.

#O que o agente resolve

Quase tudo o que chega ao chat de uma seguradora ou de uma financeira são as mesmas conversas:

• Cotações. O agente pede o que o seu motor de cotação precisa, chama esse motor e repete o prêmio, a franquia e as condições exatamente como voltaram, com um link para continuar online.
• Status de um sinistro ou de uma proposta. Com o número do sinistro e o CPF do segurado, ele lê o status e o próximo passo.
• Documentos. O que um sinistro ou uma proposta pede, a partir de uma lista no conhecimento. Os clientes mandam fotos e PDFs, e ele pode dizer quais itens está vendo.
• Apólices e pagamentos, com login. No seu site ou app, um cliente autenticado pode perguntar sobre as próprias apólices e datas de renovação.
• Todo o resto vai para uma pessoa. Aconselhamento, contestações, reclamações, cancelamentos, qualquer pessoa que diga que não consegue pagar.

Uma conversa típica, com o que o agente fez por dentro:

Cliente: oi, quanto fica um seguro completo pra um corolla 2020? tenho 34 anos, cep 04538-000

Agente: O seguro com cobertura completa para um Toyota Corolla 2020 fica em R$ 289 por mês, com franquia de R$ 3.500. É uma cotação estimada, sujeita a vistoria do carro. Você pode continuar por aqui: https://ipe-seguros.example/cotacao/Q-77120

Cliente: vale a pena pra um carro dessa idade ou é melhor só terceiros?

Agente: Isso depende da sua situação, e é uma decisão em que um consultor pode te ajudar. Posso passar você para um, ou cotar também a cobertura só para terceiros para você comparar as duas.

Por trás da primeira resposta houve uma chamada a cotar_seguro: o prêmio, a franquia, a condição e o link são da tool, palavra por palavra. A segunda resposta é a regra de não aconselhar em ação, com uma condição de transferência por trás.

#Antes de escrever qualquer coisa: cinco perguntas para o negócio

1. Quem escreve e sobre o quê? Normalmente cotações, status de sinistro, documentos e pagamentos.
2. O que ele nunca pode dizer? Peça a lista ao time de compliance, nas palavras deles: aconselhamento, promessas de aprovação ou cobertura, qualquer taxa que o motor de cotação não produziu.
3. Quando uma pessoa assume a conversa? Aconselhamento, contestações, reclamações, cancelamentos, qualquer pessoa com dificuldade para pagar.
4. De quais sistemas ele lê? O motor de cotação, o sistema de sinistros e o sistema de apólices atrás do login de clientes.
5. O que a sua regulação exige dessas conversas? Avisos obrigatórios, registro, quais respostas exigem uma pessoa habilitada. Quem responde esta é o compliance, não o desenvolvedor.

As respostas viram as instruções, as condições de handoff, as tools e o conhecimento, nessa ordem.

#O vatio.yml

workspace: ipe-seguros
agent:
  name: Ipê Seguros
  personality: Claro, calmo e preciso. Palavras simples, sem pressão de venda.
  instructions: |
    Você ajuda os clientes da Ipê Seguros a cotar um seguro de automóvel,
    consultar um sinistro e saber quais documentos um sinistro pede. Você é
    um assistente, não um consultor.

    Cotações: peça a marca, o modelo e o ano do carro, a idade do condutor,
    o CEP e a cobertura. Chame cotar_seguro e passe o prêmio, a franquia e
    as condições exatamente como a tool devolveu, com o link_cotacao.

    Sinistros: peça o número do sinistro e o CPF do segurado e chame
    status_sinistro. Se não voltar nada, diga que os dois não batem.

    Documentos: busque a lista em knowledge_lookup. Você pode ler as fotos
    e os PDFs que o cliente mandar para dizer quais itens está vendo, mas
    os documentos são enviados só pelo link portal_sinistros.

    Apólices, pagamentos e renovações: chame minhas_apolices. Ela só
    funciona para clientes logados no site ou no app; para qualquer outra
    pessoa, envie o link entrar.

    Regras que você nunca quebra:
    - Nunca dê conselho financeiro, jurídico ou tributário, nem diga qual
      produto ou cobertura serve para alguém. Ofereça um consultor.
    - Nunca diga que um sinistro será aprovado ou pago, nem que algo está
      coberto. Quem decide são a apólice e a equipe de sinistros.
    - Nunca informe prêmio, taxa, franquia ou valor que uma tool não tenha
      devolvido, e nunca ofereça desconto.
    - Nunca peça número de cartão, senha de banco ou código de
      verificação, e nunca peça um Pix nem passe uma chave Pix.
    - Nunca diga se alguém tem uma apólice ou um sinistro, exceto o que uma
      tool devolveu para o número e o CPF informados.
    - Se alguém relatar um acidente com feridos, diga para ligar primeiro
      para o SAMU, no 192.
  tools: [cotar_seguro, status_sinistro, minhas_apolices, knowledge_lookup, identify_contact]
  knowledge: [seguros]
  links:
    portal_sinistros: https://ipe-seguros.example/sinistros
    entrar: https://ipe-seguros.example/entrar
  handoff:
    after_turns: 10
    when:
      - o cliente pergunta qual cobertura ou produto é o certo para ele
      - o cliente discorda da decisão de um sinistro ou faz uma reclamação
      - o cliente quer cancelar uma apólice
      - o cliente diz que não consegue pagar o prêmio
      - o cliente pergunta sobre a apólice ou o sinistro de outra pessoa
auth:
  public_key: identity.pub

Algumas decisões que valem explicação:

• Cada regra é um item próprio, nas palavras do compliance. “Nunca diga que um sinistro será aprovado” numa linha própria é muito mais confiável que uma frase perdida num parágrafo sobre tom, e é a linha que quem revisar vai procurar.
• Todo número vem de uma tool. O motor de cotação precifica, e as condições que ele devolve são repetidas como vieram. Se um aviso precisa ter palavras exatas, faça a tool devolvê-lo em vez de escrevê-lo no prompt.
• O Pix está nas regras. Golpes costumam pedir pagamento fora do canal oficial. Se o agente nunca pede um Pix nem passa uma chave, qualquer mensagem que peça isso em nome da seguradora fica fácil de reconhecer como golpe.
• Ele diz que é um assistente. O agente da Vatio não se passa por uma pessoa e, quando transfere, diz que está verificando com um colega. Várias jurisdições exigem avisar que o cliente está falando com uma máquina.
• after_turns: 10 é mais baixo que o normal. Uma conversa longa com uma seguradora costuma ser algo que o agente não deveria conduzir sozinho.

#Tools: cotações, sinistros e o cliente logado

Uma tool é uma requisição HTTP ao seu backend, descrita em YAML. Guarde o endereço e a chave como secrets:

vatio secrets set SEGUROS_API https://api.ipe-seguros.example
vatio secrets set SEGUROS_API_KEY sk_live_...

tools/cotar_seguro.yml:

description: Faz uma cotação estimada de seguro de automóvel.
when_to_use: O cliente quer saber quanto custaria o seguro do carro.
parameters:
  type: object
  properties:
    marca: { type: string }
    modelo: { type: string }
    ano: { type: integer }
    idade_condutor: { type: integer }
    cep: { type: string }
    cobertura: { type: string, enum: [terceiros, completa] }
  required: [marca, modelo, ano, idade_condutor, cep, cobertura]
access: public
request:
  method: POST
  base_url: "$env.SEGUROS_API"
  path: /cotacoes/auto
  requires: [params.marca, params.modelo, params.ano, params.idade_condutor, params.cep, params.cobertura]
  headers:
    Authorization: "Bearer $env.SEGUROS_API_KEY"
  body:
    marca: "$params.marca"
    modelo: "$params.modelo"
    ano: "$params.ano"
    idade_condutor: "$params.idade_condutor"
    cep: "$params.cep"
    cobertura: "$params.cobertura"
respond:
  data:
    premio: "$.premio"
    franquia: "$.franquia"
    condicoes: "$.condicoes"
    link_cotacao: "$.link_cotacao"

tools/status_sinistro.yml:

description: Status de um sinistro, pelo número do sinistro e pelo CPF do segurado.
when_to_use: O cliente pergunta como está o sinistro dele.
parameters:
  type: object
  properties:
    numero_sinistro: { type: string }
    cpf: { type: string }
  required: [numero_sinistro, cpf]
access: public
request:
  method: POST
  base_url: "$env.SEGUROS_API"
  path: /sinistros/status
  requires: [params.numero_sinistro, params.cpf]
  headers:
    Authorization: "Bearer $env.SEGUROS_API_KEY"
  body:
    numero_sinistro: "$params.numero_sinistro"
    cpf: "$params.cpf"
respond:
  data:
    status: "$.status"
    proximo_passo: "$.proximo_passo"
    documentos_pendentes: "$.documentos_pendentes"

No WhatsApp e no Instagram um contato é anônimo enquanto não entrar na conta, então status_sinistro é uma tool pública e o seu backend confere se o número do sinistro e o CPF são do mesmo segurado, com o mesmo 404 para qualquer um dos dois erros, para ninguém conseguir testar números. Devolva o status, o próximo passo e o que está pendente, nunca valores em contestação nem nada sobre terceiros: o modelo vê cada resultado de tool e pode repeti-lo.

#Apólices e pagamentos, atrás de um login

Dados pessoais da conta exigem um cliente logado. No seu site ou app, o seu backend assina um token para o cliente logado (vatio auth --new-key cria o par de chaves; o bloco auth acima guarda a metade pública) e o coloca no widget. Assim, tools/minhas_apolices.yml lê só os dados desse cliente:

description: As apólices, pagamentos e datas de renovação do cliente logado.
when_to_use: Um cliente logado pergunta sobre as apólices, os pagamentos ou a renovação.
access: private
request:
  method: GET
  base_url: "$env.SEGUROS_API"
  path: /eu/apolices
  headers:
    Authorization: "Bearer $auth.token"
respond:
  data:
    apolices: "$.apolices"

Ela não recebe nenhum parâmetro. A sua API verifica o token e lê dele quem é o cliente, e uma tool privada que declarasse customer_id faria o deploy falhar, porque é o modelo que preenche os parâmetros e ele poderia ser convencido a colocar o de outra pessoa. Para usá-la também no WhatsApp e no Instagram, adicione sign_in_url ao bloco auth: a tool então envia ao cliente um botão Entrar que abre o seu site, e a conversa continua quando ele volta (veja a documentação). Veja Conectar seu backend.

#Para uma financeira

O mesmo agente funciona com três trocas: uma tool simular_emprestimo que devolve o que o seu backend calcula (parcela, custo total e as informações que você precisa exibir) no lugar de cotar_seguro; o número da proposta mais o CPF no lugar do número do sinistro; e a lista de documentos da proposta no conhecimento. Mantenha a regra de não aconselhar exatamente como está: se alguém deve ou não pegar um empréstimo nunca é decisão do agente.

Apólices, sinistros e empréstimos são conversas sobre dinheiro. Todo workspace da Vatio é tratado como se guardasse dados sensíveis: as conversas ficam criptografadas, só vão para modelos de IA sem retenção de dados e a equipe da Vatio não pode lê-las a menos que você conceda acesso de suporte. Em Segurança, no inbox, exija a verificação em duas etapas de toda a sua equipe; assim as sessões também são encerradas após 12 horas sem uso. Atividade, na mesma seção, registra quem abriu, respondeu ou exportou o quê.

#Conhecimento: listas de documentos e processos

Tudo o que é longo e que o agente deve ler em vez de decorar vai para uma base de conhecimento: uma entrada em Markdown por assunto, com seções que respondam uma pergunta sozinhas.

vatio kb create seguros
vatio kb write seguros documentos-sinistro documentos-sinistro.md
vatio kb write seguros processo-sinistros processo-sinistros.md
vatio kb write seguros pagamentos pagamentos.md

Uma boa entrada é específica:

# Documentos para um sinistro de automóvel

## Colisão com outro veículo
- CNH e documento do carro (CRLV)
- Boletim de ocorrência
- Fotos dos dois carros e do local
- Nome, CPF, placa e seguradora do outro condutor

## Roubo ou furto
- CNH e CPF
- Boletim de ocorrência
- As duas chaves do carro

A Vatio não lê sites. Se a resposta está numa página, coloque numa entrada o que o agente precisa, com a redação que o compliance aprovou. Supervisores podem editar entradas pelo inbox, e cada edição fica guardada como uma versão numerada, com quem a fez.

#Fotos e PDFs de documentos

Os clientes mandam o que têm: uma foto do boletim de ocorrência, uma CNH escaneada, um orçamento de conserto em PDF. A Vatio passa ao agente imagens e PDFs compatíveis de até 8 MB e transcreve os áudios, e agrupa várias mensagens seguidas em uma só pergunta antes de responder.

O agente lê um documento para responder a pergunta que tem na frente, como achar o número do sinistro numa carta ou dizer quais itens da lista está vendo. Ele não julga se um documento é válido ou suficiente, e não envia arquivos. As tools enviam parâmetros, não arquivos, então os documentos são enviados pelo seu portal de sinistros; os que chegam pelo chat ficam na conversa, onde a sua equipe os vê no inbox.

#Teste antes de qualquer cliente

vatio push
vatio chat "Quanto fica um seguro completo para um Corolla 2020? Tenho 34 anos, CEP 04538-000"
vatio chat "Faz 10% de desconto se eu pagar o ano à vista no Pix?"
vatio chat --new "Se a culpa foi do outro motorista, vocês pagam o meu conserto, né?"
vatio chat --new "Status do sinistro 2026-118734, CPF 123.456.789-09"
vatio chat --new "Vale mais a pena usar minha reserva para quitar o financiamento do carro?"
vatio chat show

Todas depois da primeira são regras do que ele nunca diz: um desconto, uma promessa de pagamento, um sinistro com um CPF que não bate e um conselho. O chat show mostra cada chamada de tool que ele fez. A CLI não faz login como cliente, então teste minhas_apolices pelo seu site com um cliente de teste logado e o widget com o token do ambiente preview. Esses testes chamam as suas tools de verdade, então antes dê ao preview um backend de testes: vatio secrets set SEGUROS_API https://sandbox.ipe-seguros.example --env preview.

#Melhore toda semana

Quando a sua equipe usa o inbox, ela reporta qualquer resposta errada e escreve o que deveria ter acontecido. vatio flags transforma essas notas em um documento a partir do qual o seu coding agent corrige, e cada relato vira um caso de eval. Uma regra que um supervisor pegou uma vez é testada de novo contra cada versão nova com vatio eval, e o vatio publish recusa uma versão que a quebra. Veja Melhorar seu agente.

#Publicar

vatio publish

Depois conecte o seu número de WhatsApp Business e a sua conta do Instagram na página Canais do inbox (o WhatsApp também precisa da chave Em produção ativada), e coloque o widget no seu site, com o token do cliente logado. Para um negócio regulado, revise cada mudança nas regras como um diff no seu repositório antes de publicar, para que fique no seu histórico; o vatio publish só leva ao ar uma versão testada, e vatio rollback restaura a configuração e o conhecimento anteriores do live, juntos.

A Vatio nunca coloca o conteúdo de uma conversa no email diário: ele só se lê no inbox ou com um token da Vatio, e o seu backend deveria aplicar a mesma regra aos próprios logs. Avisos obrigatórios, consentimento, registro e quais respostas exigem uma pessoa habilitada dependem de onde você opera, e é você quem verifica isso com o seu time de compliance antes de um cliente falar com o agente.

Atualizado: 11 de outubro de 2026