Investigacao Policial — Skill Operacional para Agentes

FASE 0 — Avaliacao de Volume e Modo de Processamento

Liberdade: RIGIDA — seguir a arvore de decisao. A escolha entre agente unico e multi-agente afeta toda a investigacao.

Antes de qualquer analise, avaliar o volume de documentos para decidir o modo de processamento. Esta fase acontece uma unica vez, no inicio do caso (ou quando novos documentos chegam em volume significativo).

Arvore de decisao

Volume total de paginas/documentos?
|
|-- [< 50 paginas] --> MODO UNICO
|   Pular para Fase 1 diretamente.
|   Processar tudo no contexto do agente principal.
|
|-- [50-200 paginas] --> MODO MULTI (leve)
|   Spawnar 2-3 subagentes extratores em paralelo.
|   Apos consolidacao, spawnar validador.
|
|-- [200+ paginas] --> MODO MULTI (completo)
|   Spawnar 4-6 subagentes extratores em paralelo.
|   Apos consolidacao, spawnar validador.

Se MODO UNICO: pular para Fase 1.

Se MODO MULTI:

Ler references/orquestracao.md para o guia completo de como dividir lotes, formular prompts e consolidar resultados. (NAO carregar no modo unico.)

Ler references/schemas_multiagente.md para os contratos JSON entre agentes. (NAO carregar no modo unico.)

Fluxo resumido:

1. Dividir documentos em lotes tematicos (bancario, provedores, operadoras, judicial, documental, financeiro)
2. Spawnar extratores em paralelo — cada um recebe um lote + o prompt base de agents/extrator.md + contexto do caso. Cada extrator retorna dados estruturados com referencia exata da fonte.
3. Consolidar retornos — unificar todos os dados extraidos, indexar por tipo (IPs, telefones, IMEIs, nomes), sem remover duplicatas (duplicatas entre fontes = convergencia)
4. Executar Fases 1-4 usando dados estruturados — o agente principal trabalha com tabelas, nao com documentos brutos
5. Produzir conclusoes com referencias — cada conclusao herda as referencias exatas dos dados que a sustentam, no schema da secao 3 de references/schemas_multiagente.md
6. Spawnar validador adversarial — envia conclusoes + acesso aos documentos brutos. O validador usa scripts/extrator_verificacao.py para extrair trechos especificos e verificar cada referencia contra a fonte original. Retorna veredicto por conclusao: VERIFICADO / CONTRADITO / AMBIGUO
7. Incorporar feedback do validador — remover conclusoes CONTRADITO, investigar AMBIGUO, manter apenas VERIFICADO no relatorio final

Regra critica: NUNCA relatar conclusoes ao usuario antes de passar pelo validador. A validacao e obrigatoria no modo multi-agente.

Autorizacao de subagentes: ao ativar esta skill em modo multi-agente, o usuario autoriza expressamente o uso de subagentes extratores e validador. Nao e necessario pedir confirmacao adicional — a Fase 0 ja determina quando spawnar. Se o usuario invocar esta skill em modo unico e o volume ultrapassar 50 paginas, spawnar os subagentes diretamente, informando ao usuario o que foi feito.

Trilha de auditoria: no modo multi-agente, registrar todas as acoes de agentes (extracao, analise, validacao) em arquivo de log append-only com hashes encadeados. A legislacao brasileira exige que ferramentas de IA forense sejam verificaveis, auditaveis e replicaveis. Ver secao 7.3 de references/orquestracao.md.

Pensamento critico: Se voce esta no modo multi e algum extrator retornou status "ERRO" ou tem muitas paginas_com_falha, avalie se os dados perdidos podem afetar conclusoes de convergencia. Se sim, re-processar o lote antes de prosseguir.

FASE 1 — Intake e Diagnostico de Status

Liberdade: RIGIDA — seguir o formato exato do painel. O padrao visual garante que qualquer colega consiga ler o status imediatamente.

Ao receber um caso ou quando o usuario pedir status, coletar:

