La conversación sobre la integración de un sistema antiguo casi siempre empieza igual: «No hay API». Antes venían una pausa y un presupuesto de trabajo manual; ahora hay una respuesta que suena a llave maestra: que el agente simplemente haga clic en lugar de la persona. Técnicamente funciona, y la demostración resulta convincente: el agente abre la ventana, encuentra el campo, escribe el valor y hace clic en «Guardar». La pregunta difícil es otra: qué pasará con esa automatización dentro de cuatro meses, cuando el proveedor del programa mueva el botón dos centímetros a la izquierda.
La respuesta depende de en qué se apoya el agente en el momento de actuar: en un contrato escrito o en una imagen. Las formas de integración se ordenan en peldaños, y cada uno da más alcance y menos apoyo que el anterior. Lo sensato es ir de arriba abajo y detenerse en el primer peldaño que resuelva la tarea.
Los peldaños de la integración, de menor a mayor fragilidad
El primero y el más sólido es una API documentada. No trabajas con el programa, sino con su contrato escrito: qué campos existen, qué devuelve la respuesta, qué se considera un error. Ese contrato también cambia, pero cambia con aviso: tiene versiones, y el proveedor tiene un calendario de soporte para las antiguas. El fallo llega con advertencia y con fecha.
En el segundo peldaño están los eventos y los webhooks, cuando la propia plataforma te envía un aviso del cambio. Aquí todavía hay contrato, pero la entrega ya no está garantizada: Bitrix24 dice expresamente que los eventos no se reenvían, y Shopify recomienda no confiar en absoluto en la entrega de webhooks. Hemos analizado esta clase de fallos por separado en el artículo «Dónde termina tu automatización»; el enlace está al final de este texto.
El tercero es un conector listo para usar o una plataforma iPaaS entre tus sistemas. No escribes código, y eso es un ahorro real, pero entre tú y el sistema ha aparecido un proveedor más, con su propio calendario de lanzamientos. Cuando la plataforma actualiza su API, el conector no la alcanza al instante, y en la ventana entre esos dos eventos vives tú.
El cuarto peldaño es el intercambio de archivos: exportación programada, importación programada, CSV o XML en una carpeta. Se lo saltan con frecuencia por anticuado, y es un error. El intercambio de archivos no da tiempo real, pero en los sistemas corporativos la estructura de la exportación cambia con mucha menos frecuencia que los formularios en pantalla, y el fallo se nota de inmediato: el archivo corresponde a la estructura esperada o no. Si la tarea tolera una hora de retraso, este peldaño suele resultar el más barato de los que funcionan de forma fiable.
Después viene el scraping de la página o la llamada a una solicitud interna no documentada que has visto en la pestaña «Red» del navegador. Formalmente, esto ya es trabajar sin contrato: te apoyas en un marcado y en una dirección que el proveedor no te prometió y que tiene derecho a cambiar cualquier martes.
El sexto y último es Computer Use. No hay apoyo alguno: el agente ve lo mismo que ve una persona, es decir, una imagen de la pantalla, y cada una de sus acciones es una conjetura sobre lo que está dibujado en ese punto. Todo lo que en los peldaños anteriores estaba escrito como texto, aquí hay que reconocerlo de nuevo cada vez.
Qué muestran las mediciones
Este campo se mide públicamente. El benchmark OSWorld, de investigadores de la Universidad de Hong Kong, Salesforce Research, Carnegie Mellon y la Universidad de Waterloo, sienta al agente frente a un sistema operativo real y le da tareas de trabajo. En la primera versión, publicada en 2024, las personas completaban más del 72% de las tareas y el mejor modelo, el 12,24%; además, fallaba en lo más simple: no lograba entender de forma fiable dónde hacer clic en la pantalla.
En dos años esa parte del problema ha quedado resuelta en gran medida, y justamente por eso en junio de 2026 salió la segunda versión del benchmark, con 108 escenarios largos de extremo a extremo en lugar de operaciones cortas. La tarea mediana le lleva a una persona cualificada cerca de 1,6 horas, casi el 70% de las tareas duran más de una hora, y en una tarea así el agente gasta de media 318 llamadas a herramientas, frente a unas 30 en la primera versión.
Los resultados en esos escenarios son estos. En la métrica principal (la tarea se lleva hasta el final o no) el mejor resultado es el de Claude Opus 4.8 con el máximo esfuerzo de razonamiento: un 20,6% de tareas completadas, con un crédito parcial del 54,8%. GPT-5.5 es mucho más económico en tokens, pero se estanca cerca del 14%. A octubre de 2026, la clasificación del benchmark la encabeza Claude Opus 5: un 44,33% de tareas completadas en la versión actualizada del conjunto de tareas, la v2.1; más del doble, pero todavía menos de la mitad.
La tasa de finalización solo se sostiene en los escenarios cortos. Los autores construyeron el desglose por duración con la generación anterior de modelos, GPT-5.5 y Claude Opus 4.7, de modo que el 20,6% general del más reciente Opus 4.8 se acumula justamente en los tramos cortos y medios, y no de manera uniforme en toda la escala. En los escenarios de menos de 45 minutos de trabajo humano, ambos modelos logran entre el 20 y el 24%, y de ahí en adelante caen rápido. En el tramo de 137 a 163 minutos ya ninguno de los modelos evaluados supera el 10%, y en todo lo que dura más de 163 minutos la tasa de finalización es cero para cada uno de ellos. Es un precipicio, no una degradación gradual. Un escenario para Computer Use hay que cortarlo en tramos cortos con una verificación entre ellos, porque una cadena larga simplemente no llega al final.
Los agentes no fallan donde se espera
La intuición dice que el agente errará con el ratón. Los autores de la segunda versión del benchmark registran otra cosa: los modelos no tropiezan ni con el manejo básico de la interfaz ni con el código. Pierden las restricciones fijadas al inicio de la tarea, pasan por alto información que llega ya durante la ejecución, adivinan donde convendría preguntar y no verifican su propio resultado. Lo que peor se les da es el trabajo que depende de un estado oculto: de aquello que no se ve en la pantalla actual.
Estas son seis filas del desglose de las dificultades en los 108 escenarios:
- precisión visual y espacial (se necesita en el 41,7% de las tareas): acertar, alinear, cotejar a nivel de píxeles
- inferir un estado implícito (39,8%): el valor necesario no está escrito en ninguna parte y hay que sacarlo de registros anteriores o de logs
- seguir el estado de muchos objetos (39,8%): mantener decenas de filas, registros o ediciones coherentes entre sí hasta el final del escenario
- resolver contradicciones (36,1%): dos fuentes dicen cosas distintas y hay que entender cuál de ellas manda
- trabajar según instrucciones (20,4%): extraer un procedimiento de un PDF o de un vídeo y aplicarlo a un caso que las instrucciones no describen
- cambio de condiciones sobre la marcha (9,3%): un correo o un mensaje de chat en mitad de la tarea cambia los requisitos
Si la operación que piensas entregarle al agente depende de que quien la ejecuta recuerde un acuerdo de hace tres semanas y sepa cuál de las dos listas de precios está vigente, estás poniendo la automatización justo en el punto donde hoy es más débil.
Qué dice al respecto el propio fabricante
Anthropic enumera abiertamente las limitaciones de su herramienta computer use, y vale la pena revisar esa lista antes de planificar nada. La latencia, según lo formula la documentación, puede resultar excesiva en comparación con las acciones que una persona hace directamente en el ordenador, por lo que el fabricante recomienda escenarios donde la velocidad no sea crítica (recopilación de información en segundo plano, pruebas automatizadas) y en un entorno de confianza. El modelo puede equivocarse o inventar coordenadas al determinar el punto del clic. La fiabilidad de la elección de herramienta baja en aplicaciones de nicho y cuando hay varios programas en uso a la vez. El desplazamiento tiene su propio punto en la lista: en las aplicaciones donde el scroll no surte efecto, la documentación sugiere alternativas de teclado como Av Pág.
Concéntrate en escenarios donde la velocidad no sea crítica (por ejemplo, la recopilación de información en segundo plano o las pruebas automatizadas) en entornos de confianza.
— Anthropic, sección «Limitations» de la documentación de computer use
Conviene revisar por separado qué es exactamente lo que sale de tu perímetro, porque aquí es fácil sacar una conclusión equivocada. Computer use funciona como una herramienta del lado del cliente: la sesión se ejecuta de tu lado, y las capturas de pantalla, los movimientos del ratón, la entrada del teclado y los archivos se guardan en tu entorno, no en el del proveedor del modelo. Pero las imágenes de la pantalla viajan de todos modos al modelo: las procesa en tiempo real como parte de la llamada a la API, y justamente por ellas pagas en tokens de entrada. La retención de esas solicitudes se rige por la política general de retención de datos de la API, y el modo en sí es compatible con la retención cero, porque el lugar y la forma de almacenamiento los define tu aplicación. Si en la pantalla se ven datos personales de clientes mientras el agente trabaja, eso es materia de un acuerdo de tratamiento de datos, no de una casilla de «todo se queda con nosotros».
De dónde sale el coste de mantenimiento
La factura de Computer Use no se estructura como la de una llamada a la API, y conviene incluirlo en el presupuesto antes de empezar. El agente ve el sistema a través de capturas de pantalla, cada una de las cuales cuesta aproximadamente entre mil y 1800 tokens de entrada, y toma una prácticamente en cada paso. Recuerda el orden de magnitud del benchmark: 318 llamadas por tarea frente a 30 en las operaciones cortas. El gasto crece con la longitud del escenario, no con su valor para el negocio; por eso, de dos operaciones igual de útiles, una puede costar diez veces más que la otra solo por la cantidad de pantallas en el camino.
La segunda partida de gasto son los retrabajos. Una integración por API vive hasta un cambio de versión anunciado. Una integración por pantalla vive hasta el siguiente lanzamiento de la interfaz, del que nadie te va a avisar, porque para el proveedor mover un botón no es un cambio de contrato: nunca tuvo un contrato contigo. Aquí no hay que planificar una implantación puntual, sino una revisión periódica ligada a la frecuencia de actualizaciones de ese sistema.
La tercera, y la más desagradable, es el fallo silencioso. Un script que se ha caído se ve de inmediato. Un agente que, después de que el botón cambiara de sitio, hizo clic con toda seguridad en el de al lado sigue informando de que todo ha ido bien, y la diferencia solo la verás en los datos, a veces semanas después. Por eso hay que monitorizar el resultado de la operación en el sistema de destino, no el hecho de que el agente haya terminado sin errores.
Cuándo se justifica Computer Use
En conjunto, las condiciones dejan una ventana bastante estrecha, y lo más honesto es enumerarla completa:
- de verdad no hay peldaños superiores: has revisado no solo la documentación pública, sino también el acceso para partners, la exportación a archivo y la lectura directa de la base de datos en los sistemas alojados en servidor propio
- el volumen se mantiene en decenas de operaciones al día: con miles, el coste de las pantallas y la proporción de errores superarán al trabajo manual
- el escenario es corto, de minutos y no de horas, o está cortado en tramos así con una verificación entre ellos
- el proceso es estable: la interfaz de ese sistema se actualiza rara vez y sabes con qué frecuencia
- el resultado se puede verificar de forma automática: hay dónde mirar para confirmar que la acción realmente se ejecutó
- el error es reversible: la operación no transfiere dinero, no elimina registros y no le llega al cliente sin confirmación humana
- hay un responsable: una persona que analiza los fallos y responde por el resultado
El primer punto descarta más proyectos de lo que se espera. El error más caro en este tema ni siquiera es técnico: la empresa construye una automatización frágil sobre la pantalla teniendo a mano una exportación nocturna por la que nadie se ha interesado, porque nadie le ha hecho la pregunta al proveedor.
Qué hacer antes de la implantación
Empieza por un intento más de encontrar un contrato. La pregunta al proveedor sobre una API para partners o una exportación periódica cabe en un solo correo y cierra el tema por menos de lo que cuesta cualquier desarrollo. El siguiente paso es dejar el proceso por escrito: la secuencia de pantallas, las condiciones de bifurcación, cómo se ve el éxito y cómo se ve el fallo. Un agente que actúa según la pantalla no tiene dónde consultar una regla no escrita, así que todo lo que hoy vive en la cabeza de un empleado habrá que sacarlo a la luz.
Después vienen cuatro cosas que conviene describir en concreto, no solo nombrar. Puntos de control: después de cada paso significativo el agente coteja el estado del sistema; si creó una contraparte, lee su ficha y compara el código EDRPOU (el número de registro de empresas en Ucrania) con el que escribió. Límite de irreversibilidad: el agente prepara la orden de pago, y el botón «Contabilizar» lo pulsa una persona. Plan de reversión: un volcado nocturno de la tabla antes de ejecutar el escenario, más el nombre de quien hace este trabajo a mano mientras se rehace el escenario. Y monitorización por resultado en el sistema de destino: no «el agente terminó sin errores», sino «ayer aparecieron 47 registros en el CRM, igual que en la fuente».
Este trabajo hace falta por igual para Computer Use y para cualquier forma de automatización más arriba en los peldaños. La única diferencia es que en los peldaños superiores se puede aguantar más tiempo sin él, mientras que aquí su ausencia se nota desde el primer mes.
Auspex construye automatizaciones e integraciones de CRM, y en los proyectos con sistemas heredados antiguos esta conversación surge constantemente. En la práctica, el inventario de lo que el sistema puede entregar hacia fuera (acceso para partners, exportaciones, base de datos) descarta la pregunta sobre Computer Use más veces de las que la confirma. Justamente con él empieza nuestra auditoría de CRM e integraciones; el enlace está más abajo.