Los agentes computer-use llegan a producción: lo que realmente funciona en la empresa

Los agentes de IA computer-use operan el software como lo harían las personas: ven la pantalla y accionan ratón y teclado a través de apps y navegadores.

Dos años después de que los laboratorios de frontera lanzaran sus primeros bucles captura de pantalla → acción, los agentes de IA computer use ya no son solo demos de investigación. Los proveedores exponen herramientas de control del ordenador en APIs y productos de escritorio; las empresas los prueban contra GUIs heredadas que nunca tuvieron una API limpia. La pregunta difícil ya no es si un agente puede pulsar un botón. Es si la producción de agentes de IA sobrevive al contacto con flujos reales, presupuestos de tokens y equipos de riesgo.

Este artículo separa lo que miden hoy los benchmarks públicos de lo que realmente compensa en el escritorio empresarial — y dónde el abismo de capacidad sigue marcando la hoja de ruta.

Qué significa «computer use» en la práctica

Un agente computer-use observa una interfaz gráfica (normalmente mediante capturas, a veces con canales de accesibilidad o DOM) y emite acciones de bajo nivel: mover, clic, teclear, desplazar, arrastrar, esperar. A diferencia de un script RPA clásico anclado a selectores, el agente replanifica a partir del estado visual. Esa flexibilidad explica por qué los equipos recurren a estos sistemas cuando el objetivo es un portal de proveedor, un cliente grueso o un combinación de navegador y escritorio que ningún proyecto de integración terminó.

La propia guía de producto de Anthropic es franca sobre la madurez: el computer use sigue siendo temprano frente a las fortalezas de Claude en código y texto; el agente puede equivocarse; conviene empezar con apps de confianza y evitar datos sensibles; algunas apps quedan fuera por defecto; y el sistema pide permiso antes de abrir nuevas aplicaciones mientras escanea patrones de inyección de prompts. Ese marco —útil, supervisado, aún no un piloto automático silencioso— es el modelo mental correcto para los agentes de IA empresariales que tocan sistemas de producción.

La apuesta arquitectónica es portable: tratar la pantalla como una superficie de E/S universal. La apuesta operativa es más estrecha: situar el bucle dentro de un sandbox que controles, cerrar los pasos irreversibles y medir resultados en el sistema de registro — no en el autoinforme del agente.

Benchmarks: las tareas cortas suben; los flujos largos, no

De OSWorld 1.0 a OSWorld 2.0

La suite OSWorld original metía agentes multimodales en entornos reales Ubuntu, Windows y macOS con cientos de tareas abiertas de escritorio y web. En la publicación, los humanos completaban más del 72 % de las tareas mientras el mejor modelo evaluado se situaba cerca del 12 %. Esa brecha definió la primera generación de investigación computer-use: los agentes fallaban en el anclaje GUI y el conocimiento operativo incluso en interacciones relativamente cortas.

A mediados de 2026, el campo tenía una vara más reveladora. OSWorld 2.0 sustituye muchas tareas de un solo disparo por 108 flujos de largo horizonte. Humanos hábiles necesitan una mediana de unas 1,6 horas por tarea; alrededor del 70 % de las tareas dura más de una hora. Los agentes de frontera gastan del orden de 318 llamadas a herramientas en una configuración exigente de Claude Opus, frente a unas 30 en OSWorld 1.0. Las tareas se anclan en artefactos auténticos y perfiles de usuario con estado, y la suite incluye auditorías de seguridad separadas para la ejecución sensible.

Bajo la métrica primaria de tasa de éxito binaria, con un tope de 500 pasos, la configuración más fuerte reportada —Claude Opus 4.8 con thinking máximo y llamadas agrupadas— aún termina solo el 20,6 % de las tareas, con un puntuación de crédito parcial del 54,8 %. Un competidor más eficiente en tokens (GPT-5.5 en la comparación publicada) se estanca cerca del 14 % de tasa de éxito binaria. Los modos de fallo pasan de «no sabe hacer clic» a «pierde las restricciones», «omite información a mitad de tarea», «adivina en lugar de preguntar» y «salta la verificación», sobre todo cuando el estado requerido está oculto.

La economía de tokens forma ya parte de la historia del benchmark, no una nota al pie. En la frontera reportada de OSWorld 2.0, GPT-5.5 alcanza cerca del 14 % de recompensa binaria con unos 39K tokens de salida, mientras Claude Opus 4.7 sube al 18,2 % alrededor de 150K tokens y Opus 4.8 al 20,6 % alrededor de 244K. Hay más margen de finalización —pero a un coste marginal muy alto. La longitud del horizonte agrava el problema: la tasa de éxito binaria ya es débil en tareas de menos de una hora y cae hacia cero cuando los flujos superan unas dos horas y media en los intervalos publicados.

WebArena y la franja del navegador

