Alibaba acaba de meter ruido otra vez en el ecosistema de agentes web. Page Agent es una librería JavaScript open source (licencia MIT) que promete convertir cualquier página en una aplicación «AI-native» con una línea de código: el usuario escribe en lenguaje natural y el agente interactúa con botones, formularios y enlaces leyendo el DOM en texto, sin capturas de pantalla ni navegador headless. Suena como la solución barata que llevamos meses esperando. Yo creo que merece la pena mirarlo, pero no con los ojos de quien acaba de ver el demo en GitHub.
La gracia técnica está en lo que ellos llaman DOM dehydration. En lugar de mandar HTML crudo o hacer screenshots para un modelo multimodal, Page Agent escanea la página, detecta elementos interactivos, les asigna un índice numérico y genera un FlatDomTree: un mapa de texto compacto con roles, etiquetas y la estructura que importa. El modelo recibe eso, decide qué hacer y el agente ejecuta la acción sobre el DOM real. Según MarkTechPost, el proyecto es agnóstico de modelo (cualquier endpoint compatible con OpenAI) y está pensado para ejecutarse del lado del cliente, no como automatización externa tipo Playwright.
En la documentación oficial lo venden con cuatro palabras mágicas: cero infraestructura, tus propios modelos, privacidad integrada y MIT open source. Un script, sin Python, sin servidor, sin extensión obligatoria. Si tienes una web con formularios largos, un panel de administración WordPress o un SaaS con flujos repetitivos, la tentación es obvia: montar un copiloto que rellene campos, navegue menús y explique al usuario qué está pasando. Más barato que contratar horas de UX para cada microtarea.
Ahí es donde empiezo a ponerme nervioso. Page Agent corre dentro de la página del usuario. Hereda cookies, sesión, credenciales de login y permisos del rol con el que haya entrado. Eso no es un detalle menor: es la diferencia entre un chatbot que responde preguntas y un actor con capacidad real de pulsar «Eliminar cuenta», cambiar precios en WooCommerce o exportar datos sensibles. La propia documentación advierte que la seguridad depende del prompt y del alcance de una sola página. Traducción: si alguien manipula la instrucción o el modelo alucina, no hay una capa de servidor que diga «para, esto no».
Los que llevamos tiempo montando webs para pymes ya hemos visto esta película. Primero llega el widget de IA que promete «solo ayudar». Luego alguien del marketing quiere que también «optimice el checkout». Luego un cliente pide que pueda «hacer lo mismo que yo pero más rápido». Y de repente tienes un agente con acceso de administrador interpretando frases ambiguas. Page Agent no inventa el problema — lo empeora porque la integración es tan sencilla que cualquier desarrollador junior puede activarlo un viernes por la tarde sin pasar por revisión de seguridad.
Tampoco es la alternativa mágica a WebMCP ni a los servidores MCP remotos de Contentful o Strapi. Esos apuestan por contratos estructurados entre la web y el agente: herramientas declaradas, permisos explícitos, validación server-side. Page Agent apuesta por leer tu DOM como si fuera un mapa de metro y esperar que el modelo no se equivoque de parada. En interfaces estables funciona; en temas WordPress con veinte plugins que inyectan markup distinto cada semana, el FlatDomTree puede cambiar sin avisar y el agente clica donde no toca. MarkTechPost lo resume bien: encaja en copilotos dentro de apps que controlas, no en automatizar sitios ajenos ni entornos bloqueados.
El coste tampoco desaparece. Quitas capturas y multimodal, sí, pero cada interacción sigue siendo una llamada al LLM que elijas. Con tráfico real — cien usuarios preguntando «¿dónde cambio la facturación?» — la factura de API se multiplica. Y si conectas Ollama local para ahorrar, alguien tiene que mantener ese servidor, actualizar modelos y vigilar latencias. «Cero infraestructura» es marketing; cero infraestructura de agente, no de todo el stack.
Lo que más me preocupa del posicionamiento es la confusión con «privacidad integrada». Que el procesamiento pueda quedarse en tu endpoint no significa que los datos dejan de circular. El DOM de un panel de administración contiene nombres, emails, pedidos, métricas. Mandar eso a Qwen, DeepSeek o Claude — aunque sea vía tu proxy — sigue siendo transferencia de datos personales. Si tienes clientes en la UE, necesitas base legal, DPA con el proveedor del modelo y probablemente aviso en tu política de privacidad. Ningún README de GitHub te lo resuelve.
No digo que Page Agent sea basura. Para un SaaS propio, con flujos acotados, roles limitados y acciones peligrosas validadas en backend, puede ser un atajo interesante. Alibaba lo ha open sourceado con casi 30.000 estrellas en GitHub y una demo que impresiona. Pero el mercado lo va a vender como «IA en tu web en cinco minutos», igual que vendieron los chatbots genéricos antes del AI Act. Y tú, que mantienes webs de clientes que ni saben que es el DOM, serás quien apague el fuego cuando el agente archive veinte productos porque el usuario escribió «limpia el catálogo».
Mi consejo, sin rodeos: pruébalo en staging, con un rol de prueba sin permisos reales, y asume que el agente es un usuario más con manos. Lista blanca de acciones, confirmación humana para operaciones destructivas, logs de cada comando interpretado. Si no puedes implementar eso, no lo subas a producción por impresionar en una demo.
Si mañana un cliente te pide montar Page Agent en su WooCommerce para que «la IA gestione pedidos sola», pero se niega a pagar la auditoría de permisos y el proxy de API que tú le recomiendas, ¿le dirías que sí igualmente o preferirías perder el proyecto?