Un agente de IA que navega por la web es el último recurso, no el primero
Un agente de IA que navega por la web hace exactamente lo que suena: abre un navegador, mira la pantalla, mueve el cursor, teclea y pulsa, igual que haría una persona. Y ahí está la trampa, porque suena a solución universal: si una persona puede hacerlo, el agente puede hacerlo. Es cierto y es irrelevante. También una persona puede copiar mil filas a mano. Que algo sea posible no lo convierte en la forma sensata de hacerlo.
La tesis, sin rodeos: el navegador es el plan D. Delante van la API del sistema de enfrente, la integración por conector o iPaaS, y —con más frecuencia de la que se admite— una persona dedicando diez minutos al día a algo que no justifica automatizar nada. El navegador solo entra cuando las tres están cerradas de verdad. Las vías limpias están en integrar la IA con tus sistemas: aquella guía descarta todo lo que no sea un puerto donde enchufar, y esta empieza justo donde aquella se para, en el caso que descarta.
La razón de tanto cuidado es que esta vía no falla por el modelo. Falla por cosas que no están bajo tu control: la pantalla de otro, la sesión de otro, las reglas de otro. Puedes hacerlo todo bien y despertarte un martes con el proceso roto porque alguien movió un botón.
Los tres casos en los que no hay otra puerta
Hay situaciones en las que el navegador no es pereza: es lo único que queda. Se reconocen por una señal común — no es que la API no exista todavía, es que no va a existir.
- El portal del proveedor o del cliente grande. Te obligan a entrar a su extranet a subir albaranes, descargar liquidaciones o confirmar pedidos. No hay API, no la habrá, y tu volumen no da para que la construyan por ti. La relación comercial va en una dirección y no es la tuya.
- La administración. Sedes electrónicas, portales de licitación, registros. Aquí el acceso está pensado para que lo haga una persona con su certificado, y el camino automatizado o no existe o exige una integración formal que tarda meses en concederse. Ojo con dar por hecho que porque sea público es abierto: no es lo mismo.
- El sistema interno viejo. Ese ERP de 2009, la aplicación de escritorio del almacén, el programa que instaló un proveedor que cerró. Tiene base de datos, pero nadie firma tocarla; tiene pantalla, y la pantalla funciona. La API no existe porque no existe el presupuesto para construirla, que es una forma perfectamente válida de no existir.
El contraejemplo importa tanto como los casos. Si el proveedor tiene API y no te la ha dado porque va en otro plan de precio, eso no es un problema técnico: es una negociación. Montar un agente que navegue para no pagar el conector suele salir más caro en mantenimiento el primer año que el conector, y además te deja del lado incómodo de sus condiciones de uso. Antes de escribir la primera línea, pide el precio. A veces la automatización más rentable es un correo a un comercial.
Lo que se rompe siempre: cinco fallos que no dependen de ti
Estos cinco no son riesgos hipotéticos que quizá aparezcan. Son el calendario de mantenimiento de cualquier agente que viva en un navegador ajeno. Quien te lo venda sin mencionarlos, no lo ha tenido en producción.
- La interfaz cambia y nadie te avisa. No hay versionado, no hay nota de release, no hay periodo de gracia. Un rediseño, un campo nuevo obligatorio o un aviso de cookies distinto y el flujo se detiene a mitad. Con una API rota te enteras por un código de error; aquí te enteras porque alguien pregunta por qué no llegaron las facturas.
- La sesión caduca y el segundo factor no negocia. Mantener a un agente autenticado en un sistema de terceros es el problema aburrido que se lleva la mitad del tiempo de operación. Si el acceso exige un código de un solo uso, una app en el móvil de alguien o un certificado en una tarjeta, hay una persona en el bucle por diseño. Eso no es un fallo del agente: es una decisión de seguridad de la otra parte, y es legítima.
- El captcha y las condiciones de uso. El captcha no es un bache técnico que se esquiva: es la otra parte diciendo explícitamente que no quiere tráfico automatizado. Saltarlo suele romper los términos del servicio y, en según qué contexto, algo más que los términos. La conversación correcta cuando aparece un captcha no es con el equipo técnico, es con quien firma el contrato.
- La página que lee también puede darle órdenes. Un agente que navega no distingue de forma fiable entre el contenido que le pides leer y una instrucción escondida en ese contenido. No es un problema de madurez a punto de resolverse: OpenAI declaró en diciembre de 2025 que la inyección de prompts, como las estafas y la ingeniería social, es poco probable que llegue a resolverse del todo (TechCrunch, 22 de diciembre de 2025), y Anthropic publicó sus resultados de robustez en navegación acompañados de una advertencia explícita de que ningún agente de navegador es inmune (Anthropic, 24 de noviembre de 2025). La consecuencia práctica es de diseño, no de prompt: el agente solo puede hacer daño hasta donde llegan sus credenciales.
- El coste y el reloj se cuentan por paso. Cada paso es una captura de pantalla, una decisión del modelo y una acción. Una tarea de doce pasos son doce decisiones con imagen, no una llamada. Lo que por API es una petición de milisegundos, aquí son minutos y un consumo que crece con cada reintento.
Por qué el porcentaje del benchmark no predice el tuyo
Las cifras públicas de esta categoría son mejores de lo que mucha gente cree y peores de lo que sugiere la demo. En WebArena, el banco de pruebas de referencia, el mejor sistema registrado en el marcador público ronda el 74 % de tareas completadas frente al 78 % que consigue una persona (Steel.dev, marcador WebArena). OpenAI reportó para su agente de uso de ordenador un 87 % en WebVoyager y un 58,1 % en WebArena en sus pruebas internas. Son números respetables para un problema difícil.
El problema es qué miden. Esos bancos de pruebas corren sobre réplicas de sitios públicos, con la ruta buena, sin inicio de sesión corporativo, sin segundo factor, sin captcha y —esto es lo importante— sin consecuencia. Un clic equivocado en un benchmark suma un fallo en una tabla. Un clic equivocado en el portal de tu proveedor confirma un pedido de once mil euros. No hay forma de trasladar un porcentaje de lo primero a lo segundo, así que no lo intentes: el único dato que vale es el tuyo, medido sobre tu portal, con tus casos reales, durante un par de semanas en modo observación.
Traducido a decisión: no compres por la demo ni por la tabla. Pide una prueba sobre tu pantalla, con los casos raros incluidos —el proveedor que escribe el número de factura con un guion, el pedido con dos líneas canceladas— y cuenta cuántas veces hay que rescatarlo. Ese porcentaje es el que va a determinar si el proceso te ahorra trabajo o te lo cambia de sitio.
Las cuatro condiciones para dejarlo en producción
Si el caso es legítimo y la prueba ha ido razonable, todavía falta la parte que separa un experimento de algo que puede quedarse funcionando solo. Son cuatro condiciones y no son opcionales: con tres de las cuatro, esto no sale a producción.
- Acción reversible. El agente solo ejecuta cosas que se pueden deshacer sin llamar a nadie: descargar, leer, rellenar un borrador, guardar sin enviar. Confirmar, pagar, firmar y cancelar se quedan fuera del alcance automático desde el primer día, aunque el agente sea perfectamente capaz de pulsarlos.
- Límite de pasos duro. Un tope de acciones por tarea que, al alcanzarse, detiene y avisa. Sin él, un agente perdido en una pantalla que no entiende reintenta hasta agotar el presupuesto, y el primer aviso de que algo iba mal llega en la factura.
- Captura de cada acción. Pantallazo o registro de qué vio y qué pulsó, en cada paso, guardado fuera de la sesión. No es burocracia: es lo único que permite reconstruir qué pasó cuando el proveedor dice que se confirmó un pedido que nadie recuerda haber confirmado. Sin evidencia no hay auditoría, y sin auditoría esto no es un sistema, es una apuesta.
- Humano en lo irreversible. El paso que compromete dinero, envía algo a un tercero o cambia un estado que no se puede revertir pasa por una persona que ve lo que va a ocurrir y lo aprueba. Con contexto suficiente para decidir en diez segundos, no una ventana que se pulsa por inercia.
Las dos últimas condiciones no son específicas de esta vía: son las mismas que rigen qué permisos darle a un agente de IA y cuánta autonomía darle. Lo que cambia aquí es el margen: cuando el agente actúa sobre la pantalla de otro, con la credencial de un empleado tuyo, el error no se queda en casa.
El orden de decisión, en una tarde
Cuatro preguntas, en este orden. La primera que dé un sí decide, y si llegas a la cuarta ya sabes a qué te expones.
- ¿Hay API y te la pueden dar? Si existe aunque sea de pago, pide el precio antes de programar nada. Un conector aburrido gana a un agente brillante que se rompe en cada rediseño.
- ¿Hay una integración ya hecha —conector, iPaaS, exportación programada? La exportación nocturna a un fichero que nadie presume en una demo resuelve más procesos de los que parece, y no se rompe.
- ¿Cuánto trabajo humano hay de verdad aquí? Diez minutos al día no pagan el mantenimiento de un agente que navega. Mídelo antes de decidir; a veces el resultado del ejercicio es no automatizar, y es una respuesta perfectamente buena.
- Si has llegado hasta aquí, ¿se cumplen las cuatro condiciones? Reversible, tope de pasos, captura de todo y humano en lo irreversible. Si alguna no se cumple, el proceso no está listo, y forzarlo es adquirir un riesgo para ahorrar un trámite.
Nosotros llegamos a esta vía con reticencia y la usamos cuando toca, que es más a menudo de lo que nos gustaría: media España factura contra portales sin API. Cuando es el caso, lo montamos con las cuatro condiciones puestas desde el primer día y con el mantenimiento presupuestado, porque lo que mata estos proyectos no es construirlos, es el tercer rediseño. Eso es lo que hay debajo de automatización de operaciones y de infraestructura de IA empresarial cuando el proceso tiene que convivir con sistemas que ya están en producción. El resto de decisiones del montaje —permisos, autonomía, memoria, canal— están en crear un agente de IA que aguante producción.