Voltar para Artigos

Orquestrando LLMs para OSINT: da coleta caótica à inteligência estruturada

VV

Vinicius Vieira

Vinícius Vieira é especialista em OPSEC com mais de 18 anos de experiência em cibersegurança, atuando na proteção de infraestruturas críticas e na mitigação de riscos estratégicos em ambientes corporativos e governamentais. SecOps Manager e autor de “OPSEC: Inteligência Cibernética na Prática”, dedica-se à aplicação prática de metodologias de inteligência, gestão de metadados e proteção de identidade digital em cenários de alta exposição. Une visão técnica, mentalidade analítica e disciplina operacional para reduzir superfície de ataque — não apenas de sistemas, mas de pessoas e processos.

22 de abril de 2026
5 min de leitura
25 visualizações
Orquestrando LLMs para OSINT: da coleta caótica à inteligência estruturada

A incorporação de LLMs em fluxos de OSINT trouxe ganhos evidentes de velocidade, mas também introduziu um problema menos discutido: a perda de controle sobre o processo analítico. Modelos passaram a coletar, resumir e até correlacionar dados em uma única execução, comprimindo etapas que, no ciclo de inteligência, deveriam permanecer separadas. O resultado prático é conhecido por quem já tentou usar esses sistemas em contexto real: outputs difíceis de auditar, mistura de hipótese com evidência, ausência de rastreabilidade e, principalmente, decisões implícitas sendo tomadas pelo modelo sem visibilidade do operador.

O OSINT Agentic Framework para OpenCode surge como uma resposta direta a esse cenário. Ele não é uma ferramenta de coleta, nem uma plataforma de automação, mas um modelo operacional que reorganiza o uso de LLMs dentro de uma estrutura disciplinada. A dor que ele se propõe a sanar não é a falta de dados — é a falta de método. Em vez de depender de um fluxo único e opaco, o framework fragmenta a investigação em módulos independentes, cada um com um objetivo claro, entradas definidas e saídas estruturadas. Essa separação impede que o modelo avance além do que foi solicitado e obriga a manutenção de um encadeamento lógico entre as etapas.

No núcleo da abordagem está a distinção entre coleta, validação e correlação. Em pipelines não estruturadas, essas funções tendem a se sobrepor: o modelo coleta e, simultaneamente, interpreta, valida parcialmente e produz conclusões. No framework, cada uma dessas funções é isolada. A etapa de coleta concentra-se exclusivamente em identificar sinais públicos; a validação exige convergência entre fontes plausíveis; a correlação organiza os dados já coletados, sem introduzir novas fontes; e o relatório final apenas consolida o que já foi estabelecido. Esse desenho reduz drasticamente a incidência de inferências não verificadas e torna cada decisão auditável.

Um exemplo prático ilustra melhor essa diferença. Considere a necessidade de mapear a estrutura pública de uma empresa com presença digital limitada. Em um fluxo tradicional baseado em LLM, o operador forneceria o nome da empresa e receberia um resumo com possíveis identificadores, domínios e interpretações sobre a operação. No framework, a execução ocorre de forma sequencial. O intake define claramente o alvo e o escopo. O framing estabelece hipóteses e vetores de busca. A coleta corporativa passa então a operar com regras explícitas: identificar CNPJ, razão social e nome fantasia a partir de múltiplas fontes públicas, explorar diretórios empresariais, reutilizar cada achado como pivô e só promover um dado a “confirmado” quando houver convergência entre fontes independentes. Em paralelo, o módulo amplia a visão para empresas com nomes semelhantes, domínios relacionados e sinais institucionais adicionais, permitindo ao operador avaliar não apenas um registro isolado, mas o contexto corporativo ao redor. O resultado final não é um texto descritivo, mas um conjunto estruturado de evidências, com níveis de confiança e lacunas claramente indicadas.

Essa forma de execução está diretamente relacionada ao uso de LLMs como componentes de uma pipeline modular, e não como um agente único responsável por todo o processo. Modelos de linguagem são extremamente eficientes em tarefas específicas — interpretação de texto, geração de hipóteses, organização de dados — mas perdem confiabilidade quando acumulam funções. Ao dividir a pipeline em comandos independentes, o framework permite que o mesmo modelo seja utilizado em diferentes etapas com restrições distintas, ou até que múltiplos modelos sejam combinados conforme a necessidade. Isso cria uma arquitetura flexível, onde o operador pode ajustar o comportamento de cada módulo sem reescrever o sistema como um todo.

Nesse contexto, a comparação com soluções monolíticas é inevitável. Plataformas como Manus operam com alto nível de abstração, encapsulando coleta, análise e apresentação em uma única interface. Isso reduz o esforço inicial, mas também limita a visibilidade sobre o que está sendo feito e como. O framework segue a direção oposta: expõe cada etapa, exige confirmação do operador e mantém os dados intermediários acessíveis. Essa transparência não é apenas uma escolha de design, mas um requisito para quem precisa confiar no resultado em ambientes sensíveis.

