Computer Use en producción: agentes que manejan la interfaz

Actualizado: 2026-05-03

Cuando Anthropic publicó Computer Use en octubre de 2024 la reacción fue una mezcla de asombro y escepticismo: por un lado, un modelo que podía mirar una pantalla, mover el ratón y teclear; por otro, demasiadas dudas sobre fiabilidad, seguridad y coste para imaginarlo en producción. Casi nueve meses después, la pregunta ha cambiado. Algunos equipos lo han llevado a tareas reales y empiezan a aparecer patrones sobre dónde funciona, dónde no conviene todavía, y cómo configurarlo para que la promesa no choque con la realidad operacional.

Para el contexto de los agentes de IA en flujos de empresa más amplio, el análisis de agentes de IA en empresa cubre los criterios de adopción. Los patrones de seguridad para agentes que operan con acceso a sistemas se tratan en seguridad de agentes LLM. El post sobre CI con agentes de IA describe un escenario de uso agéntico más acotado y controlado.

Puntos clave

• La versión actual tiene tasas de error del 5-15% en tareas bien especificadas, frente al 30-40% del lanzamiento; la latencia y el coste por paso han bajado aproximadamente a la mitad.
• Funciona bien para extracción de datos desde interfaces sin API, navegación de flujos burocráticos repetitivos y validación visual de cambios en aplicaciones web.
• No es adecuado para tareas con consecuencias irreversibles sin aprobación humana, interfaces muy densas en información o tareas de más de 50 pasos sin intervención.
• El patrón de doble comprobación —el agente captura el resultado y lo compara con la expectativa antes de avanzar— reduce el error en tareas largas a costa de doblar el gasto en tokens.
• Coste orientativo: 50-150 céntimos por tarea de 20 pasos; unos 200 euros anuales por tarea ejecutada una vez al día.

Lo que ha cambiado desde octubre de 2024

La versión inicial de Computer Use era una prueba de concepto funcional. El modelo entendía capturas de pantalla, podía decidir dónde hacer clic y cómo escribir, pero la latencia era alta, la tasa de error en tareas largas era del 30 al 40%, y cada paso consumía tokens en cantidades notables. Para demos impresionaba; para trabajo real era frustrante.

Las versiones posteriores han mejorado los tres ejes:

• La latencia por paso ha bajado aproximadamente a la mitad.
• La tasa de error en tareas bien especificadas se ha reducido a la franja del 5 al 15% dependiendo de la complejidad.
• El consumo de tokens por paso ha bajado gracias a mejor compresión visual.

No es magia todavía, pero ha cruzado el umbral donde ciertas tareas empiezan a ser económicamente viables.

Dónde está funcionando ya

La primera categoría donde Computer Use brilla es la extracción de datos desde interfaces que no exponen API. Hay aplicaciones empresariales antiguas, portales de proveedores, sistemas internos con pantallas verdes que navegar con un agente sale más barato que escribir un scraper frágil o pagar una integración a medida. En un proyecto visto de cerca, un equipo reemplazó cuatro semanas de desarrollo de scraper por dos días de configuración de agente, con mejor mantenibilidad porque el agente se adapta a cambios menores de la interfaz sin rompimiento brusco.

La segunda categoría es la navegación de flujos burocráticos repetitivos: rellenar formularios multipágina con lógica condicional, descargar informes periódicos de portales con autenticación, marcar conjuntos de ítems en listas con filtros. Son tareas donde el RPA clásico funciona, pero donde el coste de configuración del RPA supera al de un agente que entiende lenguaje natural y no necesita que cada paso se grabe explícitamente.

La tercera, más experimental, es la validación visual de cambios en aplicaciones web. Un agente puede abrir una rama de preview, navegar por las pantallas críticas, describir lo que ve y comparar con la versión anterior. No sustituye a las pruebas automatizadas, pero detecta regresiones visuales y de flujo que las pruebas unitarias no cubren.

Dónde todavía no conviene

La lista de casos donde Computer Use sigue siendo problemático es más larga que la de casos donde funciona bien:

• Tareas con consecuencias irreversibles sin aprobación humana: compras, envíos, aprobaciones financieras. El coste de un error es asimétrico: el agente puede equivocarse con baja probabilidad pero la pérdida cuando se equivoca es grande.
• Interfaces muy densas en información: hojas de cálculo grandes, paneles con decenas de campos, tablas con scroll horizontal complejo. El agente pierde la pista con frecuencia.
• Contenido multilingüe o ambiguo: si el agente tiene que decidir si un botón dice «Enviar» o «Cancelar» en una captura con resolución media, el resultado depende demasiado de factores que el modelo no controla.
• Tareas de más de 50 pasos sin intervención: si cada paso tiene un 95% de éxito, una tarea de 50 pasos tiene un 7% de probabilidad de completarse sin error. Para tareas de 500 pasos, completarse sin intervención es esencialmente imposible.

Patrones que emergen

El primer patrón que se está consolidando es la ejecución con doble comprobación. El agente hace el paso, captura el resultado, compara con la expectativa declarada al principio, y solo avanza si hay coincidencia. Este patrón duplica aproximadamente el coste en tokens pero baja la tasa de error de forma notable en tareas largas. Es el equivalente a programar con aserciones en cada paso.

El segundo es la ejecución con supervisor. Un modelo más barato o un sistema de reglas clásico observa las acciones del agente principal y detiene la ejecución si aparecen señales de problema: bucle de clics en el mismo sitio, mensajes de error, pantallas inesperadas. Separar la ejecución de la supervisión en dos procesos es más caro pero mucho más robusto.

El tercero, más reciente, es la ejecución en entorno aislado con commit diferido. El agente trabaja sobre un entorno temporal —máquina virtual, contenedor, sesión de navegador privada— y los cambios solo se aplican al entorno real después de que un paso de revisión los apruebe. Este patrón es más pesado pero se adapta bien a tareas de impacto alto.

El coste real

Una tarea que el agente completa en 20 pasos consume del orden de 50 a 150 céntimos, dependiendo del modelo y del tamaño de cada captura. Para tareas ejecutadas una vez al día, el coste anual por tarea ronda los 200 euros. Para tareas ejecutadas varias veces al día, la cuenta escala rápido.

La comparación útil no es contra cero, es contra el coste de una alternativa:

• Un scraper a medida cuesta semanas de desarrollo y pago de mantenimiento continuo.
• Una integración formal con API, cuando existe, cuesta el doble.
• Una persona haciendo la misma tarea cuesta mucho más por hora.

Computer Use empieza a tener sentido económico cuando la tarea es repetitiva pero cambiante, la API no existe, y el volumen es suficiente para amortizar la configuración inicial.

Seguridad práctica

El riesgo menos discutido es el de seguridad. Un agente que maneja interfaces con credenciales vive cerca de cualquier dato visible en pantalla. Si la máquina donde el agente opera tiene acceso a correos, sistemas internos o navegadores autenticados, cualquier fallo del agente —o instrucción maliciosa inyectada en lo que ve— puede llevarlo a actuar fuera del perímetro previsto.

La recomendación para cualquier uso serio es correr el agente en una máquina virtual dedicada, con credenciales acotadas a la tarea concreta, sin acceso a nada más. La tentación de reutilizar una sesión autenticada del usuario es enorme porque simplifica la configuración, pero es la puerta rápida a un incidente. Los incidentes de seguridad con agentes de computer use vienen casi todos de ahí: credenciales demasiado generosas, perímetros demasiado amplios, supervisión inexistente.

Cuándo compensa

Mi regla práctica es: Computer Use compensa cuando la tarea es repetitiva, no tiene API disponible, el coste de error es bajo o reversible, y el volumen justifica la configuración inicial. Fuera de esos cuatro requisitos, la ecuación se complica rápido.

Para equipos que quieran explorar, la mejor vía es una tarea concreta, medida, con presupuesto acotado. Configurar el agente, medir la tasa de éxito durante dos o tres semanas, calcular el coste real y decidir si escala. Empezar con ambición grande y estrategia vaga es la forma rápida de gastar dinero sin aprender nada.

Dentro de dos años Computer Use estará en muchos más flujos de los que imaginamos hoy, pero no para reemplazar personas en tareas complejas, sino para sustituir capas de integración que ahora se hacen con scrapers y RPA frágiles. El patrón probable es agentes como puente entre sistemas viejos y sistemas nuevos, operando en turnos cortos, supervisados, y con autoridad limitada.