🔒 Uso Interno
Playbook — Agente Pericial Ejzenberg
Atualizado: 06/04/2026 · Confidencial

Guia de Implantação
Agente de IA Pericial

Documento interno de referência para construção e deploy do agente RAG com base documental de 70GB — fotos, PDFs, emails e processos judiciais.

70GB de documentação
4 formatos de arquivo
Dify + Claude + Qdrant
4 semanas de implementação
4 Semanas
R$600 Setup mín.
R$350 Op. mensal
Diagnóstico de Entrada

Como tratar cada formato

Os 70GB chegam em 4 formatos distintos. Cada um exige extração diferente — usar a ferramenta errada compromete a qualidade do agente.

⚠️ Passo zero obrigatório antes de indexar
Fazer piloto com amostras de cada formato (5 fotos, 5 PDFs, 3 emails, 1 processo) antes de processar os 70GB completos. Se a extração for ruim, o agente é ruim — independente do LLM escolhido.
📷
Fotos
Conteúdo Cenas, veículos, obras, incêndios, plantas fotografadas
Desafio Conteúdo visual — não tem texto para extrair diretamente
Ferramenta Claude Vision API
Output Descrição técnica indexável da cena
Custo ~R$0,05 por foto
📄
PDFs
Conteúdo Laudos, normas ABNT/CTB, jurisprudências, contratos
Desafio Mix de digital e escaneado no mesmo arquivo
Ferramenta LlamaParse
Output Texto com estrutura preservada (títulos, quesitos, tabelas)
Custo R$1,70 por 1.000 páginas
📧
Emails
Conteúdo Comunicações com advogados, clientes, juízo
Desafio Contexto fragmentado em threads + anexos embutidos
Ferramenta Python mailparser
Output Thread completa + anexos processados separadamente
Custo Grátis (processamento local)
⚖️
Processos Judiciais
Conteúdo Petições, decisões, laudos de outros peritos, depoimentos
Desafio 500+ páginas heterogêneas num único PDF
Ferramenta LlamaParse + segmentador
Output Cada peça processual separada com tipo identificado
Custo ~R$0,50 por processo de 200 pág.
Decisão Técnica

Stack escolhida e por quê

Cada ferramenta tem uma função específica. Nenhuma é substituível sem impacto no sistema.

Plataforma RAG
Dify (self-hosted)
Feito para base documental grande. Interface de upload pronta. Conecta qualquer LLM. Dados ficam no nosso servidor.
LLM
Claude Sonnet 4.6
200k tokens de contexto. Melhor do mercado para texto técnico-jurídico longo. Segue instruções com precisão.
Visão
Claude Vision API
Analisa fotos periciais, extrai informações de cenas e texto visível em imagens digitalizadas.
Extração PDF
LlamaParse
Especializado em RAG. Preserva estrutura de laudos: títulos, quesitos, tabelas, seções. Muito superior ao PyMuPDF para este caso.
Vector Store
Qdrant (self-hosted)
Aguenta milhões de chunks. Self-hosted no Railway, gratuito. Busca semântica em milissegundos mesmo em escala.
Embeddings
OpenAI text-embedding-3-large
Melhor precisão para texto técnico. Custo de indexação: ~R$80 para os 70GB completos (pago uma vez).
Storage
Cloudflare R2
70GB por R$6/mês. Sem custo de saída de dados. Armazena os originais intocados.
Infraestrutura
Railway
Hospeda Dify + Qdrant + fila de processamento. Deploy simples, ~R$200/mês para tudo.
Plano Mestre

Estratégia completa — ferramentas, custos e Claude

Cada etapa com a ferramenta exata, custo real por cenário e o quanto o Claude Code executa. Da extração dos documentos até o agente em produção.

