Nova Act puede recorrer una web; eso aún no mide su UX

El 14 de julio de 2026, AWS publicó una arquitectura de referencia con Amazon Nova Act para generar recorridos desde documentación, ejecutarlos en navegadores paralelos y analizar capturas, tiempos y trazas. La propuesta puede ampliar lo que un equipo observa entre versiones de una web. Pero hay una frontera que no debe borrarse: que un agente complete una compra de prueba no demuestra que una persona entienda la interfaz, confíe en ella o pueda usarla con una discapacidad.

La capacidad transferible consiste en separar tres capas de evidencia. La primera pregunta si el sistema funciona: el estado final y los datos son correctos. La segunda pregunta si el recorrido es operable: el agente encuentra una ruta de manera repetible y deja una traza explicable. La tercera estudia experiencia humana: comprensión, expectativas, accesibilidad, confianza y contexto. Un agente de navegador aporta evidencia a las dos primeras; puede proponer hipótesis para la tercera, pero no representar a los usuarios.

El día correcto y lo que AWS presentó

La publicación original está fechada el 14 de julio, no el 17. Describe cuatro capas. Documentación de producto en S3 alimenta una base de conocimiento de Bedrock; una función Lambda recupera contexto y convierte tareas en instrucciones con varios grados de detalle; DynamoDB, Lambda, ECS y Fargate coordinan ejecuciones paralelas; y Nova Act opera sesiones de navegador. Los resultados se guardan y otro modelo calcula patrones, puntuaciones y posibles puntos de fricción para mostrarlos en un panel.

El repositorio de ejemplo de AWS permite inspeccionar el vehículo: registra vídeo, trazas HTML paso a paso y llamadas JSON, deposita resultados en S3 y agrega estadísticas en DynamoDB. La solución no incluye resultados de un estudio con usuarios ni una comparación empírica contra Selenium, Playwright o investigadores humanos. Es código de referencia para desplegar un método, no prueba de que ese método mida por sí solo la usabilidad.

Esta precisión cambia el uso responsable del panel. Una «puntuación de descubribilidad» calculada a partir de la conducta del agente describe cómo ese agente, con ese modelo, instrucción, semilla y estado de la web, encontró una ruta. Puede revelar una regresión o sugerir una pantalla problemática. No debe presentarse como la proporción de personas que encontrarán la función ni como una medida validada de satisfacción.

Diseñar el oráculo antes de lanzar el navegador

Toda prueba necesita un oráculo: una regla independiente que decide si ocurrió lo correcto. «El agente dijo que terminó» es un oráculo circular. Para una compra de prueba, hay que comprobar al menos el producto, cantidad, precio, impuestos, dirección de ensayo, identificador de pedido y ausencia de cobro real. Para cambiar una preferencia, se consulta el estado persistido o la API, no solo el mensaje de confirmación de la interfaz.

Separe los resultados en estados que expliquen el fallo. Éxito funcional: llegó al estado correcto. Fallo del producto: la web devolvió un resultado incorrecto o impidió una ruta válida. Fallo del agente: la interfaz permitía completar la tarea, pero el sistema eligió mal. Fallo de infraestructura: sesión, red o dependencia se interrumpió. Prueba indeterminada: falta evidencia para atribuirlo. Mezclar todo en «suspendido» hace que un error del probador parezca un defecto de producto.

La tarjeta de servicio de Nova Act recomienda que cada cliente construya una evaluación ajustada a su flujo y advierte que el mismo prompt no tiene por qué producir acciones idénticas. AWS informa de que sus puntuaciones se promedian normalmente sobre cinco ejecuciones. Para un equipo de producto, una sola pasada tampoco basta: debe repetir, conservar versiones y calcular tasa de éxito, variación de pasos, tiempo, recuperaciones y falsos fallos por ruta.

Objetivo, pasos y variaciones miden cosas distintas

Una instrucción de alto nivel —«encuentra una cafetera y llega al resumen de compra»— prueba si el agente descubre el camino con pocas pistas. Una secuencia detallada —«abre categorías, aplica este filtro, elige este producto»— prueba que una ruta prescrita continúa operativa. Una aserción directa comprueba un estado puntual. Las tres son útiles, pero no deben agregarse como si midieran lo mismo.