WebArena sigue siendo la referencia para trabajo web multi-sitio realista y autoalojado (e-commerce, foros, software colaborativo, CMS). En el paper original, el mejor agente GPT-4 alcanzó un 14,41 % de éxito de extremo a extremo frente a una referencia humana del 78,24 % en tareas plantilla muestreadas. Las tablas comunitarias se han movido desde entonces, pero la lección original sigue valiendo para planificar producción: la autonomía del navegador es una superficie de producto distinta de la ejecución fiable de negocio, y los bancos de pruebas importan tanto como los nombres de modelo.

El precipicio empresarial: UI-CUBE

Las puntuaciones académicas de escritorio y web pueden parecer alentadoras mientras la preparación empresarial sigue siendo fina. El benchmark UI-CUBE de UiPath se construyó explícitamente para esa brecha: 226 tareas entre interacciones UI simples (136) y flujos complejos (90, incluidos copiar-pegar / procesos de negocio y aplicaciones empresariales simuladas como CRM, ERP, gastos, RR. HH. y tableros de proyecto), con pruebas multi-resolución y comprobaciones programáticas contra el estado de la aplicación.

Los resultados muestran un precipicio de capacidad, no una curva suave. Promediando resoluciones, los sistemas evaluados alcanzan aproximadamente 67–85 % de éxito en interacciones simples (humanos: 97,9 %) pero solo 9–19 % en flujos complejos. Humanos sin experiencia previa en la app logran aún solo el 61,2 % en esas tareas complejas —un techo importante para quien compare agentes con «lo que haría una persona el primer día». Relativo a los humanos, los agentes alcanzan cerca del 68–87 % del rendimiento humano en lo simple, pero solo el 15–32 % en lo complejo. La resolución amplifica la fragilidad: varios modelos pierden decenas de puntos porcentuales en tareas simples al pasar de XGA a 4K, porque los errores de anclaje crecen con un espacio de acción en píxeles mayor.

Los autores de UI-CUBE argumentan que la discontinuidad apunta a límites arquitectónicos de memoria, planificación jerárquica y coordinación de estado —límites que el prompting solo no borrará. Su recomendación práctica coincide con lo que los equipos de producción ya redescubren: descomponer procesos complejos en pasos atómicos que los modelos actuales pueden manejar, en lugar de esperar que una trayectoria larga se sostenga.

Los fallos silenciosos vencen a las demos llamativas

El software empresarial falla de forma distinta a las demos de consumo. ERPBench evalúa agentes solo-captura contra un ERP vivo y reproducible y califica las tareas contra una verdad de terreno en base de datos, no solo capturas. La advertencia central del paper: un fuerte rendimiento GUI general no se traslada a fiabilidad empresarial. Los agentes pueden navegar hasta el registro correcto e incluso pulsar guardar mientras escriben el valor equivocado. En un patrón reportado, un modelo abierto alcanzó el objetivo en la mayoría de ejecuciones y confirmó un guardado en una gran parte de ellas, pero dejó el valor correcto en base solo en unos pocos porcentajes de casos —casi cada guardado era un riesgo de corrupción silenciosa.

Esa clase de error es invisible a métricas del tipo «¿el agente parecía ocupado?» y devastadora para finanzas, inventario y RR. HH. Para la producción de agentes de IA, los criterios de éxito deben vivir en el sistema de registro: aserciones a nivel de campo, escrituras idempotentes y aprobación humana antes de commits irreversibles.

El coste en tokens no es toda la factura — pero ya moldea el diseño

Los bucles computer-use son pesados en capturas. Cada observación puede enviar una carga multimodal grande; cada recuperación tras un clic erróneo quema otro turno. La frontera tokens-frente-a-puntuación de OSWorld 2.0 explica por qué a finanzas le importa: empujar unos pocos puntos de finalización puede multiplicar varias veces los tokens de salida. Mientras, los agentes suelen dar más pasos que las personas para la misma tarea —estudios de eficiencia citados junto a OSWorld reportan aproximadamente 1,4–2,7× el recuento de pasos humanos en agentes líderes—, de modo que latencia y coste escalan con el thrashing, no solo con las tarifas del modelo.

Una heurística de producción útil se sigue de la evidencia, sin inventar teatro de ROI:

1. Preferir APIs y conectores cuando existen. La propia pila de producto de Anthropic prioriza conectores precisos antes de caer al control de pantalla.
2. Acotar el horizonte. Las tareas que caben en unas pocas docenas de acciones fiables son candidatas; las odiseas multi-app a escala de horas son investigación.
3. Presupuestar automatización parcial. Emparejar el agente con validadores deterministas y revisión humana en movimientos de dinero, cambios de identidad y mensajes externos.
4. Medir el coste por resultado verificado, no por token ni por demo. Una trayectoria barata que escribe datos ERP incorrectos es infinitamente cara.

Fiabilidad y límites de seguridad que deciden el go-live

Los agentes computer-use heredan todos los riesgos clásicos de automatización y añaden otros propios del modelo:

• Inyección de prompts vía pantalla. Contenido de página no confiable, correos y documentos pueden instruir al agente. Los clasificadores del proveedor ayudan; no sustituyen allowlists de red y de acciones en la capa de ejecución.
• Exfiltración de credenciales y datos. Las capturas pueden contener secretos. Redacción antes de la inferencia y cuentas de servicio de mínimo privilegio son controles base.
• Persistencia del entorno. Los escritorios compartidos acumulan cookies y archivos. Contenedores o VM efímeros por ejecución reducen el radio de explosión.
• Acciones irreversibles. Compras, borrados, instrucciones de transferencia y despliegues de producción necesitan puertas humanas explícitas —la misma postura que recomienda Anthropic cuando aparecen acciones de consecuencias.
• Auditabilidad. Registrar observaciones, acciones, aprobaciones y postcondiciones en tu plano de control. No depender solo de una transcripción de chat del proveedor.

Lo que realmente funciona en la empresa hoy

Sintetizando benchmarks y guía de proveedores, el patrón que funciona para los agentes de IA computer use en 2026 se parece a esto:

Alto encaje (desplegar con salvaguardas)

• Tareas UI atómicas dentro de apps conocidas: abrir un formulario, rellenar campos desde una carga estructurada, descargar un archivo, exportar un informe, avanzar por un asistente fijo.
• Tareas de navegador con postcondiciones claras en dominios allowlisted, sobre todo cuando un camino Playwright o API puede tomar el relevo tras la navegación.
• Asistentes de desarrolladores y analistas que pilotan IDEs, terminales y herramientas internas bajo supervisión —donde los errores son reversibles y la revisión es natural.
• Despacho con humano en el bucle: el agente prepara; una persona aprueba el commit.

Encaje medio (pilotar de forma estrecha)

• Copiar-pegar multi-paso entre dos o tres sistemas familiares con verificación programática tras cada salto.
• Manejo de excepciones encima de RPA existente: el agente propone una vía de recuperación; la automatización o un humano la ejecuta.
• Reconocimiento mayoritariamente de lectura (recoger estado, evidencia en captura, borrador de ticket) sin acceso de escritura a sistemas de registro.

Bajo encaje (dejarlo en el laboratorio)

• Flujos desatendidos a escala de horas que atraviesan correo, portales bancarios, CAD y ERPs heredados sin checkpoints intermedios —precisamente donde OSWorld 2.0 y UI-CUBE muestran el colapso.
• Cualquier proceso donde un guardado incorrecto es peor que no guardar (datos maestros ERP críticos, nómina, historiales clínicos) salvo oráculos a nivel de base y aprobaciones obligatorias.
• Programas de «reemplazar al equipo de servicios compartidos» vendidos con capturas de leaderboard de tareas cortas.

La implicación estratégica para plataformas y «grandes actores de la IA» es convergencia, no un único ganador: agentes de captura portables, automatización nativa de navegador y control impulsado por código (estilo Playwright) coexistirán. Las empresas que ganen encaminarán cada flujo al sustrato fiable más barato —API primero, automatización estructurada de navegador después, computer use completo al final— y construirán suites de evaluación más parecidas a UI-CUBE y ERPBench que a demos de marketing.

Una lista de comprobación práctica de producción

1. Definir el resultado en datos, no en narrativas de UI. Preferir diffs de estado y comprobaciones de base.
2. Limitar pasos, tiempo y dominios. Los interruptores de emergencia vencen a los bucles infinitos de reintento.
3. Descomponer procesos largos en unidades a tamaño de agente con checkpoints y crédito parcial en tu propio arnés.
4. Separar las etapas navegar / introducir / confirmar en las métricas para que las escrituras incorrectas silenciosas no se escondan detrás de «llegó al formulario».
5. Precificar el bucle completo: tokens, cómputo del sandbox, tiempo de revisor y retrabajo.
6. Modelar la amenaza de la pantalla como un canal no confiable.
7. Reejecutar benchmarks en tus apps a tus resoluciones; las puntuaciones publicadas de OSWorld o WebArena son pantallas, no certificados.

Conclusión

Los agentes computer-use han entrado en la caja de herramientas empresarial. En trabajo UI corto y bien acotado son cada vez más competentes; en procesos de negocio largos, con estado y multi-app, la evidencia pública —del techo de ~21 % de tasa de éxito binaria de OSWorld 2.0 a las tasas de un dígito / teens bajos de UI-CUBE en lo complejo y a los fallos de guardado incorrecto de ERPBench— dice que aún no son pilotos automáticos fiables.

Lo que funciona hoy es una autonomía parcial disciplinada: agentes de IA empresariales que hacen clic donde faltan APIs, se detienen donde empieza el riesgo y demuestran el éxito en el libro mayor. Trata las subidas de leaderboard como señal de investigación. Trata la producción como un problema de sistemas —evaluación, sandbox, coste y gobernanza— alrededor de una habilidad de modelo aún en maduración.

Lecturas relacionadas

• Modelos de frontera de pesos abiertos frente a API cerradas: la contrapartida de la soberanía
• De los chatbots al work OS: cómo los asistentes de IA se tragan el SaaS empresarial
• Navegador, IDE y SO: los tres campos de batalla de las interfaces de IA

Imágenes: ilustraciones originales creadas para AndBeyond.Tech; no aparecen logotipos ni personas reales.