Los agentes de uso de computadora (CUA, por sus siglas en inglés) son sistemas de IA que operan software de la misma manera que una persona: haciendo clic, escribiendo y navegando por una pantalla en vivo para completar tareas. Nuestra investigación muestra que enfrentan un precipicio estadístico: en benchmarks deterministas, un script ciego de menos de 1MB a menudo iguala o supera a un modelo frontier — lo que significa que una demo impecable rara vez predice la confiabilidad en producción.

El estado actual de la adopción de IA sigue un patrón peligrosamente predecible. Una organización identifica un proceso manual de alto valor — quizás en operaciones de ventas o soporte al cliente — y prueba un modelo frontier. La demo es impecable. Los agentes navegan el CRM, hacen clic en los botones correctos y generan el resultado deseado. Confiada en esos resultados, la dirección avanza hacia un despliegue a gran escala, solo para ver cómo el sistema colapsa ante las pequeñas e impredecibles variaciones del mundo real. Este fenómeno no es solo un fallo técnico: es un precipicio estadístico que amenaza el ROI de las iniciativas empresariales de IA.

“Una demo impecable rara vez predice la confiabilidad en producción.”

Nuestra investigación sobre agentes de uso de computadora revela una desconexión fundamental entre cómo se evalúan estos sistemas y cómo se desempeñan en entornos reales. La mayoría de los benchmarks existentes son deterministas y estáticos, creando un entorno fácil de engañar para sistemas que no poseen ninguna capacidad real de razonamiento. Para los líderes de operaciones en empresas de crecimiento medio, entender esta brecha es la diferencia entre una transformación exitosa y un costo hundido de millones de dólares.

El problema del agente replay: por qué fallan la prueba del script

Para entender por qué los benchmarks estándar están fallando, primero debemos mirar un fenómeno conocido como el agente replay. En nuestra investigación, realizamos un experimento usando modelos frontier en benchmarks populares como OS World y Mobile World. Grabamos las trazas exitosas — la secuencia exacta de toques, escritura y scroll — para cada tarea que el modelo completaba con éxito. Luego compilamos esas grabaciones en un script simple, de menos de un megabyte, que reproducía ciegamente esas acciones cuando se iniciaba una tarea.

La lógica sugiere que un modelo frontier basado en razonamiento debería superar ampliamente a un script ciego. Sin embargo, los datos muestran lo contrario. En benchmarks estándar y deterministas, el agente replay a menudo iguala o incluso supera la tasa de éxito del modelo del que fue extraído. Esto expone una vulnerabilidad crítica: los benchmarks son estáticos. Si un entorno es determinista, no prueba inteligencia; prueba la capacidad de seguir un camino que ya fue despejado.

Por eso tantos experimentos de Shadow AI dentro de las organizaciones se sienten exitosos al principio. Un empleado podría usar ChatGPT o una integración básica para automatizar una tarea en su escritorio. En ese contexto específico y estrecho — donde la resolución de pantalla es constante, el tema de la interfaz nunca cambia y la página de inicio es siempre la misma — el agente parece brillante. Pero como es esencialmente una versión high-tech de un agente replay, carece de la robustez necesaria para un sistema de IA soberano y gobernado en el que toda una organización pueda confiar.

El mito del pass@k y la metrificación de los exploits

Una de las métricas más comunes para evaluar agentes de uso de computadora es pass@k — la probabilidad de que al menos uno de k intentos de una tarea tenga éxito. Aunque esta métrica es un estándar en la investigación de IA, nuestro análisis formal demuestra que en entornos deterministas, pass@k es efectivamente una metrificación del exploit del agente replay.

Si ejecutas un agente múltiples veces en una tarea estática, no estás midiendo su capacidad para resolver el problema; estás midiendo la probabilidad de que accidentalmente caiga en la secuencia correcta de acciones. En un contexto empresarial, esta es una métrica peligrosa. Un líder de operaciones no necesita un agente que tenga éxito “al menos una vez” en diez intentos; necesita un agente que tenga éxito 99 veces de cada 100 en un entorno impredecible.

