Como integrar dados da B3 e da CVM a um agente de IA

Se você está pensando em construir um agente para analisar ativos e apoiar as suas decisões de investimento, a primeira coisa que você deve se preocupar é com os dados que esse agente vai consumir. O seu modelo pode ser excelente, mas ele jamais irá trabalhar bem se não for alimentado com os dados corretos.

No Brasil, a B3 e a CVM disponibilizam informação de forma gratuita e em volume, mas em um formato pensado para download e processamento em lote, não para um agente consultar durante uma conversa ou uma tarefa.

Este guia mostra o que você encontra em cada fonte, por que o dado bruto trava um agente, e quais são as formas concretas de fazer a ponte entre uma API REST e Model Context Protocol.

Afinal, o que significa dar dados a um agente de IA

Dar dados a um agente de IA significa disponibilizar informação em um formato que ele consiga descobrir, consultar e usar no momento certo, e não apenas guardar o dado em algum lugar. O agente precisa poder fazer uma pergunta específica, como o patrimônio líquido de um fundo em determinada data, e receber de volta uma resposta estruturada e enxuta.

Isso muda a natureza do problema. Ter o dado não é suficiente. O que importa é como o dado é servido. Um relatório de milhares de linhas em um arquivo é uma coisa. Uma resposta pontual, estruturada e no escopo da pergunta é outra. A distância entre esses dois estados é onde a maioria dos projetos empaca.

Guarde essa distinção, porque ela organiza todo o resto do artigo: existe o dado bruto, que é como a B3 e a CVM entregam, e existe o dado servido, que é o que um agente realmente consegue usar.

O que a B3 fornece e como esse dado chega até você

A B3 fornece dados de mercado por um serviço de distribuição chamado UP2DATA. Ele entrega informações de final de dia e de referência cobrindo renda variável, renda fixa, moedas, juros, índices, debêntures, CRI e CRA, curvas, volatilidade e eventos corporativos das companhias listadas.

Dois pontos são importantes para quem quer alimentar um agente.

O primeiro é o formato. Os dados são distribuídos como arquivos, nos formatos TXT, CSV, XML ou JSON, entregues por um software cliente instalado no seu ambiente ou por um canal em nuvem. É distribuição de arquivos, não uma API que responde a uma consulta pontual.

O segundo é o modelo de acesso. O uso e, principalmente, a redistribuição desses dados dependem de contrato comercial com a B3, com anexos específicos para quem vai distribuir a informação para fora do próprio grupo econômico. Dados em tempo real ou com atraso de quinze minutos dependem de status de distribuidor. Ou seja, a resposta curta para a pergunta comum, se a API da B3 é paga, é que o acesso a dados de mercado da B3 é contratado, e a redistribuição tem regras próprias.

O que a CVM fornece e por que arquivo aberto não é o mesmo que dado pronto

A CVM disponibiliza dados públicos e gratuitos no Portal de Dados Abertos, em dados.cvm.gov.br. É um acervo extenso sobre os participantes regulados. Entre os conjuntos mais usados por quem analisa o mercado estão o informe diário de fundos, a composição e diversificação das aplicações das carteiras, o cadastro de fundos, e os informes de fundos imobiliários, FIDCs, FIPs e FIAGROs. Para companhias abertas, estão lá o formulário cadastral, o formulário de referência, as demonstrações financeiras padronizadas e as informações trimestrais.

Até aqui parece resolvido. É público, é gratuito e é oficial. O problema aparece no formato.

Os dados vêm em arquivos, quase sempre em CSV compactado, particionados por período e por tipo de documento, cada conjunto com seu próprio dicionário de campos. As estruturas mudam ao longo do tempo, com colunas que são adicionadas ou renomeadas conforme a CVM revisa os conjuntos. O informe diário de fundos, por exemplo, é atualizado de segunda a sábado, com os dados recebidos até o fim do dia anterior.

Por que jogar dado bruto no agente não funciona