1. Metadados do caso: numero do BO, numero do IP (se existir), tipo penal, quantidade de vitimas, suspeitos conhecidos, data dos fatos

2. Documentos disponiveis: listar tudo que o usuario forneceu

3. Pre-processamento:

   • Modo unico (<50 paginas): rodar o pre-processador diretamente:

     python scripts/pre_processador.py <dir_entrada> <dir_saida>
     

   • Modo multi (50+ paginas): os subagentes extratores da Fase 0 ja processaram os documentos — usar os dados estruturados que eles retornaram

4. Verificacao de OCR — OBRIGATORIA antes de gerar o painel:

   • Apos a extracao de texto (nativo ou via pre-processador), verificar quantas paginas retornaram vazias ou com menos de 80 caracteres
   • Paginas vazias em PDFs de procedimentos policiais sao quase sempre imagens escaneadas (screenshots de WhatsApp, comprovantes, fotos de CFTV, documentos de identidade, NFCs, extratos fotografados)
   • Essas paginas frequentemente contem provas criticas (NFC-e, assinaturas, extratos, imagens de suspeitos) que seriam perdidas sem OCR
   • Se houver paginas vazias: executar OCR com Tesseract (lang=por, 300dpi) usando PyMuPDF para renderizar + pytesseract para reconhecimento
   • Se Tesseract nao estiver instalado: ALERTAR o usuario imediatamente e instalar antes de prosseguir. Comando: winget install UB-Mannheim.TesseractOCR (Windows) ou apt install tesseract-ocr tesseract-ocr-por (Linux)
   • Se o pacote de idioma portugues nao estiver disponivel: baixar de https://github.com/tesseract-ocr/tessdata_best/raw/main/por.traineddata e colocar na pasta tessdata
   • Alternativa ao Poppler no Windows: usar PyMuPDF (fitz) para renderizar paginas em imagem — nao depende de binarios externos
   • Paginas que permanecam ilegiveis apos OCR devem ser marcadas no painel como "IMAGEM SEM TEXTO — VERIFICAR VISUALMENTE" para que o investigador examine manualmente
   • NUNCA pule esta etapa — em caso real (BO 158847/2025), 25 de 67 paginas eram imagens contendo NFC-e, extrato bancario completo, contrato com assinatura da criminosa e comprovantes de deposito

5. Gerar o Painel de Status — este e o produto principal da Fase 1:

═══════════════════════════════════════════════════
  STATUS DA INVESTIGACAO — [BO/IP Nº]
  Crime: [tipo]   Vitimas: [N]   Data do fato: [data]
═══════════════════════════════════════════════════

MATERIALIDADE (o crime aconteceu?):
  [✅/❌] BO registrado
  [✅/❌] Comprovante de transferencia/Pix
  [✅/❌] Conversa WhatsApp completa (extracao forense)
  [✅/❌] Conta destino identificada (banco + agencia + conta)
  [✅/❌] Extrato da conta destino obtido
  [✅/❌] Laudo ou relatorio de materialidade

AUTORIA (quem fez?):
  [✅/❌] IP do WhatsApp obtido (via Meta)
  [✅/❌] IP do banco no momento da transacao
  [✅/❌] IP do TJRN/PJe (se houve acesso indevido)
  [✅/❌] Dados da linha telefonica (titular + IMEI)
  [✅/❌] Cruzamento de IPs convergindo em suspeito
  [✅/❌] Consulta a bancos de dados policiais

PENDENCIAS:
  [lista automatica com o que esta faltando acima]
  [para cada item pendente: o que fazer + urgencia]

O painel funciona como um mapa: mostra onde voce esta e para onde precisa ir. Atualize-o sempre que novas provas chegarem.

Exemplo de painel em andamento (caso real de estelionato por falso advogado):

═══════════════════════════════════════════════════
  STATUS DA INVESTIGACAO — IP 2025/00847
  Crime: Estelionato (art.171 §2-A CP)   Vitimas: 1   Data: 10/03/2025
═══════════════════════════════════════════════════