Etapas
7
4 semanas máximo
Setup Cenário A · 1 GB
R$10–25
+ R$180–420 /mês
Setup Cenário B · 70 GB
R$580–1.380
+ R$261–511 /mês
Etapa Ferramentas Custo A · 1GB Custo B · 70GB Claude Code
0
Piloto de Extração
Testar os 4 formatos com amostras reais antes de processar tudo
Nós · 1 dia
Claude Vision API LlamaParse Python mailparser
R$ 2–5
amostras apenas
R$ 10–30
amostras apenas
85%
1
Organização dos Documentos
Separar por área antes de indexar
Sergio + Nós · A: 2h / B: vários dias
Google Drive OneDrive HD Externo Script bulk rename
R$ 0
trabalho manual
R$ 0
trabalho manual
20%
2
Infraestrutura
Subir servidores e configurar toda a stack
Nós · Semana 1
Cloudflare R2 Railway Qdrant Redis PostgreSQL BullMQ
R$ 0
free tiers
R$ 0
free tiers
70%
3
Pipeline de Ingestão
Extração → chunking → embedding → indexação
Nós · Semana 1–2
LlamaParse Claude Vision API OpenAI text-embedding-3-large Python asyncio
R$ 8–20
custo de API real
R$ 500–1.280
custo de API real
90%
4
Ingestão dos Dados
Pipeline roda em background — sem ação humana
Automático · A: 1–2 dias / B: 3–7 dias
Pipeline automático Qdrant PostgreSQL
—
incluso no step 3
—
incluso no step 3
10%
5
Agente + Prompts por Área
Busca em 2 camadas + templates de laudo para 5 áreas
Nós + Sergio · Semana 3
Dify Claude Sonnet 4.6 Templates por área Entrevista estruturada
uso mensal
Claude API
uso mensal
Claude API
75%
6
Interface + Testes com Casos Reais
Frontend completo + export Word/PDF + 10 testes reais
Nós + Sergio · Semana 4
HTML/CSS frontend Dify API python-docx WeasyPrint (PDF)
—
dev incluso
—
dev incluso
95%
Claude Code executa
~70%
do projeto completo
O que exige presença humana obrigatória:
✦ Classificação manual dos documentos por área (Sergio/Nós)
✦ Entrevista por área para definir templates de laudo (Sergio)
✦ Aprovação de recursos no Railway e Cloudflare (cliques)
✦ Validação técnica pericial nos 10 testes finais (Sergio)
✦ Feedback de qualidade por ciclo de refinamento (Sergio)
Implantação

Sequência de execução

Ordem que minimiza risco e permite uso parcial desde a semana 2.

0
Piloto de extração
1 dia
Nós
Antes de qualquer infraestrutura, testar a extração com amostras reais. Se a qualidade não for boa, ajustar a ferramenta antes de processar 70GB.
✓
5 fotos representativas → Claude Vision → avaliar descrição gerada
✓
5 PDFs (digital + escaneado) → LlamaParse → checar estrutura preservada
✓
3 threads de email → mailparser → checar contexto e anexos
✓
1 processo judicial completo → ver se peças são separadas corretamente
!
Só avançar se os resultados forem satisfatórios
1
Organização dos documentos
2–3 dias
Sergio + Nós
Os 70GB precisam estar organizados em pastas por área antes de indexar. Metadados corretos = busca precisa depois.
✓
/fotos/acidentes · /fotos/incendios · /fotos/construcao · /fotos/industrial
✓
/laudos-proprios/[por área]
✓
/processos/[por ano ou cliente]
✓
/emails/[por assunto ou parte]
✓
/normas-legislacao/[ABNT · CTB · NRs · etc]
2
Infraestrutura
Semana 1
Nós
Subir toda a infra antes de começar a ingestão. A fila de processamento garante que tudo roda em background sem travar.
✓
Cloudflare R2: bucket criado, credenciais configuradas
✓
Railway: servidor com Dify + Qdrant + Redis + BullMQ
✓
PostgreSQL: banco de metadados dos documentos
✓
Pipeline de ingestão: script de upload → extração → chunking → embedding → indexação
✓
Dashboard de progresso: Sergio acompanha quantos documentos foram indexados
3
Ingestão dos 70GB
Semana 2 · 3–7 dias rodando
Automático
O pipeline processa em background continuamente. Começa pelos laudos próprios — que são os mais valiosos para o agente. Sistema já é utilizável com parcial indexado.
✓
Prioridade 1: laudos próprios do Sergio (base do conhecimento)
✓
Prioridade 2: normas e legislação (fundamentação)
✓
Prioridade 3: processos judiciais
✓
Prioridade 4: emails e comunicações
✓
Prioridade 5: fotos (mais pesadas, processadas por último)
4
Agente e prompts
Semana 3
Nós
Configurar a busca em 2 camadas e criar os prompts por área. Esta é a etapa que define a qualidade do laudo gerado.
✓
Busca camada 1: filtro por metadados (área + tipo + data)
✓
Busca camada 2: semântica nos chunks filtrados → top 20 relevantes
✓
Prompt base: persona do Sergio, regras, limites, formato
✓
Templates por área: acidente · incêndio · construção civil · industrial · cargas
✓
Geração: caso descrito → busca → rascunho de laudo estruturado
✓
Export: Word editável + PDF formatado com cabeçalho do Sergio
5
Interface e testes com casos reais
Semana 4
Nós + Sergio
Interface limpa para uso diário. Sergio testa com casos reais e corrige o que o agente errar — cada correção melhora o prompt.
✓
Tela de upload: arrasta pasta → indexação automática
✓
Tela de novo laudo: área + descrição do caso (texto ou voz)
✓
Tela de resultado: laudo editável + botão exportar
✓
Testar 10 casos reais do Sergio antes de considerar pronto
!
Cada erro do agente = ajuste de prompt, não de infraestrutura
Construção do Agente

