IA em RI: como devs constroem pipeline RAG com Python

Quando vi a pauta do painel “IA em Relações com Investidores e as tendências discutidas no exterior” no 27º Encontro Internacional de RI, em São Paulo, fui direto pensar no que isso significa de verdade para quem está do lado técnico. Não é papo de futurismo: é NLP aplicado a earnings call, RAG sobre relatórios 10-K, LLMs gerando drafts de fatos relevantes, e pipelines automatizando disclosure. Segundo o Terra.com.br, o painel acontece no dia 25 de agosto de 2026, das 10h15 às 11h15, no Teatro B32 (Av. Brigadeiro Faria Lima, 3732, Itaim Bibi), com PH Zabisky (CEO da MZ), Vicente Gioielli (sócio da Cescon Barrieu), Pedro Tadeu Teixeira Lourenço (gerente de RI da EZTEC) e Daniel Dias (Workiva). Organização do IBRI e da ABRASCA.

O que me chamou atenção foi justamente o recorte: não é “IA substituindo o RI”, é IA augmentando o fluxo de informação entre companhias abertas e mercado. E é aí que entra o desenvolvedor — porque alguém precisa construir, auditar e manter esses sistemas.

O que uma equipe de RI realmente quer de IA — e como dev entrega isso

Converso com gente de mercado de capitais há anos. O que o time de RI precisa não é um chatbot genérico. Eles querem três coisas muito específicas:

• Sumarização de documentos longos (10-K, 20-F, prospectos) com rastreabilidade da fonte.
• Detecção de mudança de tom entre trimestres — quando o “guidance” muda de “confiante” para “cauteloso”.
• Geração de rascunhos de release com revisão humana obrigatória (compliance nunca vai deixar 100% autônomo).

Do lado técnico, isso vira um pipeline clássico: ingestion → chunking → embeddings → retrieval → LLM com guardrails → human-in-the-loop. Nada mágico. O diferencial está no detalhe — chunk size, escolha do modelo, janelas de contexto, e principalmente logs auditáveis. Em produção, ninguém aceita um output sem fonte citada.

Stack que eu testaria em 2026 para esse tipo de demanda

Na minha experiência, três caminhos valem a pena comparar antes de bater o martelo:

Para uma área de RI brasileira lidando com documentos em português, minha recomendação quase sempre é a terceira opção. Llama 3.1 70B rodando em GPU H100 ou mesmo A100 lida bem com PT-BR técnico, e quando o documento exige raciocínio mais pesado (interpretação de cláusulas contratuais, por exemplo), você escala para API externa — sem mandar o documento inteiro, só o trecho relevante com metadata.

Na Prática — um pipeline mínimo de RAG para análise de fatos relevantes

Vou te mostrar um exemplo funcional. Imagine receber 500 PDFs de fatos relevantes da B3 por mês e precisar identificar mudanças semânticas entre versões. Aqui vai um esqueleto em Python usando langchain, chromadb e um modelo de embedding local:

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain_community.llms import Ollama

# 1. Carrega e fatia o documento (chunk size importa MUITO)
loader = PyPDFLoader("fato_relevante_2T26.pdf")
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,      # em chars; ajuste para ~512 tokens
    chunk_overlap=120,   # sobreposição evita perda de contexto entre chunks
    separators=["\n\n", "\n", ".", " "]
)
chunks = splitter.split_documents(docs)

# 2. Embedding local em PT-BR — modelo multilingual
embeddings = HuggingFaceEmbeddings(
    model_name="BAAI/bge-m3",  # bom suporte a PT-BR e janela grande
    model_kwargs={"device": "cuda"},  # mude para "cpu" se não tiver GPU
    encode_kwargs={"normalize_embeddings": True}
)

# 3. Persiste em ChromaDB para auditoria
vectordb = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_ri"
)
vectordb.persist()

# 4. Retrieval com LLM local (Ollama rodando Llama 3.1 8B ou Qwen 2.5 14B)
llm = Ollama(model="llama3.1:8b", temperature=0.0)  # temp 0 = determinístico

qa = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectordb.as_retriever(search_kwargs={"k": 4}),
    return_source_documents=True  # CRUCIAL para auditoria de RI
)

# 5. Pergunta que um analista de RI faria
result = qa({"query": "Houve mudança no guidance de receita para o próximo trimestre?"})

print("RESPOSTA:", result["result"])
print("\nFONTES:")
for doc in result["source_documents"]:
    print(f"- Página {doc.metadata.get('page')}: {doc.page_content[:200]}...")

Esse é o esqueleto mínimo que eu entregaria numa POC. Em produção, três upgrades obrigatórios:

1. Logging estruturado: cada query registra pergunta, resposta, fontes, latência, custo. Sem isso, compliance te derruba.
2. Versionamento do índice: cada fato relevante entra num snapshot datado. Você precisa responder “o que o sistema sabia em 15/03?”.
3. Filtro de PII e MNPI: antes de qualquer chamada de LLM externo, rodar um classificador para garantir que você não está vazando informação privilegiada.

Erros Comuns — o que devs de fora do mercado financeiro tropeçam

Já vi muito programador brilhante entregar uma POC linda que morre na primeira reunião com compliance. Os erros que mais aparecem:

