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 e demais requisitos funcionais para o Fluxo de Agentes "Detecção de Fraudes em Relatórios de Crédito", uma solução de automação projetada para identificar padrões suspeitos e potenciais fraudes em relatórios de crédito. 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 é transformar o input de relatórios de crédito em uma análise detalhada que identifica atividades anômalas e fornece alertas imediatos sobre potenciais fraudes para ação rápida.
2. Contexto e Problema
Cenário Atual
A presença de fraudes em relatórios de crédito compromete a integridade dos dados e aumenta os riscos financeiros. Atualmente, a identificação de padrões suspeitos é lenta, o que aumenta a vulnerabilidade a fraudes e perdas financeiras.
Problemas Identificados
- Integridade dos dados: Relatórios de crédito fraudulentos comprometem a qualidade dos dados financeiros.
- Identificação rápida: A necessidade de identificar padrões suspeitos rapidamente é crucial para mitigar riscos.
- Risco financeiro: Fraudes não detectadas podem resultar em significativas perdas financeiras.
3. Impactos Esperados
A implementação deste fluxo de automação visa alcançar os seguintes resultados:
- Reduzir o tempo de identificação de fraudes em relatórios de crédito.
- Aumentar a precisão na detecção de padrões suspeitos.
- Mitigar riscos financeiros através de alertas imediatos sobre potenciais fraudes.
4. Visão Geral da Solução
O agente de IA para detecção de fraudes em relatórios de crédito processa dados de relatórios de crédito, aplica algoritmos de detecção de fraude e prepara alertas imediatos sobre potenciais fraudes. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um assistente útil e autônomo na identificação de fraudes em relatórios de crédito.
A solução consiste em um fluxo de automação composto por 3 agentes de IA. O processo inicia com a extração de conteúdo dos relatórios de crédito e termina com a geração de um sumário de risco acionável.
A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.
| Agentes | Função Principal |
|---|---|
Agente de Execução de Extração de Conteúdo do Documento (RF 1)
| Executar a extração do conteúdo bruto e metadados de relatórios de crédito. |
Agente de Padronização do Relatório de Crédito (RF 2)
| Transformar o conteúdo bruto em um JSON padronizado e normalizado. |
Agente de Detecção de Fraudes em Relatórios de Crédito (RF 3)
| Avaliar o JSON padronizado para identificar padrões suspeitos e potenciais fraudes. |
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 Execução de Extração de Conteúdo do Documento
1.1 Tarefa do Agente
Executar a extração do conteúdo bruto e metadados de relatórios de crédito recebidos (PDF, imagem ou planilha), sem interpretação, para uso por agentes posteriores.
1.2 Prompt ou Instruções do Agente
Esse agente não precisa de instruções para LLM. Sua única função é executar a extração de conteúdo bruto com os parâmetros recebidos e retornar exatamente o payload especificado sem interpretar dados.
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 um arquivo de relatório de crédito 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 arquivo na interface da Prototipe AI, para acelerar o processo de validação.
- Tipo do input: O input inicial para o fluxo é um arquivo de relatório de crédito.
-
Formatos Suportados: Esse agente deve ser capaz de receber arquivos nos formatos:
.pdf,.png,.jpg,.jpeg,.csv,.xlsx. - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 90.000 caracteres.
1.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON estruturado contendo o conteúdo bruto e metadados do relatório de crédito.
-
Exemplo de Estrutura de Output:
{"mime_type":"string","num_paginas":0,"content_raw":"string com texto concatenado","pages":[{"page":1,"text":"string"}],"tables_csv":[{"name":"tabela_1","csv":"string"}],"images_meta":[{"page":1,"bbox":"x,y,w,h","caption":"string"}],"file_metadata":{"filename":"string","filesize_bytes":0}} - Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 1.000 caracteres, variando conforme o tamanho do relatório de crédito processado.
1.3.3 Parâmetros de Geração
- Modelo: Não se aplica (execução de extração)
- Temperatura: Não se aplica
1.3.4 Ferramentas do Agente
- Documentos: Não consulta.
- 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.
- Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Padronização do Relatório de Crédito (RF 2).
1.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Padronização do Relatório de Crédito (RF 2).
RF 2. Agente de Padronização do Relatório de Crédito
2.1 Tarefa do Agente
Transformar o conteúdo bruto do relatório de crédito em um JSON padronizado e normalizado, pronto para análise de fraude.
2.2 Prompt ou Instruções do Agente
Regra 1 (Mapeamento de Seções): Detecte variações semânticas dos títulos e mapeie: Dados Cadastrais→identificacao; Endereços→enderecos; Telefones→telefones; Obrigações/Contas→contas; Consultas/Inquiries→consultas; Registros Públicos→registros_publicos; Disputas/Contestações→disputas; Score/Scoring→scores. Regra 2 (Normalização de Datas): Converta datas para YYYY-MM-DD; quando houver apenas mês/ano, use YYYY-MM e deixe dia como 01 somente se necessário para consistência do tipo. Para campos de mês (ex.: abertura, desde) use sempre YYYY-MM. Regra 3 (Monetários e Percentuais): Converta valores monetários para número decimal em ponto, sem símbolo e sem separador de milhar. Converta percentuais para número 0–100 (sem %). Se valor ausente, defina 0. Regra 4 (Documento e Tipo de Pessoa): Identifique e normalize documento: para PF, CPF com 11 dígitos (somente números); para PJ, CNPJ com 14 dígitos. Defina tipo_pessoa com base no documento identificado; se ambíguo, infira por campos semânticos (ex.: Razão Social indica PJ). Regra 5 (Deduplicação): Remova duplicatas exatas de telefones e endereços; mantenha a instância mais completa (com datas/UF/CEP). Telefone: normalize para E.164 simplificado (+55 opcional) e use apenas números para comparação. Regra 6 (Contas): Para cada conta, preencha campos ausentes com valores padrão (string vazia/0). Se limite e saldo coexistirem, calcule utilizacao_percentual=safe_div(saldo_atual,limite)*100 com arredondamento a 1 casa decimal. Se limite=0 e status ativa, mantenha utilizacao_percentual=0. Regra 7 (Consultas): Normalize finalidade para um dos valores de domínio; se não reconhecer, use "outros". Agrupe consultas idênticas no mesmo dia pela mesma origem mantendo apenas 1. Regra 8 (Registros Públicos): Normalize tipos para o domínio fechado; se informar valores, capture em valor_env (numérico) e detalhes em detalhe (string curta). Regra 9 (Scores): Se múltiplas menções a score, selecione o mais recente por data_score. Faixa permanece "0-1000" por padrão. Regra 10 (Campos Ausentes): Sempre retorne todas as chaves do schema; quando a informação não existir, retorne tipos vazios coerentes (listas vazias, 0, string vazia). Não omita chaves. Regra 11 (Renda): Se houver renda declarada, extraia para renda_mensal_declarada (numérico). Se ausente, defina 0. Regra 12 (Integridade Mínima): Defina metadados_extracao com fonte_arquivo (filename), num_paginas e data_processamento (data atual no formato YYYY-MM-DD). Regra 13 (Lotes): Se o conteúdo corresponder a múltiplos relatórios no mesmo arquivo, retorne um JSON por relatório em chamadas subsequentes, mantendo o mesmo schema e ordem.
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 como input um JSON estruturado contendo o conteúdo bruto e metadados do relatório de crédito.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 6.000 caracteres.
2.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON padronizado e normalizado, pronto para análise de fraude.
-
Exemplo de Estrutura de Output:
{"identificacao":{"nome":"string","documento":"string","data_nascimento_ou_constituicao":"YYYY-MM-DD","tipo_pessoa":"PF|PJ","renda_mensal_declarada":0},"enderecos":[{"logradouro":"string","cidade":"string","uf":"string","cep":"string","desde":"YYYY-MM"}],"telefones":[{"numero":"string","tipo":"fixo|movel","desde":"YYYY-MM"}],"contas":[{"instituicao":"string","tipo_conta":"cartao|emprestimo|financiamento|outros","abertura":"YYYY-MM","limite_ou_valor_original":0,"saldo_atual":0,"utilizacao_percentual":0,"status":"ativa|encerrada|em_atraso","dias_atraso_max":0,"pagamentos_em_atraso_12m":0}],"consultas":[{"origem":"string","finalidade":"credito_cartao|emprestimo|outros","data":"YYYY-MM-DD"}],"registros_publicos":[{"tipo":"protesto|acao_judicial|falencia|recuperacao","data":"YYYY-MM-DD","detalhe":"string","valor_env":0}],"disputas":[{"secao":"string","data":"YYYY-MM-DD","status":"aberta|fechada","resultado":"procedente|improcedente|parcial"}],"scores":{"score_principal":0,"faixa":"0-1000","data_score":"YYYY-MM-DD"},"metadados_extracao":{"fonte_arquivo":"string","num_paginas":0,"data_processamento":"YYYY-MM-DD"}} - Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 2.500 caracteres, variando de acordo com o número e a complexidade dos dados processados.
2.3.3 Parâmetros de Geração
- Modelo: GPT-5
- Temperatura: 0.6
2.3.4 Ferramentas do Agente
- Documentos: Não consulta.
- Calculadora: Não utiliza.
- Busca Online: Não utiliza.
- Sistemas Externos: Não utiliza.
2.3.5 Memória
- Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente.
- Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Detecção de Fraudes em Relatórios de Crédito (RF 3).
2.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Detecção de Fraudes em Relatórios de Crédito (RF 3).
RF 3. Agente de Detecção de Fraudes em Relatórios de Crédito
3.1 Tarefa do Agente
Avaliar o JSON padronizado do relatório de crédito para identificar padrões suspeitos, atividades anômalas e potenciais fraudes, gerando um sumário de risco acionável.
3.2 Prompt ou Instruções do Agente
Regra 1 (Consistência Cadastral): Sinalize inconsistencias_documento quando documento não atende ao padrão (CPF 11 dígitos; CNPJ 14). Liste mismatch_dados_cadastrais quando: (a) nomes divergirem substancialmente entre seções; (b) data_nascimento/constituição conflitar entre seções por > 1 ano; (c) tipo_pessoa inferido contradizer estrutura do documento. Regra 2 (Identidade Sintética): Marque padrao_sintetico quando coexistirem pelo menos 2 dos critérios: (i) todos os telefones e endereços com desde < 6 meses; (ii) ≥ 3 endereços novos em ≤ 12 meses; (iii) ausência de histórico de contas com abertura > 12 meses e presença de consultas recentes intensas (ver Regra 3). Regra 3 (Pico de Consultas): Calcule consultas_7d e consultas_30d. Marque pico_consultas_7d se consultas_7d ≥ 5 OU (consultas_30d ≥ 10 e pelo menos 60% com a mesma finalidade ou mesma origem). Registre no racional as datas e origens dominantes. Regra 4 (Aberturas Recentes): Marque muitas_contas_recente_90d quando contas com abertura nos últimos 90 dias ≥ 3. Se ≥ 2 forem do mesmo tipo_conta, reforce a severidade desse sinal no racional. Regra 5 (Utilização Anômala): Marque utilizacao_anomala quando: (a) média de utilizacao_percentual de cartões > 85% por 2 meses consecutivos (quando houver histórico mensal), ou (b) saldo_atual > limite_ou_valor_original em qualquer conta de cartão, ou (c) se histórico < 6 meses, use limiar > 75%. Regra 6 (Atrasos e Encerramentos): Marque encerramentos_subitos se ≥ 2 contas encerradas nos últimos 60 dias e não houver histórico de longos atrasos prévio (dias_atraso_max < 30 anteriormente). Marque saltos_atraso_incompativeis quando aumento de dias_atraso_max > 60 em ≤ 60 dias. Regra 7 (Endereços/Telefones): Marque muitos_enderecos_12m se enderecos com desde nos últimos 12 meses ≥ 3. Marque telefone_compartilhado_multi_perfis quando um telefone sem histórico (desde < 3 meses) aparece em consultas repetidas (≥ 3) de diferentes origens em ≤ 30 dias. Regra 8 (Registros Públicos): Marque protestos_recente_90d quando existir protesto com data ≤ 90 dias. Marque acao_judicial_incompativel_renda quando existirem ações de insolvência/falência e renda_mensal_declarada=0 OU quando valor_env de registros públicos elevado (soma ≥ 5× renda_mensal_declarada) coexistir com aberturas recentes. Regra 9 (Disputas): Marque uso_abusivo_contestacoes quando número de disputas nos últimos 6 meses ≥ 2. Marque padrao_contestacao_seletiva quando as disputas incidirem apenas sobre itens de alto valor recorrente enquanto outros itens semelhantes não são contestados. Regra 10 (Cascata por Instituição): Marque cascata_aberturas_mesma_instituicao quando houver (a) ≥ 2 contas novas da mesma instituição em ≤ 30 dias ou (b) consultas da mesma instituição > 3 em 7 dias. Regra 11 (Cálculo de Score de Risco): Converta sinais em pesos: crítico=25 (pico_consultas_7d, padrao_sintetico, acao_judicial_incompativel_renda), alto=15 (muitas_contas_recente_90d, utilizacao_anomala, protestos_recente_90d, cascata_aberturas_mesma_instituicao), moderado=8 (encerramentos_subitos, muitos_enderecos_12m, telefone_compartilhado_multi_perfis), baixo=3 (mismatch_dados_cadastrais não críticos). Some pesos únicos por sinal verdadeiro (sem duplicar por ocorrências). Classifique nivel_alerta: critico (≥ 70), alto (50–69), moderado (30–49), baixo (< 30). Principais_sinais: liste até 3 sinais com maior contribuição. Regra 12 (Racional e Referências): Em racional_analitico, cite explicitamente as chaves e índices dos arrays usados (ex.: consultas[2], contas[0]) e o motivo da marcação com o valor observado e o limiar aplicado. Regra 13 (Recomendações de Ação): Para nivel_alerta critico/alto: inclua pelo menos 3 ações entre: verificação reforçada de identidade (selfie + documento), comprovante de endereço recente, validação com instituições que consultaram, redução temporária de limite, contato ativo com cliente. Moderado: monitorar + solicitar documentação complementar específica. Baixo: monitoramento passivo. Regra 14 (Dados Incompletos): Quando campos essenciais estiverem vazios (ex.: ausência de consultas), não marque sinais dependentes desses campos. Não estime valores. Registre no racional a limitação de dados. Regra 15 (Timestamp e Versão): Preencha metadados.timestamp_analise no formato ISO 8601 UTC (YYYY-MM-DDTHH:MM:SSZ) e versao_regras="1.1".
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 como input um JSON padronizado e normalizado do relatório de crédito.
-
Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato:
.json(JSON). - Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 6.000 caracteres.
3.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON contendo o sumário de risco acionável e os sinais de detecção de fraude.
-
Exemplo de Estrutura de Output:
{"resumo_risco":{"score_risco":0.0,"nivel_alerta":"critico|alto|moderado|baixo","principais_sinais":["string"]},"sinais_deteccao":{"identidade":{"inconsistencias_documento":false,"padrao_sintetico":false,"mismatch_dados_cadastrais":["string"]},"comportamento_credito":{"pico_consultas_7d":false,"muitas_contas_recente_90d":false,"utilizacao_anomala":false,"cascata_aberturas_mesma_instituicao":false},"historico_pagamento":{"saltos_atraso_incompativeis":false,"encerramentos_subitos":false},"enderecos_telefones":{"muitos_enderecos_12m":false,"telefone_compartilhado_multi_perfis":false},"registros_publicos":{"protestos_recente_90d":false,"acao_judicial_incompativel_renda":false},"disputas":{"uso_abusivo_contestacoes":false,"padrao_contestacao_seletiva":false}},"racional_analitico":"Texto explicando o porquê de cada sinal marcado com referências a seções do input.","recomendacoes":["string"],"metadados":{"versao_regras":"1.1","timestamp_analise":"YYYY-MM-DDTHH:MM:SSZ"}} - Número de caracteres esperado: O JSON gerado terá um tamanho aproximado de 3.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: Após realizar o processamento, o agente enviará sua resposta para a fila de Alertas do Time de Risco (ex.: sistema de case management/CRM interno). Esse envio deve ser configurado manualmente na interface do fluxo na plataforma da Prototipe AI.
3.3.5 Memória
- Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente.
- Visibilidade da Resposta: A resposta gerada é o entregável final e não é passada para outros agentes internos.
3.3.6 Regras de Orquestração e Transição
A execução deste agente finaliza o fluxo. O JSON gerado é o resultado que deve ser enviado para a fila de alertas do time de risco.