Construya una matriz con intención y variación. En filas: buscar, comparar, registrarse, recuperar contraseña, comprar, cancelar. En columnas: escritorio y móvil; sesión nueva y recurrente; idioma; conexión lenta; contenido vacío o extremo; navegación por búsqueda y por menú; permisos y rol. Añada cambios de texto equivalentes para conocer la sensibilidad del agente a la instrucción. No intente cubrir todas las combinaciones: seleccione por frecuencia, impacto y áreas modificadas en la versión.

La documentación sirve para sembrar casos, no como única fuente de verdad. Si el manual omite una función o prescribe una ruta antigua, el generador heredará el hueco. AWS recomienda un enfoque híbrido: cobertura inicial generada y flujos manuales para casos límite, novedades o escenarios que exigen control. Complete esa mezcla con incidencias reales, analítica de abandono, consultas de soporte y observaciones de usuarios. Así el conjunto de pruebas refleja el producto usado, no solo el producto documentado.

Una traza no es una persona

El agente procesa capturas y decide acciones. Una persona llega con experiencia previa, objetivos incompletos, carga cognitiva, prisa, dispositivos de asistencia y expectativas culturales. El éxito del agente puede ocultar un texto confuso porque el modelo infiere la intención desde patrones visuales. Su fallo puede exagerar una dificultad que personas habituales resuelven por memoria. La automatización observa una clase de interacción, no una población.

La accesibilidad ofrece un límite especialmente claro. Las Pautas de Accesibilidad para el Contenido Web 2.2 del W3C contienen criterios verificables sobre percepción, operación, comprensión y robustez. Un agente visual que hace clic no comprueba por ese hecho el nombre accesible de un control, el orden de foco, la navegación por teclado, los avisos de error o la compatibilidad con tecnologías de asistencia. Combine verificadores automáticos, revisión experta y pruebas con personas que usan esas tecnologías.

Para conectar automatización y UX, trate las métricas del agente como señales de investigación. Muchos pasos pueden sugerir fricción; reintentos en el mismo control pueden justificar una inspección; divergencia entre instrucciones vagas y detalladas puede apuntar a baja descubribilidad. Después una persona revisa vídeo, captura y DOM, formula una hipótesis y la contrasta con datos de comportamiento o sesiones de usuario. El agente ayuda a decidir dónde mirar, no dicta por qué una persona abandonó.

El probador también necesita un perímetro

Un navegador autenticado puede comprar, borrar o enviar información. Use un entorno de ensayo o cuentas separadas, datos sintéticos, métodos de pago de prueba y limpieza reproducible. Restrinja destinos a dominios permitidos, bloquee archivos y herramientas innecesarias, limite presupuesto y pasos, y defina estados que requieren parada o intervención. La tarjeta de servicio de AWS recomienda listas de dominios, registrar solo herramientas necesarias y mantener bloqueado el acceso a rutas de archivos salvo necesidad concreta.

También hay riesgo de inyección de instrucciones desde el contenido de la web. Un texto de página puede intentar desviar al agente de su tarea o persuadirlo para visitar otro sitio. El aislamiento del entorno reduce el impacto, pero el oráculo debe detectar acciones fuera de la especificación. Nunca use credenciales de producción ni autorice una transacción irreversible porque el escenario «solo está probando».

El desarrollo necesita promoción gradual. La documentación de interfaces de Nova Act separa explorar en un navegador alojado, desarrollar y depurar con SDK o extensión, desplegar con CLI y monitorizar ejecuciones en la consola. Mantenga esa separación: primero una ruta controlada, luego un conjunto repetible, después ejecución en integración continua y finalmente observación de costes y fallos. Una prueba generada no entra en el gate de lanzamiento hasta que su oráculo y su tasa de falsos fallos estén validados.

Un informe que permita decidir

Por cada ruta, conserve objetivo, versión del sitio, datos iniciales, modelo, instrucción, semilla si existe, capturas, acciones, resultado del oráculo y clasificación del fallo. En el resumen muestre éxito repetido, duración, pasos, recuperaciones, falsos positivos, coste y cobertura por riesgo. Mantenga aparte las hipótesis de UX y el respaldo humano que las confirma o rechaza.

La arquitectura de AWS es valiosa porque convierte recorridos en material revisable a escala. Su límite es igualmente instructivo: automatizar la mirada de un agente no automatiza la experiencia de una audiencia. Si el equipo sabe distinguir función, operabilidad y experiencia humana, Nova Act puede encontrar regresiones y ampliar el mapa. Si mezcla las tres, una puntuación precisa en el panel puede dar una conclusión falsa sobre las personas para quienes se diseñó la web.