Cuando las organizaciones permiten un crecimiento descontrolado de IA, a menudo optimizan para ese éxito “de una sola vez”. Esto crea una falsa sensación de seguridad. El objetivo de una implementación profesional de IA — como el modelo Solution-First que defendemos — es alejarse de estas estadísticas frágiles y avanzar hacia resultados confiables y auditados. Debemos priorizar sistemas que puedan manejar la estocasticidad, no solo los que pueden ganar un juego amañado.

El framework PRISM: un nuevo estándar para agentes de uso de computadora

Para cerrar la brecha entre el desempeño en laboratorio y la confiabilidad en producción, hemos identificado cinco principios centrales para construir entornos de evaluación robustos. Los llamamos los principios PRISM. Cualquier organización que quiera ir más allá de simples experimentos hacia una transformación de largo plazo debe evaluar sus sistemas de IA contra estos criterios:

1. Verificación privilegiada (Privileged verification)

Los entornos deben soportar verificadores que usen información privilegiada para comprobar el trabajo del agente. No basta con mirar la pantalla final; el sistema debe verificar los cambios subyacentes en los datos. Si un agente afirma haber actualizado un registro en un CRM (HubSpot, Salesforce o tu sistema), un verificador privilegiado debería consultar la base de datos o la API directamente para confirmar que la acción se ejecutó correctamente.

2. Fidelidad realista (Realistic fidelity)

Si un agente se entrena para operar en un dispositivo Android o un escritorio Windows, la reproducción de ese sistema debe ser fiel. Muchos benchmarks usan versiones web simplificadas de las aplicaciones que no reflejan la latencia, los pop-ups o las rarezas de interfaz del software real. La falta de realismo produce agentes “sobreajustados” a un entorno sanitizado.

3. Sandboxing aislado (Isolated sandboxing)

La seguridad y la gobernanza son primordiales. Los agentes deben operar en entornos sandbox donde sus acciones estén aisladas de los datos sensibles de producción hasta que demuestren ser confiables. Esto se alinea con el enfoque de IA Soberana: mantener control total sobre los datos y el entorno de ejecución en lugar de permitir acceso sin monitoreo a través de herramientas web genéricas.

4. Configuraciones verificadas sistemáticamente (Systematically verified configurations)

Generar variación es fácil; generar variación válida es difícil. Los entornos robustos deben usar una estrategia tipo compilador para asegurar que cuando las variables cambian — como una pantalla de inicio diferente o un perfil de usuario distinto — la tarea siga siendo resoluble y la lógica de verificación siga siendo precisa.

5. Estocasticidad multifactorial (Multifactorial stochasticity)

Este es el principio más crítico. Los entornos deben variar datos, apariencia y estado inicial entre ejecuciones. Si el desempeño de un agente cae solo porque la app cambió de modo claro a modo oscuro, o porque comenzó en la página de configuración en lugar de la pantalla de inicio, ese agente no está listo para producción.

Insights de DigiWorld: por qué los modelos frontier son más frágiles de lo que crees

Nuestro trabajo con el benchmark DigiWorld — un sistema que comprende 15 aplicaciones en varios dominios con 3.2 millones de configuraciones verificadas — ha revelado la asombrosa fragilidad de los modelos frontier actuales. Encontramos que incluso los modelos más avanzados luchan significativamente cuando se ajustan factores ambientales menores.

Por ejemplo, probamos la capacidad de los modelos para realizar tareas comenzando desde pantallas diferentes. Un operador humano no tiene problema para navegar hasta el punto de partida correcto, pero muchos agentes de uso de computadora ven desplomarse sus tasas de éxito. Se observaron caídas similares al cambiar los temas de la aplicación o al alterar el perfil de datos específico (por ejemplo, cambiar el nombre de un destinatario en una app de correo simulada).

