Agente de IA para Auditoria de Processos de Adesão a Planos de Saúde

24 de December de 2025 • Tempo de leitura: 5 min

Como criar um agente de IA que revisa processos de adesão a planos de saúde para detectar inconsistências e sugerir correções.

1. Propósito e Escopo

Este documento define todos os prompts, configurações de memória, transição entre estados, ferramentas como chamadas a sistemas externos, consulta a documentos e demais requisitos funcionais para o Agente de IA para Auditoria de Processos de Adesão a Planos de Saúde. Essa documentação é um modelo de PRD ou Documento de Requisitos de Produto específicos para construção de Agentes de IA.

O objetivo principal é revisar automaticamente os processos de adesão a planos de saúde, detectar inconsistências e sugerir correções, integrando-se aos sistemas existentes para implementar melhorias.

2. Contexto e Problema

Os processos de adesão a planos de saúde frequentemente apresentam erros e inconsistências devido à falta de auditoria sistemática e eficaz. Isso resulta em atrasos, retrabalho e possíveis penalidades regulatórias.

Atualmente, a revisão desses processos é manual e sujeita a falhas humanas, o que pode comprometer a conformidade com as normas regulatórias e a satisfação do cliente.

3. Impactos Esperados

A implementação deste agente de IA visa alcançar os seguintes resultados:

  • Reduzir o tempo de revisão dos processos de adesão em pelo menos 70%.
  • Aumentar a precisão na detecção de inconsistências e não conformidades.
  • Garantir conformidade com as normas regulatórias aplicáveis.
  • Melhorar a satisfação do cliente através de processos mais ágeis e precisos.

4. Visão Geral da Solução

O agente de IA para auditoria de processos de adesão a planos de saúde revisa automaticamente os dados de adesão, identifica inconsistências e não conformidades, e sugere correções. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um auditor eficiente e autônomo dos processos de adesão.

A solução consiste em um fluxo de automação composto por 8 agentes de IA, que interagem para revisar, auditar e integrar informações dos processos de adesão.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo. O fluxo inclui etapas específicas para cada tipo de verificação e integração.

Agentes Função Principal
Agente de Padronização e Validação de Entrada (RF 1) Receber dados brutos do processo de adesão e produzir um JSON canônico validado.
Agente de Execução de Consulta a Documento (RF 2) Consultar o repositório de normas regulatórias e políticas internas.
Agente de Consolidação de Regras Regulatórias e de Produto (RF 3) Interpretar excertos recuperados e derivar regras operacionais aplicáveis.
Agente de Auditoria de Consistência e Conformidade (RF 4) Auditar o processo confrontando dados canônicos com as regras aplicáveis.
Agente Detector de Sinais de Fraude (RF 5) Aplicar heurísticas para sinalizar padrões atípicos e potenciais fraudes.
Agente de Geração de Relatório e Sumário Executivo (RF 6) Produzir relatório de auditoria em markdown e um pacote JSON acionável.
Agente de Mapeamento para Integração com Sistema (RF 7) Converter o json_actionable em payload específico do sistema de gestão de planos.
Agente de Execução de Chamada à API (RF 8) Realizar chamada à API do sistema de gestão de planos de saúde.

5. Protótipos

Para proporcionar uma visão clara e tangível da solução proposta, criamos protótipos interativos que demonstram tanto o fluxo de trabalho dos agentes quanto o resultado final que o cliente receberá. Explore os links abaixo para entender melhor a solução em ação.

6. Requisitos Funcionais

RF 1. Agente de Padronização e Validação de Entrada

1.1 Tarefa do Agente

Receber dados brutos do processo de adesão e produzir um JSON canônico validado, com campos normalizados, erros pontuais classificados e pré-checagens básicas de elegibilidade.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo dados brutos do processo de adesão a planos de saúde. Este texto é o registro bruto das informações fornecidas pelos proponentes durante a adesão.

# 2. Objetivo
Receber dados brutos do processo de adesão e produzir um JSON canônico validado, com campos normalizados, erros pontuais classificados e pré-checagens básicas de elegibilidade.

