Google ha appena aperto — in preview — un pezzo molto concreto del proprio arsenale agentico: Gemini 2.5 Computer Use. Il modello è pensato non più solo per “parlare” o “generare testo/immagini”, ma per interagire visivamente con interfacce software come un utente umano.


In pratica: dare all’IA la capacità di cliccare bottoni, scrivere in campi, fare drag & drop, scrollare, ecc., in un workflow iterativo dove lo stato del browser (screenshot + URL + storico azioni) viene continuamente feedato al modello. Google sostiene che su benchmark “web / mobile control” questo modello batte le alternative, offrendo latenza ridotta e accuratezza competitiva.

Questo è essenzialmente un agent “UI-level”, non un agente con privilegi di sistema. Google è chiara: per ora la portata si limita al browser / mobile UI; non è progettato per controllare il sistema operativo o file locali.


Cosa può fare, concretamente (e cosa no, almeno per ora)

L’obiettivo è chiaro: coprire il vuoto tra le operazioni automatizzabili via API e le cose che non hanno API. Immagina un sito legacy con form, interfacce proprietarie, widget custom: fino ad oggi un’IA generica doveva fare scraping + reverse engineer; con questo modello l’IA può agire come se fosse un utente che “vede” la UI e interagisce.

Tra gli scenari d’uso citati:

  • automatizzare inserimento dati / compilazione form in siti che non hanno API.
  • testing di interfacce utente (UI testing) e flussi utenti end-to-end (benchmarking, QA).
  • navigazione web per raccogliere dati da interfacce che non espongono API strutturate.

Ma attenzione: il modello non può (almeno ora) accedere al filesystem, interagire con processi locali, controllare OS o aggirare CAPTCHAs “hard” o meccanismi di sicurezza complessi.
In uno degli esperimenti citati, quando il modello viene abilitato a risolvere CAPTCHA complessi, va in stallo nonostante dia segnale di “task completato”.

Inoltre, essendo in preview, Google avverte che possono esserci errori, vulnerabilità, e che è necessario un controllo umano per compiti critici.


Architettura, loop agentico e tool “computer_use”

La modalità operativa è interessante: il modello espone un tool chiamato computer_use all’interno dell’API Gemini.
Quando fai una richiesta, invii:

  1. l’obiettivo / la task
  2. uno screenshot corrente del browser UI
  3. la lista delle azioni fatte finora

Il modello risponde con una “chiamata funzione” che rappresenta l’azione da compiere (clic, digitare, scorrere, drag, ecc.). Dopo che l’azione viene eseguita, si riprende con nuovo screenshot + nuovo stato URL, e il loop continua finché il task è considerato completo oppure intervenuto errore o blocco di sicurezza.

Google specifica che puoi proibire certe funzioni (escludere azioni rischiose) o aggiungerne di custom, come parte del “tool configuration”.

Anche lato implementazione, il modello va “supportato” da un client che esegue materialmente l’azione nel browser (ad esempio sfruttando Playwright o librerie simili).