A tentação óbvia é baixar os arquivos e empurrar tudo para dentro do agente. Na prática, isso funciona mal, e por motivos que se somam.

O volume estoura o contexto. Um arquivo de informe diário ou de composição de carteira tem muito mais linhas do que cabe, de forma útil, na janela de um modelo. Você acaba truncando, e o agente responde com base em um pedaço arbitrário do dado.

O formato consome raciocínio. Fazer o modelo interpretar um CSV bruto, com códigos, siglas e colunas que ele precisa adivinhar, gasta capacidade que deveria estar sendo usada na análise. E aumenta a chance de erro de leitura.

A atualização vira responsabilidade sua. Como o dado é entregue em lote e muda de estrutura ao longo do tempo, alguém precisa baixar, versionar e normalizar de forma recorrente. Sem isso, o agente trabalha com dado velho ou quebrado.

A junção entre fontes fica no seu colo. Cruzar um fundo da CVM com a cotação de um ativo da B3 exige unir bases diferentes, com identificadores diferentes. É um trabalho de engenharia de dados que não desaparece só porque tem um modelo de linguagem no fim da linha.

O ponto não é que os dados da B3 e da CVM sejam ruins. Eles são a fonte primária certa. O ponto é que o formato de entrega deles não é o formato que um agente consome bem. Entre um e outro existe uma etapa de trabalho que precisa ser feita por alguém.

Duas formas de entregar dado a um agente: API REST e MCP

Existem duas formas maduras de entregar dado estruturado a um agente. Elas não competem entre si, e as melhores arquiteturas costumam usar as duas.

A primeira é uma API REST que devolve JSON.

É o modo consolidado de expor dados a qualquer aplicação, inclusive a um agente. O agente, ou o código que orquestra o agente, faz uma chamada a um endpoint e recebe de volta uma resposta estruturada e no escopo da pergunta. A vantagem é o controle total e a compatibilidade com qualquer stack. O custo é que você precisa construir e manter essa integração.

A segunda é o Model Context Protocol, o MCP.

É um protocolo aberto criado pela Anthropic e apresentado ao mercado no fim de 2024, hoje mantido de forma aberta pela comunidade, que padroniza como uma aplicação de IA se conecta a fontes de dados e ferramentas externas. Em vez de você escrever um conector sob medida para cada combinação de modelo e ferramenta, o servidor MCP anuncia o que sabe fazer, e o agente descobre e chama essas capacidades de forma nativa. Se quiser entender o protocolo a fundo, vale um material dedicado sobre o que é MCP e como ele funciona. Para este artigo, basta o conceito: MCP é a forma padronizada de o agente descobrir e consultar dados sem integração artesanal.

A diferença prática entre os dois é simples. A API resolve a entrega do dado. O MCP resolve a padronização da conexão com o agente. Um não substitui o outro. Por baixo, o agente continua usando a mesma mecânica de chamada de função dos dois jeitos.

Passo a passo conceitual para conectar uma fonte a um agente

O caminho, em qualquer das duas abordagens, segue a mesma lógica. Vale entender a sequência antes de escolher a ferramenta.

1. Defina a pergunta que o agente precisa responder. Não comece pelo dado, comece pela tarefa. O patrimônio de um fundo, a composição de uma carteira, a cotação de um ativo, cada pergunta define qual fonte e qual recorte você precisa.
2. Dado de mercado tende a vir da B3. Dado cadastral, de fundos e de companhias tende a vir da CVM. Saber de onde vem cada informação evita cruzar dado errado.
3. Transforme o arquivo bruto em dado consultável. Aqui mora o trabalho: baixar, normalizar entre períodos, padronizar identificadores e expor o resultado de um jeito que responda a consultas pontuais. É esta etapa que separa o dado bruto do dado servido.
4. Exponha o dado por uma interface. Escolha entre uma API REST própria, um servidor MCP, ou os dois. A interface é o que o agente vai chamar.
5. Conecte o agente e valide as respostas. Ligue a interface ao seu agente e teste com perguntas reais, conferindo se a resposta bate com a fonte primária. Confiança se constrói checando, não presumindo.