# 3. Regras que você deve seguir para gerar sua resposta
- Padronize formatos: datas em ISO 8601 (YYYY-MM-DD), telefones em E.164, CEP em 8 dígitos sem separador, UF em 2 letras, moeda em decimal com ponto (ex.: 1234.56).
- CPF/CNPJ: valide dígitos verificadores; classifique como invalid_fields se falhar; remova pontuação mantendo apenas dígitos.
- Idade: calcule idade exata a partir da data de nascimento usando a data de referência submission_date; determine faixa etária conforme tabela do produto (infantil, jovem, adulto, sênior).
- Obrigatoriedade condicional: defina missing_fields[] com caminho do campo quando estiver ausente considerando o tipo de contratação: individual/familiar, coletivo por adesão, coletivo empresarial. Exemplos: empresa_id obrigatório em coletivo empresarial; vínculo associativo comprovado no coletivo por adesão.
- Endereço e área de abrangência: normalize logradouro, número, bairro, cidade, UF, CEP; derive município/UF para cruzar com área de cobertura do plano posteriormente (marque coverage_city_uf).
- Consentimento e LGPD: garanta presença de bases legais: consent_marketing (opcional), consent_processing (obrigatório); se ausente, inclua em missing_fields com tag lgpd.
- Documentos: normalize lista de documentos com tipo_documento (RG, CPF, CNH, Certidão, Comprovante_residência, etc.), data_emissão, validade, titular, extensões; marque documento obrigatório por tipo de contratação se ausente.
- Declaração de saúde: normalize respostas (sim|não) e, quando 'sim', exigir detalhamento (CID opcional, descrição, data início). Se faltar detalhamento, registre em missing_fields com tag underwriting.
- Preço e reajuste: normalize pricing com base_value, discounts[], additional_charges[], total_value; assegure moeda única; se total_value != base + adicionais - descontos, marque invalid_fields com expected_total.
- Pré-checagem de elegibilidade: defina eligibility_precheck.status como reprovado se idade superar limite do produto, CEP fora da área de abrangência informada pelo produto ou plano indisponível para o canal informado; defina motivos[].
- Registro de normalização: preencha normalization_log[] com entradas {field, from, to, rationale} para cada ajuste realizado.
- Não resolva conflitos silenciosamente: sempre registre em invalid_fields qualquer correção que altere sem confirmação um valor originalmente fornecido. 
1.3 Configurações do Agente

