Por qué se cancelan los proyectos de IA agéntica y qué hace bien un piloto de ocho semanas

Un cliente solicita un reembolso y el agente encuentra el pedido en el CRM, consulta la política de devoluciones y redacta una respuesta en menos de un minuto. Luego se atasca porque la aprobación del reembolso está en un sistema financiero al que nunca se conectó y la dirección del cliente no coincide en dos bases de datos. Este tipo de brechas rara vez sale a la luz en una demostración, pero determina cuánto cuesta operar un agente y si alguien puede confiar en él. Por eso, el mayor riesgo de la IA agéntica está en la empresa donde se incorpora el agente, no en el modelo.

Gartner prevé que más del 40 % de los proyectos de IA agéntica se cancelarán antes de finales de 2027, debido al aumento de los costos, la falta de claridad sobre el valor para el negocio y unos controles de riesgos deficientes. Si se lee con atención, el pronóstico se refiere a cómo se aprueban estos proyectos basándose en una demostración, sin tener mucha visibilidad de cuánto cuesta actualmente el trabajo ni de quién es responsable del resultado.

La pregunta que plantearía a cualquier equipo directivo es si la empresa puede sostener que este agente haga el trabajo todos los días, con un costo y un nivel de riesgo que pueda aceptar. Para responderla, hay que analizar a fondo lo que llamo el trabajo posterior a la automatización: todo lo que las personas aún tienen que hacer una vez que el agente ha terminado su parte. Un piloto de ocho semanas es una forma práctica de medirlo antes de comprometerse con una implementación completa.

Los problemas que un agente hereda de la empresa

Un agente rara vez trabaja de forma aislada, ya que incluso una tarea que parece sencilla involucra registros de clientes, un par de aplicaciones empresariales y, por lo general, una instancia de aprobación. Cada conexión limita lo que el agente puede ver y hacer. Cuando los registros son incoherentes o nadie tiene claro quién debe dar la aprobación, el agente hereda esa confusión junto con la tarea.

Los casos rutinarios rara vez son el problema; lo son las excepciones, porque es ahí donde se acumulan los costos operativos y, precisamente, es la parte que una demostración está diseñada para evitar. La investigación de Deloitte de 2026 reveló que solo el 5 % de las organizaciones considera que sus procesos empresariales están muy preparados para los agentes de IA. Esta cifra dice más que cualquier referencia de rendimiento de un modelo, porque sugiere que la IA está lista mucho antes que la mayoría de los procesos.

El caso de negocio debe incluir el trabajo posterior a la automatización

Medir cuánto tarda un agente en producir un resultado es la forma más fácil de exagerar su valor, ya que lo que importa es cuánto esfuerzo requiere completar la tarea. Supongamos que un empleado tarda 20 minutos en tramitar una solicitud y que el agente reduce a dos minutos la primera fase del trabajo. Parece un ahorro de 18 minutos, hasta que alguien dedica 15 minutos a revisar el resultado y corregir errores. Ahorrar tres minutos ofrece un rendimiento escaso una vez que se contabiliza el costo de operar el agente.

El análisis de McKinsey sobre un agente bancario de atención al cliente muestra el mismo patrón a gran escala: los tokens representaban entre el 20 y el 25 % de los costos operativos variables, y la supervisión humana, entre el 70 y el 75 %. Por tanto, la mayor parte del gasto quedaba fuera del modelo. Sin una referencia de partida establecida antes de que alguien escriba código, un piloto puede mostrar un progreso técnico considerable y, aun así, dejar sin comprobar el caso de inversión. Como mínimo, la persona responsable del negocio necesita respuestas claras sobre cada uno de estos puntos:

• Volumen: con qué frecuencia se ejecuta el proceso y cuántas personas intervienen.
• Tiempo de finalización: cuánto tarda la tarea completa, incluidas la revisión y las correcciones.
• Precisión: con qué frecuencia se cometen errores o hay que repetir el trabajo.
• Costo por tarea: cuánto cuesta hoy completar una tarea con éxito.
• Impacto en el negocio: qué cambiaría una mejora real para los clientes, el personal o la empresa.

Un agente debe ganarse su lugar en el flujo de trabajo

