Browser y computer use agents: usos reales

Dos cosas muy distintas con un mismo nombre

Cuando alguien habla de un «browser agent», en realidad está hablando de dos soluciones que se parecen muy poco entre sí:

• Basada en píxeles: el agent recibe una captura de pantalla y hace clic en unas coordenadas. Trabaja como lo haría una persona: ve la interfaz y pulsa el botón.
• Basada en código: el agent no hace clic, sino que escribe código de automatización (un script que maneja el navegador, llamadas HTTP) y lo ejecuta.

Durante mucho tiempo pareció que lo primero era el computer use «de verdad» y lo segundo un atajo. Un resultado de investigación de mayo de 2026 le dio la vuelta a eso. En la misma prueba de 300 tareas sobre 136 sitios web reales, el enfoque basado en código llegó al 86,7 % con el mismo modelo, mientras que la línea base de capturas de pantalla rendía «sensiblemente peor en todas las franjas de dificultad».

En tareas largas que atraviesan varios sitios web la diferencia es todavía más llamativa: el enfoque basado en código llegó al 60,1 %, mientras que la línea base desnuda de ese mismo modelo se quedó en 33,5 %. Eso es casi un 80 % de mejora relativa solo por manejar el navegador de otra manera — el modelo siguió siendo exactamente el mismo.

La explicación de los investigadores se entiende bien: el harness basado en código «le da al agent margen para elegir su propio camino por el espacio de la tarea». Hacer clic es lineal: un paso, una imagen, una decisión. El código puede ramificarse, puede iterar y puede resolver en cincuenta líneas lo que en clics serían cincuenta pasos.

La conclusión práctica que conviene retener: que no haya API no significa que necesites un agent de píxeles. El orden es: API → control del navegador por código → y solo al final los clics sobre capturas de pantalla.

¿Qué saben hacer hoy, medido?

La vara de medir del computer use es una prueba de 369 tareas que corre sobre sistemas operativos reales. Su cronología es la curva más empinada de los dos últimos años:

(Resultados autodeclarados en una tabla pública; ningún tercero los ha verificado. Sobre cómo leer un benchmark hay un texto aparte: el post cómo leer un benchmark de IA conviene terminarlo antes de tomarte en serio cualquiera de estas cifras.)

Detrás de esto hay dos cosas importantes. Una es que parte de los mejores resultados no vienen de un modelo, sino de un framework de agents: varios intentos, votación entre las salidas, control especializado. La otra es que estas cifras se obtienen con un presupuesto de pasos máximo.

La trampa del límite de pasos

Esta es la tabla más importante del artículo, porque habla directamente de tu cartera. Mismo modelo, mismo conjunto de tareas, solo cambia el número de pasos permitidos:

Pasar de 15 a 50 aporta +12,7 puntos. Pasar de 50 a 100 aporta menos 2,5 puntos. No es una errata: a partir de cierto punto más pasos no ayudan, solo consumen — el agent se pierde durante más tiempo, acumula más ruido en su contexto y le cuesta más volver al camino.

Otra medición apunta en la misma dirección: los primeros cincuenta pasos aportan el 82 % de la precisión, y los cincuenta siguientes añaden apenas 3–4 puntos más — allí, por tanto, el resultado no empeoró: simplemente dejó de mejorar en la práctica.

La regla que sale de aquí: pon un límite de pasos, y que no sea el más alto. Alrededor de cincuenta es donde la curva se aplana en la mayoría de las tareas.

En la web real: las cifras, y la reserva

Los resultados medidos sobre sitios web reales y vivos han mejorado igual de a la vista:

Pero esta tabla hay que leerla con cuidado. Los resultados de 2026 por encima del 90 % los enviaron empresas concretas, y no los validó la misma organización que validó los anteriores. No es el mismo régimen de medición, así que las filas solo son comparables entre sí hasta cierto punto. La tendencia es real; la cifra más alta no es una promesa.

El coste: crece al cuadrado

Aquí está la parte que nunca se cuenta en las demostraciones.

El conjunto de herramientas de computer use añade por sí solo unos 4.500 tokens de entrada a cada una de las peticiones — esa es la entrada mínima, antes de que pase nada. A eso se suman 1.000–1.800 tokens por captura de pantalla. Y como el agent reenvía en cada paso toda la conversación anterior, el contexto crece paso a paso.

[Cálculo propio] Al precio actual de un modelo puntero (5 dólares por millón de tokens de entrada y 25 por millón de salida), sin caché, con una captura por paso:

Pasar de 15 a 100 pasos son 6,7 veces más pasos — y 34 veces más coste. Esa es la forma de la curva, no la tarifa de un proveedor concreto.

El prompt caching lleva esto más o menos a una décima parte y merece la pena usarlo, pero no cambia la forma de la curva. El crecimiento cuadrático es una propiedad del sistema: en cada paso todas las capturas anteriores siguen dentro del contexto.