1.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente é o ponto de partida do fluxo e deve ser acionado pelo envio de dados brutos do processo de adesão via API. Na fase de testes, o fluxo será iniciado pelo envio manual dos dados, que serão enviados para o agente diretamente por upload do csv na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um conjunto de dados estruturados em CSV.
  • Formatos Suportados: Esse agente deve ser capaz de receber dados nos formatos: .csv, .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 50.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON canônico padronizado contendo os dados normalizados e os logs de validação realizados.
  • Exemplo de Estrutura de Output:
     {
      "applicant": "string",
      "dependents": [],
      "plan_selected": "string",
      "pricing": "string",
      "underwriting_answers": "string",
      "documents": [],
      "address": "string",
      "contact": "string",
      "employer_group": "string",
      "consent_flags": "string",
      "timestamps": "string",
      "missing_fields": [],
      "invalid_fields": [],
      "normalization_log": [],
      "eligibility_precheck": {
        "status": "string",
        "motivos": []
      }
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 3.000 caracteres.

1.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

1.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

1.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Execução de Consulta a Documento (RF 2).

1.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Execução de Consulta a Documento (RF 2).

RF 2. Agente de Execução de Consulta a Documento

2.1 Tarefa do Agente

Realizar consulta ao repositório de normas regulatórias (ANS) e políticas internas para obter regras aplicáveis ao produto, elegibilidade, carências, precificação e documentação exigida.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo parâmetros de busca prontos contendo chaves do produto, tópicos de interesse e datas de vigência.

# 2. Objetivo
Realizar consulta ao repositório de normas regulatórias (ANS) e políticas internas para obter regras aplicáveis ao produto, elegibilidade, carências, precificação e documentação exigida.

# 3. Regras que você deve seguir para gerar sua resposta
- Esse agente não precisa de instruções para chamadas ao LLM; sua função é executar a consulta ao repositório/documentos com os parâmetros recebidos e devolver os dados recuperados. 
2.3 Configurações do Agente

2.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 1).
  • Tipo do input: Este agente deve ser apto a receber parâmetros de busca estruturados em JSON.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 2.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um conjunto de excertos e tabelas recuperadas, estruturado em JSON.
  • Exemplo de Estrutura de Output:
     {
      "fonte": "string",
      "referencia_normativa": "string",
      "vigencia": "string",
      "trechos": [],
      "tabelas_estruturadas": []
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 1.500 caracteres.

2.3.3 Parâmetros de Geração

  • Modelo: Não se aplica (uso de ferramenta)
  • Temperatura: Não se aplica

2.3.4 Ferramentas do Agente

  • Documentos: Consulta somente-leitura ao repositório de documentos normativos interno (ex.: base de normas ANS e manuais de produto).
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

2.3.5 Memória

2.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Consolidação de Regras Regulatórias e de Produto (RF 3).

RF 3. Agente de Consolidação de Regras Regulatórias e de Produto

3.1 Tarefa do Agente

Interpretar os excertos recuperados e derivar um conjunto de regras operacionais aplicáveis ao caso concreto.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o JSON canônico do Agente de Padronização e o material retornado pelo Agente de Execução de Consulta a Documento.

# 2. Objetivo
Interpretar os excertos recuperados e derivar um conjunto de regras operacionais aplicáveis ao caso concreto.

# 3. Regras que você deve seguir para gerar sua resposta
- Converta trechos textuais em regras condicionais claras: exemplo: 'carência de urgência 24h' vira condição evento=urgência => carência_max=24h.
- Quando houver conflito entre política interna e ANS, priorize ANS; registre conflito em notes[] com referências.
- Inclua regras de documentação obrigatória por tipo de contratação, regras de abrangência geográfica por município/UF e regras de elegibilidade por idade e vínculo.
- Parametrize faixas etárias e seus fatores/tarifas quando disponíveis para permitir auditoria de preço.
- Atribua severidade_base: não conformidades com ANS são bloqueantes; lacunas documentais são alta; melhorias de processo normalmente média/baixa. 
3.3 Configurações do Agente

3.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 2).
  • Tipo do input: Este agente deve ser apto a receber dois artefatos como input: o JSON canônico do Agente de Padronização e o material retornado pelo Agente de Execução de Consulta a Documento.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 4.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo rules_aplicaveis[] com itens estruturados.
  • Exemplo de Estrutura de Output:
     {
      "rules_aplicaveis": [
        {
          "id_regra": "string",
          "origem": "string",
          "descricao": "string",
          "condicao": "string",
          "parametro": "string",
          "severidade_base": "string",
          "vigencia": "string"
        }
      ]
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 2.000 caracteres.

3.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

3.3.5 Memória

3.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Auditoria de Consistência e Conformidade (RF 4).

RF 4. Agente de Auditoria de Consistência e Conformidade

4.1 Tarefa do Agente

Auditar o processo confrontando dados canônicos com as rules_aplicaveis, detectando omissões, inconsistências, não conformidades e sugerindo correções executáveis.

4.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o JSON canônico e rules_aplicaveis[].

# 2. Objetivo
Auditar o processo confrontando dados canônicos com as rules_aplicaveis, detectando omissões, inconsistências, não conformidades e sugerindo correções executáveis.

# 3. Regras que você deve seguir para gerar sua resposta
- Campos obrigatórios: para cada regra de obrigatoriedade, se o campo estiver ausente, crie finding dados_faltantes severidade alta com sugestao_correcao especificando o campo e formato esperado.
- Abrangência x CEP: se município/UF do endereço não estiver coberto pela abrangência do plano, crie nao_conformidade_ans severidade bloqueante; recomende mudança de plano ou endereço de atendimento.
- Elegibilidade por idade: se idade fora da faixa do produto, marque bloqueante; se no limite com política de exceção, classifique alta e recomende aprovação condicional com justificativa.
- Documentos: verifique validade (quando aplicável), titularidade correta e coerência com tipo de contratação; ausência ou validade expirada gera alta; divergência de titular gera inconsistência.
- Declaração de saúde: respostas 'sim' sem detalhamento geram alta; inconsistências entre resposta e documentos médicos geram alta; quando carência especial se aplicar, inclua na sugestão.
- Preço: recompute total esperado a partir de regras e faixas etárias; se divergência > 1% ou valor mínimo definido, crie inconsistencia com expected_total e diferença.
- LGPD: ausência de consent_processing gera nao_conformidade_ans (quando exigido por política) ou risco_lgpd severidade alta; recomende coleta imediata.
- Portabilidade/migração: quando indicado, valide janelas de portabilidade e compatibilidade de segmentação; se incompatível, bloqueante.
- Classificação de severidade: aplique severidade_base da regra, elevando um nível quando houver impacto financeiro alto ou risco regulatório explícito.
- Owner_sugerido: direcione para Backoffice, Comercial, Compliance, Underwriting ou TI conforme a natureza do finding.
- Defina prazo_sla_horas padrão: bloqueante 24h, alta 48h, média 120h, baixa 240h; ajuste se norma impor prazo menor.
- Calcule impacto_financeiro_estimado quando possível: diferença de prêmio projetada por 12 meses ou multa regulatória indicativa. 
4.3 Configurações do Agente

4.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 3).
  • Tipo do input: Este agente deve ser apto a receber o JSON canônico e rules_aplicaveis[] como input.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 5.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo findings[] com estrutura detalhada.
  • Exemplo de Estrutura de Output:
     {
      "findings": [
        {
          "id": "string",
          "tipo": "string",
          "severidade": "string",
          "regra_referenciada": "string",
          "evidencias": [],
          "sugestao_correcao": "string",
          "acao_recomendada": "string",
          "owner_sugerido": "string",
          "prazo_sla_horas": "int",
          "impacto_financeiro_estimado": "float"
        }
      ]
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 3.500 caracteres.

4.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Utiliza lógica interna para cálculos de impacto financeiro e prazos.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

4.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente Detector de Sinais de Fraude (RF 5).

4.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente Detector de Sinais de Fraude (RF 5).

RF 5. Agente Detector de Sinais de Fraude

5.1 Tarefa do Agente

Aplicar heurísticas determinísticas para sinalizar padrões atípicos e potenciais fraudes nos dados do processo.

5.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o JSON canônico e findings existentes.

# 2. Objetivo
Aplicar heurísticas determinísticas para sinalizar padrões atípicos e potenciais fraudes nos dados do processo.

# 3. Regras que você deve seguir para gerar sua resposta
- Reuso de identificadores: se documento do proponente coincide com de dependente, sinalize severidade alta.
- Datas suspeitas: múltiplas datas de emissão idênticas em documentos distintos ou muito recentes (<= 7 dias) para todos os envolvidos, severidade média.
- Incongruência renda x plano: quando declarada renda muito abaixo do percentil estimado para o prêmio selecionado, sinalize média e recomende comprovação.
- Discrepância endereço x contato: CEP de uma UF e telefone com DDD de outra distante sem justificativa, severidade baixa.
- Arquivos nomeados com metadados inconsistentes (ex.: nome do arquivo indica titular diferente do informado), severidade média.
- Documentos vencidos utilizados como identificação, severidade alta.
- Evite duplicar achados já mapeados em findings; referencie-os quando ampliar o risco. 
5.3 Configurações do Agente

5.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 4).
  • Tipo do input: Este agente deve ser apto a receber o JSON canônico e findings existentes como input.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 3.000 caracteres.

