Durante muito tempo, a automação corporativa seguiu uma lógica relativamente previsível: se existe API, integre pela API. Se existe evento, conecte no workflow. Se existe banco, consulte o dado. Se existe regra, escreva a regra.
Só que a realidade das empresas nunca foi tão limpa assim.
Muita empresa ainda tem sistema legado. Tem aplicação interna sem API. Tem portal antigo. Tem tela que só funciona no navegador. Tem processo manual que depende de clicar, preencher, copiar, baixar, anexar, conferir e enviar. Tem operação que existe há anos e que ninguém conseguiu automatizar direito porque a integração “correta” nunca foi priorizada.
É nesse espaço que o Computer Use tool, anunciado em preview para o Azure AI Foundry Agent Service em setembro de 2025, começa a chamar atenção. A proposta é permitir que agentes interajam com interfaces de computador e navegador por meio de instruções em linguagem natural, usando um loop de ações, execução e feedback por screenshot. Em vez de depender apenas de API, o agente passa a conseguir olhar para uma tela, sugerir ações como clicar, digitar e capturar screenshots, e continuar o processo em múltiplas etapas.
Esse é o tipo de recurso que abre possibilidades enormes. E, justamente por isso, precisa ser tratado com maturidade.
Porque quando um agente começa a operar uma interface, ele deixa de ser apenas uma camada de resposta. Ele passa a tocar processo.
O que é Computer Use, na prática?
Computer Use é uma ferramenta para agentes que permite interação com sistemas e aplicações por meio da interface visual. A Microsoft descreve o recurso como uma capacidade em preview no Azure AI Foundry Agent Service que permite aos agentes não apenas raciocinar sobre texto, recuperar conhecimento ou chamar APIs, mas também interagir diretamente com interfaces de computador usando instruções em linguagem natural. No lançamento, o recurso ficou acessível via REST API e SDK, com integração ao runtime de agentes do Foundry.
Na prática, isso significa que o agente pode operar uma tela de forma parecida com um usuário humano: visualizar, clicar, digitar, capturar tela e seguir para o próximo passo.
Esse detalhe muda a categoria da solução.
Um agente que responde pergunta é um assistente.
Um agente que chama API é um operador de ferramenta.
Um agente que interage com tela começa a entrar no território de automação de processos visuais.
E isso é poderoso porque muitas empresas ainda têm processos presos em interfaces.
Por que isso importa?
A maior parte das empresas não vive em um cenário ideal de APIs modernas, documentação perfeita e sistemas bem integrados.
Na vida real, existe legado. Existe sistema comprado de terceiro. Existe dashboard sem API. Existe portal que só exporta CSV por botão. Existe aplicação interna que ninguém quer mexer porque “funciona”. Existe processo manual em que alguém abre três sistemas, copia dados de um, cola no outro, confere informação e finaliza uma etapa.
Se você olha para isso com mentalidade puramente moderna, a resposta seria: “vamos construir uma API”. E, em muitos casos, essa continua sendo a melhor resposta.
Mas nem sempre é viável no curto prazo.
Computer Use entra como uma ponte: uma forma de permitir que agentes executem tarefas em interfaces onde uma API não existe, não está disponível ou não faz sentido construir imediatamente.
A Microsoft cita casos como automação web e desktop, preenchimento de formulários, upload e download de artefatos, interação com aplicações sem API, copilotos operacionais para triagem de tickets e workflows, integração com sistemas legados e fluxos com aprovação humana para etapas sensíveis.
O ponto não é substituir API. O ponto é ampliar o alcance dos agentes onde a API não chega.
Computer Use não é a mesma coisa que Browser Automation
Esse ponto precisa ficar claro.
Browser Automation e Computer Use parecem parecidos, mas não são a mesma coisa. Browser Automation trabalha melhor quando existe uma estrutura semântica da página, como DOM, HTML ou XML. Computer Use, por outro lado, interpreta pixels a partir de screenshots e propõe ações sobre aquilo que “vê” na tela. A Microsoft compara os dois caminhos e explica que Computer Use usa dados visuais brutos, enquanto Browser Automation entende a tela por meio da estrutura da página.
Isso tem implicações práticas.
Browser Automation tende a ser mais previsível quando você está lidando com páginas web bem estruturadas. Computer Use pode ser mais flexível quando a interface é visual, dinâmica, legada, pesada em canvas ou não expõe uma estrutura fácil de automatizar.
Mas essa flexibilidade tem custo.
Quanto mais visual e menos semântico é o processo, maior é a necessidade de controle, validação e supervisão. O agente pode interpretar a tela, mas interpretar não é o mesmo que entender o risco do negócio.
O fluxo mental do Computer Use
Eu gosto de pensar no Computer Use como um ciclo:
O agente recebe uma intenção.
A ferramenta observa a tela.
O modelo sugere uma ação.
O ambiente executa essa ação.
Uma nova captura de tela é gerada.
O modelo avalia o novo estado.
O ciclo continua até concluir ou parar.
A Microsoft descreve essa dinâmica como um loop contínuo de ações sugeridas, execução e feedback por screenshot. O modelo pode pedir ações como clicar, digitar e capturar tela; o código executa essas ações em ambiente controlado e devolve o screenshot para orientar o próximo passo.
Esse fluxo parece simples, mas é aqui que mora o risco.
Se você não controla o ambiente, o agente pode acessar lugar errado.
Se você não controla credenciais, ele pode expor segredo.
Se você não controla ações, ele pode executar algo sensível.
Se você não registra passos, você não consegue auditar.
Se você não exige aprovação, uma automação visual pode virar incidente.
Computer Use precisa ser tratado como automação com risco, não como brinquedo de produtividade.
O caso de uso certo
Eu usaria Computer Use quando três condições aparecem juntas.
A primeira: existe uma tarefa repetitiva ou semi-repetitiva baseada em interface.
A segunda: não existe API viável ou integração melhor no curto prazo.
A terceira: o risco da tarefa pode ser controlado com ambiente isolado, baixa permissão e supervisão.
Por exemplo: um agente que acessa um portal, baixa um relatório, confere se um campo existe, preenche um formulário interno simples ou faz triagem inicial em um dashboard de baixa criticidade.
Esse tipo de caso pode fazer sentido.
Agora, se o processo envolve aprovação financeira, alteração de contrato, exclusão de dados, acesso a credenciais, painel administrativo sensível ou ambiente de produção, eu teria muito mais cuidado. Nesses casos, Computer Use não deve operar sozinho. No máximo, ele prepara a ação e pede aprovação humana.
A Microsoft recomenda que fluxos com etapas sensíveis ou de alto risco exijam aprovação do usuário antes da execução. Também recomenda o uso em máquinas virtuais isoladas, com baixa permissão e sem dados ou credenciais sensíveis.
Essa recomendação não é detalhe. É o centro da arquitetura.
O caso de uso errado
O pior uso possível de Computer Use é dar a ele acesso amplo a um ambiente real e pedir para “resolver o processo”.
Isso é perigoso.
Um agente visual pode clicar no botão errado.
Pode não perceber que entrou em outro contexto.
Pode interpretar mal uma tela.
Pode cair em prompt injection.
Pode operar em uma página sensível.
Pode executar uma ação irreversível.
Pode vazar dados em screenshot.
Pode falhar em silêncio.
Por isso, para mim, Computer Use nunca deve começar em produção. Deve começar em sandbox.
E não é qualquer sandbox. É um ambiente isolado, sem segredo, sem acesso amplo, com dados fictícios ou mascarados, permissões mínimas e logs completos.
A própria Microsoft alerta que Computer Use traz riscos significativos de segurança e privacidade, incluindo prompt injection.
Quando a documentação coloca esse aviso, o arquiteto precisa levar a sério.
Arquitetura segura para Computer Use
Se eu fosse desenhar uma arquitetura inicial para Computer Use no Azure AI Foundry Agent Service, eu separaria em sete camadas.
1. Agente no Foundry Agent Service
O agente recebe a intenção do usuário e decide se precisa usar Computer Use. Ele não deve ter autonomia irrestrita. As instruções precisam delimitar escopo, tipo de tarefa, limites e quando pedir aprovação.
2. Ambiente visual isolado
A execução deve acontecer em uma máquina virtual, sessão de navegador ou ambiente controlado. Nada de rodar isso na máquina pessoal do usuário ou em ambiente com credenciais abertas.
A recomendação da Microsoft é usar máquinas de baixa permissão e isoladas, sem dados sensíveis ou credenciais.
3. Política de ações permitidas
O agente não deve poder clicar em qualquer coisa. Você precisa criar regras: pode pesquisar, pode preencher formulário, pode baixar arquivo, pode navegar em domínios permitidos. Não pode acessar painel administrativo, não pode alterar senha, não pode excluir dado, não pode confirmar transação.
4. Aprovação humana
Qualquer ação de escrita, envio, confirmação, alteração ou etapa sensível precisa de aprovação humana.
5. Registro de execução
Cada screenshot, ação sugerida, ação executada, URL, janela ativa, input digitado e resultado precisa ser registrado. Sem isso, não existe auditoria.
6. Detecção de loop e falha
Se a tela não muda, se o agente repete a mesma ação, se cai em erro ou se entra em página fora do escopo, a execução deve parar.
7. Revisão e melhoria
Depois de cada execução, você precisa avaliar onde falhou, ajustar instruções, restringir ações e melhorar o processo.
Essa arquitetura pode parecer conservadora, mas é exatamente o tipo de disciplina necessária quando um agente deixa de responder texto e começa a operar interface.
Tutorial conceitual: agente para triagem visual de tickets
Vamos imaginar um caso realista.
Uma empresa tem um portal legado de chamados que não possui API. O analista precisa abrir o portal, verificar tickets novos, classificar prioridade, copiar um resumo e encaminhar para a fila correta. É um processo repetitivo, mas a interface é antiga e difícil de integrar.
Um agente com Computer Use poderia ajudar na triagem inicial.
A missão do agente seria:
Ajudar na triagem visual de tickets em um portal legado, identificando categoria, prioridade aparente e próximos passos sugeridos, sem executar alterações finais sem aprovação humana.A instrução base poderia ser:
Você é um agente de triagem operacional.
Seu objetivo é analisar a tela do portal de chamados e sugerir a classificação inicial.
Você pode navegar apenas dentro do portal autorizado.
Você pode ler informações visíveis, identificar campos relevantes e preparar uma sugestão.
Você não pode fechar tickets, alterar prioridade, enviar resposta ao cliente ou executar ações irreversíveis sem aprovação humana.
Se a tela exibir dados sensíveis, credenciais, informações fora do escopo ou qualquer ação de risco, pare a execução e solicite revisão humana.
Registre cada etapa de forma objetiva.Esse prompt não é suficiente sozinho. Ele precisa estar apoiado por política de ambiente, allowlist de domínio, aprovação humana e logs.
O erro seria confiar apenas na instrução. Instrução ajuda, mas não substitui controle técnico.
Um desenho simples de política
Eu criaria uma política parecida com esta:
Allowed domains:
- portal-interno-tickets.local
- dashboard-suporte.local
Allowed actions:
- screenshot
- click
- type
- scroll
- copy visible text
Requires approval:
- submit
- save
- close ticket
- change priority
- assign ticket
- download file
- upload file
Blocked actions:
- access admin panel
- change password
- delete record
- approve financial transaction
- expose credentialsEssa política é mais importante do que parece.
Sem uma lista clara do que pode, do que exige aprovação e do que é bloqueado, você está deixando o agente decidir risco por conta própria.
E agente não deve ser dono do risco. O negócio e a arquitetura devem ser donos do risco.
Human-in-the-loop não é opcional
Em Computer Use, human-in-the-loop precisa ser tratado como parte da arquitetura.
Não é falta de automação. É controle.
O agente pode preparar.
O agente pode sugerir.
O agente pode navegar.
O agente pode preencher rascunho.
Mas, em ações sensíveis, o humano aprova.
Esse modelo é muito mais realista para adoção corporativa. Ele permite ganho de produtividade sem entregar poder demais para um sistema probabilístico.
A própria Microsoft cita fluxos com human-in-the-loop como caso de uso, especialmente para etapas sensíveis ou de alto risco.
Para mim, essa é a forma correta de começar.
Computer Use e sistemas legados
O uso mais óbvio de Computer Use é integração com legado.
Toda empresa tem aquele sistema que ninguém quer mexer. Ele funciona, mas não tem API moderna. A automação tradicional sofre. RPA talvez resolva parte, mas exige mapeamento específico e manutenção frágil. Um agente visual pode ajudar em alguns desses cenários porque entende a tela de forma mais flexível.
Mas aqui existe uma armadilha: usar Computer Use para perpetuar legado ruim.
Se o sistema é crítico e usado todos os dias, talvez o caminho correto continue sendo modernização, API ou substituição. Computer Use pode ser uma ponte, não necessariamente o destino final.
Eu usaria Computer Use como:
prova de valor;
ponte temporária;
automação de baixa criticidade;
assistente para tarefa manual;
camada de apoio em sistema sem API.
Eu não usaria como desculpa para nunca integrar direito.
Computer Use versus RPA
É inevitável comparar Computer Use com RPA.
RPA tradicional automatiza interações de interface com regras mais determinísticas. Ele funciona bem quando o processo é estável e previsível. Computer Use adiciona um componente de raciocínio visual e adaptação, porque o modelo interpreta screenshots e propõe ações.
Isso pode ser uma vantagem em telas dinâmicas ou processos menos estruturados. Mas também aumenta imprevisibilidade.
RPA erra quando a regra quebra.
Computer Use pode errar quando interpreta mal.
A decisão não deveria ser “qual é mais moderno?”. A decisão deveria ser “qual é mais seguro, previsível e barato para este processo?”.
Para processo altamente repetitivo e estável, RPA pode continuar fazendo sentido. Para interfaces variáveis, legado visual e tarefas que exigem interpretação, Computer Use pode abrir novas possibilidades.
O papel do arquiteto
O arquiteto precisa atuar como freio e acelerador ao mesmo tempo.
Acelerador porque Computer Use permite automatizar processos que antes eram difíceis. Freio porque o risco de automação visual é real.
Eu avaliaria cada caso com cinco perguntas:
Existe API?
Se existe, por que não usar API?
Qual é o risco da ação?
O ambiente pode ser isolado?
Existe aprovação humana nos pontos críticos?
Se a resposta para essas perguntas não estiver clara, o projeto não está pronto.
O papel do arquiteto é impedir que a empresa confunda capacidade técnica com autorização para usar em qualquer lugar.
O papel do desenvolvedor
O desenvolvedor também precisa mudar a mentalidade.
Não basta fazer o agente “clicar certo”. É preciso construir o loop com segurança: capturar screenshot, validar estado, executar ação, registrar resultado, tratar erro e parar quando algo sai do escopo.
O desenvolvedor precisa pensar em:
tempo máximo de execução;
número máximo de ações;
domínios permitidos;
janelas permitidas;
detecção de loop;
mascaramento de dados;
logs;
confirmações;
rollback quando possível.
Em Computer Use, o código não é apenas integração. O código é o guardião do ambiente.
O que eu jamais faria
Eu não colocaria Computer Use com acesso a produção no primeiro teste.
Não deixaria credenciais salvas no navegador.
Não rodaria em máquina com dados reais desnecessários.
Não daria acesso administrativo.
Não permitiria ações irreversíveis sem aprovação.
Não deixaria o agente navegar livremente na internet.
Não aceitaria automação sem logs.
Não usaria em processo regulado sem revisão de segurança.
Essas restrições não diminuem o valor da tecnologia. Elas permitem que a tecnologia seja usada com responsabilidade.
Como começar de forma segura
Eu começaria com um piloto de baixo risco.
Escolheria um processo manual simples.
Criaria um ambiente isolado.
Usaria dados fictícios.
Definiria uma lista pequena de ações permitidas.
Bloquearia qualquer ação sensível.
Registraria cada etapa.
Mediria taxa de sucesso.
Analisaria erros.
Só depois aumentaria escopo.
Um bom primeiro caso seria geração de relatório a partir de uma interface sem API. O agente acessa, navega, baixa um arquivo de teste, extrai informação e prepara resumo. Nada de alteração de dados. Nada de envio. Nada de ação irreversível.
Comece por leitura. Só depois pense em escrita.
O que medir
Eu mediria cinco coisas.
Taxa de conclusão: o agente conseguiu completar a tarefa?
Taxa de intervenção humana: quantas vezes precisou parar?
Erros de navegação: entrou em tela errada?
Tempo por tarefa: reduziu tempo real ou só criou complexidade?
Risco evitado: quantas ações foram bloqueadas corretamente?
Sem métricas, Computer Use pode virar uma demonstração impressionante, mas sem prova de valor.
E demonstração sem métrica não sustenta decisão de arquitetura.
Minha leitura sobre setembro de 2025
Setembro de 2025 foi um mês importante porque o Azure AI Foundry Agent Service expandiu o conceito de ferramenta para agentes. Até então, muitos cenários giravam em torno de busca, APIs, funções, MCP, Deep Research e automação de navegador. Com Computer Use, a Microsoft abriu espaço para agentes interagirem com interfaces de computador e navegador de forma visual, usando pixels e screenshot feedback loop.
Isso não significa que todo processo deve ser automatizado assim. Mas significa que uma nova categoria entrou no radar: agentes operando ambientes digitais quando não existe integração ideal.
A tecnologia é interessante. O risco também.
E é por isso que o tema merece ser discutido com seriedade.
Conclusão
Computer Use no Azure AI Foundry Agent Service é uma das capacidades mais interessantes e, ao mesmo tempo, mais delicadas da evolução agentic.
Ela permite que agentes saiam do texto, ultrapassem APIs e comecem a interagir com interfaces reais. Isso pode ajudar muito em processos legados, portais sem API, tarefas visuais e automações operacionais.
Mas o poder vem com risco.
Um agente que clica, digita e navega precisa de ambiente isolado, baixa permissão, aprovação humana, logs, políticas claras e limites rígidos. Sem isso, a automação deixa de ser inovação e vira exposição operacional.
Minha leitura é simples: Computer Use não deve ser tratado como substituto de arquitetura. Deve ser tratado como uma ferramenta dentro de uma arquitetura bem governada.
A pergunta não é “o agente consegue clicar?”.
A pergunta é: “ele deve clicar, em qual ambiente, com qual permissão, sob qual controle e com qual auditoria?”
Essa diferença separa uma demo bonita de uma solução séria.
E, em IA corporativa, essa diferença é tudo.
Seja o primeiro a comentar