MATERIALIDADE:
  [✅] BO registrado (BO 2025.001234 — DRCC)
  [✅] Comprovante Pix R$ 47.000 (3 transferencias)
  [🔄] Conversa WhatsApp (screenshots com hash, falta exportacao completa)
  [✅] Conta destino: Bradesco ag 3421 cc 12345-6, titular Jose C. Ferreira
  [⏳] Extrato da conta destino (oficio enviado 12/03, sem resposta)
  [❌] Laudo de materialidade

AUTORIA:
  [✅] IP do WhatsApp obtido (Meta: 187.34.56.78, 10/03 09:15:23 BRT)
  [⏳] IP do banco no momento do Pix (oficio enviado 15/03)
  [✅] IP do PJe (TJRN: 187.34.56.78, 09/03 16:42:11 BRT) — CONVERGENTE
  [⏳] Dados da linha (84) 99876-5432 (oficio Claro enviado 15/03)
  [🔄] Cruzamento de IPs: 2 fontes convergem, falta 3a para robustez
  [❌] Consulta BD policial

PENDENCIAS:
  1. Extrato Bradesco — cobrar resposta (urgencia: CURTO PRAZO)
  2. Resposta Claro IMEI/titular — cobrar (urgencia: CURTO PRAZO)
  3. Exportacao completa WhatsApp — solicitar a vitima (urgencia: IMINENTE)
  4. Consulta INFOSEG do suspeito — executar (urgencia: CURTO PRAZO)

Pensamento critico: Antes de marcar qualquer item como ✅, pergunte-se: "essa prova, isoladamente, sobreviveria a um questionamento da defesa em audiencia?" Se a resposta for "talvez nao", o item e 🔄 (parcial), nao ✅.

FASE 2 — Plano de Coleta de Provas

Liberdade: MEDIA — adaptar as categorias de prova ao tipo de crime. Nem todos os 9 itens se aplicam a todos os casos.

Para cada lacuna no painel de status, indicar exatamente:

• O que coletar
• De quem solicitar
• Como coletar (com cadeia de custodia)
• Urgencia (iminente 24h / curto prazo 15 dias / estrategico)

Ler references/categorias_prova.md para o catalogo completo de 9 categorias de provas digitais (A-I). (NAO carregar na Fase 1 — so quando houver lacunas no painel para preencher.)

Ler references/cadeia_custodia.md para regras de preservacao: hash MD5/SHA256, extracao forense vs. manual, nomenclatura de arquivos. (NAO carregar se o usuario ja tem todas as provas — so quando for coletar novas.)

Ler references/requisitos_judiciais.md para saber se cada dado exige ordem judicial ou pode ser requisitado diretamente. (NAO carregar antes da Fase 2 — so quando for planejar oficios e requisicoes.)

Priorizacao por Risco de Perecimento

Para gerar os oficios de requisicao, usar a skill oficios-policiais.

FASE 3 — Cruzamento de IPs

Liberdade: RIGIDA — campos obrigatorios de IP sao inegociaveis. Um oficio sem segundo e fuso horario e um oficio perdido.

Este e o nucleo tecnico da investigacao digital. O objetivo e cruzar IPs de fontes independentes para encontrar convergencia — o mesmo IP aparecendo em multiplas fontes e indicio forte de autoria. No modo multi-agente, os IPs ja foram extraidos e estruturados pelos subagentes — usar as tabelas indexadas por tipo_dado: "ip" em vez de reler documentos brutos.

Ler references/metodologia_ip.md para o protocolo completo. (NAO carregar nas Fases 1-2 — so quando o usuario tiver dados de IP para cruzar.)

Resumo operacional

1. Reunir todos os IPs disponiveis de cada fonte:

   • Meta/WhatsApp (momento da fraude)
   • Banco (momento da transacao Pix/TED)
   • TJRN/PJe (momento da consulta processual)
   • Operadora (titular do IP)
   • Outros (email, plataformas)

2. Para cada IP, verificar campos obrigatorios: endereco IP, data, hora, minuto, segundo, fuso horario (America/Fortaleza ou UTC)