Outro aspecto central é o controle da exposição de dados. Ao utilizar LLMs em investigações, há sempre o risco de enviar informações sensíveis para processamento externo sem a devida avaliação. O framework mitiga esse risco ao estruturar o fluxo de forma que apenas os dados necessários para cada etapa sejam utilizados, evitando o envio indiscriminado de contextos completos. Além disso, ao separar coleta de análise, ele permite que partes do processo sejam executadas localmente ou em ambientes controlados, reduzindo a superfície de exposição. Essa preocupação com OPSEC também se reflete na própria definição de escopo: o operador estabelece, desde o início, quais tipos de dado podem ser coletados e utilizados, e o modelo é instruído a respeitar essas restrições ao longo de toda a pipeline.

Em termos operacionais, o efeito combinado dessas escolhas é a recuperação do controle sobre o processo de inteligência. O modelo deixa de ser uma caixa-preta que “descobre coisas” e passa a ser um executor de tarefas bem definidas. O operador, por sua vez, volta a ter visibilidade sobre cada etapa, podendo intervir, ajustar ou interromper a execução conforme necessário. Em um ambiente onde a quantidade de dados disponíveis tende a crescer e a pressão por respostas rápidas aumenta, essa capacidade de manter método e rastreabilidade torna-se um diferencial relevante.

O OSINT Agentic Framework não elimina a necessidade de ferramentas tradicionais nem substitui a experiência analítica, mas estabelece uma base sobre a qual essas capacidades podem ser integradas de forma mais controlada. Ao tratar LLMs como componentes de uma pipeline e não como um substituto do operador, ele reposiciona a tecnologia como um amplificador de capacidade, e não como um ponto único de decisão. É uma abordagem menos automatizada, mas mais alinhada com a produção consistente de inteligência.

Link para o projeto no Github: https://github.com/V1n1v131r4/OSINT-Agentic-Framework

Compartilhar:

Conteúdo produzido sob responsabilidade do/s autor/es.

Sobre o Autor

VV

Vinicius Vieira

Vinícius Vieira é especialista em OPSEC com mais de 18 anos de experiência em cibersegurança, atuando na proteção de infraestruturas críticas e na mitigação de riscos estratégicos em ambientes corporativos e governamentais. SecOps Manager e autor de “OPSEC: Inteligência Cibernética na Prática”, dedica-se à aplicação prática de metodologias de inteligência, gestão de metadados e proteção de identidade digital em cenários de alta exposição. Une visão técnica, mentalidade analítica e disciplina operacional para reduzir superfície de ataque — não apenas de sistemas, mas de pessoas e processos.

Artigos Relacionados

TCSM para OPSEC: por que criptografia não te protege (e o que realmente denuncia sua operação na rede)

TCSM para OPSEC: por que criptografia não te protege (e o que realmente denuncia sua operação na rede)

Criptografia não garante OPSEC: metadados, handshake TLS e padrão de tráfego expõem a operação. TCSM foca em se misturar à rede com técnicas como V2Ray e Xray.

FGV sob pressão: o que se sabe sobre a alegação de ataque ransomware do grupo DragonForce

FGV sob pressão: o que se sabe sobre a alegação de ataque ransomware do grupo DragonForce

Em 2 de março de 2026, o grupo DragonForce alegou ter atacado a Fundação Getulio Vargas (FGV) e exfiltrado 1,52 TB de dados, mas, embora essa alegação tenha sido amplamente replicada em fontes abertas, não havia até o momento analisado confirmação técnica pública independente que comprovasse a invasão, a extensão real do vazamento ou a execução de ransomware no ambiente da instituição; o caso ganhou relevância porque ocorreu dias após instabilidades operacionais divulgadas pela própria FGV em fevereiro, o que torna o cenário plausível, mas não conclusivo, exigindo uma análise OSINT cuidadosa para separar alegações do ator criminoso, indícios observáveis e fatos efetivamente confirmados.

OSINT em Conflitos Recentes: Dashboards Emergentes, Telemetria e a Exposição do Operador

OSINT em Conflitos Recentes: Dashboards Emergentes, Telemetria e a Exposição do Operador

Dashboards OSINT modernos como WorldWatch, World Monitor e painéis temáticos centralizam e aceleram a análise de conflitos, mas também geram telemetria detalhada de navegação. Beacons de performance, cookies de terceiros e logs de edge permitem reconstruir padrões de uso, interesses temáticos e rotas acessadas — mesmo sem login. O ponto não é demonizar as plataformas, mas entender que eficiência e produção de metadados caminham juntas. Em contextos sensíveis, maturidade operacional deixa de ser opcional.

Quer aprender mais sobre OSINT?

Explore nossos guias de ferramentas e recursos completos