Hace unas semanas publiqué los cinco criterios para distinguir autonomía real de humo comercial: percibir, navegar, decidir, ejecutar, aprender. Desde entonces he visto muchos pilotos bloquearse en vez de funcionar. Y casi siempre por las mismas razones que ningún vendedor o fabricante menciona en las demos.
Ese framework teórico choca brutalmente contra la realidad operativa cuando un agente se encuentra con la web tal como es: caótica, impredecible y llena de obstáculos que ninguna presentación comercial incluye.
Tres grietas donde la autonomía se rompe (justo cuando más la necesitas)
La fragilidad no aparece en el laboratorio o POC. Aparece en producción, en esos pequeños detalles que cualquier empleado resolvería sin pestañear.
La primera grieta son los ‘captchas’. Suena trivial hasta que tu agente llega al punto crítico de un proceso, por ejemplo, un portal de proveedores o una gestión con la administración, y se topa con un captcha. Ahí se acaba el cuento. La promesa de automatización ‘end-to-end’ se convierte en una coreografía incómoda donde alguien tiene que intervenir manualmente para que la cadena continúe. El valor del agente se merma…
La segunda grieta son los pop-ups y overlays. Basta un cambio de diseño, un banner de consentimiento o una ventana modal para descolocar completamente a un agente entrenado sobre la versión anterior de la web. Un humano lo resuelve con un clic intuitivo. El agente, si no está preparado para esa desviación, entra en bucle o falla en silencio.
La tercera grieta es más sutil pero igual de letal: la navegación directa a URL. Muchos entornos de prueba son limpísimos. URL estáticas, sin redirecciones, sin cookies heredadas, sin estados previos. La web real no funciona así. Hay estados de sesión, parámetros ocultos, tiempos de carga variables, interacciones previas que condicionan lo que ve el navegador. Un agente que no convive con ese caos difícilmente puede llamarse autónomo.
Aquí va lo incómodo, si no conseguimos evidencia de robustez en estos puntos, no estás implementado autonomía. Estás implementando más riesgo operativo .
Del bucle interno al bucle exterior: cuando ya no puedes seguir cada paso
La tentación humana ante algo nuevo y poderoso es querer verlo todo. Muchos pilotos empiezan con supervisión de “bucle interno”. Alguien del equipo sigue cada paso, revisa cada interacción, aprueba cada acción significativa. Es razonable para un POC, pero inviable en producción.
Cuando el volumen crece, ese modelo se rompe. Nadie tiene tiempo para revisar interacción por interacción, igual que nadie revisa manualmente cada operación de un sistema de trading algorítmico. La supervisión tiene que moverse al “bucle exterior”: mirar patrones, métricas agregadas, anomalías y desvíos significativos.
Para un CIO o un CISO, la pregunta cambia. Ya no es “¿qué está haciendo exactamente el agente ahora mismo?”, sino “¿qué necesito ver en mi panel para dormir tranquilo y confiar en el proceso?”.
Algunas métricas resultan especialmente útiles: tasa de tareas completadas sin intervención humana, frecuencia y motivo de las llamadas a un operador, patrones de fallo por tipo de web (formularios, portales públicos, intranets), tiempos de recuperación ante error. Es otra forma de relación con la tecnología. Menos micromanagement digital, más gobernanza basada en señales.
Identidad y contención: el nombre y la jaula del agente
Hay una diferencia enorme entre “usar un modelo de IA” y “darle capacidad de actuar en sistemas reales”. En cuanto un agente puede iniciar sesión, navegar por aplicaciones internas o tocar procesos críticos, deja de ser un experimento y se convierte en un actor dentro de la organización.
Aquí la identidad es clave. Igual que no imaginas a un empleado sin usuario propio, no deberías imaginar agentes sin identidad única y auditada. Conceptos como “Entra Agent ID” de Microsoft o sistemas de identidad federada para agentes ilustran esta dirección: saber qué agente hizo qué, cuándo y con qué permisos. Sin esto, cualquier incidente se convierte en un laberinto forense.
El segundo pilar es la contención. El equivalente, en el mundo agentivo, a los escritorios virtuales que usamos desde hace años para proveedores de BPO o terceros con acceso sensible. Arquitecturas como “Windows 365 para Agentes” o entornos sandbox equivalentes muestran este enfoque: espacios controlados, con capacidades definidas, donde el agente puede operar sin entrar en contacto directo con el resto de la infraestructura.
No se trata de desconfiar de la tecnología. Se trata de aplicar el mismo rigor que aplicamos con cualquier persona externa a la que damos acceso a sistemas críticos.
El coste real de mirar hacia otro lado
En casi todas las conversaciones sobre agentes aparece, tarde o temprano, el argumento del ahorro, temas como : menos tareas manuales, menos tiempo invertido, más eficiencia. Pero ese cálculo suele ignorar un factor que en los comités de riesgo pesa mucho más: el coste de una hora de interrupción grave.
Estudios recientes sitúan el coste medio de una interrupción de TI de alto impacto en torno a los dos millones de dólares por hora. Incluso si tomamos esa cifra con cautela, el orden de magnitud es claro. En ese contexto, los ahorros esperados de un piloto mal diseñado se desvanecen en el momento en que un error desencadena una caída, una corrupción de datos o una reacción en cadena.
Pensemos en un escenario concreto. Un agente de compras autorizado para actualizar portales de proveedores. Si el diseño de controles es débil y la supervisión exterior inexistente, un fallo de lógica provocado por un rediseño de la web podría generar cientos de pedidos erróneos antes de que alguien levante la mano. Lo que empezó como ahorro proyectado termina siendo un ejercicio de remediación de seis cifras y una crisis de relaciones con proveedores.
El problema ya no es el agente. Es la organización que no fijó límites claros a lo que podía hacer antes de romper algo valioso.
El precipicio del 2 de agosto: cuando la regulación deja de ser teórica
Mientras tanto, pasó algo que muchos directivos ignoraron : que el 2 de agosto de 2025 dejó de ser una fecha en el calendario regulatorio para convertirse en un problema operativo real. Ese día marcó un salto cualitativo en la aplicación del AI Act europeo para los modelos de propósito general, especialmente en usos de navegación y automatización. El Artículo 53 introduce obligaciones concretas de transparencia y respeto al opt-out de propiedad intelectual.
Traducido a lenguaje de negocio: una empresa debería poder responder preguntas como “¿de dónde ha aprendido a navegar mi agente?”, “¿qué contenidos reutiliza o transforma?” y “¿puedo demostrar que respete la voluntad de quienes decidieron no ser usados para entrenar estos sistemas?”.
Para organizaciones en Europa , el AI Act es el marco nativo. Influye en cómo se diseñan contratos, se evalúan proveedores y se priorizan casos de uso. Para CIOs en Estados Unidos, la regulación europea puede parecer lejana hasta que tu mayor cliente europeo te pide documentación de cumplimiento, o las operaciones europeas de tu proveedor generan exposición legal.
He visto esto más veces de las que quisiera, la regulación se convierte en requisito comercial más rápido de lo que la mayoría espera. En ambos casos, el mensaje es el mismo: la decisión de desplegar agentes que navegan y actúan en la web dejó de ser únicamente técnica y pasó a tener consecuencias legales y reputacionales directas para el liderazgo.
Tres decisiones que un CIO no puede delegar
Llegados a este punto, la pregunta no es “qué tareas añadir a un checklist“, sino qué decisiones no puede delegar un CIO frente a este escenario.
Primera decisión: dónde jamás hay que permitir que un agente navegue. Esto implica definir líneas rojas explícitas. Sistemas financieros core, portales regulatorios, consolas de administración con credenciales privilegiadas, procesos donde un error pueda tener consecuencias legales o de seguridad inmediatas.
Segunda decisión: qué evidencia pedir antes de autorizar un piloto. No debería bastar con capturas de pantalla o vídeos controlados. Es razonable exigir pruebas en webs reales, con captchas, pop-ups, cambios de layout y condiciones de red imperfectas, acompañadas de métricas de fallo, tiempos de recuperación y límites de actuación configurados.
Tercera decisión: qué tienes resuelto ahora que el 2 de agosto ya pasó. Eso incluye saber qué proveedores están realmente alineados con el AI Act, tener un inventario claro de casos de uso agentivos en producción, un modelo de supervisión por bucles exteriores y responsabilidades claras en caso de incidente.
Para terminar…
La autonomía no se mide por lo que un agente promete en una demo. Se mide por lo que tu organización puede contener, auditar y recuperar cuando algo se rompe. El 2 de agosto ya pasó. La pregunta ahora no es si tu organización cumple, sino si puedes demostrarlo cuando te lo pidan. Y te lo van a pedir.
En la próxima entrega vamos a lo concreto: qué métricas específicas vigilar en tus dashboards de observabilidad, qué hitos del calendario de enforcement del AI Act no puedes permitirte ignorar, y cómo diseñar arquitecturas de supervisión que funcionen cuando tienes 50 agentes operando simultáneamente. Porque una cosa es entender el riesgo en abstracto y otra muy distinta es saber qué botón apretar cuando algo falla a las 3 de la mañana.