Quando o Agente precisa clicar na tela: computer use resolve o que a API não cobre?

Durante anos, uma das primeiras perguntas de qualquer projeto de automação foi quase obrigatória: o sistema possui API?

Se a resposta fosse sim, havia um caminho relativamente claro para consultar dados e executar ações. Se fosse não, o projeto frequentemente esbarrava em alternativas mais frágeis, como automações de navegador, RPA tradicional ou desenvolvimento específico para reproduzir ações que uma pessoa faria manualmente.

Essa lógica começa a mudar com modelos capazes de operar computadores.

A partir do GPT-5.4, a OpenAI passou a oferecer em um modelo de propósito geral capacidades nativas de computer use. Na prática, isso permite que um Agente interprete o que aparece na tela e produza ações como clicar, digitar, rolar uma página e navegar por diferentes interfaces.

A documentação também prevê arquiteturas que combinam percepção visual com ferramentas como Playwright, Selenium e outros mecanismos de automação.

Com o GPT-5.5, essa direção avançou. O modelo foi apresentado com melhorias em uso do computador, operação de softwares e trabalho entre ferramentas, enquanto o recurso `computer` também aparece entre as ferramentas suportadas pelo modelo na Responses API.

Isso não torna APIs menos importantes.

Mas muda uma limitação antiga da automação: a ausência de uma API adequada deixou de significar automaticamente que o Agente não consegue utilizar aquele sistema.

API e computer use resolvem o mesmo problema de formas diferentes

Imagine que uma empresa precise consultar um pedido dentro de um ERP.

Com uma API, o Agente pode fazer uma solicitação semelhante a:

`GET /pedidos/12345`

O sistema devolve uma estrutura previsível contendo número do pedido, cliente, produtos, valor e status.

A interface visual nem precisa existir para que a automação funcione.

Com computer use, o caminho é diferente.

O Agente pode abrir o ERP, localizar o campo de pesquisa, digitar o número do pedido, clicar em buscar, interpretar as informações exibidas e decidir o que fazer em seguida.

Para quem observa apenas o resultado, as duas abordagens podem parecer equivalentes. Tecnicamente, são bastante diferentes.

A API conversa com o sistema. O computer use opera o sistema.

Essa diferença explica tanto o potencial da tecnologia quanto suas limitações.

Por que APIs continuam sendo a primeira escolha quando existem

Uma API bem projetada oferece algo extremamente valioso para automações: previsibilidade.

O software sabe quais campos existem, quais dados devem ser enviados, qual estrutura será recebida e como sucesso ou erro serão representados.

Não é necessário localizar visualmente um botão, interpretar uma mensagem na tela ou descobrir se determinado campo mudou de posição.

Isso geralmente torna integrações por API:

• mais rápidas;
• mais previsíveis;
• mais fáceis de testar;
• mais simples de monitorar;
• melhores para grandes volumes;
• menos dependentes de mudanças visuais.

Se um Agente precisa atualizar dez mil registros em um sistema que oferece uma API adequada, dificilmente faria sentido abrir dez mil telas e repetir a operação visualmente.

A interface existe principalmente para pessoas. A API existe justamente para permitir que softwares conversem com softwares.

É a mesma lógica discutida quando explicamos por que um Agente IA precisa de ferramentas para resolver problemas de verdade. Quanto mais estruturado for o acesso à capacidade necessária, maior tende a ser o controle sobre a execução.

Por isso, computer use não deve ser entendido como substituto universal para APIs.

Seu valor aparece principalmente onde a camada programática não chega.

O problema é que grande parte do software empresarial não possui uma API adequada

Na prática, empresas trabalham com uma mistura bastante heterogênea de sistemas.

Existem ERPs antigos, portais de fornecedores, plataformas governamentais, sistemas desenvolvidos internamente há muitos anos, aplicações desktop e serviços de terceiros que expõem apenas uma pequena parte de suas funcionalidades por API.

Em alguns casos, a API existe, mas não permite executar justamente a operação necessária.

