Google integra o "computer use" ao Gemini 3.5 Flash como ferramenta nativa

De modelo separado a ferramenta nativa

A mudança estrutural aqui é simples de descrever, mas grande na prática. Antes, o "computer use" só estava disponível como um modelo isolado, o Gemini 2.5 computer use. Nesta versão, ele passa a ser uma ferramenta nativa dentro do Gemini 3.5 Flash, ao lado das ferramentas de function calling e grounding (Search, Maps) que o Flash já oferecia.

Isso importa porque muda a forma como você monta um agente. Em vez de direcionar as etapas de interação com a interface para um modelo e as etapas de raciocínio para outro, o desenvolvedor pode pedir a uma única instância do Flash que veja, raciocine e aja — nas palavras do Google — em ambientes de navegador, mobile e desktop dentro de um único loop de chamadas de ferramenta. As costuras entre "entender a tarefa" e "clicar no botão" desaparecem da superfície de integração.

As duas demonstrações são trabalho de frontend, não chatbots

O Google ilustra o recurso com duas tarefas concretas, e ambas são tarefas típicas de engenharia frontend. Na primeira, o 3.5 Flash analisa o app do Gemini e retorna uma lista categorizada de funcionalidades. Na segunda, ele audita sua própria documentação em busca de problemas de acessibilidade.

Vale ler isso como modelos a seguir. Fazer o inventário de funcionalidades numa UI ativa é trabalho de mapeamento de regressão e cobertura. Auditoria de acessibilidade é uma tarefa que times de frontend costumam deixar para depois, porque exige percorrer com paciência uma interface renderizada. As duas são exatamente o tipo de trabalho repetitivo, de leitura de tela, que um agente controlando um navegador real pode tentar assumir — e é justamente para isso que o Google está apontando os desenvolvedores, com seu conceito de "testes contínuos de software".

A distinção que vale guardar: esse é um agente operando na superfície renderizada de uma aplicação, não no seu código-fonte. Isso o torna útil justamente onde você não controla ou não consegue instrumentar facilmente o frontend — apps de terceiros, widgets incorporados, fluxos multiplataforma.

Injeção de prompt é tratada como condição normal de uso, não como caso extremo

Qualquer agente que lê uma UI ativa pode ler também um texto que um atacante tenha plantado nela. O Google reconhece isso diretamente e vai além de um simples aviso. Há treinamento adversarial específico incorporado ao modelo, além de dois sistemas opcionais de proteção para empresas: um que exige confirmação explícita do usuário antes de ações sensíveis ou irreversíveis, e outro que interrompe automaticamente uma tarefa quando detecta uma injeção de prompt indireta.

Adotando uma abordagem de "defesa em profundidade", recomendamos que os desenvolvedores combinem esses recursos com sandboxing seguro, verificação humana no processo e controles de acesso rígidos.Montana Labs

O sinal honesto nessa frase é que o treinamento em nível de modelo não é apresentado como suficiente. As proteções são opcionais e em camadas, o que significa que a responsabilidade por uma implantação segura ainda recai sobre o time que constrói o agente. Se você apontar o Flash para uma página que um adversário pode editar, o trabalho de sandboxing e controle de acesso é seu.

O que uma ferramenta nativa de computer use muda para times que lidam com automação de UI

A implicação prática é que a automação de UI deixa de ser uma escolha de modelo especializado e passa a ser um simples toggle de recurso dentro do modelo que você provavelmente já usava para chamadas de ferramenta. O acesso é feito pela Gemini API e pela Gemini Enterprise Agent Platform, com um ambiente de demonstração hospedado pela Browserbase para times que querem testar antes de montar seu próprio sandbox.

Para os times de frontend e QA, o teste de curto prazo é bem específico e fácil de responder: um agente controlando o app renderizado produz um inventário de funcionalidades ou um relatório de acessibilidade em que você confiaria a ponto de agir com base nele? O Google colocou as duas tarefas como vitrine, o que as torna o parâmetro justo de avaliação. A questão de infraestrutura — sandboxing, confirmações, bloqueios de injeção — é agora o que vai determinar se isso é uma demonstração ou uma implantação real.