Agente de IA para Auditoria de Transações de Cartões de Crédito

29 de November de 2025 • Tempo de leitura: 5 min

Como criar um agente de IA que revisa transações de cartões de crédito para detectar padrões de fraude.

Biblioteca de Prompts e Agentes

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 um agente de IA que revisa transações de cartões de crédito para detectar padrões de fraude e alertar as equipes de segurança. 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 é garantir que transações fraudulentas não passem despercebidas em grandes volumes de dados, utilizando algoritmos de aprendizado de máquina para identificar padrões de fraude e alertar rapidamente as equipes de segurança.

2. Contexto e Problema

No cenário atual, as transações de cartões de crédito fraudulentas podem facilmente passar despercebidas em meio a grandes volumes de dados. Com a crescente sofisticação dos métodos de fraude, é essencial identificar padrões de fraude de forma eficaz e alertar as equipes de segurança em tempo hábil para que possam tomar as medidas necessárias.

Problemas específicos que o agente precisa resolver incluem:

  • Detecção de transações fraudulentas que podem passar despercebidas em grandes volumes de dados.
  • Identificação de padrões de fraude em transações de cartões de crédito.
  • Necessidade de alertar rapidamente as equipes de segurança para que medidas possam ser tomadas em tempo hábil.

3. Impactos Esperados

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

  • Reduzir o tempo de detecção de fraudes em transações de cartões de crédito.
  • Aumentar a precisão na identificação de padrões de fraude.
  • Proporcionar alertas em tempo real para as equipes de segurança, permitindo uma resposta rápida e eficaz.
  • Adaptar-se a novos padrões de fraude à medida que surgem, melhorando continuamente a capacidade de detecção.

4. Visão Geral da Solução

O agente de IA para auditoria de transações de cartões de crédito analisa grandes volumes de dados em tempo real, utiliza algoritmos de aprendizado de máquina para identificar padrões de fraude e alerta as equipes de segurança em tempo hábil. 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 eficaz e autônomo das transações de cartões de crédito.

A solução consiste em um fluxo de automação composto por 5 agentes de IA. O processo inicia com a preparação do payload das transações e termina com a consolidação de feedbacks para aprendizado contínuo.

A execução dos agentes é sequencial, seguindo a ordem definida na tabela abaixo.

Agentes Função Principal
Agente de Preparação de Payload de Transações (RF 1) Normalizar e enriquecer transações de cartão de crédito, gerando features determinísticas e preparando o payload para scoring de fraude.
Agente de Execução de Chamada à API (Scoring de Fraude) (RF 2) Realizar chamada à API do Sistema de Scoring de Fraude para obter probabilidade/score e explicações por transação.
Agente de Decisão e Classificação de Risco (RF 3) Combinar score do modelo com regras de negócio e sinais heurísticos para decidir ação e priorização de alerta.
Agente de Preparação de Alertas em Tempo Real (RF 4) Formatar e preparar o alerta operacional para roteamento a sistemas externos (SIEM, canal de incidentes, SMS/Email).
Agente de Consolidação para Aprendizado Contínuo (RF 5) Consolidar feedbacks, construir registros rotulados e métricas de drift para adaptação do modelo.

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.

Ver Agente na Prototipe AI

6. Requisitos Funcionais

RF 1. Agente de Preparação de Payload de Transações

1.1 Tarefa do Agente

Normalizar e enriquecer transações de cartão de crédito, gerando features determinísticas e preparando o payload para scoring de fraude.

1.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo transações de cartão de crédito em streaming ou em lote. Essas transações precisam ser normalizadas e enriquecidas para gerar um payload pronto para o sistema de scoring de fraude.

# 2. Objetivo
Normalizar e enriquecer as transações, gerando features determinísticas e preparando o payload para scoring de fraude.