Em outros, ela depende de um plano comercial diferente, possui documentação limitada ou exige um projeto de integração desproporcional ao valor da automação.

Também existem processos nos quais um funcionário precisa transitar entre vários sistemas.

Ele recebe uma informação por e-mail, consulta um portal, copia um código, abre um ERP, preenche alguns campos e registra o resultado em outra plataforma.

A dificuldade não está necessariamente em alguma etapa isolada. Está em conectar o processo inteiro.

É nesse cenário que Agentes capazes de operar interfaces começam a abrir possibilidades interessantes.

O que mudou em relação ao RPA tradicional?

Automatizar interfaces não é uma ideia nova.

Ferramentas de RPA existem há muitos anos e conseguem reproduzir cliques, preenchimentos e sequências de ações em aplicações.

O que muda com modelos multimodais é a forma como a automação interpreta o ambiente.

Um fluxo tradicional pode depender de uma regra como:

localize determinado elemento pelo seletor configurado e clique nele.

Um Agente com capacidade visual pode receber um objetivo mais próximo da forma como uma pessoa trabalha:

encontre o cliente pelo CPF, abra o cadastro e consulte a última fatura.

O modelo observa a interface, interpreta o que está acontecendo e decide quais ações executar.

Isso aumenta a flexibilidade, principalmente quando o caminho não é exatamente igual em todas as execuções.

Também introduz imprevisibilidade.

Uma automação determinística sabe antecipadamente qual será a próxima etapa. Um Agente pode precisar decidir o próximo passo com base naquilo que encontrou.

Essa distinção entre autonomia e determinismo também aparece na escolha entre usar um Agente IA ou manter determinada etapa em um workflow.

O avanço de modelos como GPT-5.4 tornou essa abordagem mais viável

No lançamento do GPT-5.4, a OpenAI apresentou o modelo como seu primeiro modelo de propósito geral com capacidades nativas de computer use.

O modelo pode trabalhar tanto emitindo comandos de mouse e teclado a partir de screenshots quanto utilizando código para controlar interfaces por meio de ferramentas como Playwright.

No benchmark OSWorld-Verified, criado para medir a capacidade de operar ambientes de desktop por meio de screenshots e ações de teclado e mouse, o GPT-5.4 alcançou 75% de sucesso. O GPT-5.2 havia registrado 47,3%.

O resultado mostra uma evolução relevante na capacidade de operar interfaces.

Mas benchmarks precisam ser interpretados com cuidado.

Obter bom desempenho em um conjunto controlado de tarefas não significa que um Agente possa operar qualquer software empresarial indefinidamente sem falhas.

Interfaces mudam. Sites ficam lentos. Pop-ups aparecem. Sessões expiram. Um carregamento pode demorar mais que o esperado. Dois botões podem ter nomes parecidos. Uma janela pode surgir no meio do processo.

Em sistemas empresariais, também existe uma diferença enorme entre clicar no botão errado em uma tarefa de consulta e clicar no botão errado em uma operação financeira.

O avanço torna computer use uma alternativa real de arquitetura. Ele não elimina a necessidade de controlar como essa arquitetura será usada.

API ou computer use: como comparar?

| Critério | API | Computer use |

| --- | --- | --- |

| Velocidade | Geralmente maior | Geralmente menor |

| Previsibilidade | Alta | Menor |

| Estrutura dos dados | Estruturada | Precisa ser interpretada |

| Sensibilidade a mudanças visuais | Baixa | Maior |

| Sistemas sem integração | Limitada | Grande vantagem |

| Escala | Excelente | Depende do processo |

| Observabilidade | Mais simples | Exige instrumentação adicional |

| Softwares antigos | Depende da existência de integração | Pode viabilizar a operação |

| Flexibilidade diante de interfaces diferentes | Exige integrações específicas | Pode se adaptar ao que encontra |

| Controle de ações | Muito alto | Exige guardrails e validações |

A pergunta, portanto, não deveria ser simplesmente “API ou computer use?”, como se uma única tecnologia precisasse ser escolhida para toda a arquitetura.