5.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON contendo fraud_signals[] com estrutura detalhada.
  • Exemplo de Estrutura de Output:
     {
      "fraud_signals": [
        {
          "id": "string",
          "padrao_detectado": "string",
          "severidade": "string",
          "evidencias": [],
          "recomendacao": "string",
          "acao_recomendada": "string"
        }
      ]
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 2.500 caracteres.

5.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

5.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

5.3.5 Memória

5.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Geração de Relatório e Sumário Executivo (RF 6).

RF 6. Agente de Geração de Relatório e Sumário Executivo

6.1 Tarefa do Agente

Produzir relatório de auditoria em markdown e um pacote JSON acionável para integração.

6.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o JSON canônico, findings[], fraud_signals[] e rules_aplicaveis[].

# 2. Objetivo
Produzir relatório de auditoria em markdown e um pacote JSON acionável para integração.

# 3. Regras que você deve seguir para gerar sua resposta
- Calcule score_conformidade: 100 menos penalidades por severidade (bloqueante -30, alta -15, média -5, baixa -2), mínimo 0.
- Agrupe achados por categoria e severidade; destaque bloqueantes e prazos.
- Para cada finding, inclua referência de regra, evidências e instruções de correção passo a passo em linguagem operacional.
- Inclua checklist por área (Backoffice, Comercial, Compliance, Underwriting).
- Inclua seção de riscos LGPD e recomendações específicas (p.ex. coleta de consentimento).
- Gere um resumo executivo de até 200 palavras com status geral e próximos passos.
- No json_actionable, traduza cada sugestão em tarefa com campos {owner, descricao, prazo_sla_horas, dependencias, prioridade}. 
6.3 Configurações do Agente

6.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 5).
  • Tipo do input: Este agente deve ser apto a receber o JSON canônico, findings[], fraud_signals[] e rules_aplicaveis[] como input.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 6.000 caracteres.