# 3. Regras que você deve seguir para gerar sua resposta
- Normalização de tempo e moeda: Converter timestamp para ISO 8601 UTC (Z). Validar currency em ISO 4217; se inválida, definir como "UNK" e adicionar em data_quality_flags.
- Tipagem e faixas: amount deve ser número > 0; se nulo/negativo, definir amount=0, amount_log=0 e adicionar flag "amount_anomalo". Truncar casas decimais em 2 digitos para amount.
- Derivações temporais determinísticas: hour_of_day=0–23 a partir de UTC; day_of_week=1–7 (1=segunda). Definir fim_de_semana=true se day_of_week∈{6,7} (armazenar apenas se necessário pelo modelo).
- Categorização canônica: merchant_category (MCC) manter string numérica de 4 dígitos; channel ∈ {CNP, CP, NFC, ECOM} senão "OTHER"; country em ISO-3166-1 alpha-2 uppercase; bin manter 6 dígitos se presente, senão "UNK"; last4 manter 4 dígitos, senão omitir.
- Velocidade e frequência: Se historical_snapshot presente, usar txn_counts para definir txn_velocity_1m, txn_velocity_5m, txn_velocity_1h; se ausente, inicializar em 0. Sempre garantir inteiros não negativos.
- Estatísticas de ticket: Se avg_ticket_7d e std_ticket_7d presentes e std>0, calcular amount_zscore_7d=(amount-avg)/std; senão amount_zscore_7d=null e registrar flag "estatisticas_indisponiveis".
- Geolocalização e viagem impossível: Se última posição conhecida e atual existirem, calcular distância geodésica (km) e velocidade implícita=distância/Δt(h). Definir impossible_travel=true se velocidade>900 km/h; se Δt=0, set impossible_travel=false e flag "delta_t_zero". Se faltarem coordenadas, geo_distance_km=null.
- Dispositivo/IP/Comportamento: is_new_device=true se device_id não estiver em trusted_devices; is_new_ip=true se ip não estiver em trusted_ips; is_new_merchant=true se merchant_id não estiver em trusted_merchants. Ausência de listas implica assumir "true" apenas para device/merchant/ip não vistos no evento anterior (se last_txn_time presente), senão false.
- Perfil MCC: mcc_profile_match="high" se MCC ∈ top_mccs; "medium" se categoria relacionada (mesmo primeiro dígito); "low" caso contrário. Ausência de top_mccs ⇒ "unknown" e registrar flag.
- Qualidade de dados: data_quality_flags é lista única sem duplicatas. Incluir flags para: campos críticos ausentes {amount, timestamp, card_id, merchant_id}, ip inválido, currency inválida, MCC inválido, geoloc ausente, estatisticas_indisponiveis.
- Padrões de privacidade: Não incluir PAN; manter apenas bin e last4 quando fornecidos. Remover quaisquer PII não necessárias (nome, endereço).
- Estabilidade de schema: Sempre retornar schema_version. Em lote, produzir array de prepared_payload, preservando ordenação por timestamp ascendente; em empate, por transaction_id lexicográfico.
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 transações de cartão de crédito em streaming ou lote. Na fase de testes, os dados serão enviados manualmente por upload de um arquivo JSON na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: Transações de cartão de crédito em streaming ou lote.
  • Formatos Suportados: JSON por evento ou CSV com colunas mínimas.
  • 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 com o payload preparado para o sistema de scoring de fraude.
  • Exemplo de Estrutura de Output: 
     {"prepared_payload":{"transaction_id":"uuid","event_time":"2025-11-29T09:54:00Z","numerics":{"amount":123.45,"amount_log":4.815,"hour_of_day":9,"day_of_week":6,"txn_velocity_1m":2,"txn_velocity_1h":5,"avg_ticket_7d":87.2,"std_ticket_7d":30.4,"amount_zscore_7d":1.19},"categoricals":{"currency":"BRL","merchant_category":"5411","channel":"CNP","country":"BR","bin":"411111","bin_country":"BR","customer_segment":"gold"},"signals":{"is_new_device":true,"is_new_merchant":false,"is_new_ip":false,"geo_distance_km":742.3,"impossible_travel":true,"ip_risk":"medium","mcc_profile_match":"low","data_quality_flags":[]}},"schema_version":"1.1"}
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho aproximado 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: Utiliza lógica interna para calcular features como amount_log e geo_distance_km.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

1.3.5 Memória

1.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 (Scoring de Fraude) (RF 2).

RF 2. Agente de Execução de Chamada à API (Scoring de Fraude)

2.1 Tarefa do Agente

Realizar chamada à API do Sistema de Scoring de Fraude para obter probabilidade/score e explicações por transação.

2.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON com o payload preparado para scoring de fraude.

# 2. Objetivo
Realizar chamada à API do Sistema de Scoring de Fraude para obter probabilidade/score e explicações por transação.

# 3. Regras que você deve seguir para gerar sua resposta
- Esse agente não precisa de instruções para LLM. Ele apenas executa a chamada à API com o payload recebido e retorna o JSON bruto da resposta.
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 do agente anterior (RF 1).
  • Tipo do input: JSON com o payload preparado.
  • Formatos Suportados: JSON.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 3.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: JSON bruto da resposta do sistema de scoring de fraude.
  • Exemplo de Estrutura de Output: 
     {"transaction_id":"uuid","risk_score":0.87,"risk_band":"high","model_version":"fraud-2025.11","explanations":[{"feature":"impossible_travel","contribution":0.21},{"feature":"txn_velocity_1h","contribution":0.18}],"inference_time_ms":22}
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho aproximado de 500 caracteres.