Como criar o agente — passo a passo completo

Ferramenta escolhida, como instalar, como alimentar com os documentos e como configurar o comportamento pericial. Cada etapa com custo, prazo e dificuldade.

1. Qual ferramenta usar para o agente
Dify ESCOLHIDO
Interface visual, self-hosted, RAG nativo, suporta Qdrant, exporta API pronta. Claude escreve os configs, você só clica.
Open source · Deploy: Railway · R$ 0
Flowise
Mais simples, menos recursos. Sem Knowledge Base nativo com Qdrant. Descartado.
LangChain
Máxima flexibilidade, mas exige Python completo. Manutenção alta. Descartado fase 1.
N8N
Ótimo para automações laterais. Não é voltado para RAG com base vetorial grande.
2. Sequência de criação no Dify — A até H
A
Deploy do Dify no Railway
2–4h Nós · Claude 95% Custo: R$ 0
Claude gera o docker-compose com todos os serviços. Você aprova no painel do Railway e acessa o Dify via URL gerada.
✓ Ferramenta: Railway + Docker (Dify self-hosted)
✓ docker-compose: dify-api · dify-worker · dify-web · PostgreSQL · Redis
✓ Variáveis: SECRET_KEY · DATABASE_URL · REDIS_URL · storage R2
✓ Apontar storage para Cloudflare R2 (documentos fora do servidor)
✓ Acessar painel Dify via URL Railway → criar conta admin
⚠ Dificuldade Média — vários serviços simultâneos, Railway simplifica
Skills necessárias
Docker Railway CLI YAML / env vars Cloudflare R2
Custo mensal Railway: R$ 80–120
B
Configurar o modelo de IA (Claude Sonnet 4.6)
30min Nós · Claude 80% Custo: R$ 0
Dentro do Dify, configurar Claude Sonnet 4.6 como modelo principal e OpenAI text-embedding-3-large para indexação dos documentos.
✓ Ferramenta: Painel Dify → Settings → Model Provider → Anthropic
✓ Inserir Anthropic API Key (console.anthropic.com)
✓ Modelo padrão: claude-sonnet-4-6
✓ Embedding: OpenAI text-embedding-3-large (inserir OpenAI API Key)
✓ Testar conexão com ambas as APIs antes de avançar
Skills necessárias
Painel Dify API Keys Anthropic API Keys OpenAI
Custo mensal uso: R$ 100–300
C
Conectar o Qdrant como vector store
1–2h Nós · Claude 85% Custo: R$ 0
Qdrant faz a busca semântica nos documentos. Self-hosted no Railway garante confidencialidade dos dados periciais.
✓ Ferramenta: Qdrant (container Railway) + Dify Settings → Vector Store
✓ Claude gera docker-compose do Qdrant com persistência de dados
✓ Dify: Settings → Vector Store → Qdrant → URL + API key
✓ Criar coleções por área: acidentes · incendios · construcao · industrial · cargas
✓ Testar busca com 10 documentos de teste
⚠ Dificuldade Média — rede entre containers no Railway exige atenção
Skills necessárias
Qdrant CLI Docker networking Dify Vector Store Docker volumes
D
Criar as Knowledge Bases (bases de conhecimento)
1 dia Nós · Claude 70% 1GB: R$2 · 70GB: R$80
Uma Knowledge Base por área pericial. A busca é cirúrgica — não mistura acidente com incêndio. O custo aqui é o embedding dos documentos.
✓ Ferramenta: Dify → Knowledge → New Knowledge
✓ 5 bases: Acidentes · Incêndios · Construção Civil · Industrial · Cargas
✓ Chunking: 512 tokens · overlap 50 tokens
✓ Indexação: Automatic (OpenAI Embeddings via API)
✓ Upload dos documentos pré-processados pelo pipeline
⚠ Custo de embedding acontece aqui: R$2 (1GB) ou R$80 (70GB)
Skills necessárias
Dify Knowledge Chunking / indexação Upload em lote
E
Criar a Application (Chatflow com RAG)
2–3h Nós · Claude 85% Custo: R$ 0
Dify Chatflow controla exatamente como o contexto dos documentos é montado antes de ir pro Claude. Melhor que chatbot simples para uso pericial.
✓ Ferramenta: Dify → Studio → Create App → Chatflow
✓ Entrada: dropdown área pericial + campo descrição do caso
✓ Knowledge Retrieval: base da área selecionada · Top-K: 20 · Score mín: 0.6
✓ LLM: Claude Sonnet 4.6 recebe contexto + input do Sergio
✓ Saída: laudo em Markdown → Word/PDF pela interface
✓ Publicar: Dify gera URL + API endpoint
Skills necessárias
Dify Chatflow Design de fluxos Blocos RAG Dify API endpoint
F
Escrever o System Prompt pericial
4–8h · iterativo Nós + Sergio · Claude 75% Custo: R$ 0
O system prompt define o comportamento do agente. A qualidade do laudo depende 80% daqui. Claude escreve o rascunho, Sergio valida e corrige. Uma sessão de 2h por área pericial.
✓ Ferramenta: Dify → bloco LLM → System Prompt
✓ Persona: "Você é o assistente pericial do Eng. Sergio Ejzenberg, M.Sc, CREA 0600493..."
✓ Regras: estrutura obrigatória (objeto · metodologia · análise · conclusão · quesitos)
✓ Limites: "Nunca afirme fatos não presentes nos documentos. Cite sempre a fonte."
✓ Template por área: acidente tem campos diferentes de incêndio
⚠ Esta é a etapa de maior valor — aqui entra o conhecimento pericial do Sergio
Skills necessárias
Prompt Engineering Entrevista estruturada Linguagem pericial Templates por área
G
Configurar retrieval e testar busca
1–2h Nós · Claude 80% Custo: R$ 1–2
Ajustar Top-K, score mínimo e busca híbrida. Top-K alto = contexto longo (caro). Baixo = perde referências. Testar com queries reais antes de usar com o Sergio.
✓ Ferramenta: Dify → Knowledge → Testing
✓ Parâmetros iniciais: Top-K = 20 · Score mín = 0.6 · Max tokens = 8.000
✓ Testar 10 queries reais: ver se os chunks certos voltam
✓ Ajustar score se resultados irrelevantes aparecerem (0.7 ou 0.75)
✓ Busca híbrida (semântica + keyword): ativar para nomes e números de processo
Skills necessárias
Dify Knowledge Testing RAG: Top-K / Score Análise de chunks Busca híbrida
H
Testar com 10 casos reais do Sergio
3–5 dias Sergio + Nós · ciclos Custo: R$ 5–15
Sergio usa o agente em casos que ele já tem a resposta certa. Compara o laudo gerado com o laudo real. Cada diferença vira ajuste de prompt. Esse ciclo é o que faz o agente se tornar "pericial" de verdade.
✓ Ferramenta: Interface do agente + Dify Logs
✓ Ciclo 1: 10 casos → anotar erros → Claude ajusta system prompt
✓ Ciclo 2: 10 casos diferentes → erros menores → ajustes finos
✓ Ciclo 3: aprovação final do Sergio → agente calibrado
⚠ Regra: erros de conteúdo = ajuste de prompt. Erros de busca = ajuste de retrieval. Nunca mexer nos dois ao mesmo tempo.
Skills necessárias
Avaliação pericial (Sergio) Dify Logs Iteração de prompts Ciclos de feedback
Etapas
8
A até H
Prazo
~3 sem
com testes Sergio
Criação · 1GB
R$10–25
APIs de ingestão
Criação · 70GB
R$580–1.380
APIs de ingestão
Financeiro

