Agentes de uso de computadoras: por qué una demostración exitosa aún puede ser un sistema poco confiable

Los agentes de uso de computadoras ahora pueden hacer clic, escribir, navegar, editar archivos, operar aplicaciones de escritorio y completar impresionantes tareas de varios pasos. Eso hace que las demostraciones exitosas sean fáciles de entender y fáciles de sobreinterpretar. Un solo flujo de trabajo completado muestra que el agente puede tener éxito bajo esas condiciones. No muestra con qué frecuencia tiene éxito, cómo se comporta cuando el entorno cambia, si verifica el resultado o con qué seguridad actúa cuando el objetivo se vuelve ambiguo.

Por qué la demostración es la prueba de confiabilidad más sencilla posible

Una demostración suele mostrar una trayectoria que funcionó. El entorno es conocido, la tarea se selecciona con anticipación, el operador puede reiniciar tras un fallo y la audiencia ve la ruta exitosa. En cambio, los sistemas en producción se enfrentan a una distribución: diferentes páginas, condiciones de red, estados de cuenta, ventanas emergentes, latencia, cambios en la interfaz de usuario, estados ocultos, permisos, interrupciones y usuarios que describen los objetivos de forma imperfecta.

Esa distinción es importante porque los agentes de uso de computadoras operan a través de interfaces diseñadas para humanos en lugar de APIs deterministas. Su ciclo de acción depende de la percepción, la interpretación del estado, la planificación, la sincronización de las interacciones y la respuesta del entorno. Pequeños cambios pueden alterar la trayectoria incluso cuando el objetivo del usuario no ha cambiado.

El trabajo WAREX de Microsoft Research hace explícito el problema: los agentes de benchmark que parecen capaces en entornos controlados pierden un éxito sustancial en las tareas cuando se introduce una inestabilidad web realista. El fallo no se debe necesariamente a que «el modelo se volvió menos inteligente». El entorno dejó de ser determinista.

Capacidad, tasa de éxito, confiabilidad y seguridad son afirmaciones distintas

La Escala de Confiabilidad para el Uso de Computadoras

Una forma útil de evaluar los sistemas de uso de computadoras es avanzar desde la capacidad puntual hacia propiedades de confiabilidad progresivamente más complejas. Los niveles superiores asumen los inferiores, pero no se derivan automáticamente de ellos.

Nivel 1 — Capacidad: la pregunta de la demostración

La capacidad cuestiona si un agente puede realizar la tarea en absoluto. Esto es valioso. Los sistemas de uso de computadoras han avanzado rápidamente, y los agentes modernos pueden completar flujos de trabajo que los sistemas anteriores no podían ejecutar de forma confiable.

Pero la capacidad es un criterio débil para el despliegue. Una sola ejecución exitosa no indica si el agente tiene éxito el 95% de las veces o el 30% de las veces, si los fallos son inofensivos o destructivos, o si el éxito depende de un estado afortunado de la página.

Nivel 2 — Repetibilidad: ¿se mantiene resuelta la misma tarea?

Las trayectorias de uso de la computadora son estocásticas. Las respuestas de los modelos varían, las páginas cargan a diferentes velocidades, los estados visuales cambian y los flujos de trabajo largos generan múltiples ramificaciones. Por lo tanto, una prueba en producción debe ejecutar la misma tarea varias veces en lugar de tratar un único rastro exitoso como representativo.

Mida no solo la tasa de éxito promedio, sino también la distribución de los modos de fallo: clic erróneo, finalización prematura, confirmación omitida, campo incorrecto, acción duplicada, bucle de navegación, suposición de estado obsoleto y reporte de falso éxito.

Nivel 3 — Robustez ambiental: ¿qué ocurre cuando la web se comporta como la web?

Los sitios web reales no son entornos de referencia estáticos. Las solicitudes fallan, los elementos tardan en cargar, las sesiones caducan, las páginas cambian, aparecen banners de consentimiento, los servidores devuelven errores y las condiciones de la red fluctúan.

WAREX evalúa esta brecha inyectando una falta de fiabilidad web realista en los entornos de referencia existentes y reporta caídas significativas en el éxito de las tareas. Esta es una perspectiva crítica para la producción: un benchmark puede medir la competencia en la tarea mientras subestima la recuperación ante la inestabilidad ambiental.

Nivel 4 — Control de horizonte largo: el éxito cambia cuando la tarea se convierte en trabajo real

Las tareas cortas ocultan una clase de fallos que solo aparecen tras decenas o cientos de acciones: restricciones olvidadas, trabajo duplicado, finalización prematura, cambios de estado no detectados, inconsistencias entre aplicaciones y pequeños errores acumulados.

OSWorld 2.0 se diseñó específicamente en torno a flujos de trabajo reales de horizonte largo. Sus tareas toman a los usuarios humanos una mediana de aproximadamente 1,6 horas y requieren muchas más llamadas a herramientas que los benchmarks anteriores de uso de computadoras. Bajo su métrica principal de finalización, incluso los sistemas evaluados más avanzados siguen estando lejos de una fiabilidad completa en la tarea.

