Como o Nosso Agente Local Faz Investigação a Sério — Sem Qualquer Cloud Americana no Processo

Pergunte a qualquer "agente de investigação de IA" da moda o que acontece aos seus dados e a resposta honesta é quase sempre a mesma: saem do edifício, vão para uma API de cloud e passam a viver no modelo de outra pessoa. A maioria destas demonstrações é apenas uma camada fina por cima dessa API.

A nossa não é. O pi — o nosso próprio agente local — corre um modelo aberto numa máquina debaixo da minha secretária, pesquisa na web através de infraestrutura que alojamos nós mesmos, e entrega as partes difíceis a uma pequena equipa de subagentes. Sem chave de API. Sem que um prompt, um documento ou sequer uma pesquisa saiam do edifício.

Este texto é o companheiro de correr o próprio modelo numa placa gráfica de 2018. Esse artigo era sobre o hardware. Este é sobre a arquitetura — como um agente local faz de facto investigação em que se pode confiar, de ponta a ponta, sem nada ir para uma cloud americana.

O motor: um modelo aberto que aloja

O pi é construído sobre o harness open-source earendil-works/pi. O motor de raciocínio é um modelo aberto de 12B — Gemma 4 QAT — servido pelo llama.cpp numa única placa gráfica de consumo, cujo orçamento de memória descrevi no artigo da GPU de 2018. O que importa aqui: o modelo é um ficheiro no meu disco, não um ponto de acesso pago ao token. Tudo o que se segue é construído em cima de um motor de raciocínio que é nosso por inteiro.

Todas as ferramentas são self-hosted

Um agente é tão privado quanto a sua ferramenta mais fraca. Se o modelo é local mas a caixa de pesquisa liga a um grafo publicitário americano, não se manteve nada dentro de casa. Por isso as três ferramentas do pi correm todas sob o nosso próprio teto:

• Pesquisa na web através do nosso SearXNG. O SearXNG é um motor de metapesquisa open-source que corremos no nosso próprio servidor. Quando o agente pesquisa, a consulta chega à nossa máquina — não às análises de terceiros.
• Leitura de páginas através de um navegador furtivo. Para ler mesmo uma página — e não apenas um excerto de resultado — o agente conduz o Camoufox, um Firefox reforçado, para ir buscar e extrair o conteúdo real. Trata dos casos incómodos em que a maioria dos raspadores falha: obtém os releases do GitHub a partir da API em vez do HTML ruidoso, reescreve os links de blob para bruto e extrai o texto de PDFs localmente com o pdftotext. Esta última parte importa na UE: PDFs oficiais portugueses e jurídicos passam a texto legível, não a moldura de um visualizador.
• Uma camada de memória. As regras e os factos de longa duração vivem num simples ficheiro Markdown que o agente controla. As regras que têm de aplicar-se sempre não ficam à mercê de o modelo se lembrar de as consultar — são injetadas no seu contexto em cada turno, de forma determinística.

Nenhuma destas ferramentas é um SaaS. Cada uma é um componente que podemos inspecionar, alterar e correr offline.

A divisão de tarefas: scout, researcher, verifier

Um único modelo a tentar fazer tudo num só contexto longo é precisamente onde os agentes locais se desmoronam. Por isso o trabalho é dividido por subagentes, cada um com uma função estreita e o seu próprio orçamento de ferramentas:

• Scout — reconhecimento só de leitura. Mapeia o terreno antes de qualquer leitura profunda começar.
• Researcher — o cavalo de trabalho. Dada uma faceta da pergunta, pesquisa, abre algumas páginas e devolve um resumo curto. Só pode citar uma página que tenha aberto de facto e corre com um orçamento rígido: um punhado de pesquisas, no máximo algumas aberturas de página. Esse orçamento é exatamente o que impede um modelo pequeno de divagar e transbordar o seu contexto num tema difícil.
• Verifier — uma passagem adversarial sobre algumas afirmações específicas, usada quando um número tem mesmo de estar certo.

Sob o comando /research, o agente principal decompõe a pergunta e despacha até quatro researchers em paralelo, e depois costura os seus resumos numa só síntese — com tudo o que não conseguiu confirmar empurrado para uma secção explícita de "por verificar" em vez de ser branqueado num facto apresentado com confiança.

Mais agentes não é mais profundidade

O instinto tentador é "atirar-lhe mais agentes". Medimos; não funciona assim.