Dois cenários — Sergio escolhe

Mesma stack, mesma segurança, volumes diferentes. O custo de uso mensal (Claude API) é idêntico nos dois — o que muda é o setup inicial e a infra de storage.

Cenário A — 1 GB
Piloto com documentação principal e recente
Entrada
Setup inicial
Pago uma vez
LlamaParse — ingestão PDFs/processos R$ 5–15
Claude Vision — processamento fotos R$ 3–8
OpenAI Embeddings — indexação 1GB R$ 2
Desenvolvimento (4 semanas) —
Total Setup R$ 10–25
Operação mensal
Recorrente
Cloudflare R2 (1GB storage) R$ 0 (free tier)
Railway (instância menor) R$ 80–120
Claude API (uso diário do Sergio) R$ 100–300
OpenAI Embeddings (novos docs) R$ 0,50
Total Mensal R$ 180–420
Cenário B — 70 GB
Acervo histórico completo — 30 anos de casos
Completo
Setup inicial
Pago uma vez
LlamaParse — ingestão PDFs/processos R$ 300–800
Claude Vision — processamento fotos R$ 200–500
OpenAI Embeddings — indexação 70GB R$ 80
Desenvolvimento (4 semanas) —
Total Setup R$ 580–1.380
Operação mensal
Recorrente
Cloudflare R2 (70GB storage) R$ 6
Railway (Dify + Qdrant + Redis) R$ 150–200
Claude API (uso diário do Sergio) R$ 100–300
OpenAI Embeddings (novos docs) R$ 5
Total Mensal R$ 261–511
Por que o mensal não cai tanto?
O Claude API depende de quanto o Sergio usa, não de quanto está armazenado. Armazenar 1GB ou 70GB não muda o custo de conversa — só o que ele consegue pesquisar muda.
Recomendação
Começar com Cenário A usando os 30 casos mais recentes. Se o agente provar valor, expandir para o Cenário B — a infraestrutura é a mesma, só adiciona mais dados.
Ação Imediata

