Mainstream
OpenAI Presence: operar o agente já virou o produto
A OpenAI parou de vender modelo e passou a vender operação de agente: política, guardrail, avaliação e escalonamento. Leia o que isso ensina a quem opera IA.
Leia a primeira frase do anúncio do OpenAI Presence e você entende a virada. Segundo a OpenAI, o desafio das empresas deixou de ser provar que agentes de IA funcionam e passou a ser torná-los confiáveis o bastante para fazer trabalho de valor em produção. Depois de dois anos vendendo modelo, a maior empresa de IA do mundo lançou, em 22 de julho de 2026, um produto para vender a parte difícil: operação. Para quem coloca IA em produção no Brasil, esse é o documento primário que confirma o que a gente vem repetindo. O gargalo não é o modelo. É a esteira em volta dele.
O que a OpenAI de fato anunciou
O Presence é descrito como um produto para empresas implantarem agentes que respondem perguntas, resolvem problemas, usam sistemas da companhia, tomam ações aprovadas e escalam para pessoas quando preciso. Hoje ele cobre experiências em tempo real de voz e chat, como suporte ao cliente, vendas ativas e fluxos internos de maior risco. A lógica de implantação é o ponto interessante. Cada projeto começa por um trabalho específico, como resolver uma questão de cobrança ou um chamado de TI, e o agente recebe apenas o conhecimento e o acesso que aquela tarefa exige. A empresa define as políticas: o que o agente pode fazer, quando precisa de aprovação, quando um humano assume.
Em volta do modelo, a OpenAI empacotou o que chama de componentes para rodar agentes em produção: políticas e procedimentos operacionais padrão, guardrails, ações aprovadas, simulações, ferramentas de avaliação e um processo de melhoria movido pelo Codex. Antes de ir ao ar, o time testa o agente contra pedidos comuns, casos de borda e cenários de risco, e graders checam se ele chegou ao resultado certo, seguiu a política, usou as ferramentas direito e escalou quando devia. Depois do lançamento, sessões de produção e escalonamentos revelam as falhas, e o Codex propõe ajustes que a equipe testa contra a versão em produção antes de aprovar. É o loop de avaliação e correção virando produto de prateleira.
Os números que a OpenAI colocou na mesa
O caso mais concreto é o próprio suporte da OpenAI. O Presence opera o canal de atendimento por telefone em inglês da empresa, no 1-888-GPT-0090, verificando quem liga, usando contexto de conta e tomando ações aprovadas. Segundo a OpenAI, em semanas ele atingiu ou superou os parâmetros usados para avaliar a qualidade do suporte humano de primeira linha e hoje resolve 75% dos chamados sem ajuda de pessoas. O ciclo de melhoria movido pelo Codex reduziu os repasses para humanos em 15 pontos percentuais em apenas 10 dias. Como parceiros de design, o BBVA testa suporte por voz para o dia a dia bancário no México, o SoftBank experimenta conversas naturais em japonês e a IAG mira atendimento em picos de demanda, como eventos climáticos severos.
A leitura crítica: o que isso significa na prática
Três coisas, para quem opera e não para quem faz slide.
A primeira: o diferencial competitivo saiu do modelo e foi para a operação. A própria OpenAI, que poderia vender só capacidade, escolheu vender política, guardrail, avaliação e escalonamento. Isso confirma a tese que levantamos com Cassie Kozyrkov sobre capacidade não ser segurança e com o error budget aplicado a IA. O modelo é o motor. O valor está no freio, no cinto e no airbag.
A segunda, e talvez a mais reveladora: o Presence não é self-service. A OpenAI diz explicitamente que as implantações são lideradas por seus Forward Deployed Engineers e por integradores selecionados, e que o produto ainda não está disponível de forma self-service. Traduzindo: mesmo com o melhor modelo do mundo, colocar um agente confiável em produção ainda exige engenheiro embarcado ajustando política e contexto caso a caso. Se fosse fácil, seria um botão. Não é. Guarde isso na próxima vez que um fornecedor prometer agente pronto em uma semana.
Se a dona do modelo precisa mandar engenheiro embarcado para o agente funcionar em produção, o seu projeto também vai precisar de esteira, não de fé.
A terceira: o Presence é uma peça de um movimento maior. No mesmo período, a OpenAI publicou o texto "How enterprises put AI to work", sobre a passagem da assistência para a execução, a Microsoft anunciou a fusão de Copilot, Cowork e GitHub Copilot num app só, e o Google consolidou sua oferta de agentes empresariais no Gemini Enterprise. A camada de plataforma está se organizando em torno de agentes que agem dentro da empresa. Quem escolher fornecedor sem olhar política, avaliação e escalonamento vai comprar promessa, não operação.
O que fazer com isso na segunda-feira
Não é adotar o Presence amanhã, até porque a disponibilidade é restrita. É copiar a arquitetura. Comece cada agente por um trabalho específico, dê a ele só o acesso necessário, escreva a política do que ele pode e do que exige aprovação, monte simulações e graders antes do go-live e um loop de correção depois. Defina onde o humano assume. Esse é o mesmo esqueleto que defendemos ao falar de governança que não desliga o agente. A OpenAI acabou de transformar esse esqueleto em produto e cobrar por ele. A boa notícia é que a receita está pública. A má é que executar continua dando trabalho.
Se você quer montar a esteira de política, avaliação e escalonamento antes de soltar um agente em produção, fale com a AI Boutique no WhatsApp. A gente ajuda a copiar a parte certa: a operação, não só o modelo.
Fontes
Perguntas frequentes
O que é o OpenAI Presence?
É um produto empresarial da OpenAI, anunciado em 22 de julho de 2026, para colocar agentes de IA para trabalhar em fluxos de atendimento e processos internos, hoje em voz e chat. Cada implantação começa por um trabalho específico, como resolver uma cobrança ou um chamado de TI, e o agente recebe só o conhecimento e o acesso necessários para aquela tarefa. A empresa define as políticas: o que o agente pode fazer, quando precisa de aprovação e quando um humano assume. O diferencial anunciado não é o modelo, é a camada em volta dele: políticas, guardrails, simulações, ferramentas de avaliação e um ciclo de melhoria em que o Codex propõe ajustes que o time testa e aprova antes de subir.