O agente de dados da OpenAI: por que contexto institucional vale mais que um modelo maior

Quando um agente de IA erra uma pergunta de negócio, a reação automática é trocar o modelo. Mais parâmetros, mais contexto, mais raciocínio. É a resposta mais cara para o diagnóstico mais preguiçoso.

Um modelo pode escrever SQL impecável e ainda responder a pergunta errada. Basta escolher a tabela parecida em vez da tabela canônica, contar usuários deslogados numa métrica que deveria excluí-los ou ignorar que a definição de “cliente ativo” mudou depois de um lançamento. O erro não está na sintaxe. Está no significado.

O agente de dados interno que a OpenAI apresentou em janeiro de 2026 é interessante justamente porque deixa isso explícito. A plataforma de dados à qual ele se conecta atende mais de 3.500 usuários internos e reúne mais de 600 petabytes em 70 mil conjuntos de dados. Mas o centro da arquitetura não é o GPT-5.2 que executa o agente. São seis camadas de contexto construídas ao redor dele.

Essa é a lição importante para qualquer empresa tentando criar um agente de IA para dados, BI ou analytics: modelo é motor. Contexto institucional é o mapa, as regras de trânsito e a memória de por que a estrada existe.

As seis camadas que transformam dados em resposta

O modelo fica no meio, não no topo. A resposta nasce da combinação entre contexto histórico, significado humano, código, permissões e validação ao vivo.

A primeira camada é uso de tabelas: schema, tipos, linhagem e histórico de consultas. Ela mostra quais tabelas costumam aparecer juntas e como os dados percorrem a plataforma.

A segunda são anotações humanas. É onde o especialista registra que uma coluna tem uma exceção, que certa tabela não deve alimentar relatório financeiro ou que uma métrica tem uma definição específica. Banco de dados nenhum deduz sozinho uma regra que só existe na cabeça do time.

A terceira vem do código que produz o dado. A OpenAI usa Codex para entender definições no nível do código, inclusive escopo, frequência de atualização e lógica de geração. É uma escolha forte: schema descreve a forma; pipeline descreve a intenção. Como resume a própria equipe, o significado vive no código.

A quarta camada é conhecimento institucional recuperado de Slack, Google Docs e Notion: lançamentos, incidentes, codinomes e definições canônicas. Esse conteúdo é armazenado com metadados e permissões, não despejado num índice sem controle.

A quinta é memória. Correções e restrições não óbvias podem ser salvas para a próxima análise, em escopos pessoal ou global e com possibilidade de edição. O agente deixa de tropeçar todos os dias na mesma exceção.

A sexta é contexto de execução. Quando a informação anterior está ausente ou velha, o agente consulta o warehouse e sistemas como catálogo de metadados, Airflow e Spark para validar o estado atual.

O detalhe arquitetural que amarra tudo: as três primeiras fontes são consolidadas diariamente, convertidas em embeddings e recuperadas sob demanda. O agente não enfia 70 mil datasets no prompt. Ele busca o pedaço relevante e consulta dados ao vivo quando precisa.

Por que um modelo maior não resolve isso

Imagine duas tabelas: users_daily e active_users_daily. As duas têm user_id, date e country. Um modelo excelente entende a pergunta “quantos usuários ativos tivemos no Brasil?”. O que ele não sabe é que a primeira inclui tráfego deslogado, que a segunda ficou incompleta durante um incidente e que o board usa uma terceira definição depois de determinada data.

Esses fatos não estão no modelo. Alguns estão no código, outros num documento, outros na memória de quem corrigiu a análise anterior. Aumentar a janela de contexto só aumenta o recipiente; não cria o conteúdo que falta nem decide qual versão é canônica.

Por isso um agente de dados é menos parecido com “ChatGPT conectado ao banco” e mais parecido com um sistema operacional de conhecimento. Ele precisa descobrir, interpretar, executar, conferir e mostrar evidência. É a evolução natural do RAG agêntico: recuperar o trecho certo é só uma etapa do trabalho.

IA para BI não é um gerador de SQL

Gerar SQL é a parte demonstrável numa reunião. Confiar no resultado é a parte que decide se a ferramenta entra na operação.

A arquitetura da OpenAI traz quatro controles que uma demo costuma esconder:

• permissão por passagem: o agente só acessa tabelas que o próprio usuário já pode acessar;
• transparência: respostas resumem premissas e etapas e apontam para os resultados usados;
• avaliação contínua: perguntas relevantes têm SQL “golden”, e o sistema compara tanto a consulta gerada quanto o resultado executado;
• ferramentas sem sobreposição: a equipe reduziu ferramentas redundantes porque opções parecidas confundiam o agente e derrubavam a confiabilidade.

Esse último ponto é contraintuitivo e importante. Agentes não ficam necessariamente melhores quando recebem vinte maneiras de fazer a mesma coisa. Capacidade sem fronteira vira ambiguidade.

O mínimo para construir um agente de dados sério

Antes de escolher modelo, vector database ou interface de chat, eu fecharia cinco contratos:

1. Contrato semântico: quais métricas são canônicas, quem é o dono e desde quando cada definição vale.
2. Contrato de proveniência: toda resposta precisa ligar afirmação, consulta, tabela, versão e horário de execução.
3. Contrato de acesso: o agente herda a permissão do usuário; nunca ganha uma credencial onipotente por conveniência.
4. Contrato de memória: o que pode ser aprendido, quem aprova, qual o escopo e como uma correção é revogada.
5. Contrato de avaliação: conjunto versionado de perguntas críticas, resultados esperados e limites aceitáveis de regressão.

Sem esses contratos, o time mede a eloquência da resposta. Com eles, mede correção operacional.

O ativo real é o contexto que a empresa consegue governar

O caso da OpenAI não prova que toda companhia precisa copiar sua stack nem operar 600 petabytes. Prova algo mais útil: até a empresa que fabrica alguns dos modelos mais capazes do mundo precisou construir uma camada própria de contexto, memória, permissões e avaliação para responder perguntas sobre o próprio negócio.

Esse é exatamente o domínio do BRAIN MAKER: transformar documentos, dados, código e relações institucionais num cérebro corporativo com proveniência e governança. O agente é a interface visível; o trabalho pesado está em organizar o que ele pode saber, quando pode usar e como alguém confere.

Se a sua empresa quer sair do “chat com banco de dados” e construir IA para BI que sobreviva ao primeiro número contestado pelo financeiro, essa decisão começa na arquitetura. É o tipo de sistema que desenhamos na consultoria agêntica da Arvor.

Modelo muda todo trimestre. O significado do seu negócio não pode mudar junto com ele.