Como a OpenAI construiu um agente de dados com apenas dois engenheiros e hoje atende milhares de funcionários
Imagine precisar encontrar uma informação específica em um mar de 70.000 datasets, escrever queries SQL na mão, validar schemas de tabelas e ainda montar gráficos bonitos para apresentar os resultados. Até pouco tempo atrás, esse era o dia a dia dos analistas da OpenAI. Um simples comparativo de receita entre regiões geográficas e segmentos de clientes podia consumir horas de trabalho pesado. Hoje, esse mesmo analista abre o Slack, digita uma pergunta em inglês simples e recebe um gráfico pronto em minutos. A ferramenta por trás dessa transformação foi construída por apenas dois engenheiros em três meses, teve 70% do código escrito por inteligência artificial e agora é usada diariamente por milhares de funcionários da empresa.
Em entrevista exclusiva ao VentureBeat, Emma Tang, líder de infraestrutura de dados da OpenAI, abriu os bastidores do sistema e explicou como ele funciona, onde falha e o que sinaliza sobre o futuro dos dados corporativos. A conversa, junto com o blog post oficial da empresa sobre a ferramenta, revela algo que toda organização vai precisar encarar em breve: o gargalo para ter empresas mais inteligentes não são modelos melhores. São dados melhores.
Uma interface em linguagem natural para 600 petabytes de dados corporativos
Para entender por que a OpenAI decidiu construir esse sistema, é preciso dimensionar o tamanho do problema. A plataforma de dados da empresa abrange mais de 600 petabytes distribuídos em 70.000 datasets diferentes. Só encontrar a tabela certa para responder uma pergunta podia consumir horas do tempo de um cientista de dados experiente. O time de Data Platform da Emma Tang, que faz parte da infraestrutura da empresa e cuida de sistemas de big data, streaming e camada de ferramentas de dados, atende uma base interna impressionante.
A OpenAI tem cerca de 5.000 funcionários atualmente. Mais de 4.000 deles usam ferramentas de dados fornecidas pelo time da Tang. Isso significa que mais de 80% da empresa depende diretamente dessa infraestrutura no dia a dia.
O agente foi construído sobre o GPT-5.2 e está disponível onde os funcionários já trabalham: Slack, uma interface web, IDEs, o Codex CLI e o aplicativo interno do ChatGPT. O usuário digita uma pergunta em linguagem natural e recebe de volta gráficos, dashboards interativos e relatórios analíticos completos. A equipe estima que cada consulta economiza entre duas e quatro horas de trabalho. Mas Tang fez questão de destacar que o ganho mais difícil de medir é também o mais importante: o agente dá às pessoas acesso a análises que simplesmente não conseguiriam fazer antes, independentemente de quanto tempo tivessem disponível.
Engenheiros, times de growth, produto e até equipes não técnicas que não conhecem todos os detalhes dos sistemas de dados e schemas das tabelas agora conseguem extrair insights sofisticados por conta própria 🎯
De comparativos de receita a debugging de latência, um único agente faz tudo
Tang apresentou vários casos de uso concretos que ilustram a versatilidade do sistema. O time de finanças da OpenAI usa o agente para comparar receita entre regiões geográficas e segmentos de clientes. Nas palavras dela, basta enviar a pergunta em texto simples e o agente responde com gráficos, dashboards e todo tipo de visualização.
Mas o poder real aparece nas análises estratégicas com múltiplas etapas. Tang descreveu um caso recente em que um usuário identificou discrepâncias entre dois dashboards que acompanhavam o crescimento de assinantes Plus. O agente de dados conseguiu gerar um gráfico mostrando, posição por posição, exatamente quais eram as diferenças. Acabaram sendo cinco fatores distintos causando a divergência. Para um humano, essa investigação levaria horas ou até dias. O agente resolveu em poucos minutos.
Product managers usam a ferramenta para entender adoção de funcionalidades. Engenheiros usam para diagnosticar regressões de performance — perguntando, por exemplo, se um componente específico do ChatGPT realmente ficou mais lento que no dia anterior e, se sim, quais componentes de latência explicam a mudança. O agente consegue detalhar tudo e comparar com períodos anteriores a partir de um único prompt.
O que torna esse sistema especialmente diferente é que ele opera através de fronteiras organizacionais. A maioria dos agentes de IA corporativos existentes hoje fica isolada dentro de departamentos específicos — um bot para finanças aqui, outro para RH ali. O agente da OpenAI corta horizontalmente toda a empresa. Tang explicou que o lançamento foi feito departamento por departamento, com memória e contexto curados para cada grupo, mas que em determinado momento tudo converge para o mesmo banco de dados. Um líder sênior pode combinar dados de vendas com métricas de engenharia e analytics de produto em uma única consulta.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Como o Codex resolveu o problema mais difícil dos dados corporativos
Encontrar a tabela certa entre 70.000 datasets é, segundo a própria Tang, o maior desafio técnico que sua equipe enfrenta. E é exatamente aí que o Codex — o agente de programação da OpenAI — desempenha seu papel mais engenhoso.
O Codex cumpre três funções no sistema. Primeiro, os usuários acessam o agente de dados através do Codex via MCP. Segundo, a equipe usou o Codex para gerar mais de 70% do código do próprio agente, permitindo que dois engenheiros entregassem o projeto em três meses. Mas a terceira função é a mais fascinante do ponto de vista técnico: um processo diário e assíncrono em que o Codex examina tabelas de dados importantes, analisa o código dos pipelines que alimentam essas tabelas e determina dependências upstream e downstream, propriedade, granularidade, chaves de junção e tabelas similares para cada uma delas.
Tang explicou o processo de forma direta: a equipe fornece um prompt, o Codex examina o código e responde com as informações necessárias, que são então persistidas no banco de dados. Quando um usuário pergunta sobre receita, o agente busca em um banco de dados vetorial para encontrar quais tabelas o Codex já mapeou para aquele conceito.
Esse processo, chamado de Codex Enrichment, é uma das seis camadas de contexto que o agente utiliza. As camadas vão desde metadados básicos de schema e descrições curadas por especialistas até conhecimento institucional extraído do Slack, Google Docs e Notion, além de uma memória de aprendizado que armazena correções de conversas anteriores. Quando nenhuma informação prévia existe, o agente recorre a consultas ao vivo contra o data warehouse.
A equipe também classifica padrões de consultas históricas por níveis de relevância. Tang explicou que todo histórico de queries inclui muitos comandos simples do tipo select star limit 10, que não são realmente úteis. Dashboards canônicos e relatórios executivos — onde analistas investiram esforço significativo para determinar a representação correta dos dados — são marcados como fonte de verdade. Todo o resto é desprioritizado.
O prompt que força a IA a desacelerar e pensar antes de agir
Mesmo com seis camadas de contexto sofisticadas, Tang foi notavelmente honesta sobre a maior falha comportamental do agente: excesso de confiança. É um problema que qualquer pessoa que já trabalhou com large language models vai reconhecer imediatamente.
Tang descreveu o cenário assim: o que o modelo costuma fazer é se sentir confiante demais. Ele diz que encontrou a tabela certa e sai gerando análises imediatamente. E essa abordagem apressada é justamente o caminho errado.
A solução veio por meio de engenharia de prompt que força o agente a permanecer mais tempo em uma fase de descoberta. Tang explicou que, quanto mais tempo o agente passa explorando cenários possíveis e comparando qual tabela usar — apenas investindo mais tempo na fase de descoberta — melhores são os resultados. O prompt funciona quase como orientar um analista júnior: antes de sair correndo com uma análise, o sistema é instruído a fazer mais validações sobre se aquela é realmente a tabela correta e a checar mais fontes antes de gerar dados concretos.
A equipe também descobriu, por meio de avaliações rigorosas, que menos contexto pode gerar resultados melhores. Tang explicou que é muito tentador despejar tudo que se tem disponível e esperar que o modelo se saia melhor. Mas nas avaliações, o time descobriu o oposto. Quanto menos informação você fornece, desde que ela seja curada e precisa, melhor o desempenho do agente.
Para construir confiança com os usuários, o agente transmite seu raciocínio intermediário em tempo real, mostra quais tabelas selecionou e por que, e fornece links diretos para os resultados das queries. Os usuários podem interromper o agente no meio da análise para redirecioná-lo. O sistema também cria checkpoints do progresso, permitindo retomar o trabalho após falhas. E ao final de cada tarefa, o modelo avalia seu próprio desempenho. A equipe pergunta ao modelo como ele acha que foi, se o resultado ficou bom ou ruim. E segundo Tang, o modelo é surpreendentemente bom em avaliar a própria performance.
Guardrails simples que funcionam surpreendentemente bem
Quando o assunto é segurança, Tang adotou uma abordagem pragmática que pode surpreender empresas que esperam técnicas sofisticadas de AI alignment.
A filosofia dela é direta: às vezes você precisa de guardrails até meio simples. O sistema possui controle de acesso rigoroso. Ele sempre usa o token pessoal do funcionário, então cada pessoa só tem acesso exatamente ao que suas permissões já permitiam antes. O agente funciona puramente como uma camada de interface, herdando as mesmas permissões que já governam os dados da OpenAI.
O agente nunca aparece em canais públicos — apenas em canais privados ou na interface individual do usuário. Acesso de escrita é restrito a um schema temporário de testes que é periodicamente apagado e não pode ser compartilhado. Tang também enfatizou que o sistema não tem permissão para escrever aleatoriamente em outros sistemas.
O feedback dos usuários fecha o ciclo. Funcionários sinalizam resultados incorretos diretamente, e o time investiga. A autoavaliação do modelo adiciona mais uma camada de verificação. A longo prazo, Tang disse que o plano é migrar para uma arquitetura multi-agente, onde agentes especializados monitoram e auxiliam uns aos outros. Mas mesmo no estado atual, o sistema já avançou bastante.
Por que a OpenAI não vai vender essa ferramenta, mas quer que você construa a sua
Apesar do potencial comercial óbvio, a OpenAI confirmou ao VentureBeat que não tem planos de transformar seu agente de dados interno em um produto. A estratégia é fornecer os blocos de construção e deixar que as empresas criem suas próprias soluções. Tang deixou claro que tudo que seu time usou para construir o sistema já está disponível externamente.
Nas palavras dela: a equipe usa as mesmas APIs disponíveis publicamente — a Responses API, a Evals API. Não existe um modelo fine-tuned. Eles simplesmente usam o GPT-5.2. Então sim, qualquer empresa pode construir algo similar.
Essa mensagem está alinhada com a estratégia mais ampla da OpenAI para o mercado corporativo. A empresa lançou o OpenAI Frontier no início de fevereiro, uma plataforma completa para empresas construírem e gerenciarem agentes de IA. Desde então, firmou parcerias com McKinsey, Boston Consulting Group, Accenture e Capgemini para ajudar a vender e implementar a plataforma. A AWS e a OpenAI estão desenvolvendo em conjunto um Stateful Runtime Environment para o Amazon Bedrock, que replica algumas das capacidades de contexto persistente que a OpenAI construiu em seu agente de dados. E a Apple recentemente integrou o Codex diretamente ao Xcode.
Segundo dados compartilhados com o VentureBeat, o Codex é usado por 95% dos engenheiros da OpenAI e revisa todos os pull requests antes de serem mergeados. A base de usuários ativos semanais globais triplicou desde o início do ano, ultrapassando um milhão. O uso geral cresceu mais de cinco vezes.
Tang descreveu uma mudança na forma como os funcionários usam o Codex que vai muito além da programação. Segundo ela, o Codex não é mais apenas uma ferramenta de codificação. Equipes não técnicas usam para organizar pensamentos, criar apresentações e gerar resumos diários. Uma de suas gerentes de engenharia configurou o Codex para revisar suas anotações todas as manhãs, identificar as tarefas mais importantes, puxar mensagens do Slack e DMs, e rascunhar respostas. O sistema está literalmente operando em nome dela de várias formas.
O pré-requisito nada glamouroso que vai definir quem vence a corrida dos agentes de IA
Quando perguntada sobre o que outras empresas deveriam aprender com a experiência da OpenAI, Tang não apontou para capacidades de modelos ou engenharia de prompt sofisticada. Ela apontou para algo muito mais mundano.
Suas palavras foram diretas: governança de dados é extremamente importante para que agentes de dados funcionem bem. Os dados precisam estar limpos o suficiente e anotados o suficiente, e precisa existir uma fonte de verdade em algum lugar para que o agente consiga navegar.
A infraestrutura subjacente — armazenamento, computação, orquestração e camadas de business intelligence — não foi substituída pelo agente. Ele ainda precisa de todas essas ferramentas para fazer seu trabalho. Mas funciona como um ponto de entrada fundamentalmente novo para inteligência de dados, mais autônomo e acessível do que qualquer coisa que existia antes.
Tang encerrou a entrevista com um alerta para empresas que hesitam. Segundo ela, as organizações que adotarem esse tipo de solução vão colher benefícios muito rapidamente. E as que não adotarem vão ficar para trás. A distância entre os dois grupos vai aumentar. As empresas que usarem essa tecnologia vão avançar muito, muito rápido.
Quando perguntada se essa aceleração preocupava seus próprios colegas — especialmente depois de uma onda recente de demissões em empresas como a Block — Tang fez uma pausa e respondeu: o quanto a OpenAI consegue fazer como empresa acelerou significativamente, mas isso ainda não chega nem perto de corresponder às ambições da companhia.
As lições práticas para quem quer replicar esse modelo
O caso da OpenAI traz aprendizados valiosos para qualquer organização que esteja pensando em construir agentes de dados internos. O primeiro e mais importante é que a qualidade dos dados importa mais do que a sofisticação do modelo. De nada adianta ter acesso ao modelo mais avançado do mercado se seus datasets estão desorganizados, mal documentados e sem uma fonte de verdade clara.
O segundo aprendizado é que equipes pequenas podem entregar resultados enormes quando apoiadas por ferramentas de IA adequadas. Dois engenheiros em três meses, com 70% do código gerado por inteligência artificial, produziram um sistema que atende milhares de pessoas. Isso redefine completamente o que é possível em termos de velocidade de desenvolvimento.
O terceiro ponto é sobre a importância de forçar o agente a desacelerar. A tendência natural dos LLMs é responder rápido e com confiança, mesmo quando deveriam estar investigando mais. Investir em prompts que incentivem uma fase de descoberta mais longa e criteriosa pode ser a diferença entre respostas úteis e respostas perigosamente erradas.
Por fim, guardrails não precisam ser complexos para serem eficazes. Controle de acesso baseado em tokens pessoais, restrição de escrita, operação apenas em canais privados e feedback contínuo dos usuários formam uma camada de segurança simples, mas que funciona na prática. A sofisticação pode — e deve — vir com o tempo, mas não precisa ser um pré-requisito para começar.
Estamos entrando em uma era onde o papel do analista de dados muda radicalmente. Menos tempo escrevendo SQL e mais tempo formulando as perguntas certas, interpretando resultados e garantindo que a infraestrutura de dados esteja saudável. O agente não substitui pessoas, mas transforma profundamente o que se espera delas 🚀