WeaveBench llega a una conclusión similar desde otra perspectiva. Evalúa flujos de trabajo híbridos de GUI, CLI y código, e informa que la mejor combinación evaluada de modelo y entorno de ejecución supera solo el 41,2 % de las tareas. El resultado importante no es una cifra en una tabla de clasificación; es que la orquestación realista entre interfaces expone fallos ocultos en tareas más simples de una sola interfaz.

Nivel 5 — Conciencia del estado: el entorno puede cambiar por debajo del plan

Las tareas de larga duración a menudo dependen de un estado oculto o cambiante: llega un correo electrónico, se modifica un calendario, se envía un formulario, finaliza un proceso en segundo plano, caduca una sesión del navegador, un usuario modifica un archivo o un sistema externo cambia su disponibilidad.

SentinelBench de Microsoft sostiene que muchas tareas de larga duración no deberían resolverse en absoluto mediante una acción continua. El comportamiento correcto puede ser monitorizar, esperar un evento externo y luego actuar cuando el estado cambie. Esta es una capacidad diferente a hacer clic más rápido o planificar más pasos.

Por lo tanto, un agente de uso de computadoras fiable necesita distinguir entre ejecutable ahora, esperando estado, estado cambiado y suposición invalidada.

Nivel 6 — Verificación de resultados: ¿realmente funcionó la acción?

Un agente puede ejecutar una secuencia aparentemente correcta y, aun así, fracasar en la tarea. Es posible que no se registre el clic en un botón. Un formulario puede rechazar una validación oculta. Un archivo puede guardarse en el directorio incorrecto. Una compra puede quedar sin confirmar. Un sitio web puede mostrar una pantalla que aparenta éxito mientras la operación subyacente falló.

Las directrices actuales de OpenAI sobre el uso de computadoras recomiendan explícitamente acotar y verificar la ejecución en lugar de confiar únicamente en la respuesta final del modelo. El trabajo de Microsoft Research sobre verificadores de uso de computadoras llega a la misma conclusión a partir de la evaluación: el proceso y el resultado deben juzgarse por separado.

La investigación de Universal Verifier reporta que las configuraciones de verificación anteriores pueden producir altas tasas de falsos positivos, mientras que un diseño de rúbricas más sólido y la separación explícita de proceso, resultado, fallos controlables y fallos incontrolables mejoran sustancialmente la coincidencia con las etiquetas humanas.

Nivel 7 — Gestión segura de objetivos: el agente debe saber cuándo no continuar

Los agentes de uso de computadoras están optimizados para cumplir objetivos, pero la persistencia hacia el objetivo puede convertirse en sí misma en un modo de fallo. Una solicitud ambigua, una condición imposible, una instrucción contradictoria, una página web sospechosa o un entorno modificado pueden requerir aclaración o detenerse en lugar de tomar más acciones.

El benchmark BLIND-ACT estudia este problema como Direccionalidad Ciega hacia el Objetivo (Blind Goal-Directedness). En todos los sistemas evaluados en ese trabajo, los agentes continuaron con frecuencia persiguiendo tareas a pesar de la ambigüedad, la inviabilidad, el contexto conflictivo u otros motivos para reconsiderar. Los autores identifican patrones como el sesgo de ejecución primero (execution-first bias) y la primacía de la solicitud (request primacy).

Esta clase de fallo es importante porque un agente altamente capaz puede empeorar una mala situación con mayor rapidez. Por lo tanto, la fiabilidad incluye una política sobre cuándo no actuar.

La prueba de estrés de la demo a producción

Antes de implementar un flujo de trabajo de uso de computadora, tome la demo exitosa y elimine sistemáticamente los supuestos que la hicieron sencilla.

El éxito en los benchmarks tiene un límite de validez

Una puntuación de benchmark es una afirmación condicional. Es válida para un modelo, harness, entorno, conjunto de tareas, evaluador, interfaz de herramientas, presupuesto de pasos, política de reintentos, fecha y método de evaluación específicos.

El número se vuelve engañoso cuando esas condiciones desaparecen de la afirmación. «El agente X obtiene un 80 %» es más débil que «El agente X obtuvo un 80 % en el benchmark Y bajo el entorno Z con el evaluador J y un presupuesto de pasos N». La segunda afirmación preserva el límite que indica si la cifra es extrapolable a su aplicación.

El éxito del proceso y el éxito del resultado deben puntuarse por separado

WeaveBench informa que la calificación basada únicamente en el resultado puede sobreestimar materialmente el rendimiento en el uso de computadoras, ya que un agente puede producir un artefacto aparentemente exitoso mediante un atajo o evidencia fabricada. El verificador debe inspeccionar la trayectoria y los entregables, no simplemente la afirmación final.

La fiabilidad en producción es una distribución, no una única tasa de éxito

Una evaluación de producción útil muestrea las dimensiones que realmente varían en su entorno. Para un flujo de trabajo en el navegador, esto podría incluir la antigüedad de la cuenta, la configuración regional, el viewport, la versión de la página, la calidad de la red, el estado de autenticación, el estado existente del carrito, las cookies, las ventanas emergentes, los permisos de usuario y si un humano interrumpe la ejecución.