3. Distinguir tipo de IP — isso muda o procedimento de requisicao:

   • IPv4 sozinho: NAO individualiza o usuario (NAT). Requisitar dados em dois horarios distintos + pedir porta logica
   • IPv4 + porta logica: individualiza. Um horario basta
   • IPv6: individualiza por natureza. Um horario basta

4. Montar a tabela de cruzamento usando templates/tabela_ip_cruzamento.md

5. Marcar convergencia: quando o mesmo IP (ou mesmo bloco/operadora) aparece em fontes diferentes com timestamps proximos, isso e um ponto de convergencia — forte indicio

6. Gerar orientacao para oficios: para cada IP que precisa de identificacao, indicar o que requisitar a operadora (modelo em references/metodologia_ip.md)

Pensamento critico: Antes de marcar convergencia, pergunte-se: "Esse IP poderia ser de WiFi publica (aeroporto, shopping), VPN comercial, rede corporativa, ou NAT de operadora movel (CGNAT)?" Se sim, a convergencia e mais fraca do que parece — buscar corroboracao por IMEI ou biometria.

FASE 3B — Formulacao de Hipoteses Concorrentes

Liberdade: MEDIA — o numero de hipoteses depende do caso, mas minimo 2 e obrigatorio.

Antes de expandir a rede, formular hipoteses concorrentes sobre autoria. Isso evita vies de confirmacao — a tendencia natural de buscar apenas provas que confirmem o primeiro suspeito identificado.

Para cada caso, listar pelo menos 2 hipoteses:

A Fase 4 (expansao) deve buscar provas que testem as hipoteses — nao apenas as que confirmem H1. Se H2 ou H3 forem plausiveis, a expansao deve incluir diligencias que as verifiquem.

FASE 4 — Expansao de Rede e Estabelecimento de Autoria

Liberdade: ALTA em profundidade, RIGIDA em metodologia — o investigador decide quantos passos executar e qual profundidade, mas cada passo segue o protocolo. Nem toda investigacao precisa de todos os 7 passos.

Quando voce ja tem alguns dados e precisa expandir a rede de suspeitos ou confirmar quem e o autor. Usar as hipoteses da Fase 3B para guiar quais dados buscar.

4A — Expansao por Telefone/Pix/IMEI

Ler references/expansao_rede.md para o protocolo completo de 7 passos. (NAO carregar nas Fases 1-3 — so quando tiver dados para expandir.)

Resumo do fluxo de expansao:

Chave Pix destino
    ↓
Todas as chaves Pix da mesma conta
    ↓
Se chave = email → requisitar logs ao provedor (Google/Microsoft)
    ↓
Telefones obtidos
    ↓
Para cada telefone → requisitar IMEI a operadora
    ↓
Para cada IMEI → encontrar TODAS as linhas que usaram esse aparelho
    ↓
Filtrar: pos-pago + linha antiga = maior credibilidade
    ↓
Cruzar modelo do aparelho entre fontes (banco, email, operadora)

A logica e simples: cada dado novo gera mais dados. Uma chave Pix leva a um email, que leva a um telefone, que leva a um IMEI, que leva a outras linhas. E como puxar um fio — a rede se revela.

4B — Modelo de Convergencia de Autoria

Ler references/estabelecimento_autoria.md para criterios detalhados. (NAO carregar antes de ter pelo menos 2 fontes de dados para cruzar.)

Autoria e estabelecida quando fontes independentes convergem no mesmo individuo. Ver diagrama completo e niveis de robustez (1-4+ fontes) em references/estabelecimento_autoria.md.

Operador direto vs. Laranja

• Operador direto: IP no momento do crime vincula inequivocamente a pessoa ao terminal
• Laranja ativo: abriu a conta, forneceu selfie biometrica, manteve a conta ativa, nunca reclamou ao banco sobre uso indevido — presuncao de conivencia

Antes de concluir sobre autoria: sempre consultar bancos de dados policiais e solicitar ao banco o historico de reclamacoes/bloqueios da conta.

