Do vídeo de demo à automação de verdade
Há um ano e meio, Computer Use ainda era uma demo da Anthropic: uma IA mexe um cursor de mouse, clica em botões, digita em campos. Impressionante, mas lento, sujeito a erros e dificilmente usável em produção. Hoje, na primavera de 2026, os agentes de navegador chegaram a um nível de maturidade que torna workflows reais automatizáveis.
Já usamos eles em vários projetos de cliente – para migrações de dados, tarefas de pesquisa e integrações com sistemas que não oferecem API. Nem todo caso de uso virou automatizável de uma hora para outra. Mas a lista de aplicações que fazem sentido cresceu bastante.
Como a tecnologia mudou
A geração antiga de automação de navegador – Selenium, Puppeteer, Playwright – funciona via seletores CSS e caminhos no DOM. Assim que o HTML de uma página muda, os scripts quebram. Cada redesign de uma ferramenta de terceiros significava dias de manutenção.
A nova geração funciona via compreensão visual. O agente vê a tela como um humano – em pixels ou pela árvore de acessibilidade – e decide com base no que enxerga. „Clique no botão de salvar" é uma instrução que ele entende, mesmo que amanhã o botão esteja em outro lugar ou tenha outra cara. Isso torna os agentes de navegador robustos contra mudanças de UI que destruiriam scripts clássicos.
A isso se somaram três avanços importantes:
Velocidade: O roundtrip screenshot → modelo → ação caiu de vários segundos para menos de um. Com isso, workflows com dezenas de passos rodam em minutos em vez de horas.
Confiabilidade: A precisão de reconhecimento de elementos de UI passa de 95% nos modelos líderes. Não é perfeito, mas é suficiente para workflows supervisionados.
Estrutura de custo: Um workflow típico de navegador custa hoje entre 5 centavos e 1 euro – dependendo do tamanho. Isso torna a automação viável até para volumes médios.
Para o que os agentes de navegador servem
Dos nossos projetos, alguns pontos fortes ficam claros:
Integração com sistemas legados: Quando um ERP ou CRM antigo não tem API, a única opção antes era pôr um colaborador para clicar pelo sistema ou manter um script Selenium frágil. Agentes de navegador são a nova alternativa, mais robusta.
Extração de dados de páginas web: Tarefas de pesquisa que reúnem dados de várias páginas são um campo natural. Diferente do scraping clássico, o agente não precisa ser programado para cada página individualmente – ele entende cada uma ad hoc.
Tarefas administrativas repetitivas: Cadastros em portais públicos, pedidos em portais de fornecedores, upload de notas em sistemas de contabilidade alheios. Tarefas em que uma pessoa repete diariamente os mesmos passos em uma interface estranha – candidatos ideais.
Testes end-to-end: Em vez de adaptar scripts de teste a cada mudança de UI, dá para instruir um agente a „percorrer todo o fluxo de pedido e reportar qualquer anomalia". A manutenção dos testes muda de código para instruções.
Para o que eles não servem
Igualmente importante: onde os agentes de navegador ainda falham hoje.
Operações de alta frequência: Quando algo precisa rodar cem vezes por minuto, um agente de navegador é lento e caro demais. Aqui a solução baseada em API ou em script clássico continua sendo a primeira escolha.
Ações críticas de segurança: Banco, transferências, assinatura de contratos – tudo que tem consequência financeira ou jurídica. Mesmo uma taxa de erro de 1% é inaceitável aqui.
Captcha e detecção de bot: Muitos sites reconhecem operação automatizada e bloqueiam. Um agente de navegador é legítimo quando opera os próprios sistemas ou as próprias contas. Em plataformas de terceiros pode violar os termos de uso – um campo minado jurídico.
Workflows muito longos: Tarefas com mais de 30–40 passos acumulam erros. Se o agente clica no botão errado no passo 27, o mundo fica desalinhado dali em diante. Workflows mais longos devem ser quebrados em etapas com validação intermediária.
A arquitetura que funciona
Os setups produtivos de agentes de navegador que construímos seguem um padrão parecido:
Separação entre orquestrador e agente de navegador: Um sistema orquestrador (muitas vezes uma ferramenta de workflow ou um componente próprio de backend) decide quais workflows rodam. O agente de navegador recebe tarefas claras e delimitadas, com critério de sucesso definido.
Execução em sandbox: O agente roda em um ambiente de navegador isolado – container, conta de usuário própria, acesso de rede restrito. Assim, o estrago de um erro fica contido.
Camada de validação: Depois de cada workflow, um segundo mecanismo valida – muitas vezes uma chamada de API, uma checagem em banco de dados ou um segundo agente – se o resultado desejado foi alcançado. O auto-relato do agente não basta.
Human-in-the-loop para edge cases: Quando o agente fica inseguro ou esbarra em algo inesperado, ele escala para um humano. Calibrar esse limite de escalonamento de forma deliberada importa mais do que a escolha do modelo.
As armadilhas jurídicas e éticas
Agentes de navegador se movem em uma zona cinzenta. Três pontos devem estar resolvidos antes:
Autorização do operador da plataforma. Se o agente roda no próprio site ou na própria conta, sem problema. Em plataformas de terceiros pode haver violação de termos de uso. Uma olhada esclarecedora nos terms of service economiza dor de cabeça.
Proteção de dados. Agentes de navegador veem tudo o que está na tela – inclusive dados de que o agente nem precisa. Quem confronta o sistema com dados de pacientes, clientes ou colaboradores precisa documentar e proteger esses fluxos.
Responsabilidade por erros. Quando um agente de navegador dispara um pedido errado, envia um formulário errado ou escreve um erro em um sistema de terceiros – quem responde? Isso entra no contrato com o fornecedor e nos processos internos.
O que isso significa para empresas
Agentes de navegador são a peça que faltava para a automação em empresas com uma paisagem de sistemas heterogênea. Quem opera workflows de cliente ou colaborador que hoje são clicados manualmente em interfaces alheias deveria ao menos avaliar em 2026 o que dá para automatizar. As economias são reais, o esforço de implementação ficou administrável.
Na nh labs, começamos projetos assim com um mapeamento rápido: quais workflows são frequentes o suficiente, claros o suficiente e tolerantes o suficiente para automação por navegador? Dessa lista sai o primeiro piloto – quase sempre com ROI em menos de três meses.
Conclusão
Agentes de navegador chegaram em 2026 onde os agentes de código estavam em 2024: não servem para tudo, mas surpreendentemente bons para as tarefas certas. Quem agora junta as primeiras experiências constrói uma competência de automação que vai ser estrategicamente importante nos próximos anos. Quem espera até a tecnologia estar „totalmente madura" abre mão de um a dois anos de potencial de otimização – e entrega a vantagem aos concorrentes.