Cada researcher carrega o mesmo pequeno orçamento de aberturas de página, por isso acrescentar agentes cobre mais terreno — mais facetas, mais páginas — mas não torna nenhuma linha individual mais profunda. A nossa regra prática é simples: aproximadamente um researcher por cada três páginas que a pergunta precise de abrir, com um teto de quatro. O número de agentes é uma alavanca menor. O que protege mesmo a qualidade é a verificação.

A verificação não é tarefa do modelo

A lição mais dura de construir isto: um modelo local não consegue verificar o próprio trabalho. Testámo-lo diretamente — pedimos ao agente que revisse a sua própria investigação com um prompt céptico e severo, que lhe dizia para não defender as conclusões anteriores. Ele releu a fonte, calculou corretamente um número e depois certificou uma conclusão que contradizia a sua própria aritmética. A auto-revisão do mesmo modelo limita-se a reconfirmar os seus pontos cegos.

Por isso a camada de veredicto nunca é o modelo. São duas verificações independentes que fazem o trabalho:

• Uma verificação determinística de links. Antes da síntese, um simples script testa em paralelo cada URL citado para apanhar tudo o que seja inventado, morto ou bloqueado. Sem modelo no processo — um URL ou resolve ou não. Uma tentativa anterior de pôr um segundo modelo a reabrir todas as páginas citadas demorou quase meia hora e engasgou-se com a carga; um script de um segundo faz melhor o serviço.
• Um registo de URLs abertos que o modelo não pode contestar. A ferramenta de navegação anota cada página que foi de facto buscar. Uma segunda verificação reprova a nota se esta citar algum URL que não esteja nesse registo. O modelo não tem voto no veredicto, por isso não consegue argumentar para lá dele. (Essa verificação merece um artigo só dela — eis como apanhou citações que uma revisão humana tinha deixado passar.)

O padrão repete-se por toda esta stack: num modelo local pequeno, uma regra no prompt é uma sugestão; uma verificação determinística é uma garantia.

A prova: um projeto real, totalmente local

Isto não é uma arquitetura de quadro branco. O teste de campo mais claro é a Bela Luz — a nossa própria quinta de permacultura em Portugal (projeto nosso, não de um cliente). Apontámos o agente ao projeto e deixámo-lo construir a base de conhecimento. No primeiro dia produziu 15 notas com fontes verificadas em sete temas, cada uma a passar no validador determinístico.

Cada facto jurídico foi confirmado em fontes primárias portuguesas e da UE — DGAV, EUR-Lex, o Diário da República — com o agente a paginar PDFs de legislação real. Quando esbarrou numa afirmação que não conseguiu verificar, o próprio agente retirou-a em vez de a enfeitar.

Tudo isto correu no modelo local, numa única GPU de 2018, a custo zero de cloud. A quinta ainda está em fase pré-lançamento, por isso não há números de receita a reportar — o objetivo da demonstração é a capacidade: um agente de que se é dono por inteiro, a fazer investigação real e com fontes verificadas em infraestrutura que se controla.

Porque importa ser dono de todo o ciclo

Cada etapa — pesquisar, ler, raciocinar, verificar — corre nas nossas próprias máquinas. Isso tem duas consequências que uma API de cloud não consegue igualar.

A privacidade é estrutural: os seus dados, ou os do seu cliente, nunca chegam ao modelo de um terceiro, porque não há terceiro. E a pergunta de conformidade que as obrigações de alto risco do Regulamento Europeu da IA tornam incontornável a partir de 2 de agosto de 2026 — "onde é que isto é processado?" — tem uma resposta limpa: em hardware de que somos donos, na UE, sem nada a sair do edifício.

Ganha-se ainda a possibilidade de acrescentar as garantias que um fornecedor não dá. A verificação de links, o registo de URLs abertos, os orçamentos por agente — existem porque somos donos da stack onde vivem. Não se está à espera de que um fornecedor lance uma funcionalidade de "confiança"; a lógica do veredicto é nossa.

A conclusão

Um agente de investigação útil não é um modelo gigante por trás de uma API paga. É um modelo aberto modesto, algumas ferramentas self-hosted, uma divisão de tarefas sensata e — acima de tudo — verificação que não depende de o modelo ser honesto.

Junte essas peças e obtém algo que uma subscrição de cloud não lhe consegue vender: investigação autónoma capaz de que é mesmo dono, a correr no seu próprio hardware, sem nada a sair do edifício. Se conseguir correr o modelo — e consegue, numa placa gráfica de sete anos — a arquitetura à volta dele é a parte que o transforma de uma demonstração em algo em que se pode confiar.

---

Todos os detalhes concretos deste artigo vêm de sessões documentadas da ImparLabs a construir e a testar em campo o pi, o nosso agente de investigação local, numa única GPU de consumo.