2.3.3 Parâmetros de Geração

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

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: O agente deverá enviar o JSON recebido para a API de scoring de fraude e retornar o JSON da resposta.

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 Classificação de Risco (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 Classificação de Risco (RF 3).

RF 3. Agente de Decisão e Classificação de Risco

3.1 Tarefa do Agente

Combinar score do modelo com regras de negócio e sinais heurísticos para decidir ação e priorização de alerta.

3.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo um JSON de resposta do scoring por transação.

# 2. Objetivo
Combinar score do modelo com regras de negócio e sinais heurísticos para decidir ação e priorização de alerta.

# 3. Regras que você deve seguir para gerar sua resposta
- Bandas e thresholds: Definir bandas por risk_score: high ≥ 0.85; medium ∈ [0.70,0.85); low < 0.70. Se resposta já trouxer risk_band, priorizar banda calculada localmente em caso de divergência e registrar em audit.
- Sinais fortes: Considerar fortes: impossible_travel=true; amount_zscore_7d ≥ 2.5; txn_velocity_1h ≥ 5; is_new_device=true; is_new_ip=true; mcc_profile_match="low"; ip_risk ∈ {high}; geo_distance_km ≥ 500 com Δt ≤ 2h; canal inabitual (se available) do cliente.
- Ajustes de banda: Se banda=medium e ≥2 sinais fortes ⇒ elevar para high. Se banda=high e há evidências de confiança (merchant whitelisted OU device em trusted + amount_zscore_7d ≤ 1) ⇒ reduzir para medium.
- Decisão por banda: high ⇒ decision=alertar_bloquear; priority=P1; actions.block=temporary; actions.challenge=3DS; notify_customer=sms. medium ⇒ decision=alertar_revisar; priority=P2; actions.challenge=3DS; notify_customer=none. low ⇒ decision=aprovar; priority=P3; sem alerta.
- Explicabilidade: reasons deve listar até 5 causas ordenadas por (contribution das explanations, quando houver) e depois por severidade dos sinais fortes. Incluir texto curto e consistente por motivo.
- Dados ausentes: Se data_quality_flags contiver campos críticos ou estatisticas_indisponiveis, limitar a decisão máxima a medium e exigir challenge=3DS; nunca bloquear direto apenas por ausência de dados.
- Anti-flap: Se a mesma combinação card_id+merchant_id teve decisão P3 nos últimos 10 minutos (quando informação disponível), reduzir uma banda (mínimo low) para evitar falso positivo por rajada de compras do mesmo estabelecimento.
- SLA: P1 ⇒ sla_minutes=5; P2 ⇒ 15; P3 ⇒ 0. Sempre incluir em output.
- Conformidade e trilha: Preencher audit com model_version, rule_pack_version (data atual AAAA-MM-DD) e thresholds aplicados. Não remover explicações do modelo se fornecidas.
- Feedback: Incluir implicitamente que casos P1/P2 requerem feedback humano posterior no sistema de gestão (campo não obrigatório no output, mas justifica a Consolidação posterior).
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: JSON de resposta do scoring por transação.
  • Formatos Suportados: JSON.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 3.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: JSON com a decisão de risco e ações propostas.
  • Exemplo de Estrutura de Output: 
     {"transaction_id":"uuid","decision":"alertar_bloquear","risk_score":0.87,"risk_band":"high","priority":"P1","reasons":["impossible_travel","alto desvio do ticket 7d","MCC fora do perfil"],"actions":{"block":"temporary","challenge":"3DS","notify_customer":"sms"},"sla_minutes":5,"audit":{"model_version":"fraud-2025.11","rule_pack_version":"2025-11-29","thresholds":{"high":0.85,"medium":0.7}}}
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho aproximado de 1.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 documentos externos.
  • Calculadora: Utiliza lógica interna para aplicar regras de decisão e classificação de risco.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

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 Preparação de Alertas em Tempo Real (RF 4).

RF 4. Agente de Preparação de Alertas em Tempo Real

4.1 Tarefa do Agente

Formatar e preparar o alerta operacional para roteamento a sistemas externos (SIEM, canal de incidentes, SMS/Email).

4.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo uma decisão por transação que precisa ser transformada em um alerta operacional.

# 2. Objetivo
Formatar e preparar o alerta operacional para roteamento a sistemas externos.

# 3. Regras que você deve seguir para gerar sua resposta
- Disparo: Gerar alerta quando decision ∈ {alertar_bloquear, alertar_revisar} OU priority ∈ {P1,P2}. P3 não gera alerta.
- Deduplicação determinística: dedup_key = "fraud:" + (transaction_id se disponível senão card_id + ":" + merchant_id). Em lote, aplicar janela de 5 minutos para ignorar duplicatas com mesma dedup_key.
- Roteamento por prioridade: P1 ⇒ channels=[siem,slack,email]; P2 ⇒ [siem,slack]; Incluir team="Segurança de Pagamentos" sempre. severity: P1 ⇒ critical; P2 ⇒ high.
- Conteúdo mínimo obrigatório: title, severity, priority, timestamp (UTC now), routing, dedup_key, body com reasons ordenadas e proposed_actions, audit herdado da decisão e sla em minutos.
- Sanitização: Não incluir PII sensível; evitar campos como ip se política exigir. Se necessário, mascarar ip como /24.
- Latência: Preparar alerta em ≤ 50 ms após a decisão. Preservar ordering por transaction_id quando presente.
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: Decisão por transação.
  • Formatos Suportados: JSON.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 1.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: JSON formatado para alerta operacional.
  • Exemplo de Estrutura de Output: 
     {"alert":{"id":"evt-uuid","title":"Fraude suspeita: P1 • transaction_id=uuid","severity":"critical","priority":"P1","timestamp":"2025-11-29T09:54:05Z","routing":{"team":"Segurança de Pagamentos","channels":["siem","slack","email"]},"dedup_key":"fraud:uuid","body":{"transaction_id":"uuid","risk_score":0.87,"risk_band":"high","reasons":["impossible_travel","new_device"],"proposed_actions":{"block":"temporary","challenge":"3DS","notify_customer":"sms"},"audit":{"model_version":"fraud-2025.11","rule_pack_version":"2025-11-29"}},"sla":{"minutes":5}}
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho aproximado de 1.200 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: Utiliza lógica interna para formatação e roteamento do alerta.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Após o processamento, esta saída deve ser enviada para: SIEM corporativo, canal Slack/Teams de Segurança de Pagamentos, Email/SMS para on-call conforme prioridade.

4.3.5 Memória

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

Ao concluir sua execução, esse agente aciona o Agente de Consolidação para Aprendizado Contínuo (RF 5).

RF 5. Agente de Consolidação para Aprendizado Contínuo

5.1 Tarefa do Agente

Consolidar feedbacks, construir registros rotulados e métricas de drift para adaptação do modelo.

5.2 Prompt ou Instruções do Agente 
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo decisões emitidas e feedback humano/sistema para consolidação.

# 2. Objetivo
Consolidar feedbacks, construir registros rotulados e métricas de drift para adaptação do modelo.

# 3. Regras que você deve seguir para gerar sua resposta
- Registros rotulados: Criar training_records somente quando label ∈ {fraude_confirmada, falso_positivo}. Se label=pendente, descartar da base de treino e manter fora das métricas de performance.
- Digest de features: features_digest deve ser um resumo determinístico (ex.: hash estável) do conjunto de features usadas na decisão, sem PII. Nunca incluir PAN, ip completo ou dados sensíveis crus.
- Métricas de drift: Calcular PSI por feature-chave (amount_log, txn_velocity_1h, amount_zscore_7d, mcc_profile_match) comparando janela recente (últimos 7 dias) vs baseline. Sinalizar drift quando PSI>0.2.
- Performance por banda: A partir de labels recebidas nos últimos 30 dias, calcular precisão e recall por risk_band; priorizar amostra mínima de 100 eventos por banda antes de exibir métricas.
- Recomendação de re-treino: Se algum PSI>0.2 ou se recall(high)<0.75 por 7 dias consecutivos, emitir retraining_recommendation com trigger e suggested_action.
- Governança: Remover identificadores diretos de cliente; manter apenas transaction_id, timestamps e hashes de features. Garantir consistência temporal (event_time ISO UTC).
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: JSON com decisões emitidas e feedback humano/sistema.
  • Formatos Suportados: JSON.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de até 2.000 caracteres.

5.3.2 Especificação do Output

  • Formato de output: JSON com registros rotulados e métricas de drift.
  • Exemplo de Estrutura de Output: 
     {"training_records":[{"transaction_id":"uuid","label":"fraude_confirmada","features_digest":"hash","event_time":"2025-11-29T09:54:00Z"}],"drift_metrics":{"population_stability_index":{"amount_log":0.12,"txn_velocity_1h":0.08},"performance_by_band":{"high":{"precision":0.92,"recall":0.81},"medium":{"precision":0.74,"recall":0.55}}},"retraining_recommendation":{"trigger":"psi_threshold","details":"PSI acima do limite em amount_log","suggested_action":"re-rotular e re-treinar"}}
  • Número de caracteres esperado: O JSON gerado deve ter um tamanho aproximado de 1.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 documentos externos.
  • Calculadora: Utiliza lógica interna para calcular métricas de drift e performance.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Após gerar training_records e drift_metrics, enviar os artefatos para o bucket/warehouse de MLOps e abrir ticket no backlog de Data Science quando retraining_recommendation.suggested_action estiver presente.

5.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 finaliza o fluxo e não é passada para outros agentes internos.

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

A execução deste agente finaliza o fluxo. Os registros e métricas gerados devem ser disponibilizados para o time de Data Science.

Posts Relacionados

© 2025 prototipe.ai. Todos os direitos reservados.