Gemini 3.5 Flash integra el control de interfaces para crear agentes

Google DeepMind anunció el 24 de junio de 2026 que Computer Use pasaba a ser una herramienta integrada en Gemini 3.5 Flash. El comunicado oficial dice que los desarrolladores pueden construir agentes que observan, razonan y actúan en interfaces de navegador, móvil y escritorio mediante la API de Gemini y la plataforma empresarial de agentes. Integrada no significa que el modelo reciba control ilimitado del ordenador: una aplicación sigue decidiendo qué acciones ejecutar y en qué entorno.

Hasta ese anuncio, Google ofrecía el control de interfaces mediante un modelo separado basado en Gemini 2.5. Incorporarlo a Flash reduce el cambio de contexto entre razonamiento, herramientas y operación gráfica. La empresa señala pruebas continuas de software y trabajo de conocimiento entre sus usos, y muestra demostraciones que analizan la app de Gemini y revisan documentación en busca de problemas de accesibilidad.

La capacidad es atractiva porque alcanza aplicaciones que no ofrecen una API adecuada. Si una persona puede completar un proceso mirando pantallas, pulsando controles y escribiendo campos, un agente visual puede intentar el mismo recorrido. Esa flexibilidad es también su debilidad: la interfaz cambia, contiene texto no confiable y mezcla información con acciones que afectan al mundo.

El agente es un bucle, no un cursor mágico

Un sistema de Computer Use tiene al menos cuatro piezas. El entorno produce una captura o representación del estado. El modelo interpreta ese estado y propone una acción. Un ejecutor del lado de la aplicación valida y realiza el clic, desplazamiento o entrada de teclado. Después se captura el nuevo estado y el ciclo empieza otra vez.

La implementación de referencia enlazada por Google usa un navegador controlado por software y ofrece una opción local con Playwright y otra alojada con Browserbase. Esto hace visible una separación crucial: el modelo elige; el código del desarrollador ejecuta. Entre ambos cabe una política que permita, modifique, pida confirmación o bloquee la acción.

Cada pieza puede fallar de forma diferente. La percepción puede confundir dos botones. El plan puede seleccionar una ruta incorrecta. La traducción a coordenadas puede apuntar a otro elemento. El estado puede cambiar entre la captura y el clic. Y una acción correcta puede tener un efecto inesperado por permisos, sesión o datos ocultos. Evaluar solo el resultado final impide saber qué capa necesita corrección.

Por qué las tareas largas acumulan fragilidad

Una tarea de varios pasos no hereda automáticamente la tasa de acierto de un paso aislado. Si cada transición tiene una probabilidad de éxito inferior a uno, la probabilidad de completar toda la cadena sin error disminuye al multiplicar transiciones. Además, algunos errores alteran el estado y contaminan los pasos siguientes: escribir en el campo equivocado puede cambiar una búsqueda, una compra o un destinatario.

Por eso un benchmark de control de interfaz no equivale a una garantía de automatización. La tarjeta de Gemini 3.5 Flash publica resultados de OSWorld-Verified y otras pruebas agénticas, pero cada cifra pertenece a un entorno, un arnés y un criterio. Antes de trasladarla a una empresa hay que preguntar cuántos pasos tenía la tarea propia, qué aplicaciones usa y qué coste tiene una desviación.

La estrategia práctica es introducir puntos de comprobación. Tras completar una fase, el agente confirma un estado observable: archivo creado, total calculado, destinatario seleccionado o formulario aún sin enviar. Si el estado no coincide, se detiene o vuelve a un punto conocido. Esto convierte una cadena opaca en segmentos que pueden auditarse y recuperarse.

La inyección de instrucciones cambia de escala

Una interfaz contiene órdenes legítimas del usuario y contenido escrito por terceros. Una página, un documento o un mensaje puede incluir texto que intente presentarse como una instrucción para el agente. Es una inyección indirecta: el dato no confiable trata de ascender en la jerarquía y dirigir acciones. Cuando el sistema solo resume, el daño puede ser una respuesta falsa; cuando puede operar, puede exfiltrar datos, modificar registros o comunicarse con alguien.

