Um agente de IA que navega na web é o último recurso, não o primeiro
Um agente de IA que navega na web faz exatamente o que o nome promete: abre um browser, olha para o ecrã, move o cursor, escreve e clica, tal como faria uma pessoa. E é aí que está a armadilha, porque soa a solução universal: se uma pessoa consegue, o agente consegue. É verdade e é irrelevante. Uma pessoa também consegue copiar mil linhas à mão. Que algo seja possível não o torna a forma sensata de o fazer.
A tese, sem rodeios: o browser é o plano D. À frente vão a API do sistema do outro lado, a integração por conector ou iPaaS e — com mais frequência do que se admite — uma pessoa a dedicar dez minutos por dia a algo que não justifica automatizar nada. O browser só entra quando as três estão realmente fechadas. As vias limpas estão em integrar a IA com os teus sistemas: esse guia descarta tudo o que não seja uma porta onde ligar a ficha, e este começa exatamente onde aquele pára, no caso que descarta.
A razão para tanto cuidado é que esta via não falha por causa do modelo. Falha por causa de coisas fora do teu controlo: o ecrã de outro, a sessão de outro, as regras de outro. Podes fazer tudo bem e acordar numa terça-feira com o processo parado porque alguém mudou um botão de sítio.
Os três casos em que não há outra porta
Há situações em que o browser não é preguiça: é o único que resta. Reconhecem-se por um sinal comum — não é que a API ainda não exista, é que não vai existir.
- O portal do fornecedor ou do cliente grande. Obrigam-te a entrar na extranet deles para carregar guias de remessa, descarregar liquidações ou confirmar encomendas. Não há API, não vai haver, e o teu volume não dá para que construam uma para ti. A relação comercial vai numa direção e não é a tua.
- O Estado. Portais de submissão, plataformas de contratação pública, registos. Aqui o acesso está pensado para uma pessoa com o seu certificado, e o caminho automatizado ou não existe ou exige uma integração formal que demora meses a ser concedida. Atenção a assumir que público significa aberto: não é a mesma coisa.
- O sistema interno antigo. Aquele ERP de 2009, a aplicação de secretária do armazém, o programa instalado por um fornecedor que fechou. Tem base de dados, mas ninguém assina para lhe tocar; tem ecrã, e o ecrã funciona. A API não existe porque não existe orçamento para a construir, o que é uma forma perfeitamente válida de não existir.
O contra-exemplo conta tanto como os casos. Se o fornecedor tem API e não ta deu porque está noutro escalão de preço, isso não é um problema técnico: é uma negociação. Montar um agente que navega para não pagar o conector costuma sair mais caro em manutenção no primeiro ano do que o próprio conector, e ainda te deixa do lado incómodo das condições de utilização deles. Antes de escrever a primeira linha, pede o preço. Às vezes a automatização mais rentável é um email a um comercial.
O que parte sempre: cinco falhas que não dependem de ti
Estas cinco não são riscos hipotéticos que talvez apareçam. São o calendário de manutenção de qualquer agente que viva no browser de outro. Quem te vender isto sem as mencionar nunca o teve em produção.
- A interface muda e ninguém te avisa. Não há versionamento, não há nota de versão, não há período de graça. Um redesenho, um campo obrigatório novo ou um aviso de cookies diferente e o fluxo pára a meio. Com uma API partida dás por isso por um código de erro; aqui dás por isso porque alguém pergunta porque é que as faturas não chegaram.
- A sessão expira e o segundo fator não negoceia. Manter um agente autenticado num sistema de terceiros é o problema aborrecido que leva metade do tempo de operação. Se o acesso exige um código de uso único, uma aplicação no telemóvel de alguém ou um certificado num cartão, há uma pessoa no circuito por desenho. Isso não é uma falha do agente: é uma decisão de segurança da outra parte, e é legítima.
- O captcha e as condições de utilização. O captcha não é um obstáculo técnico que se contorna: é a outra parte a dizer explicitamente que não quer tráfego automatizado. Ultrapassá-lo costuma quebrar os termos do serviço e, consoante o contexto, algo mais do que os termos. Quando aparece um captcha, a conversa certa não é com a equipa técnica, é com quem assina o contrato.
- A página que ele lê também lhe pode dar ordens. Um agente que navega não distingue de forma fiável o conteúdo que lhe pedes para ler de uma instrução escondida nesse conteúdo. Não é um problema de maturidade prestes a resolver-se: a OpenAI declarou em dezembro de 2025 que a injeção de prompt, tal como as burlas e a engenharia social, dificilmente alguma vez será resolvida por completo (TechCrunch, 22 de dezembro de 2025), e a Anthropic publicou os seus resultados de robustez em navegação com um aviso explícito de que nenhum agente de browser é imune (Anthropic, 24 de novembro de 2025). A consequência prática é de arquitetura, não de prompt: o agente só pode fazer estragos até onde chegam as suas credenciais.
- O custo e o relógio contam-se por passo. Cada passo é uma captura de ecrã, uma decisão do modelo e uma ação. Uma tarefa de doze passos são doze decisões com imagem, não uma chamada. O que por API é um pedido de milissegundos, aqui são minutos e um consumo que cresce a cada nova tentativa.
Porque é que a pontuação do benchmark não prevê a tua
Os números públicos desta categoria são melhores do que muita gente pensa e piores do que a demo sugere. No WebArena, o banco de ensaio de referência, o melhor sistema registado na tabela pública anda pelos 74 % de tarefas concluídas contra os 78 % que uma pessoa consegue (Steel.dev, tabela WebArena). A OpenAI reportou para o seu agente de uso de computador 87 % no WebVoyager e 58,1 % no WebArena nos testes internos. São números respeitáveis para um problema difícil.
O problema é o que medem. Esses bancos de ensaio correm sobre réplicas de sites públicos, pelo caminho bom, sem autenticação corporativa, sem segundo fator, sem captcha e — isto é o importante — sem consequência. Um clique errado num benchmark acrescenta uma falha a uma tabela. Um clique errado no portal do teu fornecedor confirma uma encomenda de onze mil euros. Não há forma de transportar uma percentagem do primeiro para o segundo, por isso não tentes: o único dado que vale é o teu, medido no teu portal, com os teus casos reais, durante duas semanas em modo de observação.
Traduzido em decisão: não compres pela demo nem pela tabela. Pede um ensaio no teu ecrã, com os casos estranhos incluídos — o fornecedor que escreve o número da fatura com um hífen, a encomenda com duas linhas anuladas — e conta quantas vezes é preciso resgatá-lo. Essa percentagem é que determina se o processo te poupa trabalho ou se apenas to muda de sítio.
As quatro condições para pôr isto em produção
Se o caso é legítimo e o ensaio correu razoavelmente, falta ainda a parte que separa uma experiência de algo que pode ficar a trabalhar sozinho. São quatro condições e não são opcionais: com três em quatro, isto não vai para produção.
- Ação reversível. O agente só executa coisas que se possam desfazer sem telefonar a ninguém: descarregar, ler, preencher um rascunho, guardar sem enviar. Confirmar, pagar, assinar e cancelar ficam fora do âmbito automático desde o primeiro dia, por muito capaz que o agente seja de os clicar.
- Limite de passos rígido. Um teto de ações por tarefa que, ao ser atingido, pára e avisa. Sem ele, um agente perdido num ecrã que não percebe volta a tentar até esgotar o orçamento, e o primeiro aviso de que algo corria mal chega na fatura.
- Registo de cada ação. Captura de ecrã ou registo do que viu e do que clicou, em cada passo, guardado fora da sessão. Não é burocracia: é a única coisa que permite reconstruir o que aconteceu quando o fornecedor diz que se confirmou uma encomenda de que ninguém se lembra. Sem prova não há auditoria, e sem auditoria isto não é um sistema, é uma aposta.
- Pessoa no que é irreversível. O passo que compromete dinheiro, envia algo a um terceiro ou muda um estado que não se pode reverter passa por uma pessoa que vê o que vai acontecer e aprova. Com contexto suficiente para decidir em dez segundos, não uma janela que se fecha por inércia.
As duas últimas condições não são específicas desta via: são as mesmas que regem que permissões dar a um agente de IA e quanta autonomia lhe dar. O que muda aqui é a margem: quando o agente atua no ecrã de outro, com a credencial de um empregado teu, o erro não fica em casa.
A ordem de decisão, numa tarde
Quatro perguntas, por esta ordem. A primeira que der um sim decide, e se chegares à quarta já sabes ao que te expões.
- Há API e podem dar-ta? Se existe, mesmo que paga, pede o preço antes de programar seja o que for. Um conector aborrecido ganha a um agente brilhante que parte a cada redesenho.
- Há uma integração já feita — conector, iPaaS, exportação agendada? A exportação noturna para um ficheiro, de que ninguém se gaba numa demo, resolve mais processos do que parece, e não parte.
- Quanto trabalho humano há aqui de verdade? Dez minutos por dia não pagam a manutenção de um agente que navega. Mede-o antes de decidir; às vezes o resultado do exercício é não automatizar, e é uma resposta perfeitamente boa.
- Se chegaste até aqui, cumprem-se as quatro condições? Reversível, teto de passos, registo de tudo e pessoa no irreversível. Se alguma falhar, o processo não está pronto, e forçá-lo é comprar um risco para poupar um trâmite.
Chegamos a esta via com relutância e usamo-la quando é caso disso, que é mais vezes do que gostaríamos: boa parte da Europa ainda fatura contra portais sem API. Quando é o caso, montamo-la com as quatro condições postas desde o primeiro dia e com a manutenção orçamentada, porque o que mata estes projetos não é construí-los, é o terceiro redesenho. É isso que está por baixo da automatização de operações e da infraestrutura de IA empresarial quando o processo tem de conviver com sistemas que já estão em produção. As restantes decisões da montagem — permissões, autonomia, memória, canal — estão em criar um agente de IA que aguente produção.