Dos trucos baratos que cuentan mucho: menos resolución (para tareas de escritorio se recomienda 1024×768 o 1280×720; no pases de 1920×1080) y menos imágenes — si un paso no necesita una captura nueva, no la pidas. La lógica de los precios en general la desarrolla el post el precio de la IA, descifrado con sus propias cuentas.

¿Y cuánto cuesta un punto de precisión?

Hay una tabla pública que publica los tokens, los dólares y el tiempo de cada ejecución — eso es raro, y muy instructivo. De ahí salen dos conclusiones, y las dos se miden en dinero:

1. El nivel de razonamiento más alto no compensa. El mismo modelo en «alto» y en «máximo» saca 57,9 % y 58,2 % — la diferencia está dentro del margen de error, mientras que la configuración máxima es un 43 % más cara y un 32 % más lenta.

2. Elegir mal el modelo no son unos puntos, es un orden de magnitud. Un modelo del grupo gastó 29 dólares por ejecución para un resultado del 12,4 %; la configuración con mejor relación calidad-precio gastó 7 dólares para un 57,9 %. Por punto de precisión, eso es una diferencia de diecinueve veces.

La lección no es qué modelo elegir — eso cambia cada mes —, sino si mides esas dos cifras siquiera: dólares por ejecución y dólares por ejecución exitosa.

El tiempo que nadie calcula

Esto no es un defecto, es la naturaleza del asunto. La propia documentación del fabricante lo dice: la latencia actual del computer use «puede resultar demasiado lenta» para la interacción humana, así que conviene usarlo donde la velocidad no sea crítica — recogida de información en segundo plano, pruebas automatizadas de software, un entorno de confianza.

Esa frase es la mejor brújula que hay para esta tecnología. Quien quiera ejecutar un computer use agent delante de un cliente en vivo ha elegido mal la tarea.

¿Dónde se cae?

Aquí está el dato más sorprendente del artículo. Quienes mantienen la medición de 369 tareas publicaron los informes de fallo que habían recibido: 360 informes, sobre 217 tareas distintas — es decir, más de la mitad de las tareas recibió una queja.

[Cálculo propio] Los informes por categoría:

(De los 360 informes, 153 quedaron sin clasificar, y un mismo informe puede caer en varias categorías: por eso la tabla no suma 360. Por construcción la lista se inclina hacia los defectos de la medición: la gente informa de lo que parece roto. La lección se sostiene igualmente.)

El caso concreto más instructivo de la lista: el agent hizo la tarea correctamente, pero el evaluador miró un fichero de configuración que el programa todavía no había escrito en disco — así que la misma ejecución contaba unas veces como éxito y otras como fallo.

Y aquí está la verdadera lección de negocio. Si unos evaluadores hechos a medida, trabajando sobre un benchmark, se equivocaron 148 veces sobre el éxito, en tu proceso la pregunta difícil tampoco es si el agent sabe hacerlo, sino si tú puedes saber que lo hizo. Por eso no se puede dejar sin vigilancia; el post el humano en el bucle recorre dónde colocar la aprobación.

Las demás categorías describen justo lo que vuelve inestable a un browser agent en producción: el sitio web cambia, la sesión caduca, salta la defensa antibot y una ventana emergente estropea el clic. No son fallos del modelo, y no se arreglan cambiando de modelo.

La parte de seguridad que no se puede saltar

Un browser agent, por definición, lee contenido no fiable mientras tiene acceso a tus cuentas con la sesión iniciada. Es la peor combinación que existe.

Cifras medidas en el estudio propio de un fabricante, sobre 123 casos de prueba y 29 escenarios de ataque:

Entre los ataques específicos de navegador: campos de formulario invisibles escondidos en el DOM e instrucciones metidas en el texto de la URL y en el título de la pestaña.

Y un caso real, documentado, del verano de 2025. La instrucción maliciosa estaba en un comentario de una red social, escondida tras una marca de spoiler: texto blanco sobre fondo blanco, un comentario HTML, elementos invisibles. Cuando el usuario pulsó «resúmeme esto», el asistente leyó la dirección de correo asociada a la cuenta, intentó iniciar sesión en un nombre de dominio engañosamente parecido, sacó el código de un solo uso del buzón y lo escribió de vuelta en el comentario del atacante. El arreglo llegó en dos oleadas, y la primera no fue completa.

La conclusión de los investigadores se puede citar: las hipótesis clásicas de seguridad web no valen para la IA agéntica.

Los propios fabricantes lo reconocen. Una documentación dice que «en determinadas circunstancias el modelo sigue instrucciones encontradas en el contenido aunque contradigan las tuyas». Y la guía para desarrolladores de otro fabricante enuncia la postura correcta sin rodeos: el contenido de la pantalla hay que tratarlo como no fiable — el texto de una página web, de un documento o de una respuesta de herramienta no otorga permisos.

Hay además un hilo secundario inquietante: en la página de resultados de la medición pública y académica de prompt injection más conocida la entrada más reciente es de febrero de 2025. Es decir, la medición de seguridad pública e independiente se ha quedado atrás respecto a los modelos — mientras las capacidades se triplicaban en año y medio.