Google declara entrenamiento adversarial específico para Computer Use y dos salvaguardas empresariales opcionales: exigir confirmación explícita para acciones sensibles o irreversibles y detener una tarea si se identifica una inyección indirecta. El anuncio también recomienda aislamiento, verificación humana y controles de acceso estrictos. La palabra «opcional» importa: quien construye el agente debe comprobar qué capa está activada y no asumir que el nombre del modelo configura por sí solo el perímetro.

Un detector de inyección no debe ser la única defensa. Un texto hostil puede no parecerse a los ataques conocidos, y un contenido legítimo puede activar una alarma. La arquitectura segura limita de antemano qué datos puede leer el agente, qué destinos puede alcanzar y qué operaciones puede ejecutar. Así, incluso si una instrucción atraviesa el detector, encuentra un radio de acción acotado.

El contrato de acción antes del primer clic

Antes de desplegar, escriba un contrato con cinco columnas: acción, objeto, condición, confirmación y reversión. «Leer una página pública» puede permitirse sin pausa. «Crear un borrador» puede requerir guardar en una carpeta temporal. «Enviar», «borrar», «comprar» o «cambiar permisos» deben mostrar el objeto exacto y esperar una confirmación humana reciente.

El contrato debe aplicar identidad de mínimo privilegio. Un agente que prueba una web no necesita una cuenta de administrador ni acceso al correo personal. Un agente que prepara facturas puede leer el catálogo y crear borradores, pero no necesita autorizar pagos. Las credenciales se separan por entorno y se excluyen de capturas, registros y páginas que el modelo no deba interpretar.

También hay que definir límites de volumen y tiempo. Una instrucción que parecía crear un archivo puede entrar en un bucle y producir cientos. El ejecutor debe fijar número máximo de acciones, dominios permitidos, duración, gasto y tamaño de transferencia. Alcanzar un límite termina la sesión y conserva el estado para revisión; no invita al modelo a sortearlo.

Cómo probarlo sin arriesgar producción

El primer ensayo usa una máquina virtual, contenedor o perfil de navegador aislado, datos sintéticos y cuentas sin privilegios. Se parte siempre del mismo estado. El conjunto incluye tareas normales y obstáculos diseñados: una ventana emergente, dos controles parecidos, un cambio de diseño, una instrucción hostil dentro de una página y una acción que exige confirmación.

La evaluación registra más que éxito. Debe contar acciones propuestas, acciones ejecutadas, confirmaciones correctas, bloqueos, desviaciones de dominio, recuperaciones, tiempo y correcciones humanas. Una tarea completada después de intentar una operación prohibida no es un éxito limpio. Una tarea detenida por una salvaguarda puede ser un resultado correcto.

Después se revisa la trayectoria paso a paso. Para cada error se asigna capa: percepción, planificación, política, ejecución o cambio de estado. Esa clasificación evita responder a todo con un prompt más largo. Un error de coordenadas puede requerir un controlador distinto; uno de permisos, una identidad más estrecha; uno de intención, una instrucción o un punto de aprobación mejor.

Cuándo usar interfaz y cuándo usar una API

El control visual es valioso para aplicaciones cerradas o procesos heredados, pero una API estructurada ofrece campos, tipos, errores y operaciones menos ambiguas. Si existe una API estable para la acción crítica, suele ser preferible reservar Computer Use para navegación, recopilación o puentes entre sistemas. La interfaz se convierte así en adaptador, no en única capa de control.

Combinar ambas rutas permite que el modelo lea el contexto visual, pero entregue una intención estructurada a una función que valida parámetros. La aplicación puede mostrar una vista previa y ejecutar solo después de confirmar. Esta separación reduce el riesgo de que un clic en una posición cambiante produzca una consecuencia distinta de la prevista.

La capacidad transferible es diseñar un agente de interfaz como un bucle de percepción, decisión, política, ejecución y verificación. Gemini 3.5 Flash aporta el modelo y la herramienta; el desarrollador sigue siendo responsable del ejecutor, los permisos, las confirmaciones, los límites y los registros. La autonomía útil no consiste en eliminar esas capas, sino en hacer que permitan avanzar sin perder el control.