O passo três é o que costuma ser subestimado. É trabalho recorrente de engenharia de dados, não uma configuração única. Quem monta tudo internamente assume esse custo de forma permanente.

Confiabilidade e segurança da fonte, o que não pode faltar em finanças

Em um contexto financeiro, a procedência do dado não é um detalhe técnico, é um requisito. Um agente que responde com dado errado sobre um fundo ou uma companhia não é apenas impreciso, ele induz decisão ruim. Por isso, ao escolher como servir dado a um agente, alguns critérios pesam mais do que a facilidade de conectar.

Rastreabilidade.

Você precisa saber de qual fonte primária cada resposta veio e de quando é aquele dado. Sem isso, não há como auditar uma decisão.

Atualização e cobertura.

O dado precisa refletir a realidade recente e cobrir o universo que você analisa. Uma base desatualizada ou parcial contamina a análise inteira.

Segurança na conexão.

Quando o agente se conecta a servidores externos, há um vetor de risco específico. No caso do MCP, por exemplo, as descrições das ferramentas são texto lido pelo modelo, o que abre espaço para manipulação por meio de injeção de prompt se o servidor não for confiável. A recomendação do próprio protocolo é tratar servidores não confiáveis com cautela e exigir consentimento explícito antes de executar ações. A lição prática é: conecte seu agente apenas a fontes e servidores em que você confia.

Esses critérios explicam por que muita equipe, depois de tentar montar tudo do zero, passa a considerar uma camada de dados pronta. Não é sobre terceirizar o raciocínio do agente, que continua seu. É sobre não reconstruir, sozinho e de forma frágil, a ponte entre a fonte primária e o dado consultável.

Como uma camada de dados encurta o caminho

Uma camada de dados é justamente o serviço que faz o passo três por você. Ela pega o dado bruto da fonte primária, normaliza, mantém atualizado e o expõe por uma interface que o agente consulta. Em vez de você baixar arquivos da CVM e da B3, versionar e padronizar tudo, você faz uma pergunta e recebe o dado estruturado.

A Partnr é um exemplo de camada de dados voltada ao mercado brasileiro. Ela oferece os dados por API REST com JSON e também por um servidor MCP, cobrindo dados de mercado, dados fundamentalistas, dados macroeconômicos e dados de fundos listados, como fundos imobiliários, FIDCs e FIAGROs.

Para tornar concreto o contraste entre dado bruto e dado servido: consultar um fundo imobiliário específico por meio do servidor MCP retorna, em uma única chamada, um objeto estruturado com a identidade do fundo, a classificação, o administrador, o escriturador, o número de cotistas e o total de cotas. É a mesma informação que existiria espalhada em arquivos da CVM, só que já normalizada e pronta para o agente usar. O agente pergunta, a camada responde, e o raciocínio do modelo fica livre para o que importa, que é a análise.

Conclusão

Construir um agente de IA financeiro que analisa o mercado brasileiro não esbarra no modelo, esbarra no dado. A B3 e a CVM são as fontes primárias certas, mas entregam arquivos pensados para download e processamento em lote, não uma interface que um agente consulta durante a tarefa. Entre o dado bruto e o dado servido existe uma etapa de normalização, atualização e exposição que alguém precisa fazer.

As duas formas maduras de fazer essa ponte são a API REST com JSON e o Model Context Protocol, e elas se complementam. A decisão real não é qual protocolo usar, e sim quem vai manter a ponte entre a fonte primária e o dado consultável, com a rastreabilidade e a confiabilidade que finanças exigem. Montar internamente é possível, e é trabalho recorrente. Usar uma camada de dados pronta encurta o caminho e devolve o foco para onde ele deve estar, que é a análise que o seu agente faz.

O próximo passo prático é definir quais perguntas o seu agente precisa responder e, a partir delas, decidir de quais fontes e por qual interface o dado vai chegar.