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 "Controle de Uso de Vale-Transporte". 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 o uso dos vales-transporte pelos usuários, detectando padrões de uso e possíveis fraudes, e fornecer relatórios regulares para auxiliar na tomada de decisões.
2. Contexto e Problema
Cenário Atual
Atualmente, as empresas enfrentam desafios significativos em relação à visibilidade do uso dos vales-transporte pelos usuários. A falta de monitoramento eficaz e a dificuldade em detectar fraudes no uso dos vales são problemas críticos que precisam ser resolvidos para garantir a eficiência operacional e a integridade dos processos de transporte.
Problemas Identificados
- Falta de visibilidade: Não há um sistema eficiente para monitorar o uso dos vales-transporte, o que dificulta o rastreamento de padrões de uso.
- Dificuldade em detectar fraudes: A ausência de um mecanismo automatizado para identificar e alertar sobre possíveis fraudes compromete a segurança e o uso adequado dos recursos.
3. Impactos Esperados
A implementação deste fluxo de automação visa alcançar os seguintes resultados:
- Aumentar a visibilidade sobre o uso dos vales-transporte pelos usuários, permitindo um monitoramento contínuo.
- Detectar e prevenir fraudes de forma eficaz, gerando alertas para as partes responsáveis.
- Fornecer relatórios regulares sobre o uso dos vales para auxiliar na tomada de decisões estratégicas.
4. Visão Geral da Solução
O agente de IA para controle de uso de vale-transporte monitora continuamente o uso dos vales, detecta padrões de uso e possíveis fraudes, e fornece relatórios regulares para auxiliar na tomada de decisõ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 assistente útil e autônomo na gestão de vale-transporte.
A solução consiste em um fluxo de automação composto por 6 agentes de IA. O processo inicia com a execução de consultas em banco de dados e termina com a geração de relatórios periódicos de uso e fraude.
A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.
| Agentes | Função Principal |
|---|---|
Agente de Execução de Consultas em Banco de Dados (RF 1)
| Realizar conexão com o sistema de bilhetagem/ERP de VT para obter dados de uso de vale-transporte. |
Agente de Normalização e Qualidade de Dados (RF 2)
| Padronizar o schema das transações, corrigir inconsistências simples e produzir um resumo de qualidade de dados. |
Agente de Engenharia de Atributos e Perfil de Uso (RF 3)
| Construir o perfil de uso por usuário e métricas agregadas para detecção de anomalias. |
Agente de Detecção de Anomalias e Suspeita de Fraude (RF 4)
| Aplicar regras de negócio e limiares para classificar transações e usuários com suspeita de fraude. |
Agente de Preparação de Alertas e Roteamento (RF 5)
| Consolidar suspeitas em alertas por responsável e preparar payloads para notificação ou integração. |
Agente de Relatórios Periódicos de Uso e Fraude (RF 6)
| Gerar relatórios regulares sobre o uso do vale-transporte e sobre detecções de possíveis 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 Consultas em Banco de Dados
1.1 Tarefa do Agente
Realizar conexão com o sistema de bilhetagem/ERP de VT para obter dados de uso (validações) de vale-transporte em um período definido.
1.2 Prompt ou Instruções do Agente
Este agente não necessita de instruções de LLM. Sua única função é executar a consulta ao banco/fonte oficial e retornar os dados brutos conforme o schema indicado no expected_output.
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 parâmetros de consulta 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 de um arquivo na interface da Prototipe AI, para acelerar o processo de validação.
- Tipo do input: Parâmetros de consulta 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 até 5.000 caracteres.
1.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON contendo os dados brutos das transações de vale-transporte.
-
Exemplo de Estrutura de Output:
{ "transacoes": [ { "transacao_id": "string", "usuario_id": "string", "data_hora_validacao": "ISO-8601", "linha": "string", "modalidade": "string", "municipio": "string", "estacao_ou_ponto": "string", "sentido": "ida|volta|nao_informado", "valor_tarifa": "number", "dispositivo_id": "string", "latitude": "number|opcional", "longitude": "number|opcional" } ], "metadata_origem": { "fonte": "nome_sistema", "periodo_consultado": { "inicio": "YYYY-MM-DD", "fim": "YYYY-MM-DD" }, "total_registros": "number" } } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 10.000 caracteres.
1.3.3 Parâmetros de Geração
- Modelo: Não se aplica
- Temperatura: Não se aplica
1.3.4 Ferramentas do Agente
- Documentos: Não consulta documentos externos.
- Calculadora: Não utiliza.
- Busca Online: Não utiliza.
- Sistemas Externos: Conecta-se ao sistema de bilhetagem/ERP de VT para obter dados.
1.3.5 Memória
- Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
- Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Normalização e Qualidade de Dados (RF 2).
1.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Normalização e Qualidade de Dados (RF 2).
RF 2. Agente de Normalização e Qualidade de Dados
2.1 Tarefa do Agente
Padronizar o schema das transações, corrigir inconsistências simples e produzir um resumo de qualidade de dados pronto para análise.
2.2 Prompt ou Instruções do Agente
Converta todos os timestamps para timezone America/Sao_Paulo e gere data_hora_validacao_local em ISO-8601. Descarte registros sem usuario_id, transacao_id ou data_hora_validacao. Deduplice por chave composta [transacao_id] e, quando ausente, por [usuario_id + data_hora_validacao_local + dispositivo_id]. Normalize modalidade para o conjunto: onibus, metro, trem, ferry, BRT, outros; se não mapeável, use 'desconhecida'. Derive dia_da_semana (1=segunda) e hora (HH:MM) a partir de data_hora_validacao_local. Preencha sentido como 'nao_informado' se ausente. Arredonde valor_tarifa para 2 casas decimais; valores negativos devem ser descartados. Se latitude/longitude fora de faixa válida (lat<-90|>90 ou lng<-180|>180), defina como null. Gere o relatório de qualidade preenchendo contagens e percentuais com base no total_entrada.
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: Este agente deve ser apto a receber como input um JSON contendo dados brutos das transações de vale-transporte.
-
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 até 10.000 caracteres.
2.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON contendo as transações normalizadas e um resumo de qualidade de dados.
-
Exemplo de Estrutura de Output:
{ "transacoes_normalizadas": [ { "transacao_id": "string", "usuario_id": "string", "data_hora_validacao_local": "ISO-8601", "dia_da_semana": "1-7 (1=segunda)", "hora": "HH:MM", "linha": "string", "modalidade": "enum[onibus,metro,trem,ferry,BRT,outros,desconhecida]", "municipio": "string", "estacao_ou_ponto": "string", "sentido": "ida|volta|nao_informado", "valor_tarifa": "number", "dispositivo_id": "string", "geo": { "lat": "number|null", "lng": "number|null" } } ], "qualidade_dados_resumo": { "total_entrada": "number", "total_saidas": "number", "registros_descartados": { "motivo_campos_essenciais_ausentes": "number", "motivo_data_invalida": "number", "motivo_duplicidade": "number" }, "percentual_campos_faltantes_por_campo": { "linha": "number", "modalidade": "number", "municipio": "number", "estacao_ou_ponto": "number", "sentido": "number", "valor_tarifa": "number", "dispositivo_id": "number" } } } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 15.000 caracteres.
2.3.3 Parâmetros de Geração
- Modelo: Não se aplica
- Temperatura: Não se aplica
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 não são visíveis para agentes subsequentes.
- Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Engenharia de Atributos e Perfil de Uso (RF 3).
2.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Engenharia de Atributos e Perfil de Uso (RF 3).
RF 3. Agente de Engenharia de Atributos e Perfil de Uso
3.1 Tarefa do Agente
Construir o perfil de uso por usuário e métricas agregadas necessárias para detecção de anomalias.
3.2 Prompt ou Instruções do Agente
Calcule estatísticas de baseline utilizando a janela dos últimos N dias (janela_baseline_dias). Considere como dia útil os dias_da_semana 1 a 5; fim de semana 6 e 7. Para horas médias, converta HH:MM para minutos, calcule a média e reconverta para HH:MM. Rotas frequentes são pares [linha, modalidade, municipio] com frequência relativa >= 5% das validações do usuário na janela. Janelas horárias habituais são intervalos contínuos de 60 minutos com pelo menos 30% das validações do usuário nos dias indicados. Preencha uso_medio_por_dia com a contagem de validações por data do período analisado.
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 contendo transações normalizadas e um resumo de qualidade de dados.
-
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 até 15.000 caracteres.
3.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON contendo o perfil de uso dos usuários e métricas agregadas.
-
Exemplo de Estrutura de Output:
{ "perfil_usuarios": [ { "usuario_id": "string", "estatisticas_uso": { "media_validacoes_por_dia_util": "number", "desvpad_validacoes_por_dia_util": "number", "media_validacoes_fim_semana": "number", "hora_primeira_validacao_media": "HH:MM", "hora_ultima_validacao_media": "HH:MM" }, "rotas_frequentes": [ { "linha": "string", "modalidade": "string", "municipio": "string", "frequencia": "number" } ], "janelas_horarias_habituais": [ { "inicio": "HH:MM", "fim": "HH:MM", "dias_da_semana": [1, 2, 3, 4, 5] } ], "uso_medio_por_dia": [ { "data": "YYYY-MM-DD", "validacoes": "number", "e_fim_de_semana": "boolean" } ] } ], "metricas_globais": { "usuarios_total": "number", "validacoes_total": "number", "media_validacoes_por_usuario_no_periodo": "number" } } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 20.000 caracteres.
3.3.3 Parâmetros de Geração
- Modelo: Não se aplica
- Temperatura: Não se aplica
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 não são visíveis para agentes subsequentes.
- Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Detecção de Anomalias e Suspeita de Fraude (RF 4).
3.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 Suspeita de Fraude (RF 4).
RF 4. Agente de Detecção de Anomalias e Suspeita de Fraude
4.1 Tarefa do Agente
Aplicar regras de negócio e limiares para classificar transações e usuários com suspeita de fraude.
4.2 Prompt ou Instruções do Agente
Uso geograficamente impossível: duas validações do mesmo usuário com diferença < janela_minutos_conflito_temporal e distância em linha reta > min_distancia_km_para_conflito_temporal; score base 90; severidade 'alta' ou 'critica' se distância > 80 km. Uso simultâneo improvável: validações em dispositivos diferentes com diferença <= 5 minutos e municípios distintos; score base 80. Uso fora de expediente: validações antes de horario_trabalho_inicio - 30min ou após horario_trabalho_fim + 30min em dias úteis; score proporcional ao tempo fora (máximo 75). Uso excessivo em fim de semana quando politica_permite_fim_de_semana=false: se validações no dia > limite_validacoes_dia_nao_util; score 70. Pico anormal de uso: validações no dia > média_dia_util + limiar_desvio_uso_diario*desvpad; score entre 60 e 85 conforme gravidade. Desvio de rota: validações em linha/modalidade que não constem nas rotas_frequentes do perfil e representem >20% das validações do dia; score 65. Compartilhamento de cartão (padrão): múltiplas validações consecutivas com intervalo < 2 minutos em locais diferentes na mesma linha ou dispositivos distintos; score 75. Mapeie score_risco para severidade: 0-49=baixa, 50-69=media, 70-84=alta, 85-100=critica. Cada suspeita deve incluir ao menos uma evidência com números concretos (datas, horários, distâncias, contagens) e a lista de transacao_id impactadas. Recomende ação objetiva conforme severidade: baixa=monitorar, media=revisar em 72h, alta=notificar RH/compliance e congelar recargas preventivamente, critica=bloqueio temporário e auditoria imediata. Inclua data_referencia como a data do evento principal gerador da suspeita.
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 como input um JSON contendo o perfil de uso dos usuários e métricas agregadas.
-
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 até 20.000 caracteres.
4.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON contendo as suspeitas de fraude e um resumo.
-
Exemplo de Estrutura de Output:
{ "suspeitas": [ { "usuario_id": "string", "tipo": "enum[uso_simultaneo_improvavel, compartilhamento_cartao, uso_fora_expediente, uso_excessivo_fds, desvio_rota, pico_anormal_uso, uso_geograficamente_impossivel]", "score_risco": 0, "severidade": "baixa|media|alta|critica", "evidencias": [ "string explicativa curta com valores observados e limiares aplicados" ], "registros_relacionados": ["transacao_id", "transacao_id"], "data_referencia": "YYYY-MM-DD", "recomendacao_acao": "string curta e objetiva" } ], "resumo": { "total_suspeitas": "number", "usuarios_unicos_sinalizados": "number", "tipos_mais_comuns": [ { "tipo": "string", "quantidade": "number" } ] } } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 25.000 caracteres.
4.3.3 Parâmetros de Geração
- Modelo: Não se aplica
- Temperatura: Não se aplica
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 não são visíveis para agentes subsequentes.
- Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Preparação de Alertas e Roteamento (RF 5).
4.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Preparação de Alertas e Roteamento (RF 5).
RF 5. Agente de Preparação de Alertas e Roteamento
5.1 Tarefa do Agente
Consolidar suspeitas em alertas por responsável e preparar payloads para notificação ou integração.
5.2 Prompt ou Instruções do Agente
Agrupe suspeitas por destinatário com base no tipo de ação recomendada e na severidade. Somente inclua em alertas suspeitas com score >= limiar_score_envio. Para cada alerta, calcule score_maximo como o maior score entre as suspeitas agregadas. Monte mensagem_resumo contendo: tipo(s) predominante(s), quantidade de usuários e severidade. Defina sla_horas igual ao configurado para o destino; se não houver, use 24h para 'alta' e 4h para 'critica'. Gere um alerta_id único por agrupamento e referencie as suspeitas incluídas.
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 como input um JSON contendo as suspeitas de fraude e um resumo.
-
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 até 25.000 caracteres.
5.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON contendo os alertas preparados para notificação ou integração.
-
Exemplo de Estrutura de Output:
{ "alertas": [ { "alerta_id": "string", "destinatario_tipo": "RH|Compliance|Gestor_Unidade|Usuario", "severidade": "baixa|media|alta|critica", "score_maximo": "number", "usuarios_afetados": ["usuario_id"], "suspeitas_ids": ["derivado ou hash de evidencias"], "mensagem_resumo": "string curta", "payload": { "detalhes": "objeto com suspeitas agregadas e recomendações", "anexos": ["opcional"] }, "sla_horas": "number" } ], "contadores": { "total_alertas_gerados": "number", "por_destinatario": { "RH": "number", "Compliance": "number", "Gestor_Unidade": "number", "Usuario": "number" } } } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 30.000 caracteres.
5.3.3 Parâmetros de Geração
- Modelo: Não se aplica
- Temperatura: Não se aplica
5.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.
5.3.5 Memória
- Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
- Visibilidade da Resposta: A resposta gerada por este agente deve ser visível para o Agente de Relatórios Periódicos de Uso e Fraude (RF 6).
5.3.6 Regras de Orquestração e Transição
Ao concluir sua execução, esse agente aciona o Agente de Relatórios Periódicos de Uso e Fraude (RF 6).
RF 6. Agente de Relatórios Periódicos de Uso e Fraude
6.1 Tarefa do Agente
Gerar relatórios regulares sobre o uso do vale-transporte e sobre detecções de possíveis fraudes para apoiar a tomada de decisão.
6.2 Prompt ou Instruções do Agente
Calcule KPIs no período informado, considerando apenas transações e suspeitas dentro do intervalo. Taxa_fim_de_semana = validações em sábados e domingos / validações totais. Top tipos de suspeita por percentual relativo ao total de suspeitas no período. Ranking de risco ordenado por maior_score desc, depois por qtd_suspeitas. Se o volume de linhas detalhadas exceder 5.000, inclua relatorio_detalhado_csv_base64 com colunas essenciais (usuario_id, data, tipo_suspeita, score, evidencias_resumidas).
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 como input um JSON contendo transações normalizadas e suspeitas de fraude.
-
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 até 30.000 caracteres.
6.3.2 Especificação do Output
- Formato de output: O output deve ser um JSON contendo o relatório resumo e, opcionalmente, o relatório detalhado em base64.
-
Exemplo de Estrutura de Output:
{ "relatorio_resumo": { "periodo": { "inicio": "YYYY-MM-DD", "fim": "YYYY-MM-DD" }, "kpis": { "validacoes_totais": "number", "usuarios_ativos": "number", "media_validacoes_por_usuario": "number", "taxa_fim_de_semana": "number", "suspeitas_geradas": "number", "usuarios_sinalizados": "number", "top_tipos_suspeita": [ { "tipo": "string", "percentual": "number" } ] }, "tendencias": [ { "data": "YYYY-MM-DD", "validacoes": "number", "suspeitas": "number" } ], "ranking_risco_usuarios": [ { "usuario_id": "string", "maior_score": "number", "qtd_suspeitas": "number" } ] }, "relatorio_detalhado_csv_base64": "string|opcional" } - Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 35.000 caracteres.
6.3.3 Parâmetros de Geração
- Modelo: Não se aplica
- Temperatura: Não se aplica
6.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.
6.3.5 Memória
- Visibilidade das Instruções (Prompt): As instruções não são visíveis para agentes subsequentes.
- Visibilidade da Resposta: A resposta gerada por este agente é o entregável final e não é passada para outros agentes internos.
6.3.6 Regras de Orquestração e Transição
A execução deste agente finaliza o fluxo. O relatório gerado é o resultado que deve ser disponibilizado ao usuário.