O que fazer agora

Três passos para começar antes da próxima reunião com o Sergio.

Passo 1 · Nós
Rodar o piloto de extração
Pedir ao Sergio amostras representativas de cada formato — 5 fotos, 5 PDFs (digital + escaneado), 3 emails, 1 processo. Rodar o pipeline e avaliar a qualidade.
→ Define se LlamaParse é suficiente ou precisa de Textract
Passo 2 · Sergio
Organizar os 70GB em pastas
Separar os documentos por área (acidente, incêndio, construção, industrial) e tipo (laudos próprios, processos, normas, emails). Sem organização, a busca perde precisão.
→ Pode ser feito em paralelo com o passo 1
Passo 3 · Nós
Levantar os 10 quesitos mais comuns
Por área, quais são os quesitos que o Sergio mais responde? Isso vira o backbone dos templates de prompt e define a estrutura de cada tipo de laudo.
→ Entrevistar o Sergio ou analisar laudos anteriores
Análise de Esforço

Dificuldade por etapa e o que o Claude faz

Para cada etapa: nível de dificuldade técnica, quanto o Claude executa sozinho e o que precisa de nós.

Etapa Dificuldade Claude faz sozinho Observação
Piloto de extração Testar os 4 formatos com amostras
● Fácil
Claude Code executa 85%
Escreve os scripts de extração, chama as APIs, gera relatório de qualidade. Só precisa das amostras em mãos.
Organização dos documentos Estruturar pastas dos 70GB
● Fácil
Claude Code executa 20%
Ação manual do Sergio. Claude pode criar script de renomeação e organização em lote, mas o conteúdo precisa ser classificado por quem conhece os casos.
Infraestrutura (Railway + R2 + Qdrant) Subir os servidores e configurar
● Médio
Claude Code executa 70%
Escreve todos os arquivos de configuração, Dockerfiles, variáveis de ambiente. Precisa de aprovação manual no painel do Railway e Cloudflare para criar os recursos.
Pipeline de ingestão Extração → chunking → embedding → Qdrant
● Médio
Claude Code executa 90%
Escreve o pipeline completo em Python. A complexidade está no tratamento de erros e na fila assíncrona — que Claude resolve bem. Monitoramento de qualidade precisa de revisão humana.
Ingestão dos 70GB Rodar o pipeline em produção
● Fácil
Claude Code executa 10%
É tempo de máquina, não trabalho técnico. O pipeline roda sozinho por dias. Claude monitora logs e corrige erros pontuais que aparecerem.
Agente + prompts por área Busca em 2 camadas + templates de laudo
● Difícil
Claude Code executa 75%
A lógica de busca e integração Claude faz. Os templates de laudo por área precisam da expertise do Sergio para definir estrutura, seções obrigatórias e tom correto.
Interface web Upload + chat + export Word/PDF
● Médio
Claude Code executa 95%
Frontend e backend completos escritos pelo Claude. Revisão de UX e ajuste de layout pela nossa parte antes de entregar ao Sergio.
Refinamento com casos reais Ajuste de prompts após testes do Sergio
● Médio
Claude Code executa 60%
Claude ajusta os prompts com base no feedback. Mas o feedback de qualidade técnica do laudo só pode vir do Sergio — ele é o especialista, não nós.
Claude Code faz (média geral)
~70%
do projeto completo
O que é insubstituível:
✦ Classificação manual dos 70GB de documentos
✦ Definição da estrutura dos templates de laudo por área
✦ Validação técnica dos laudos gerados (Sergio)
✦ Aprovação de recursos em painéis externos (Railway, Cloudflare)
✦ Feedback de qualidade pericial nos testes finais
Cobertura Completa

