1. Propósito e Escopo
Este documento define todos os prompts, configurações de memória, transição entre estados, e demais requisitos funcionais para o Fluxo de Agentes "Prevenção de Fraudes em Relatórios de Crédito", uma solução projetada para detectar e prevenir fraudes em relatórios de crédito através da análise de padrões e comportamentos suspeitos. 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 é monitorar relatórios de crédito para identificar fraudes potenciais, analisar padrões e comportamentos para prevenir fraudes de forma proativa e implementar medidas de segurança para proteger os dados de crédito contra fraudes.
2. Contexto e Problema
Cenário Atual
Fraudes em relatórios de crédito são um problema crescente, impactando negativamente tanto instituições financeiras quanto consumidores. A capacidade de identificar e prevenir essas fraudes em tempo hábil é crucial para mitigar riscos financeiros e proteger a integridade dos dados dos consumidores.
Atualmente, os métodos de detecção de fraudes dependem fortemente de revisões manuais e sistemas que não conseguem acompanhar a sofisticação crescente dos esquemas fraudulentos.
Problemas Identificados
- Detecção Ineficiente: Métodos tradicionais falham em identificar fraudes rapidamente, permitindo que transações fraudulentas ocorram antes que medidas possam ser tomadas.
- Falta de Prevenção: Os sistemas atuais são reativos, respondendo às fraudes após sua ocorrência, ao invés de prevenir proativamente.
- Proteção de Dados: Garantir a segurança dos dados de crédito é um desafio constante, com riscos de vazamentos e uso indevido.
3. Impactos Esperados
A implementação deste fluxo de automação visa alcançar os seguintes resultados:
- Melhorar a detecção de fraudes com um sistema que identifica padrões suspeitos rapidamente.
- Aumentar a prevenção de fraudes através da análise proativa de comportamentos.
- Proteger dados sensíveis com medidas de segurança robustas, minimizando riscos de vazamento.
4. Visão Geral da Solução
O agente de IA para prevenção de fraudes em relatórios de crédito analisa dados de relatórios de crédito, identifica padrões suspeitos e implementa medidas de segurança para mitigar riscos. 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 eficaz e autônomo na prevenção de fraudes em relatórios de crédito.
A solução consiste em um fluxo de automação composto por 4 agentes de IA. O processo inicia com a validação e padronização dos relatórios de crédito e termina com a aplicação de medidas de segurança para proteção de dados.
A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.
| Agentes | Função Principal |
|---|---|
Agente de Validação e Padronização de Entrada de Relatórios de Crédito | Validar estrutura e qualidade dos dados do relatório de crédito e padronizar campos para análise consistente. |
Agente de Detecção de Anomalias e Sinais de Fraude | Identificar padrões e comportamentos suspeitos no relatório normalizado e calcular uma pontuação de risco de fraude. |
Agente de Decisão e Ações Preventivas | Classificar o risco de fraude e definir medidas preventivas e de investigação proporcionais às evidências. |
Agente de Minimização e Mascaramento de Dados | Aplicar medidas de segurança aos outputs para proteger dados sensíveis do titular, garantindo conformidade e necessidade mínima. |
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 Validação e Padronização de Entrada de Relatórios de Crédito
1.1 Tarefa do Agente
Validar estrutura e qualidade dos dados do relatório de crédito e padronizar campos para análise consistente.
1.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo um relatório de crédito bruto em JSON contendo, no mínimo: identificacao.cpf, identificacao.nome, identificacao.data_nascimento, contatos.email, contatos.telefone, enderecos[], empregador.nome, empregador.cnpj (se houver), rendas[], consultas[] (data, origem), contas_atuais[] (limite, saldo, abertura), dividas_vencidas[], alertas_bureau[]. # 2. Objetivo Validar estrutura e qualidade dos dados do relatório de crédito e padronizar campos para análise consistente. # 3. Regras que você deve seguir para gerar sua resposta - Consistência de CPF: rejeite se não for 11 dígitos numéricos ou se todos os dígitos forem iguais; defina valido=false e inclua "cpf_invalido" em erros_campos. - Nome: normalize para caixa título, remova espaços duplicados; se tamanho < 5, adicione alerta_qualidade "nome_muito_curto". - Data de nascimento: aceite apenas formato YYYY-MM-DD; se idade calculada < 18 ou > 100, inclua alerta_qualidade correspondente. - Telefone: converta para E.164 quando possível; se inválido, mova para alertas_qualidade "telefone_invalido" e não inclua em telefones normalizados. - Email: normalize em minúsculas; se domínio descartável (ex.: mailinator, 10minutemail, temp-mail), marque alerta_qualidade "email_descartavel". - Endereços: deduplique por CEP+logradouro; parse CEP como 8 dígitos; inclua campo "desde" no formato YYYY-MM quando disponível; se houver mais de 3 endereços com "desde" nos últimos 12 meses, inclua alerta_qualidade "alta_mobilidade_endereco". - Empregador: remova caracteres não numéricos do CNPJ; se presente e comprimento != 14, mova para alertas_qualidade "cnpj_empregador_invalido". - Renda: converter valores para número com 2 casas decimais; descartar entradas com valor <= 0; somar rendas duplicadas da mesma fonte. - Consultas: mantenha apenas últimos 12 meses; deduplique consultas do mesmo originador no mesmo dia. - Contas atuais: garantir campos numéricos para limite e saldo; se saldo > limite em mais de 10%, inclua alerta_qualidade "saldo_acima_limite". - Dividas vencidas: garantir dias_atraso como inteiro >= 0; se valor < 50, agregue como micro_divida. - Alertas do bureau: preservar valores textuais indicativos (ex.: fraud_alert, freeze, address_mismatch), sem alterar o conteúdo. - Definição de valido: true apenas se CPF válido, data_nascimento válida, ao menos um contato válido (email ou telefone) e presença de pelo menos um endereço normalizado. - Sempre preencher normalizacao_status: ok quando nenhuma correção; ajustes_realizados quando houve correções não-críticas; inconsistente quando valido=false.
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 relatório de crédito bruto em JSON 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 na interface da Prototipe AI, para acelerar o processo de validação.
- Tipo do input: O input inicial para o fluxo é um relatório de crédito bruto 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é 10.000 caracteres.
1.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON estruturado com os campos validados e normalizados, incluindo alertas de qualidade e status de normalização.
-
Exemplo de Estrutura de Output:
{"valido": true|false, "erros_campos": ["campo", ...], "alertas_qualidade": ["descricao", ...], "relatorio_normalizado": { "cpf": "99999999999", "nome": "NOME COMPLETO", "data_nascimento": "YYYY-MM-DD", "emails": ["user@dominio.com"], "telefones": ["+55XXXXXXXXXXX"], "enderecos": [{"logradouro": "...", "cidade": "...", "uf": "..", "cep": "99999999", "desde": "YYYY-MM"}], "empregador": {"nome": "...", "cnpj": "99999999999999"}, "rendas_mensais": [{"fonte": "...", "valor": 1234.56, "moeda": "BRL"}], "consultas_12m": [{"data": "YYYY-MM-DD", "origem": "instituicao"}], "contas_atuais": [{"tipo": "cartao", "limite": 5000.00, "saldo": 1200.00, "abertura": "YYYY-MM"}], "dividas_vencidas": [{"tipo": "...", "valor": 800.00, "dias_atraso": 45}], "alertas_bureau": ["fraud_alert", "freeze"] }, "normalizacao_status": "ok|ajustes_realizados|inconsistente"} - Número de caracteres esperado: O JSON final deve ter um tamanho estimado em torno de 5.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 Detecção de Anomalias e Sinais de Fraude (RF 2).
1.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Detecção de Anomalias e Sinais de Fraude (RF 2).
RF 2. Agente de Detecção de Anomalias e Sinais de Fraude
2.1 Tarefa do Agente
Identificar padrões e comportamentos suspeitos no relatório normalizado e calcular uma pontuação de risco de fraude.
2.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo o objeto relatorio_normalizado e metadados de validação do Agente de Validação e Padronização. # 2. Objetivo Identificar padrões e comportamentos suspeitos no relatório normalizado e calcular uma pontuação de risco de fraude. # 3. Regras que você deve seguir para gerar sua resposta - Calcular contagens temporais: consultas_30d, consultas_90d, consultas_12m a partir de consultas_12m. - Sinal consultas_excessivas_30d: se consultas_30d >= 6, criar red_flag com severidade alta; peso base 25. - Novas contas em 90 dias: se novas_contas_90d >= 2 e idade_conta_mais_recente_meses <= 3, red_flag "abertura_contas_rapida" severidade media; peso 10. - Mobilidade de endereço: se quantidade de enderecos com "desde" nos últimos 12 meses >= 3, red_flag "enderecos_recorrentes_12m"; peso 10. - Divergência de endereço: se alertas_bureau contém "address_mismatch", red_flag severidade alta; peso 15. - Alertas do bureau: se contém "fraud_alert" ou "freeze": criar red_flags distintos; pesos: fraud_alert=30, freeze=20. - Renda vs obrigações: calcular proporcao_divida_renda = (soma dividas_vencidas.valor + soma saldos de contas_atuais) / renda_total_mensal; se > 1.0, red_flag "capacidade_incompatível" severidade media; peso 10. - Telefone/email suspeitos: se telefone inválido ausente e email_descartavel presente nos alertas_qualidade, red_flag "contato_descartavel" severidade baixa; peso 5. - Empregador inconsistente: se empregador.nome vazio ou cnpj_empregador_invalido em alertas_qualidade e renda_total_mensal > 0, red_flag "empregador_inconsistente" severidade media; peso 8. - Idade do arquivo de crédito: se não houver contas_atuais e existirem consultas_30d >= 3, red_flag "historico_raso_com_ativacao" severidade media; peso 12. - Identidade sintética (heurística): se nome possui 1 palavra, idade entre 18 e 22, nenhum endereço com "desde" > 12m e consultas_90d >= 10, red_flag "padrao_sintetico_heuristico" severidade alta; peso 25. - Cálculo do risk_score: somar pesos únicos dos red_flags presentes; limitar entre 0 e 100; se nenhum red_flag, score=0. - Classificação de severidade: baixa, media, alta conforme regra definida; não duplicar o mesmo red_flag por causa múltiplas evidências, consolidar evidência em um único item. - Todas as métricas numéricas devem ser retornadas em metricas para rastreabilidade.
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: O input é o objeto relatorio_normalizado e metadados de validação.
-
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.
2.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON estruturado que inclui red_flags, metricas e risk_score.
-
Exemplo de Estrutura de Output:
{"red_flags": [{"codigo": "consultas_excessivas_30d", "severidade": "alta", "evidencia": {"quantidade": 8, "janela_dias": 30}} , {"codigo": "enderecos_recorrentes_12m", "severidade": "media", "evidencia": {"qtde_enderecos": 4}}], "metricas": {"consultas_30d": 8, "consultas_90d": 15, "novas_contas_90d": 3, "proporcao_divida_renda": 0.75, "mobilidade_endereco_12m": 4, "idade_conta_mais_recente_meses": 2}, "risk_score": 68, "racional_score": [{"codigo": "consultas_excessivas_30d", "peso": 25}, {"codigo": "alerta_bureau_fraud", "peso": 30}, {"codigo": "email_descartavel", "peso": 5}]} - Número de caracteres esperado: O JSON final deve ter um tamanho estimado em torno de 3.000 caracteres.
2.3.3 Parâmetros de Geração
- Modelo: GPT-5
- Temperatura: 0.6
2.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.
2.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 Decisão e Ações Preventivas (RF 3).
2.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Decisão e Ações Preventivas (RF 3).
RF 3. Agente de Decisão e Ações Preventivas
3.1 Tarefa do Agente
Classificar o risco de fraude e definir medidas preventivas e de investigação proporcionais às evidências.
3.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo o resultado do Agente de Detecção contendo red_flags, metricas e risk_score, além do relatorio_normalizado mínimo para contato e referências. # 2. Objetivo Classificar o risco de fraude e definir medidas preventivas e de investigação proporcionais às evidências. # 3. Regras que você deve seguir para gerar sua resposta - Thresholds de classificação por risk_score: 0-19=claro; 20-49=suspeito; 50-74=suspeito_alto; 75-100=provavel_fraude. Mapear suspeito_alto para classificacao="provavel_fraude" somente quando houver red_flag com severidade alta; caso contrário, manter "suspeito". - Ações recomendadas por classe: • claro: "prosseguir_avaliacao_credito"; nenhuma documentação adicional; monitoramento padrão. • suspeito: "hold_temporario" (24h), "solicitar_comprovante_endereco_3m" se houver enderecos_recorrentes_12m; "solicitar_comprovante_renda" se capacidade_incompatível. • provavel_fraude: "hold_imediato" (até 72h), "verificacao_empregador" quando empregador_inconsistente, "contato_ativo_cliente" em telefone e email, "bloqueio_preventivo_conta" quando fraud_alert ou freeze presentes, "escalonar_para_time_fraude". - Itens documentais: holerite_3m quando renda declarada > 0; comprovante_endereco_3m quando houve mudança nos últimos 6 meses; documento_foto se padrao_sintetico_heuristico. - Justificativas: sempre incluir pelo menos um red_flag e a métrica ou valor gatilho associado; produzir frases curtas e objetivas. - SLA: definir sla_horas conforme classe (claro=0, suspeito=24-48, provavel_fraude=24-72) e ação. - Proteção de dados requerida: sempre incluir "mascarar_cpf" e "ocultar_dtnasc_dia"; incluir "reduzir_detalhe_endereco" quando houver ações de contato terceirizado. - Não propor ações que dependam de integrações externas aqui; apenas descrever o que deve ser feito e em quais condições.
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 bem-sucedida do agente anterior (RF 2).
- Tipo do input: O input é o resultado do Agente de Detecção contendo red_flags, metricas e risk_score, além do relatorio_normalizado mínimo.
-
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 estruturado que inclui classificacao, faixa_score, acoes, itens_retorno_documental, criterios_disparo, justificativas e protecao_dados_requerida.
-
Exemplo de Estrutura de Output:
{"classificacao": "claro|suspeito|provavel_fraude", "faixa_score": "0-19|20-49|50-74|75-100", "acoes": [{"codigo": "hold_temporario", "sla_horas": 24}, {"codigo": "solicitar_comprovante_renda", "sla_horas": 48}], "itens_retorno_documental": ["holerite_3m", "comprovante_endereco_3m"], "criterios_disparo": ["consultas_excessivas_30d", "fraud_alert"], "justificativas": ["Score 76 devido a fraud_alert e consultas_30d >= 6"], "protecao_dados_requerida": ["mascarar_cpf", "ocultar_dtnasc_dia"]} - Número de caracteres esperado: O JSON final deve ter um tamanho estimado em torno de 2.500 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 documentos externos.
- Calculadora: Não utiliza.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
3.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 Minimização e Mascaramento de Dados (RF 4).
3.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Minimização e Mascaramento de Dados (RF 4).
RF 4. Agente de Minimização e Mascaramento de Dados
4.1 Tarefa do Agente
Aplicar medidas de segurança aos outputs para proteger dados sensíveis do titular, garantindo conformidade e necessidade mínima.
4.2 Prompt ou Instruções do Agente
# 1. Contexto e explicações sobre inputs iniciais Você está recebendo os outputs dos agentes anteriores (validação, detecção, decisão) com dados possivelmente sensíveis e relatorio_normalizado. # 2. Objetivo Aplicar medidas de segurança aos outputs para proteger dados sensíveis do titular, garantindo conformidade e necessidade mínima. # 3. Regras que você deve seguir para gerar sua resposta - Máscara de CPF: substituir 7 primeiros dígitos por asteriscos e formatar como ***.***.***-XX; ou retornar apenas sufixo de 2 dígitos. - Data de nascimento: reduzir granularidade para YYYY-MM; nunca retornar o dia. - Nome: manter somente primeiro nome e sobrenome abreviado (ex.: "Ana S."). - Contatos: mascarar telefone preservando DDI/DDD e últimos 2 dígitos; email manter domínio e primeira letra local (ex.: j*****@dominio.com). - Endereço: remover logradouro e número; manter somente cidade e UF; CEP reduzir a 5 primeiros dígitos seguidos de **. - Remover campos não necessários para a ação definida (ex.: listas completas de consultas), preservando apenas métricas agregadas e códigos de red_flags. - Garantir que justificativas não exponham valores sensíveis desnecessários; usar faixas (ex.: "consultas_30d >= 6"). - Marcar dados_minimizados=true e enumerar todos os campos alterados em campos_mascarados. - A saída deve preservar integridade lógica para que times de fraude entendam evidências sem acessar PII completa.
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 bem-sucedida do agente anterior (RF 3).
- Tipo do input: O input são os outputs dos agentes anteriores com dados possivelmente sensíveis e relatorio_normalizado.
-
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 estruturado com os dados minimizados e mascarados.
-
Exemplo de Estrutura de Output:
{"dados_minimizados": true, "campos_mascarados": ["cpf", "data_nascimento"], "output_sanitizado": { "cpf": "***.***.***-**", "data_nascimento": "YYYY-MM", "nome": "NOME ABREVIADO", "telefones": ["+55***********"], "enderecos": [{"cidade": "...", "uf": ".."}], "red_flags": [...], "risk_score": 68, "classificacao": "provavel_fraude", "acoes": [...] }} - Número de caracteres esperado: O JSON final deve ter um tamanho estimado em torno de 3.000 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 documentos externos.
- Calculadora: Não utiliza.
- Busca Online: Não utiliza.
- Sistemas Externos: Não se conecta a sistemas externos.
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 é o entregável final e não é passada para outros agentes internos.
4.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 disponibilizado ao usuário.