Autonomía prestada: por qué los agentes de IA empresarial no pueden simplemente activarse
Hay una diferencia entre un sistema que funciona en una demostración y uno que no destruye valor cuando nadie está mirando. Con los agentes de IA, esa diferencia se mide en registros modificados, pagos procesados y decisiones tomadas sin intervención humana. El problema no es tecnológico. Es de gobernanza.
Un análisis publicado en Forbes Technology Council por un senior manager de generative AI en Amazon Web Services sitúa el debate exactamente donde debe estar: no en las capacidades del modelo, sino en la arquitectura de supervisión que rodea al agente. La pregunta operativa que propone es brutalmente sencilla. Antes de desplegar un sistema agéntico, tienes que saber si tu organización puede detectar sus errores después de que ocurran, y si esa detección puede cambiar lo que el sistema hace. Si la respuesta a cualquiera de las dos preguntas es no, la decisión de dar autonomía es prematura, independientemente de los benchmarks que el modelo haya superado.
Eso puede sonar conservador en un mercado donde Grand View Research estima que el segmento global de IA agéntica alcanzará los 22.900 millones de dólares en 2026 y proyecta 224.500 millones para 2033. Pero el tamaño del mercado no es argumento de seguridad. Es argumento de urgencia para construir bien.
El modelo de reembolso que revela el problema de fondo
El análisis usa un ejemplo que parece mundano y resulta ser preciso: un agente que gestiona reembolsos a clientes. La primera distinción que establece es entre redactar una respuesta y emitir el reembolso. El primero produce texto que un humano puede revisar. El segundo modifica el estado de una cuenta bancaria.
Esa distinción no es semántica. Define el tipo de error posible, su reversibilidad y su coste de detección. Un texto mal redactado genera fricción. Un pago incorrecto genera pérdida financiera, exposición regulatoria y, dependiendo del sector, consecuencias legales. La velocidad a la que un agente puede generar errores es exactamente proporcional a la velocidad a la que puede operar.
El enfoque propuesto es estructurar la aprobación humana alrededor de definiciones previas: qué casos puede manejar el agente, qué evidencia debe tener antes de actuar. Registros de pedidos incompletos, políticas ambiguas o condiciones no especificadas deben disparar una escalada automática, no una respuesta improvisada del modelo. Esto transforma la supervisión humana de un concepto vago en un control operativo con criterios explícitos.
Lo que hace interesante esta arquitectura es lo que revela sobre el error más frecuente en implementaciones agénticas: asumir que una alta tasa de finalización equivale a resultados correctos. Un sistema puede completar el 95% de los casos y aún así producir errores sistemáticos en el 5% restante sin que nadie lo sepa, porque nadie está mirando los casos aparentemente exitosos. La recomendación es muestrear también las resoluciones sin incidentes, no solo las escaladas. De lo contrario, el agente decide qué partes de su propio trabajo reciben escrutinio, que es exactamente lo opuesto a supervisión.
Un estudio de 2026 que evaluó 15 modelos sobre dos benchmarks distintos encontró que las mejoras en capacidad vinieron acompañadas de ganancias modestas en fiabilidad. El dato importa porque rompe la intuición más común: que un modelo más potente es proporcionalmente más seguro de desplegar. La potencia y la consistencia no escalan a la misma velocidad.
La economía que los reportes suelen ocultar
El análisis propone un cálculo hipotético con 1.000 casos de reembolso: 850 resueltos por el agente sin corrección humana, 100 resueltos por personas, 50 sin resolver. El software e infraestructura cuestan 400 dólares; la validación, revisión y recuperación cuestan 1.600 dólares. El resultado: 950 casos verificados por 2.000 dólares, aproximadamente 2,11 dólares por caso. El cálculo excluye costes de implementación inicial y consecuencias de errores no detectados.
La aritmética parece favorable. Pero la presentación habitual de ese mismo caso sería reportar 95% de finalización y atribuir el ahorro al agente. Lo que ese reporte omite es la contribución laboral humana, que en el ejemplo representa el 80% del coste total del proceso. Si ese coste está absorbido por otro equipo o línea presupuestaria, la decisión de escalar puede tomarse sobre una base de costes artificialmente reducida.
Hay una investigación de 2024, "AI Agents That Matter", que argumenta exactamente esto: la mayoría de las prácticas de evaluación de agentes se concentran demasiado en precisión bruta e ignoran el coste. Para una decisión de despliegue, el cálculo correcto debe incluir el tiempo que las personas dedican a revisar, corregir y completar el trabajo del agente. Ese tiempo puede ser invisible en el presupuesto de ingeniería si el equipo de operaciones absorbe las excepciones sin reportarlas como coste asociado al sistema.
El problema se amplifica cuando se escala. Los casos fáciles, que son los primeros que se automatizan, generan la economía más favorable. Extender la autonomía a transacciones disputadas o casos complejos requiere una evaluación separada, porque la economía de los casos sencillos no predice el tiempo que consumirán los difíciles. Un agente que procesa 850 reembolsos estándar a 0,47 dólares cada uno puede generar excepciones que cuestan 60 dólares en revisión humana por caso. La tasa de finalización agregada sigue pareciendo buena. El margen operativo real no.
Hay un coste adicional que el análisis menciona y que tiende a desaparecer de los modelos de negocio: la cola de revisión necesita dueño. Los revisores necesitan evidencia suficiente para entender qué ocurrió y una manera de completar el caso sin repetir todo el trabajo previo. Si esa capacidad no está en el plan de despliegue, los casos esperan aprobación mientras el agente sigue operando, y el cliente espera igualmente, independientemente de lo rápido que el sistema generó su respuesta inicial.
La cadena que convierte errores en restricciones
IBM anunció el 27 de octubre de 2026 actualizaciones a su plataforma watsonx Orchestrate que incluyen simulación de usuario, evaluación determinista, investigación de fallos en producción, generación de casos de prueba y un "AgentOps Agent" diseñado para mejorar la calidad del agente antes de su promoción a producción. La dirección del producto es exactamente la que el análisis de Forbes describe desde el lado de la gobernanza: conectar lo que ocurre en producción con el comportamiento del sistema antes de que se autorice una expansión de autoridad.
Esa arquitectura, prueba antes del despliegue más observación en producción más actualización de restricciones, es el ciclo que convierte un agente en algo que una empresa puede gestionar en lugar de simplemente monitorizar. La diferencia es que monitorizar detecta fallos. Gestionar los convierte en ajustes de política, límites de autorización o nuevos casos de prueba que previenen la recurrencia.
El enfoque que propone el análisis tiene una secuencia concreta: empezar con acciones propuestas, pasar a aprobación humana, permitir ejecución dentro de límites definidos una vez que los resultados la justifican. Algunos casos pueden requerir aprobación de forma permanente. Un cambio de política, un backlog creciente o errores descubiertos a posteriori deben disparar una revisión de los permisos ya otorgados, no una revisión de los permisos futuros.
El último paso de esa cadena es el que más fácilmente se omite en implementaciones reales: pedir al responsable de negocio del proceso que recorra los casos sin resolver y los errores detectados durante la revisión, y preguntar qué cambió como resultado de ese análisis. La siguiente decisión sobre autonomía debería depender de si esos problemas fueron resueltos y de si el equipo que gestiona las excepciones tiene capacidad para absorber trabajo adicional. Si no hay respuesta a ninguna de esas dos preguntas, ampliar la autoridad del agente es una apuesta, no una decisión.
Antes de dar permisos, define quién absorbe el costo del error
El patrón que emerge de este análisis no es nuevo en la historia de la automatización empresarial. Cada ola tecnológica, desde el ERP hasta el RPA, pasó por una fase en que la promesa de eficiencia se evaluó sobre los casos que el sistema manejaba bien, y el coste real apareció en los casos que no. La diferencia con los agentes de lenguaje es que su flexibilidad, que es precisamente lo que los hace atractivos, también hace que sus fallos sean menos predecibles que los de una regla determinista.
Un agente que opera con una instrucción en lenguaje natural puede variar su comportamiento con el contexto, con datos ambiguos, con actualizaciones del modelo o con herramientas que responden distinto según el estado del sistema. Eso significa que validarlo contra un benchmark finito en preproducción no garantiza consistencia en producción. Garantiza que pasó ese benchmark.
La pregunta que cualquier responsable de operaciones debería hacerse antes de aprobar la expansión de autoridad de un agente no es cuántos casos completó. Es cuántos de los casos que completó fueron revisados por alguien con capacidad de detectar un error, y qué hizo la organización con los errores que encontró. Si nadie revisó los casos exitosos, si los errores encontrados no modificaron las reglas del sistema, o si el equipo de revisión no tiene visibilidad sobre el razonamiento del agente, la tasa de finalización no mide lo que parece medir.
Los mercados de IA agéntica crecerán con o sin gobernanza. Lo que determinará qué organizaciones escalan con control y cuáles acumulan pasivos silenciosos es exactamente eso: si el coste del error está visible en el presupuesto correcto, si los revisores tienen las herramientas para completar el trabajo que el agente no terminó, y si alguien es responsable de convertir cada fallo en una restricción que evite el siguiente. La autonomía no se otorga. Se construye con evidencia operativa, y ese proceso tarda más de lo que el calendario de despliegue suele admitir.