6.3.2 Especificação do Output

  • Formato de output: O output deve ser um relatório em markdown e um pacote JSON acionável para integração.
  • Exemplo de Estrutura de Output:
     {
      "report_markdown": "string",
      "json_actionable": {
        "resumo": "string",
        "score_conformidade": "int",
        "findings_priorizados": [],
        "tarefas_recomendadas": [],
        "bloqueios": [],
        "aprovacoes_condicionais": [],
        "dados_para_correcao": []
      }
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 4.000 caracteres.

6.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

6.3.4 Ferramentas do Agente

  • Documentos: Não consulta.
  • Calculadora: Utiliza lógica interna para cálculo de score de conformidade.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

6.3.5 Memória

6.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Mapeamento para Integração com Sistema (RF 7).

RF 7. Agente de Mapeamento para Integração com Sistema

7.1 Tarefa do Agente

Converter o json_actionable em payload específico do sistema de gestão de planos para abertura de tarefas, bloqueios e aprovações condicionais.

7.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o json_actionable e parâmetros de mapeamento do sistema alvo.

# 2. Objetivo
Converter o json_actionable em payload específico do sistema de gestão de planos para abertura de tarefas, bloqueios e aprovações condicionais.

# 3. Regras que você deve seguir para gerar sua resposta
- Mapeie severidade em códigos de prioridade do sistema: bloqueante=P1, alta=P2, média=P3, baixa=P4 (ou conforme parâmetros recebidos).
- Converta owner_sugerido em fila/owner_id conforme tabela de mapeamento.
- Para bloqueios, gere eventos com status_code 'BLOCK' e motivo referenciando id do finding.
- Inclua prazos em SLA absoluto (timestamp limite) calculado a partir do momento de criação.
- Anexe link ou conteúdo do report_markdown no campo de descrição estendida.
- Valide tamanhos máximos de campos e quebre descrição em notas se necessário. 
7.3 Configurações do Agente

7.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 6).
  • Tipo do input: Este agente deve ser apto a receber o json_actionable e parâmetros de mapeamento do sistema alvo como input.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 4.000 caracteres.

7.3.2 Especificação do Output

  • Formato de output: O output deve ser um payload_api pronto com arrays: tasks[], blocks[], conditional_approvals[], e anexos do report_markdown.
  • Exemplo de Estrutura de Output:
     {
      "tasks": [],
      "blocks": [],
      "conditional_approvals": [],
      "anexos": "string"
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 3.000 caracteres.

7.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

7.3.4 Ferramentas do Agente

  • Documentos: Prepara payload conforme contrato da API do sistema de gestão de planos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não utiliza.

7.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Execução de Chamada à API (RF 8).

7.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Execução de Chamada à API (RF 8).

RF 8. Agente de Execução de Chamada à API

8.1 Tarefa do Agente

Realizar chamada à API do sistema de gestão de planos de saúde para registrar tarefas, bloqueios e aprovações condicionais derivados da auditoria.

8.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo o payload_api pronto para execução da chamada.

# 2. Objetivo
Realizar chamada à API do sistema de gestão de planos de saúde para registrar tarefas, bloqueios e aprovações condicionais derivados da auditoria.

# 3. Regras que você deve seguir para gerar sua resposta
- Esse agente não precisa de instruções para LLM; sua única função é executar a chamada à API com o payload recebido. 
8.3 Configurações do Agente

8.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão do agente anterior (RF 7).
  • Tipo do input: Este agente deve ser apto a receber o payload_api pronto para execução da chamada.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 2.000 caracteres.

8.3.2 Especificação do Output

  • Formato de output: O output deve ser a resposta da API com status, ids gerados e mensagens de confirmação/erro.
  • Exemplo de Estrutura de Output:
     {
      "status": "string",
      "ids_gerados": [],
      "mensagens": []
    } 
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho estimado de 1.000 caracteres.

8.3.3 Parâmetros de Geração

  • Modelo: Não se aplica (uso de ferramenta)
  • Temperatura: Não se aplica

8.3.4 Ferramentas do Agente

  • Documentos: Executar a requisição conforme parâmetros recebidos e retornar a resposta crua do sistema para registro.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá enviar o JSON recebido para a API do sistema de gestão de planos e retornar a resposta recebida como resposta.

8.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente subsequente.
  • Visibilidade da Resposta: A resposta (status da API) é o entregável final e não é passada para outros agentes internos.

8.3.6 Regras de Orquestração e Transição

A execução deste agente finaliza o fluxo. A resposta da API é o resultado que deve ser disponibilizado ao usuário.

© 2025 prototipe.ai. Todos os direitos reservados.