Pensamento critico: Antes de concluir sobre autoria, pergunte-se: "Se eu fosse o advogado de defesa desse suspeito, como eu contestaria cada uma dessas evidencias?" Se voce consegue imaginar uma contestacao plausivel para TODAS, a convergencia ainda nao e suficiente.

FASE 5 — Producao de Documentos

Liberdade: RIGIDA — roteamento obrigatorio entre documento operacional e documento formal. A escolha errada produz peca inadequada ao destinatario.

Roteamento: operacional vs. formal

Documento operacional (uso interno, agente para agente):

• Quando: usuario pede "status", "o que falta", "o que temos", "checklist", "tabela de IPs"
• Formato: Markdown — pode ter emojis, paineis, tabelas de status
• Templates: relatorio_diligencias.md, checklist_provas_fraude.md, tabela_ip_cruzamento.md

Relatorio de Missao Policial (documento formal externo — MP, Judiciario, Delegado):

• Quando: usuario pede "relatorio de missao", "relatorio para o MP", "subsidiar o relatorio final", "enviar ao juiz/promotor", "relatorio completo da investigacao", "peça formal"
• Formato: OBRIGATORIAMENTE .docx — NUNCA entregar Markdown como documento final
• Template: templates/relatorio_missao_policial.md
• PROIBIDO no corpo do documento: emojis, icones de status (✅/❌/🔄/⏳), paineis visuais, placeholders como "a complementar", linguagem de dashboard
• OBRIGATORIO: todas as conclusoes de autoria e materialidade devem ser VERIFICADO pelo validador antes de entrar no relatorio

Documentos disponiveis

Geracao de .docx (Relatorio de Missao Policial)

python scripts/gerar_docx_relatorio.py \
  --input relatorio_missao.md \
  --output relatorio_missao_IP<numero>.docx \
  --template assets/template_pcrn_drcc.docx \
  --ip-numero "<Numero do IP>" \
  --footer-text "Rel. Missao — IP n. <Numero>"

Antes de gerar: verificar que todos os dados obrigatorios estao preenchidos (nº IP, agente, matricula, unidade). Se algum estiver ausente, perguntar ao usuario — nunca gerar com placeholder.

Quarentena de narrativas preexistentes

Se existirem relatorios, analises ou rascunhos anteriores sobre o caso (de outra IA, de investigador anterior, ou de fase previa):

1. Identificar afirmacoes de alto impacto: convergencias, atribuicoes de autoria, identificacoes de laranja
2. Para CADA afirmacao: localizar a fonte bruta citada e extrair diretamente (via scripts/extrator_verificacao.py)
3. Classificar:
   • confirmada — bruto sustenta a afirmacao
   • nao_confirmada — bruto nao contem a informacao citada
   • contradita — bruto contem informacao divergente
4. Regra: somente afirmacoes confirmada podem alimentar a consolidacao. As demais sao descartadas e registradas no log de auditoria.

Formato padrao de confronto:

| Afirmacao anterior | Fonte citada | Achado no bruto | Status | Consequencia |
|--------------------|-------------|-----------------|--------|-------------|
| IP X converge em suspeito A e B | relatorio_anterior.md | Bruto mostra A em IP X, B em IP Y | contradita | Remover convergencia falsa |

Validacao antes de relatar (modo multi-agente)

Se estiver no modo multi-agente, TODAS as conclusoes de convergencia e autoria devem ter passado pelo validador adversarial antes de incluir no relatorio de diligencias ou no painel de status. Conclusoes com veredicto CONTRADITO nao podem aparecer em nenhum documento. Conclusoes com veredicto AMBIGUO devem ser marcadas como "pendente de verificacao manual".

Quando encaminhar para o delegado

A investigacao esta madura para o relatorio final quando:

• Materialidade comprovada (todos os itens ✅ no painel)
• Autoria estabelecida por convergencia de pelo menos 3 fontes independentes
• Todas as diligencias criticas executadas
• Nenhum bloqueio pendente

Nesse ponto, usar a skill relatorio-final-ip para a producao do relatorio final com tipificacao penal e fundamentacao juridica.