• Confundir LLM com fonte de verdade. LLM alucina. Em RI, um número errado num release é multa da CVM. Sempre trate o modelo como redator de rascunho, não como autor.
• Ignorar a janela de contexto do embedding. bge-m3 aguenta 8192 tokens, mas se seu chunk for maior, você perde precisão. Chunk de 800–1200 caracteres é o sweet spot para texto financeiro denso.
• Esquecer do custo de reindexação. Quando o modelo de embedding muda, você reindexa TUDO. Planeje isso desde o dia 1 — escolha um modelo com roadmap claro e versione o índice.
• Mandar PDF bruto para o LLM. Não funciona. PDF tem tabelas, cabeçalhos, rodapés que destroem a extração. Use parser robusto (Unstructured, Marker, ou Docling) e valide saída antes de embedar.
• Subestimar a revisão humana. A interface precisa mostrar a fonte ao lado da resposta, permitir editar e aprovar. Human-in-the-loop não é opcional.
• Esquecer latência em hora de fechamento. Às 18h de um dia de disclosure, todos os sistemas do mercado consultam APIs externas. Se sua chamada demora 8s, você vira gargalo.

Tendências discutidas no exterior — o que eu acompanharia se fosse dev de RI

Esse é o ponto que o painel promete abordar. Pelo que tenho visto em eventos como o AI in Finance Summit (NY) e o relatório do CFA Institute Research Foundation, três tendências estão consolidadas fora:

1. Agents autônomos com guardrails regulatórios

O padrão “single prompt + single response” está dando lugar a agentes multi-step que planejam, executam e validam. Frameworks como LangGraph e CrewAI permitem criar fluxos com aprovação humana em pontos críticos — exatamente o que regulação exige.

2. SLMs (Small Language Models) no edge

Modelos de 3B a 14B parâmetros, quantizados, rodando localmente para tarefas específicas: classificação de sentimento, extração de entidades nomeadas, sumarização extrativa. Latência baixa, custo quase zero, dados nunca saem do servidor. Para RI brasileiro, faz todo sentido.

3. Avaliação contínua com datasets gold

Times maduros mantêm um dataset de perguntas canônicas com respostas esperadas. Cada mudança de modelo, chunk size ou prompt passa por esse benchmark. Parece óbvio, mas 90% dos projetos em produção não têm isso.

Comparativo rápido: ferramentas que valem a pena estudar

• Workiva — plataforma que o painel cita (Daniel Dias é da Workiva). Já tem módulos de IA generativa integrados ao fluxo de disclosure.
• MZ Group — outro painelista. Foco em inteligência de mercado e target investor; usa NLP pesado para classificar acionistas.
• Docling (IBM) — parser de PDF que entende tabelas e layout. Open-source, vale testar.
• Unstructured.io — alternativa comercial com bom suporte a documentos financeiros.
• Weights & Biases — para tracking de experimentos de prompt engineering e avaliação de modelo.

FAQ — perguntas que um dev faria sobre IA em RI

1. Qual o melhor modelo de embedding para documentos financeiros em português?
Na minha experiência, bge-m3 da BAAI é o melhor equilíbrio entre qualidade, suporte multilíngue e licença. Alternativas: text-embedding-3-large da OpenAI (pago, melhor em tarefas complexas) ou multilingual-e5-large (Microsoft, bom custo-benefício).

2. Como evitar vazamento de informação privilegiada (MNPI) ao usar LLM?
Três camadas: (1) classificador local que detecta MNPI antes de qualquer chamada externa; (2) contrato com fornecedor LLM proibindo treinamento com seus dados; (3) opção self-hosted para documentos sensíveis. Nunca mande um 10-K bruto para API pública sem essas garantias.

3. RAG ou fine-tuning? Quando usar cada um?
RAG quando a informação muda com frequência (documentos novos toda semana) e você precisa de rastreabilidade. Fine-tuning quando o estilo e formato importam mais que o conteúdo (gerar rascunhos com a “voz” da empresa, por exemplo). Em RI, começo sempre com RAG e fine-tuno só se a métrica de qualidade justificar o custo.

4. Vale a pena usar LangChain/LlamaIndex em produção?
Para MVP e protótipo, sim. Para produção crítica, eu prefiro construir o pipeline com chamadas explícitas. Abstrações dessas libs mudam rápido, debugar é doloroso, e quando o cliente é uma área regulada, você quer saber exatamente o que cada linha faz.

5. Como medir se o sistema está realmente ajudando o RI?
Métricas técnicas (latência, taxa de alucinação, cobertura de fontes) são fáceis. Métricas de negócio importam mais: tempo médio de elaboração de release caiu? O analista corrigiu menos o rascunho? Aumento de cobertura em calls? Defina isso ANTES de colocar em produção.

Implicações práticas para quem está construindo isso agora

Se você é dev e quer entrar nesse mercado, minha sugestão é dupla. Primeiro, estude regulação — nem precisa virar advogado, mas entenda o básico de CVM 44, Sarbanes-Oxley e GDPR. Isso muda completamente como você desenha o sistema. Segundo, monte um portfólio com dados públicos: baixe 10-Ks da SEC em PDF, faça um pipeline de RAG, publique no GitHub. É o tipo de prova de conceito que vale mais que certificado.

O painel do Encontro Internacional de RI em agosto de 2026 promete trazer cases reais do que está sendo feito fora. Fique de olho — principalmente nas tendências de SLMs e agents autônomos. Quem souber entregar isso com compliance embutido vai ter mercado por muito tempo.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.