La adopción suele incluirse en la gestión del cambio, aunque, por mi experiencia, se define mucho antes, según dónde se integre el agente en el flujo de trabajo. Una empresa global de servicios profesionales había creado agentes para tareas de soporte y cumplimiento normativo. Su agente de soporte podía obtener información de varios sistemas internos, pero, para usarlo, el personal tenía que abrir una aplicación aparte y, en general, no se molestaba en hacerlo. Cuando se trasladó el mismo flujo de trabajo a la plataforma de soporte existente, el agente apareció dentro del ticket que el personal ya estaba atendiendo. Se hizo lo mismo con un agente de evaluación del cumplimiento normativo, integrado en Salesforce para que se ejecutara cada vez que se creaba un caso.

Los agentes no cambiaron; lo que cambió fue su ubicación en el flujo de trabajo. El personal ya tenía motivos para abrir un ticket o crear un caso, así que encontrarse con el agente en ese momento no le exigía ningún esfuerzo adicional. Por eso, la ubicación es tanto una decisión de arquitectura como de adopción: el agente necesita tener contexto en el lugar donde se realiza el trabajo y su resultado debe alimentar el siguiente paso sin que nadie tenga que copiarlo manualmente.

La autonomía cambia el panorama de la seguridad

Un agente que solo puede leer información conlleva un tipo de riesgo; uno que puede modificar registros o enviar correos electrónicos a clientes conlleva otro completamente distinto. Por eso, los controles deben ajustarse a lo que realmente tiene permitido hacer. Los permisos excesivos y las filtraciones de datos confidenciales son riesgos conocidos, pero la inyección de instrucciones merece especial atención: se trata de instrucciones ocultas en un documento o un correo electrónico que el agente encuentra mientras realiza una tarea perfectamente legítima.

Las directrices de Gartner de mayo de 2026 sobre la gobernanza de agentes dividen la autonomía en cuatro niveles, lo que ofrece una forma práctica de decidir cuán estrictos deben ser los controles:

1. Observar: el agente recupera información y detecta patrones, con acceso de solo lectura.
2. Recomendar: propone una acción y un empleado toma la decisión.
3. Actuar con aprobación: prepara o inicia una acción que una persona debe autorizar antes de que se ejecute.
4. Actuar de forma autónoma: ejecuta por sí solo acciones aprobadas dentro de límites establecidos, con supervisión y escalamiento de las excepciones.

En todos los niveles, un agente necesita una identidad propia, permisos limitados a su tarea y un registro de cada acción que realiza. Las organizaciones también necesitan reglas para el manejo y la conservación de los datos, claridad sobre qué información llega a los proveedores de modelos externos y una persona con autoridad para pausar el agente y revocar su acceso en cuanto algo parezca ir mal.

Todos estos controles tienen un costo continuo, ya que los permisos más amplios, la supervisión adicional y las aprobaciones frecuentes van sumando gastos con el tiempo. Por eso, el nivel adecuado de autonomía es tanto una decisión económica como de seguridad, y debe situarse allí donde el agente genere un resultado valioso con un nivel de riesgo que la empresa pueda aceptar.

Elige un proceso que justifique el uso de un agente

Muchos equipos empiezan por la tecnología y luego buscan un problema, cuando sería mejor partir de un proceso cuyos costos o demoras ya son evidentes para quienes realizan el trabajo.

Una empresa global de redes de expertos con la que trabajamos encajaba en esa descripción: su equipo asignaba solicitudes de encuestas a expertos mediante tres sistemas que no se comunicaban entre sí, y verificaba manualmente los perfiles, la participación anterior y el cumplimiento normativo para cada asignación. Creamos un agente que combinaba la búsqueda semántica con ese historial de participación y las reglas de cumplimiento; una vez en producción, los tickets por asignaciones incorrectas disminuyeron un 80 %, la precisión de las asignaciones aumentó un 40 % y el equipo recuperó un 22 % de su capacidad.

El proyecto funcionó porque el problema estaba bien definido: la información estaba dispersa, había que combinarla manualmente y la calidad de las asignaciones podía medirse antes y después. Esa precisión también ayuda a determinar si un proceso realmente necesita un agente. Por lo general, la automatización convencional permite gestionar a menor costo el trabajo regido por reglas fijas, y un asistente de IA suele ser suficiente cuando la tarea consiste principalmente en encontrar y resumir información. En cambio, los agentes justifican su costo y riesgo adicionales cuando el trabajo requiere interpretar el contexto, elegir entre acciones permitidas y encadenar varios pasos para alcanzar un resultado.

Un piloto de ocho semanas con puntos de decisión claros

Todo el piloto gira en torno a una pregunta comercial: ¿puede este agente mejorar lo suficiente el proceso como para justificar su implementación a gran escala? Ocho semanas dan tiempo suficiente para evaluar el caso de negocio, la tecnología y la capacidad de la organización para gestionar lo que construye.