Arvore de Decisao — Situacoes Comuns

"Tenho um IP mas o provedor nao informou a porta logica"

→ E IPv4? Entao requisite a operadora em dois horarios distintos desse IP. Se o mesmo titular aparecer nos dois, aumenta a confianca. Em paralelo, volte ao provedor (Meta, banco) e pergunte explicitamente: "Informar porta logica/porta de origem dos acessos."

"O IP aponta para um servico de VPN ou proxy"

→ O IP direto e inutilizavel para identificacao do titular. Mude a estrategia: foque em IMEI + linha telefonica (expansao por Pix/telefone), selfie biometrica do banco, e cruzamento de dispositivo (modelo do aparelho em multiplas fontes). A autoria tera que ser construida sem IP.

"A operadora retornou uma lista com dezenas de usuarios para o mesmo IP"

→ Isso e NAT (CGNAT). O IP sozinho nao individualiza. Opcoes: (1) verificar se algum nome da lista aparece em outras provas do caso, (2) requisitar novamente com porta logica se o provedor original tiver, (3) usar outros vetores de investigacao (IMEI, Pix, biometria).

"O suspeito usa aparelhos diferentes para cada acao"

→ Nao dependa do cruzamento de IMEI. Foque em: (1) chaves Pix — todas as chaves da conta destino, (2) IPs — mesmo que de aparelhos diferentes, o suspeito pode usar a mesma rede WiFi/operadora, (3) padroes temporais — acoes em horarios similares sugerem mesma pessoa.

"O titular da conta bancaria alega que foi enganado (laranja passivo)"

→ Verificar: (1) a pessoa registrou BO sobre perda de documentos antes da fraude? (2) solicitou bloqueio da conta antes de ser procurada pela policia? (3) ha indicio de emprego falso ou coacao? Se nenhum desses se aplica, presume-se laranja ativo (conivencia).

"Uma fonte reporta horario em UTC e outra em BRT — como comparar?"

→ Para comparacao cruzada, o agente principal (nao o extrator) normaliza ambos para UTC apenas para fins de calculo de intervalo temporal. Registrar SEMPRE ambos os valores: o original do documento e o normalizado. Exemplo: "Meta: 12:15:23 UTC (= 09:15:23 BRT) | Banco: 09:18:01 BRT → intervalo: 2min38s". Atencao especial para datas anteriores a novembro/2019: o Brasil usava horario de verao (BRST = UTC-2), entao "BRT" pode significar UTC-3 ou UTC-2 dependendo da data.

"O IP retornado pela operadora pertence a uma empresa/rede corporativa"

→ IP corporativo nao individualiza (qualquer funcionario pode ter usado). Opcoes: (1) identificar a empresa titular, (2) requisitar a empresa (via oficio judicial) os logs internos de NAT/proxy para o horario exato, (3) em paralelo, reforcar outros vetores (IMEI, linha, Pix). Se a empresa for de grande porte, o IP corporativo sozinho tem valor probatorio muito baixo.

"Recebi documentos protegidos por senha ou criptografados"

→ O extrator nao consegue processar. Opcoes: (1) solicitar ao orgao remetente a versao sem protecao, (2) se for arquivo apreendido, encaminhar para pericia tecnica para desbloqueio, (3) registrar no painel como ⏳ com nota "aguardando desbloqueio".

"A resposta da Meta/Google veio em ingles"

→ Processar normalmente. Campos comuns: "Access IP", "Last Seen", "Device Type", "Phone Number", "Account Creation Date". O extrator deve preservar o texto original em ingles — nao traduzir. O agente principal interpreta.

"A vitima pode tambem ser suspeita (ex: autofraude, fraude de seguro)"

→ Tratar como hipotese concorrente na Fase 3B (geracao de hipoteses). Manter a coleta de provas neutra — nao assumir inocencia nem culpa da vitima. Coletar provas que possam tanto confirmar quanto refutar a autofraude (ex: geolocalizacao da vitima no momento do fato, historico de reclamacoes).