Esta investigación resalta un riesgo mayor para las industrias intensivas en operaciones. Si el éxito de tu agente de IA depende de una interfaz estática, tu sistema se romperá cada vez que un proveedor de software actualice su interfaz.

Cuantificando el error de $100,000: por qué las malas métricas cuestan dinero real

La fragilidad técnica eventualmente se traduce en responsabilidad financiera. Uno de los hallazgos más sorprendentes de nuestra investigación es el costo de los intervalos de confianza excesivamente optimistas. Muchos equipos usan métodos de prueba ingenuos que solo miran un pequeño número de despliegues “caso base”. Esto lleva a intervalos de confianza extremadamente estrechos, pero inexactos.

En nuestro análisis, encontramos que los métodos de prueba tradicionales a menudo tienen una “cobertura” de solo 17% a 20%. Esto significa que el 80% de las veces, la estimación del equipo sobre cómo se desempeñará el agente en el mundo real es completamente incorrecta. Creen que tienen una tasa de éxito del 95%, pero la realidad podría ser del 70%.

Hagamos las matemáticas para una operación de alto volumen:

  • Imagina un agente manejando 1 millón de tareas por mes.
  • Un desajuste del 4% entre el desempeño predicho y el real genera 40,000 errores inesperados.
  • Si cada error cuesta un promedio de $12 de remediación (intervención humana manual, valor de lead perdido o tickets de soporte), ese solo error de medición le cuesta a la empresa $480,000 en un solo mes.

“Un benchmark que un script de 1MB puede engañar no es un benchmark: es una ilusión.”

Por eso enfatizamos la importancia de la gobernanza central y la capa de observabilidad que falta en los experimentos de Shadow AI. Cuando una organización depende de herramientas no gobernadas, no solo arriesga un fallo técnico — está creando una responsabilidad financiera masiva y no cuantificada en su balance general.

De experimentos fragmentados a sistemas soberanos

La meta para cualquier líder de mercado medio debería ser alejarse del “precipicio estadístico” y avanzar hacia una base de IA Soberana. Esto significa ser dueño de la infraestructura, los datos y la lógica de evaluación que impulsan a tus agentes — lo opuesto de alquilar tu contexto a una pila de herramientas SaaS de terceros.

En lugar de quedar atrapado en un proyecto de consultoría de meses que quizás nunca entregue, recomendamos un enfoque enfocado. Empieza con un único resultado de negocio de alto impacto — el tipo de proyecto de automatización de operaciones gobernado donde la confiabilidad se mide, no se asume. Usa un runtime que proporcione estado persistente, acceso multi-usuario y hosting gobernado para asegurar que la capa de agentes sea de grado producción desde el día uno. A diferencia de las plataformas SaaS estándar, este enfoque se centra en unidades de trabajo sintético que realmente reemplazan o aumentan personal, en lugar de tarifas por asiento.

Nuestra investigación demuestra que la diferencia entre un juguete de IA y una herramienta de IA es el rigor de su evaluación. Si no estás probando la estocasticidad del mundo real, simplemente estás esperando a que tus agentes fallen. Al adoptar los principios PRISM y avanzar hacia una arquitectura gobernada y orientada a soluciones, las organizaciones pueden finalmente realizar la promesa de los agentes autónomos sin los riesgos catastróficos de un despliegue no verificado.

Conclusión: el imperativo de liderazgo para la gobernanza de IA

El mensaje más importante de esta investigación es que la evaluación de IA no es solo una tarea para desarrolladores — es un problema estratégico de gobernanza para el liderazgo. Un benchmark que puede ser engañado por un script de 1MB no es un benchmark; es una ilusión. La era de la demo terminó; la era del agente auditado y soberano ha comenzado.

Para las empresas latinoamericanas que están evaluando agentes de IA, la lección práctica es directa: desconfía de las demos impecables, exige métricas con cobertura real y prueba la estocasticidad antes de escalar. Sigue explorando estos temas en el blog de DojoFullStack.