O que cobre os % que o Claude não faz

Cada lacuna tem uma ferramenta ou processo específico. Nada fica descoberto.

Etapa % restante O que cobre Custo extra
Piloto de extração Avaliação de qualidade
15%
Revisão humana — nós lemos o output e aprovamos a qualidade antes de avançar. Não tem ferramenta que substitua julgamento técnico neste ponto.
R$ 0 — tempo nosso
Organização dos 70GB Classificação por área/tipo
80%
Sergio + script de bulk rename — Claude escreve um script que percorre as pastas e sugere classificação automática por palavras-chave nos nomes dos arquivos. Sergio confirma ou corrige em lote. Reduz o trabalho manual de semanas para horas.
R$ 0 — script Python
Infraestrutura Criação de recursos em nuvem
30%
Railway CLI + Cloudflare CLI — Claude gera todos os comandos. Nós executamos com aprovação. Com as CLIs configuradas, até isso pode ser automatizado. O 30% é só aprovação com clique.
R$ 0 — ferramentas grátis
Agente + templates de laudo Estrutura pericial por área
25%
Entrevista estruturada com Sergio — 1 sessão de 2h por área (5 áreas = ~10h total). Claude transforma as respostas em templates e prompts. O conhecimento é do Sergio, a estruturação é do Claude.
Tempo do Sergio
Refinamento com casos reais Validação técnica pericial
40%
Ciclos de feedback Sergio → Claude — Sergio usa o agente em 10 casos reais e anota o que errou. Claude ajusta os prompts. Esse ciclo acontece 2-3 vezes até o agente estar calibrado para a linguagem pericial do Sergio.
Tempo de iteração
Proteção de Dados