A pergunta mais útil é:

qual é a melhor forma de executar cada etapa do processo?

Muitas arquiteturas serão híbridas

Considere um Agente responsável por processar uma solicitação comercial.

Ele recebe as informações pelo CRM através de API.

Consulta dados internos por outra ferramenta estruturada.

Verifica o cadastro do cliente.

Em determinado momento, porém, precisa acessar um portal externo que não oferece integração.

Nesse ponto, o Agente pode abrir a interface, executar a operação necessária e depois retornar ao fluxo programático.

Não existe motivo para utilizar computer use onde uma chamada de API resolve a tarefa melhor.

Também não existe motivo para abandonar uma automação inteira apenas porque uma das cinco plataformas envolvidas não oferece uma API adequada.

Essa combinação tende a ser uma das aplicações mais úteis da tecnologia:

API onde houver estrutura. Interface onde for necessário.

Quando computer use começa a fazer sentido

Um dos sinais mais claros aparece quando existe um processo manual relevante preso a um sistema legado sem integração adequada.

Outro cenário ocorre quando a API cobre apenas parte da aplicação. Talvez permita consultar clientes, por exemplo, mas determinada função administrativa exista somente no painel.

Portais de terceiros também são candidatos naturais. A empresa depende deles para executar uma operação, mas não possui qualquer controle sobre o produto e dificilmente conseguirá solicitar uma nova API ao fornecedor.

Processos de baixo ou médio volume podem justificar a abordagem pelo custo.

Construir e manter uma integração dedicada para uma tarefa realizada algumas dezenas de vezes por mês pode custar mais do que permitir que o Agente utilize uma interface existente.

Existe ainda um cenário especialmente interessante: tarefas que variam.

Se cada execução segue exatamente a mesma sequência, uma automação determinística costuma funcionar muito bem.

Quando o Agente precisa interpretar informações diferentes, reconhecer situações inesperadas e adaptar a sequência de ações conforme aquilo que encontra, a capacidade visual pode ganhar valor.

Quando provavelmente não faz sentido

Se existe uma API estável, documentada e capaz de executar exatamente a operação necessária, ela tende a continuar sendo a melhor escolha.

O mesmo vale para processos de altíssimo volume ou muito sensíveis à latência.

Também é preciso cautela quando uma única ação incorreta possui consequências graves.

Imagine permitir que um Agente navegue livremente por um sistema financeiro com autorização para confirmar pagamentos, alterar dados bancários ou conceder permissões administrativas.

A capacidade de clicar na interface não elimina a necessidade de controle.

Na realidade, torna essa camada ainda mais importante.

A documentação de computer use da OpenAI recomenda utilizar ambientes isolados, definir previamente quais sites, contas e ações o Agente pode acessar e manter participação humana para ações de maior impacto.

Isso se conecta diretamente ao problema de quando deixar um Agente agir sozinho e quando exigir aprovação humana.

O desafio deixa de ser apenas integrar e passa a ser governar

Quando uma API é construída especificamente para uma automação, as permissões podem ser bastante restritas.

Uma credencial pode permitir apenas consultar pedidos, atualizar um campo específico ou criar determinadas entidades.

Ao fornecer acesso a uma interface, o Agente pode potencialmente enxergar tudo aquilo que o usuário daquela conta consegue enxergar.

Por isso, autenticação, perfis de acesso, isolamento, logs e políticas de confirmação passam a fazer parte da própria arquitetura.

A identidade utilizada pelo Agente também importa.

Uma operação fica muito mais difícil de auditar quando Agentes e funcionários compartilham as mesmas credenciais. Ter contas separadas, permissões limitadas e registros de execução ajuda a responder uma pergunta básica depois de qualquer incidente: quem fez o quê?

Esse é o mesmo problema tratado ao discutir identidade, permissões e responsabilidade em Agentes IA.

A documentação da OpenAI também recomenda que a confirmação aconteça no ponto em que a próxima ação cria risco externo. Isso inclui situações como envio de informações, exclusão ou alteração de dados, mudança de acesso e confirmação de operações financeiras.

