# Sistema sin API: el agente trabaja a mano | Auspex > Computer Use automatiza un sistema sin API y se rompe si se mueve un botón. OSWorld 2.0: ni el líder completa la mitad de los escenarios. Cuándo se justifica. Source: https://auspex.company/es/blog/no-api-agent-works-by-hand/ [Blog](/es/blog/) / Field Notes # Cuando el sistema no tiene API: el agente trabaja a mano Por: Andrew Maryasov · 28 ago 2026 · 12 min de lectura Computer Use es cuando el agente trabaja con un programa igual que una persona: mira la pantalla, mueve el ratón y escribe con el teclado. Es la única forma de automatizar un sistema que no tiene API, y la más frágil de todas las disponibles. En el benchmark OSWorld 2.0, publicado el 26 de junio de 2026, el mejor modelo del momento llevaba hasta el final el 20,6% de los escenarios de trabajo reales, y en las tareas de más de 163 minutos ninguno de los modelos evaluados terminaba ni una sola. A octubre de 2026, el líder completa alrededor del 44%, todavía menos de la mitad. En la lista de formas de integración, Computer Use ocupa el último lugar. Le llega el turno con menos frecuencia de lo que parece en una demostración. 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. Regla práctica: toma el peldaño más alto que resuelva la tarea, no el más bajo que resuelva todas las tareas a la vez. La universalidad de Computer Use no es una ventaja, sino el precio de no tener contrato. ## 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. Sigue leyendo - [Dónde termina tu automatización: la frontera del proveedor](/es/blog/automation-vendor-single-point/) - [Qué dejar por escrito en el contrato de desarrollo de un agente de IA](/es/blog/ai-agent-contract-what-to-write/) - [Autonomía, no adopción: qué métrica medir](/es/blog/autonomy-rate-not-adoption-rate/) - [Por qué se abandonan las automatizaciones](/es/blog/why-automations-get-abandoned/) - [Por dónde empezar a automatizar una pyme](/es/blog/where-to-start-automation-smb/) - [Auditoría de CRM e integraciones](/es/services/crm-audit/) Andrew Maryasov fundador de Auspex Fundador de Auspex. Implanta CRM y automatiza procesos de negocio desde 2015: más de 1500 proyectos para más de 1200 empresas. [amaryasov.expert →](https://amaryasov.expert) ## Preguntas frecuentes ¿Qué es Computer Use en palabras simples? Es un modo de trabajo del agente de IA en el que maneja un programa a través de la misma interfaz que una persona: recibe la imagen de la pantalla, mueve el cursor, hace clic y escribe. A diferencia de la integración por API, el agente no recurre al contrato del sistema, sino que reconoce cada vez los elementos en la imagen. Por eso Computer Use sirve para cualquier programa, incluso cerrado y antiguo, y al mismo tiempo se rompe con cambios que en una integración por contrato no existen. ¿Se puede automatizar un sistema que no tiene API? Sí, y hay más de dos opciones. De menor a mayor fragilidad son: API documentada, eventos y webhooks, un conector listo para usar o iPaaS, intercambio programado de archivos, scraping de la página o de una solicitud interna y, en último lugar, Computer Use. Cuando no hay API, lo más subestimado y a la vez lo más fiable de lo que queda suele ser el cuarto peldaño, la exportación periódica a archivo, porque la estructura de la exportación cambia con menos frecuencia que los formularios en pantalla. ¿Hasta qué punto son fiables los agentes que trabajan a través de la pantalla? A octubre de 2026, no lo suficiente para operaciones largas e irreversibles. En el artículo de OSWorld 2.0, con escenarios de trabajo reales, el mejor modelo, Claude Opus 4.8 con el máximo esfuerzo de razonamiento, llevaba hasta el final el 20,6% de las tareas, con un crédito parcial del 54,8%; en la clasificación a octubre de 2026, Claude Opus 5 completa el 44,33% de las tareas en la versión actualizada del conjunto, todavía menos de la mitad. En las tareas cortas, de hasta 45 minutos de trabajo humano, el indicador ronda el 20–24%, y en las de más de 163 minutos cae a cero para todos los modelos evaluados. ¿Por qué falla con más frecuencia este tipo de automatización? No por errar con el ratón. Los investigadores de OSWorld 2.0 registran que los agentes no tropiezan con el manejo básico de la interfaz, pero sí pierden las restricciones fijadas al inicio de la tarea, pasan por alto información que llega durante la ejecución, adivinan en lugar de preguntar y no verifican su propio resultado. Lo más difícil para ellos es cuando el valor necesario no aparece en ninguna parte de la pantalla y hay que deducirlo de registros anteriores. ¿Cuánto cuesta mantener un agente que trabaja a través de la interfaz? El coste tiene tres partes. El gasto corriente en el modelo es proporcional a la cantidad de pantallas: una captura equivale aproximadamente a entre mil y 1800 tokens de entrada, y los escenarios largos de las mediciones exigen cerca de 318 llamadas a herramientas frente a 30 en los cortos. La segunda parte son los retrabajos tras cada actualización de la interfaz de ese sistema, y hay que planificarlos según su calendario de lanzamientos. La tercera es la monitorización del resultado, sin la cual un fallo silencioso solo se detecta en los datos y con retraso. ¿Qué hacer si la interfaz del sistema ha cambiado? El plan de reversión debe existir antes del lanzamiento, no redactarse el día del incidente. El conjunto mínimo: una monitorización que coteje el resultado de la operación en el sistema de destino y no el hecho de que el agente haya terminado; un responsable con nombre que analice los fallos; una lista de acciones irreversibles que el agente no ejecuta sin confirmación humana; y un acuerdo sobre quién hace este trabajo a mano mientras se rehace el escenario. Es razonable ligar la periodicidad de la revisión a la frecuencia de actualizaciones de ese sistema. ¿Cuándo no conviene usar Computer Use en absoluto? Cuando la operación es irreversible: una transferencia de fondos, la eliminación de datos, un mensaje al cliente sin confirmación. Cuando el escenario es largo y no se puede cortar en tramos cortos con verificación. Cuando el volumen se mide en miles de operaciones al día: ahí el coste de las pantallas y la proporción de errores pesarán más que el trabajo manual. Cuando la tarea se apoya en un conocimiento oculto que no está escrito en ninguna parte. Y cuando no se ha encontrado un responsable que responda por el resultado. ## Boletín de automatización empresarial 2–3 emails al mes: lo que de verdad funciona en CRM y automatización. Sin spam. Puedes darte de baja en un clic. [Auditoría CRM gratuita →](/es/contact/) ↳ AUDITORÍA GRATIS 30 min · gratis · ↓ ## ¿Listo para poner orden en tus ventas? Auditoría gratuita de procesos: 30 minutos, y recibirás: 1200+ empresas desde 2015 · puesta en marcha en 30 días (mediana) 01 Un mapa de dónde pierdes leads 02 Prioridades: qué automatizar primero 03 Un plan de implantación en 2–4 semanas Te llamaremos en 24 horas. El plan es tuyo, aunque no trabajemos juntos.