Segurança e sigilo dos documentos

Documentos periciais têm sigilo processual. A arquitetura foi escolhida exatamente para isso.

⚖️ Por que self-hosted é obrigatório neste caso
Laudos periciais contêm dados sensíveis de partes, testemunhas e segredos de processo. Enviar esses documentos para servidores de terceiros (ChatGPT, Gemini, NotebookLM) configura quebra de sigilo. Com self-hosted, os dados nunca saem dos servidores que controlamos.
🔒

Dados nunca saem do servidor

Dify e Qdrant rodam no Railway — servidor dedicado. Nenhum documento é enviado para OpenAI, Anthropic ou qualquer terceiro. Só os embeddings (números matemáticos, sem texto) são gerados externamente.

🛡️

Criptografia em trânsito e em repouso

R2 (Cloudflare) criptografa todos os arquivos armazenados com AES-256. Todas as conexões são HTTPS/TLS 1.3. Qdrant e Railway têm rede privada interna sem exposição pública.

🔑

Acesso exclusivo do Sergio

Autenticação com senha + 2FA no painel do Dify. Nenhuma URL pública expõe os documentos. O agente só é acessível com login — sem links compartilháveis.

💾

Backup automático

R2 replica os originais automaticamente. Qdrant faz snapshot diário dos vetores. Railway persiste o banco de metadados. Recuperação total em caso de falha em menos de 1 hora.

Quais APIs recebem dados externos
✓ SEGURO
OpenAI Embeddings
Recebe apenas chunks de texto anônimos. Não recebe nomes, processos ou partes. Não armazena os dados após processar.
✓ SEGURO
Claude API (Anthropic)
Recebe o contexto da consulta ativa. Anthropic não usa inputs de API para treinar modelos. Zero retenção após a resposta.
✓ SEGURO
LlamaParse
Processa e devolve o texto. Não armazena documentos após extração. Política explícita de não retenção.
⚠ ATENÇÃO
ChatGPT / Gemini / NotebookLM
NÃO usar para documentos periciais. Armazenam inputs, podem usar para treino e não oferecem garantia de sigilo processual.
Pergunta Crítica

Importação sem inserção caso a caso — é possível?

Sim. Nenhum documento precisa ser inserido manualmente. O sistema monitora pastas e ingere automaticamente.

📁
Opção 1 — Pasta monitorada
Script Python roda em background no servidor. Monitora uma pasta local ou de rede. Qualquer arquivo novo adicionado é automaticamente detectado, processado e indexado em minutos.
Watch folder
Zero clique
☁️
Opção 2 — Google Drive / OneDrive sync
Sergio já usa Google Drive ou OneDrive? O sistema se conecta via API. Toda vez que um arquivo é adicionado ou atualizado na pasta pericial, a ingestão dispara automaticamente.
Drive API
Sync automático
📧
Opção 3 — Email automático
Sergio encaminha qualquer email com anexo para um endereço especial (ex: base@ejzenberg.ai). O sistema processa o email, extrai os anexos e indexa tudo automaticamente.
Forward por email
Imediato
📱
Opção 4 — Upload pelo celular
Interface mobile simples: Sergio fotografa um documento no campo (acidente, obra) e envia pelo app. Claude Vision processa a foto na hora e indexa com os metadados do caso.
Mobile upload
Campo → base em 1 toque
✓ Recomendação: combinar Opção 1 + Opção 4
Pasta monitorada no computador do escritório captura tudo que já existe e o que for adicionado pelo PC. Upload mobile captura o que Sergio produz em campo. A base cresce sozinha, sem nenhuma ação manual além de salvar o arquivo onde sempre salvou.