La fiabilidad necesita un presupuesto de fallos, no la perfección

Ningún sistema en producción es perfectamente fiable. La pregunta útil de ingeniería es qué fallos son aceptables, detectables y recuperables. Un intento fallido de ordenar una carpeta local no equivale a enviar el correo electrónico equivocado, comprar el producto erróneo o cambiar la configuración de una cuenta.

Clasifique las acciones según sus consecuencias y reversibilidad. Las acciones reversibles de bajo impacto pueden tolerar una mayor autonomía. Las acciones de alto impacto, visibles externamente o difíciles de revertir requieren una confirmación más sólida, verificación de estado, autorización y comprobaciones posteriores a la acción.

Una matriz práctica de fiabilidad para el uso del ordenador

Qué registrar ante un fallo en el uso del ordenador

• Objetivo del usuario y restricciones explícitas.
• Versión del modelo y del harness.
• Versiones del entorno y de las aplicaciones.
• Capturas de pantalla u observaciones estructuradas relevantes para el fallo.
• Acciones realizadas con marcas de tiempo.
• Resultados de herramientas, clics, teclado y navegación.
• Transiciones de estado y periodos de espera.
• Eventos de aprobación, rechazo o transferencia.
• Errores externos y fallos de red.
• Estado final observable del entorno.
• Resultado reportado por el agente.
• Resultado del verificador y si el fallo era controlable por el agente.

La comparación crucial es entre el éxito reportado y el éxito observable. Un sistema que no pueda distinguir entre ambos acumulará con el tiempo falsos positivos en producción.

La seguridad es parte de la fiabilidad para los agentes de uso del ordenador

Los agentes de uso del ordenador no solo leen contenido no confiable; pueden actuar después de leerlo. Esto convierte la inyección de prompts, el contenido malicioso de páginas y el phishing en riesgos en la ruta de ejecución.

La guía actual de OpenAI para el uso del ordenador recomienda aislar el entorno, crear listas de permitidos para sitios y acciones, tratar el contenido en pantalla como no confiable, confirmar las acciones de impacto, delimitar la ejecución y verificar el resultado real. El agente de ChatGPT utiliza de manera similar confirmaciones, monitorización de inyección de prompts y modos supervisados para contextos sensibles.

El principio arquitectónico va más allá de cualquier proveedor concreto: no se debe permitir que el contenido observado por el agente redefina la autoridad del usuario. Una página web puede proporcionar datos. No puede otorgar permisos para enviar datos a otro lugar, realizar compras, modificar credenciales o anular los límites de la tarea.

¿Qué cambiaría esta respuesta?

La brecha de fiabilidad se reduciría si los modelos de uso del ordenador se volvieran robustos frente a horizontes largos, estados dinámicos, variaciones en la interfaz de usuario, fallos del entorno y objetivos ambiguos en distribuciones representativas de producción. Unas mejores API de estado nativo, interfaces legibles por máquinas estandarizadas y una infraestructura de verificación más sólida también podrían reducir la cantidad de interacción frágil con la interfaz gráfica requerida.

El umbral de despliegue también cambia según las consecuencias de la tarea. Una tasa de éxito del 70 % puede ser útil para una tarea de investigación supervisada y de bajo riesgo, e inaceptable para un flujo de trabajo financiero o destructivo autónomo. Por tanto, la fiabilidad debe evaluarse en función del coste de cada clase de fallo, no mediante un umbral universal de tasa de aprobación.

Limitaciones

Los benchmarks citados evalúan entornos diferentes y no deberían clasificarse comparándose entre sí como si midieran lo mismo. WAREX pone a prueba la falta de fiabilidad web; WeaveBench se centra en el trabajo híbrido de horizonte largo; OSWorld 2.0 se enfoca en flujos de trabajo largos y realistas; BLIND-ACT se centra en la gestión de objetivos bajo ambigüedad e inviabilidad.

Los resultados de los benchmarks también envejecen con rapidez. Las mejoras en el modelo, el harness y los verificadores pueden modificar sustancialmente las puntuaciones en cuestión de meses. Por consiguiente, la lección duradera radica en el método de evaluación: variar las condiciones, separar el proceso del resultado, verificar el estado externo y preservar los límites en torno a cada afirmación sobre el rendimiento.

Conclusión

Los agentes con manejo de ordenadores ya son lo suficientemente competentes como para ser útiles. Por esa misma razón, la pregunta de evaluación ha cambiado. El reto ya no es solo si un agente puede completar un flujo de trabajo mediante clics. Consiste en saber si el sistema sigue siendo fiable cuando desaparecen las condiciones ideales de la demo.

Considere una ejecución exitosa como prueba de capacidad. Luego, evalúe la repetibilidad, la robustez ambiental, el control de horizontes largos, la percepción del estado, la verificación de resultados y la gestión segura de objetivos. Un agente con manejo de ordenadores para producción no es aquel capaz de completar la demo, sino aquel cuyos límites de fallo se conocen, se miden y se controlan.

Preguntas frecuentes

Glosario

Fuentes primarias y lecturas complementarias