O Computer Using Agent (CUA) é uma abordagem da OpenAI para fazer a IA operar sites e aplicativos como uma pessoa, olhando a tela e usando cliques e digitação, em vez de depender de integrações via API. Na prática, isso abre automações em ferramentas que não oferecem APIs, mas ainda exige supervisão, principalmente em ações sensíveis como logins e pagamentos.
O que muda com o CUA
O CUA é um modelo treinado para interagir com interfaces gráficas, como botões, menus, abas e campos de texto, diretamente na tela. Em vez de “conversar” com um sistema por uma API, ele tenta executar a tarefa do jeito mais universal: vendo o que aparece e agindo com mouse e teclado.
O diferencial é a versatilidade. Se um site muda levemente o layout, ou se um aplicativo não tem documentação, a ideia é que o agente ainda consiga se virar, tentando caminhos alternativos e corrigindo o curso quando encontra erros.
Onde ele é mais útil
Uma boa forma de enxergar o CUA é como uma ponte para o “mundo sem API”. Exemplos típicos:
- Backoffice legado: sistemas internos com navegação toda em tela, sem integração oficial.
- Rotinas repetitivas: cadastrar produtos, baixar relatórios, preencher formulários recorrentes.
- Fluxos multi-site: copiar informação de um portal e registrar em outro.
Exemplo prático rápido
Imagine um time financeiro que precisa baixar todo mês um extrato em um portal que só funciona via interface web. Um fluxo típico com CUA seria: abrir o site, navegar até “Relatórios”, selecionar o período, exportar em CSV, salvar, e então avisar o usuário para conferir se o arquivo corresponde ao mês correto antes de anexar em um e-mail.
Visual vira ação no navegador

Por baixo do capô, o CUA trabalha em ciclos curtos: ele observa a tela, decide o próximo passo e executa uma ação, repetindo até concluir ou até pedir ajuda. Esse formato é o que permite lidar com interfaces “vivas”, onde elementos mudam de lugar e estados (carregando, erro, confirmação) aparecem no meio do caminho.
1) Leitura do estado da tela
O agente recebe uma captura do que está visível e identifica pontos relevantes para a tarefa, como caixas de busca, botões de avançar, mensagens de erro e campos obrigatórios.
2) Planejamento do próximo passo
Com base no objetivo e no que acabou de ver, ele escolhe uma ação específica, por exemplo clicar em um botão, rolar a página, abrir um menu, ou digitar em um campo. Se um caminho falha, ele tenta alternativas, como voltar, buscar outra seção do site, ou refazer um preenchimento.
3) Execução com controles virtuais
As ações são realizadas como se fossem comandos de mouse e teclado. Em tarefas delicadas, como inserir credenciais, lidar com CAPTCHA ou confirmar uma ação com impacto externo, o comportamento esperado é pedir confirmação do usuário.
O que os benchmarks dizem na prática
Os números mais citados para o CUA vêm de benchmarks que tentam medir o quanto um agente consegue “se virar” em ambientes reais. A leitura importante aqui é: em tarefas simples e bem delimitadas, o desempenho tende a ser alto, já em tarefas longas e cheias de exceções, a confiabilidade ainda cai.
| Benchmark | O que mede | Resultado reportado |
|---|---|---|
| OSWorld | Uso de computador em tarefas mais amplas (sistema operacional e apps) | 38,1% de sucesso |
| WebArena | Navegação em sites offline auto-hospedados (cenários tipo e-commerce, CMS, fóruns) | 58,1% de sucesso |
| WebVoyager | Navegação em sites ao vivo (ex.: Amazon, GitHub, Google Maps) | 87% de sucesso |
Regra de decisão para usar ou não usar
- Tem API estável: prefira integração via API, costuma ser mais barata, mais rápida e mais auditável.
- Não tem API: CUA faz sentido quando o trabalho é essencialmente “clicar e preencher”, com impacto controlado.
- Alto risco: mantenha humano no loop, com confirmação obrigatória antes de envio, compra, mudança de senha, ou qualquer ação irreversível.
Mini-modelo de mercado para entender o momento
Um jeito simples de posicionar agentes de “uso de tela” é pela tríade Cobertura, Custo e Confiança. A promessa do CUA é aumentar cobertura, porque funciona onde não existe API, mas o custo operacional pode subir com supervisão, e a confiança ainda depende de boas travas de segurança e de tarefas bem escolhidas.
Onde isso aparece no ChatGPT hoje
A OpenAI lançou o Operator como prévia de pesquisa em janeiro de 2025, inicialmente para assinantes Pro nos Estados Unidos. Em 17 de julho de 2025, a OpenAI informou que o Operator foi integrado ao ChatGPT como “agent mode”, e que o site separado do Operator seria descontinuado ao longo das semanas seguintes.
Na prática, o acesso tende a acontecer pelo próprio ChatGPT, com a experiência de agente dentro do produto. Para referência, o endereço histórico do Operator era Operator, que hoje redireciona para o ChatGPT com dica de modo agente, e o anúncio oficial está em Introducing Operator.
Links úteis para aprofundar
Segurança e limites que importam
Quando um agente ganha capacidade de navegar e agir em sites, o risco deixa de ser só “responder errado” e vira “fazer algo errado”. Por isso, a OpenAI descreve camadas de mitigação no Operator System Card, incluindo bloqueios, recusa de solicitações indevidas e pedidos de confirmação antes de ações sensíveis.
Principais categorias de risco
- Uso indevido: tentativas de orientar o agente para atividades proibidas, golpes ou automações maliciosas.
- Erros de execução: clicar no lugar errado, preencher campo incorreto, ou interpretar mal um elemento da tela.
- Ataques no ambiente: conteúdos que tentam enganar o agente, como prompt injection em páginas e phishing disfarçado.
O que esperar na prática
Mesmo quando funciona bem, um agente desse tipo não é “piloto automático” para tudo. Ele tende a brilhar em tarefas repetitivas com começo, meio e fim claros, e ainda exige governança: quais sites pode acessar, quais ações pode executar, quando precisa parar e pedir revisão, e como registrar logs para auditoria.
