
Computer use: IA que usa la pantalla como una persona
Computer use es una IA que ve la pantalla, mueve el cursor y teclea para completar tareas en cualquier app. Es útil, pero en 2026 aún falla en tareas largas.
¿Cómo funciona?
El ciclo es simple: el agente recibe una captura de pantalla, decide una acción (hacer clic en una coordenada, escribir un texto, desplazarse), la ejecuta, observa el nuevo estado y repite. Es el mismo loop de un agente de pensar, actuar y observar, pero con la pantalla como entorno.
Esa flexibilidad tiene un costo. Cada paso requiere interpretar una imagen, y las tareas largas acumulan muchos pasos. Un agente que llena un formulario en un sitio antiguo tiene que leer etiquetas, detectar errores y recuperarse si una ventana emergente cambia el orden de los campos.
¿Qué tan bien funciona hoy?
El benchmark de referencia es OSWorld. Su versión original evalúa 369 tareas de uso real de computadora, cada una con un script de evaluación basado en ejecución. Según el sitio del proyecto, las personas completan más de 72% de esas tareas, mientras que en el lanzamiento de 2024 el mejor agente llegó a 12,24%.
En junio de 2026 apareció OSWorld 2.0, con 108 flujos largos. Según el artículo, una persona tarda una mediana de unas 1,6 horas en cada uno (en la versión original, unos dos minutos), y el agente de mayor consumo usó cerca de 318 llamadas a herramientas por tarea, frente a unas 30 antes. El mejor modelo completó 20,6% de las tareas con puntuación binaria estricta y llegó a 54,8% de puntaje parcial con un límite de 500 pasos. Otro modelo fue más eficiente en tokens, pero se estancó cerca de 13%.
Lo más útil del estudio no es el número, sino el diagnóstico: los agentes fallan sobre todo por razonamiento y gestión de la tarea. Pierden restricciones, no ven información que aparece a mitad de camino, adivinan en lugar de preguntar y se saltan la verificación. El control básico de la interfaz, como hacer clic en el lugar correcto, deja de ser el cuello de botella.
¿Qué ofrecen hoy los proveedores?
Los tres grandes laboratorios exponen computer use como una herramienta de API en la que tu aplicación ejecuta las acciones y devuelve capturas:
- Anthropic: la herramienta de computer use de la API de Claude. Las versiones anteriores (
computer_20251124,computer_20250124) exigen un encabezado beta; el conjunto de herramientas actual (computer_toolset_20260801) no lo necesita, aunque las clases del SDK siguen en beta. - OpenAI: la herramienta
computerde la Responses API, que sustituye al antiguo modelocomputer-use-preview. - Google: la herramienta
computer_usede la API de Gemini, con entornos de navegador, móvil y escritorio.
Las tres documentaciones coinciden en lo esencial: aislar el entorno, tratar el contenido de pantalla como no confiable y pedir confirmación humana antes de acciones con consecuencias. Los nombres de modelos y versiones cambian cada pocos meses, así que consulta la documentación oficial antes de construir sobre ellos.
¿Cuándo conviene usarlo?
Computer use tiene sentido en tres casos:
- No hay API. Un sistema viejo o un portal sin integración.
- El flujo es repetitivo y acotado. Pasos claros, sin decisiones de alto riesgo.
- Hay revisión humana en los resultados que importan. El agente propone, la persona confirma.
Si existe una API o una integración estable, casi siempre es mejor usarla. Es más rápida, más barata y menos frágil que mirar una pantalla.
Pasos para probar un caso de uso
- Elige una tarea repetitiva con inicio y fin claros y un resultado verificable.
- Ejecútala en un entorno aislado, con una cuenta de prueba y sin acceso a datos reales.
- Registra en qué paso falla el agente, qué confirma y qué omite.
- Mide el tiempo y el número de correcciones, no solo si terminó.
- Decide si el ahorro justifica la supervisión antes de usarlo con datos reales.
Ejemplo ilustrativo
Ejemplo ilustrativo: una agencia de diseño tiene que descargar cada mes reportes de un portal de un cliente que no tiene API. Un agente de computer use hace el recorrido en un entorno aislado con una cuenta de prueba. Funciona en tres de cada cuatro meses. En el mes que falla, el portal cambió el orden de un menú y el agente descargó el reporte equivocado sin avisar. El equipo añade una verificación: el agente debe leer el nombre del archivo y el periodo, y compararlo con una lista antes de guardarlo. La tarea sigue siendo supervisada, pero ya no depende de la suerte.
¿Qué medidas de seguridad aplicar?
Tres medidas básicas antes de cualquier prueba real. La primera es el aislamiento: una máquina virtual o un perfil de navegador dedicado, sin sesiones guardadas de cuentas personales ni de la empresa. La segunda es el mínimo privilegio: el agente solo ve las carpetas y los sitios que necesita para la tarea, y nada más. La tercera es la confirmación en los pasos irreversibles, como enviar un formulario con datos de pago o borrar un archivo.
Hay además un riesgo menos visible: una página web puede contener texto diseñado para desviar al agente, por ejemplo instrucciones escondidas que le piden compartir datos. Trata todo lo que el agente lee en pantalla como información no confiable, no como instrucciones. Anthropic recomienda además restringir el acceso a internet a una lista de dominios permitidos y no dar al modelo datos sensibles como credenciales. Para el marco de permisos, revisa sandboxing y permisos de agentes.
¿Qué registrar en cada ejecución?
Cada ejecución debe dejar un registro que se pueda revisar sin repetirla. Guarda la captura inicial, la lista de acciones con su hora, la captura final y el resultado de la verificación. Si el agente falla, el registro muestra en qué captura se desvió, algo que no puedes ver en un simple “tarea fallida”. Esos registros también sirven para comparar versiones del flujo cuando el portal cambia.
Conserva los registros con una política de retención clara, porque las capturas pueden contener datos personales. Borrarlas a tiempo es parte de la seguridad, no un detalle de almacenamiento.
Errores comunes
- Darle acceso a cuentas reales en la primera prueba.
- Medir solo si la tarea terminó, sin contar errores silenciosos.
- Usarlo cuando existe una API estable.
- Confiar en que un agente que hizo bien tres casos hará bien el cuarto.
- Olvidar que una página puede contener instrucciones que intenten desviar al agente.
Cuándo NO conviene usarlo
Cuando la tarea tiene consecuencias graves, como pagos, cambios de contraseña o envíos a clientes, y no hay confirmación humana. También cuando el flujo cambia con frecuencia, porque el agente se rompe con cada rediseño. Para pensar en el límite de autonomía, revisa niveles de autonomía de un agente y sandboxing y permisos de agentes.