A aprovação humana não precisa interromper cada clique.

Ela precisa aparecer onde uma decisão realmente muda o risco da operação.

A própria interface pode tentar manipular o Agente

Existe outro problema particular quando o Agente interpreta páginas, documentos, e-mails e outras interfaces.

O conteúdo encontrado durante a execução pode conter instruções destinadas a manipular o modelo.

Uma página pode, por exemplo, apresentar um texto dizendo ao Agente para ignorar suas regras anteriores, acessar outra área do sistema ou enviar determinada informação.

Para uma pessoa, aquilo pode parecer apenas texto exibido na tela.

Para um modelo de linguagem, também é linguagem.

Por isso, a documentação recomenda tratar conteúdo de páginas, screenshots, PDFs, e-mails, chats e resultados de ferramentas como informação não confiável. Encontrar uma instrução em uma página não significa receber autorização para executá-la.

Esse problema é conhecido como prompt injection indireta e merece tratamento próprio. O post sobre como sites, PDFs e e-mails podem manipular um Agente IA aprofunda justamente esse risco.

Portanto, permitir que um Agente opere um computador não significa simplesmente fornecer usuário e senha e deixá-lo trabalhar.

Significa definir onde ele pode entrar, quais informações pode utilizar, o que pode executar, quais ações exigem confirmação e como cada etapa será registrada.

Como avaliar se vale a pena usar computer use em um processo

Antes de decidir pela abordagem, algumas perguntas ajudam a separar um bom caso de uso de uma automação desnecessariamente frágil:

1. Existe uma API capaz de executar a operação?

2. A API cobre toda a tarefa ou apenas parte dela?

3. Qual é o volume de execuções esperado?

4. Quanto custa construir e manter uma integração dedicada?

5. A interface muda com frequência?

6. O Agente precisa apenas consultar ou também alterar informações?

7. Qual é o impacto de uma ação incorreta?

8. É possível limitar a conta utilizada pelo Agente?

9. Existe uma forma confiável de registrar e verificar o resultado?

10. Alguma etapa deveria exigir aprovação humana?

A resposta pode levar a três arquiteturas diferentes.

Em uma delas, tudo acontece por API.

Em outra, computer use assume praticamente toda a operação porque o sistema só pode ser acessado visualmente.

Na terceira, provavelmente a mais interessante para muitas empresas, o fluxo mistura os dois métodos.

A ausência de API deixa de ser uma barreira absoluta

Talvez essa seja a principal mudança.

Durante muito tempo, encontrar um sistema importante sem API significava redesenhar o processo, construir uma integração específica, introduzir RPA ou aceitar que aquela etapa continuaria manual.

Com modelos capazes de enxergar e operar interfaces, surge uma alternativa.

Ela não é necessariamente tão rápida quanto uma API.

Não é tão previsível.

E não deveria substituir uma integração estruturada quando essa integração já resolve bem o problema.

Mas existe uma diferença enorme entre “essa não é a melhor maneira de integrar” e “essa automação não pode ser feita”.

Computer use começa a ocupar justamente esse espaço.

Um Agente pode conversar com sistemas modernos através de APIs, utilizar ferramentas estruturadas sempre que disponíveis e recorrer à interface visual nas etapas em que nenhuma dessas opções existe.

Isso amplia consideravelmente o conjunto de processos empresariais que podem ser automatizados.

Antes de iniciar o desenvolvimento de uma nova integração, vale fazer uma pergunta que poucos anos atrás teria utilidade limitada:

esse sistema realmente precisa expor uma API para que o Agente consiga utilizá-lo ou a própria interface pode fazer parte da arquitetura?

A resposta não será sempre computer use. Em muitos casos, continuará sendo API.

A diferença é que agora existe outra opção.

Fontes

OpenAI: Introducing GPT-5.4

OpenAI: Introducing GPT-5.5

OpenAI API: Computer use

OpenAI API: GPT-5.4 Model

OpenAI API: GPT-5.5 Model