Los principios de defensa los expone el post el agent con los permisos mínimos , y la mecánica del ataque la explica la introducción a los fundamentos del prompt injection , paso a paso.

La parte jurídica: nueva, e importante

En septiembre de 2026 quedó firme una resolución estadounidense, el primer precedente serio sobre quién responde de lo que hace un browser agent. Una gran plataforma de comercio demandó al desarrollador de un navegador con IA porque su agent entró en la cuenta del usuario y compró en su nombre.

El tribunal de apelación desestimó la demanda, y algunas frases de la motivación merecen quedarse:

«Por avanzado que sea hoy el asistente, es una herramienta, no una persona a efectos de la ley.»

«Es el usuario quien accede al sistema, con ayuda del asistente.»

El tribunal se formuló deliberadamente estrecho: declaró que no estaba creando un régimen jurídico nuevo para la IA agéntica, y no resolvió qué pasaría con otros tipos de reclamación (una indemnización, por ejemplo).

Tiene dos consecuencias prácticas, y las dos importan si piensas en esto como empresa:

1. Las condiciones de uso siguen vigentes. El tribunal dejó constancia en una nota aparte de que la resolución no afecta al derecho de la plataforma a regular el acceso con sus propias condiciones contractuales. Solo dijo que las leyes sobre delitos informáticos no sirven de base para ello.

2. El núcleo del conflicto no fue que el agent entrara, sino que ocultara que era un agent. La cuestión técnica del pleito era una cadena identificadora que habría avisado de que el usuario había activado un agent de IA, y con la que la plataforma habría podido bloquearlo. Omitirla fue el centro de toda la disputa.

Así que si montas un negocio sobre un browser agent, el riesgo no es sobre todo penal, sino contractual: te pueden suspender la cuenta si las condiciones del proveedor prohíben el acceso automatizado. En Europa se suma el marco de transparencia de la AI Act, cuyo primer plazo de cumplimiento es el 2 de diciembre de 2026.

¿Cuándo merece la pena?

SÍ, SI
- no hay API y no la va a haber;
- la tarea puede correr en segundo plano, sin prisa;
- los pasos se pueden mantener por debajo de 50;
- el error es barato y reversible;
- tienes una cuenta aparte que puedes limitar.

NO, SI
- hay API - entonces usa esa;
- un cliente o un compañero espera la respuesta;
- hay dinero o el paso es irreversible;
- las condiciones del proveedor lo prohíben;
- no puedes saber si la ejecución salió bien.

Y un orden de preferencia que sale de las mediciones, no de una opinión:

1. API, si la hay. Más barata, rápida y fiable.
2. Si no: CÓDIGO que maneje el navegador.
   Medido: más preciso Y más barato.
3. Solo al final: captura de pantalla y clic.
4. En los tres: límite de pasos, cuenta aparte,
   permisos mínimos, registro.

Malentendidos típicos

• «Si no hay API, entonces hace falta un agent de píxeles.» No. Primero va el control del navegador por código, que según la medición es a la vez más preciso y más barato.
• «Le dejo dar más pasos y lo resuelve.» Por encima de cincuenta pasos el resultado medido empeoró. Un margen más largo no es constancia, es más ocasión de perderse.
• «Un benchmark del 85 % significa que me hará ocho de cada diez.» No. Esa cifra sale de tareas definidas con cuidado, con presupuesto máximo e intentos repetidos. Tu proceso no se parece en nada a eso.
• «El coste es proporcional al tiempo de ejecución.» El coste en tokens crece con el cuadrado del número de pasos. Por eso «solo unos pasos más» suele significar una factura multiplicada.
• «Corre en mi ordenador, o sea que es seguro.» Justo al revés: ahí están tus cuentas con la sesión iniciada. El riesgo de un browser agent no viene de dónde se ejecuta, sino de que lee contenido no fiable con permisos en la mano.
• «Una sentencia dijo que se puede.» Una resolución estadounidense dijo que ciertos tipos penales no se aplican aquí. Las condiciones contractuales de los proveedores quedaron intactas.

Lo que conviene llevarse

El computer use pasó del 12 % al 86 % en dos años, y en diciembre de 2025 superó la línea base humana. La capacidad es real — el cuello de botella es la economía.

Tres cifras que conviene tener en la cabeza: el número de pasos encarece al cuadrado, por encima de cincuenta pasos el resultado empeora y la configuración más cara no es la mejor — en una medición el nivel de razonamiento máximo costó un 43 % más por una diferencia que caía dentro del margen de error.

Y la más importante: un browser agent es buena elección cuando no hay API, la tarea puede correr en segundo plano y el error es barato. Si falla cualquiera de las tres, probablemente no sea esta la herramienta que buscas. Qué separa a un agent que llama herramientas de uno que hace clic lo cuenta el post tool use y function calling , y la forma estandarizada de conectar herramientas la resume la introducción a MCP , con ejemplos.