Semanas 1–2: determina qué debe mejorar

Empieza por documentar el proceso tal como funciona hoy: desde el volumen y el tiempo de finalización hasta las tasas de error, el retrabajo y los costos. Anota qué sistemas intervienen, quién es responsable de cada etapa y qué excepciones requieren la intervención de una persona; luego, acuerda con el responsable del área de negocio y el equipo técnico cuál es el único resultado que se espera que mejore el agente. Punto de decisión: continúa cuando estén claros el problema, la situación de partida, la persona responsable y las medidas de éxito.

Semana 3: define los límites del agente

En esta etapa se establecen los límites del agente: su identidad, sus permisos, el acceso a los datos, las herramientas aprobadas y su grado de autonomía. Ponlo a prueba frente a la inyección de instrucciones, el acceso no autorizado, la exposición de datos confidenciales y el uso indebido de herramientas. Además, implementa el registro de actividad y la respuesta a incidentes, junto con un mecanismo para suspender el agente o revocar su acceso. Punto de decisión: continúa cuando se hayan probado los controles y los procedimientos de intervención, y todos sepan qué tiene permitido hacer el agente.

Semanas 4–6: pon a prueba las situaciones que hacen fracasar la demostración

Ahora asígnale trabajo realista, con registros incompletos, información contradictoria, solicitudes inusuales y algún fallo ocasional del sistema. Registra cuántas tareas completa, qué tan preciso es y cuánto tienen que corregir las personas; luego calcula cuánto cuesta realmente cada tarea completada, incluyendo el uso del modelo, las integraciones, la supervisión y la revisión. Punto de decisión: pasa a las pruebas en vivo cuando el agente alcance los umbrales acordados y el equipo comprenda tanto su costo operativo como las formas en que falla.

Semanas 7–8: ponlo a disposición de usuarios reales

Ponlo a disposición de un grupo pequeño de empleados para que lo utilicen en una parte controlada del trabajo real, manteniendo el proceso anterior para todo lo que el agente no pueda gestionar. Observa si la gente realmente lo usa, si les ahorra trabajo y si confía en los resultados que produce.

Al final, compara los resultados con la situación de partida registrada en la primera semana y evalúa la productividad, la precisión, la adopción, la frecuencia con que las personas tuvieron que intervenir, el costo operativo total y cualquier riesgo de seguridad aún pendiente. Entonces, la decisión será ampliar su uso, corregir problemas concretos y volver a probarlo, o detenerse. Un piloto que demuestra que el agente es demasiado costoso o poco fiable para la tarea también ha cumplido su función, porque ha evitado una inversión mucho mayor basada en conjeturas.

Mide los resultados y decide cuánta autonomía conceder

Contar cuántas tareas procesa un agente dice muy poco: un sistema puede tramitar miles de solicitudes y, aun así, dejar que los empleados verifiquen, corrijan o terminen la mayoría. El costo por tarea completada con éxito, considerado junto con la precisión y las tasas de excepciones, ofrece una imagen mucho más clara de si el proceso ha mejorado de principio a fin.

Esas mismas métricas sirven para justificar que se dé más margen de acción a un agente. Se puede confiar en que uno que gestiona de forma fiable las solicitudes rutinarias dentro de los límites acordados actúe por su cuenta; en cambio, si sigue encontrándose con casos ambiguos, una persona debe aprobar esas decisiones, mientras se revisan los permisos a medida que se acumulan pruebas.

Amplía su alcance cuando la empresa pueda respaldar al agente

Tarde o temprano, un agente que funciona bien para un equipo tendrá que interactuar con otros departamentos, aplicaciones y cadenas de aprobación. Para ampliar su alcance hacen falta una responsabilidad claramente asignada, controles de acceso coherentes y un método para gestionar las excepciones, además de un presupuesto para mantener el agente actualizado a medida que cambien los procesos que lo rodean.

La decisión de fondo es cuánta responsabilidad está dispuesta a delegar la organización, y debe basarse en pruebas obtenidas en el trabajo real, no en una buena demostración. Al cabo de las ocho semanas, la dirección debería saber qué puede gestionar el agente, en qué situaciones aún deben intervenir las personas y cuánto costará ponerlo en funcionamiento. Las empresas que tomarán la delantera con la IA agéntica serán las que, desde la primera semana, planifiquen el trabajo posterior a la automatización y asignen presupuesto a los agentes para las tareas que realmente completan.