Por qué añadir un agente de IA a un flujo de trabajo roto suele fallar

Respuesta directa

Añadir un agente de IA a un flujo de trabajo roto suele fallar porque el agente hereda cada decisión sin definir, cada traspaso perdido y cada excepción silenciosa que ya vivía en ese proceso, no las arregla. Gartner espera que más del 40% de los proyectos de IA agéntica se cancelen antes de finales de 2027, y los motivos declarados son el coste creciente y el valor poco claro, no modelos débiles. El proceso ya era el problema antes de que llegara el agente.

Puntos clave

• El fallo de los agentes de IA suele ser un fallo de sistemas, no de modelo: las integraciones rotas, las rutas de excepción inexistentes y las reglas de decisión sin definir se automatizan junto con todo lo demás.
• Los flujos de trabajo de varios pasos acumulan errores. Si cada paso es fiable el 95% de las veces, un proceso de seis pasos solo se completa correctamente de principio a fin alrededor del 74% de las veces.
• El estudio NANDA de 2025 del MIT encontró que el 95% de los pilotos de IA generativa no producían un impacto medible en resultados, en gran parte porque se colocaban herramientas genéricas en flujos de trabajo que nunca cambiaron.
• La solución no es un mejor agente. Es mapear la capa de coordinación —quién le entrega qué a quién, y por qué— antes de decidir qué automatizar.
• Arreglar el proceso primero es más lento de lanzar. También es la única versión que sobrevive al contacto con una excepción real.

¿Qué significa realmente “añadir un agente de IA a un flujo de trabajo roto”?

Imagina el flujo de trabajo que realmente ejecutan la mayoría de los equipos de operaciones: llega una solicitud por correo, alguien la copia en una hoja de cálculo, otra persona revisa un sistema que no habla con esa hoja, y se toma una decisión según cuál de los dos esté más actualizado ese día. Nadie diseñó esto. Se fue acumulando, una excepción cada vez, hasta que las excepciones se convirtieron en el proceso.

“Añadir un agente de IA” a ese flujo suele significar apuntar un modelo a la bandeja de entrada de correo y pedirle que redacte la respuesta, o conectarlo a la hoja de cálculo para que rellene un campo automáticamente. El agente ahora se sienta dentro del mismo proceso sin definir: la misma regla ausente para cuando los dos sistemas discrepan, la misma solución improvisada que alguien inventó hace dieciocho meses y nunca documentó.

El agente no sabe que existe esa solución improvisada. Ve una tarea, produce un resultado con plena confianza y sigue adelante. Nada en ese bucle le dice a nadie que el proceso ya estaba roto. Simplemente ahora parece automatizado en vez de manual.

Lo que no es

Un agente de IA atornillado a un flujo de trabajo roto no es lo mismo que una automatización que elimina un paso. Vale la pena ser precisos con la diferencia, porque los proveedores la difuminan constantemente.

No es un rediseño de procesos. Colocar un modelo dentro de una herramienta existente cambia quién ejecuta un paso, no si ese paso debería existir. Si un flujo de trabajo tiene un paso que existe solo porque dos sistemas no pueden compartir datos, un agente que rellena ese vacío escribiendo a mano entre ambos ha automatizado el síntoma, no resuelto la causa.

No es una solución para las reglas de decisión que faltan. Si dos personas resuelven hoy la misma excepción de dos formas distintas, un agente entrenado con ese comportamiento histórico aprenderá a ser inconsistente en las mismas proporciones. La confianza en el resultado no tiene relación alguna con si es correcto.

No es lo que la mayoría de los proveedores quieren decir cuando dicen “agéntico”. Gartner ha señalado un “agent washing” a gran escala: chatbots existentes, scripts RPA y asistentes rebautizados como agentes sin ninguna capacidad nueva debajo. De los miles de proveedores que dicen ofrecer IA agéntica, Gartner calcula que solo unos cientos tienen algo estructuralmente distinto que ofrecer.

Y no es una integración de una sola vez. Un flujo de trabajo con excepciones sin definir sigue produciendo excepciones nuevas después de que el agente se lance. Cada una necesita que un humano la detecte, que es el mismo trabajo que ya necesitaba el proceso antes, ahora con una capa extra que depurar.

¿Por qué fallan la mayoría de los proyectos de agentes de IA?

Las cifras publicadas sobre esto son inusualmente consistentes para un campo que avanza tan rápido. El proyecto NANDA del MIT encuestó 300 despliegues públicos de IA además de a más de 150 líderes empresariales en 2025 y encontró que el 95% de los pilotos de IA generativa no entregaron un impacto medible en resultados. La distinción central del informe no fue la calidad del modelo, sino si la herramienta estaba integrada en un flujo de trabajo específico o se dejaba como un asistente genérico superpuesto a uno.

La investigación de Gartner apunta a la misma brecha desde otro ángulo: se espera que más del 40% de los proyectos de IA agéntica se cancelen antes de 2027, impulsados por sobrecostes, retorno poco claro y gobernanza inadecuada, más que por un modelo subyacente que no rinde.

Debajo de ambas cifras hay un problema mecánico: los errores se acumulan a través de los pasos. Los equipos que midieron esto en atención al cliente descubrieron que si cada paso de un flujo de trabajo tiene éxito el 95% de las veces —un número razonable para una tarea bien delimitada—, un proceso de seis pasos solo se completa correctamente de principio a fin alrededor del 74% de las veces. Añade un séptimo u octavo paso, algo normal en cualquier proceso que toque facturación, cumplimiento normativo o un traspaso entre departamentos, y el número sigue bajando. El agente no está fallando en cada paso. El flujo de trabajo nunca se diseñó para sobrevivir a tantas dependencias secuenciales, y ahora tiene que hacerlo.

Nada de esto tiene realmente que ver con la inteligencia del agente. Tiene que ver con dónde necesita estar realmente el juicio humano dentro del bucle y si alguien lo mapeó antes del despliegue. La mayoría de los proyectos pasan directamente a elegir una herramienta. Eso es empezar en la capa equivocada de la pila: elegir la interfaz antes de entender el proceso que hay debajo.

¿Qué tiene que cambiar realmente antes de añadir un agente?

El trabajo que tiene que suceder primero no es glamuroso, y es la parte que la mayoría de los proveedores de IA se saltan porque no cabe en una demo.

Mapea la ruta actual, incluyendo las partes que nadie quiere admitir que existen. Todo flujo de trabajo que lleva más de un año en marcha tiene al menos un paso que existe solo porque dos sistemas no se hablan, o porque alguien se quemó una vez y añadió una comprobación manual que nunca se retiró. No puedes automatizar alrededor de un paso que no has nombrado.

Pregunta por qué existe cada paso antes de decidir si eliminarlo. Algunos pasos son regulatorios. Otros existen porque una persona necesita ver la decisión antes de que sea definitiva: una cuestión de responsabilidad legal, no de velocidad. Algunos existen puramente por costumbre. Solo la tercera categoría es segura para automatizar por completo; las dos primeras necesitan un tipo distinto de rediseño, uno en el que el agente prepara la decisión y una persona sigue tomándola. El procesamiento de facturas rediseñado desde cero es un caso útil: la mayor parte del trabajo manual no es la aprobación en sí, son los treinta minutos que se tarda en encontrar a qué orden de compra corresponde realmente la factura.

Decide hacia dónde debería moverse realmente el traspaso, no solo quién ejecuta el actual. El traspaso entre un humano y un paso automatizado es donde la mayoría de los proyectos fallan en silencio, porque los equipos automatizan el 80% fácil de una tarea y dejan a la persona con el 20% difícil, sin nada del contexto que sí tenía el sistema.

Construye la ruta de excepción antes que la ruta ideal. Un flujo de trabajo que solo funciona cuando nada sale mal no es un flujo de trabajo, es una demo. El agente necesita una ruta definida para lo que pasa cuando los dos sistemas discrepan, cuando a un documento le falta un campo, cuando la solicitud del cliente no encaja en ninguna de las categorías de los datos de entrenamiento. Si esa ruta no existe, el agente inventará una, en silencio, y nadie se dará cuenta hasta que el resultado ya esté equivocado.

Resumen

El fallo no está en el modelo. Está en lanzar un agente dentro de un proceso que nunca quedó del todo definido, y esperar que el agente absorba decisiones que nadie escribió. Las cifras lo respaldan desde tres direcciones: el pronóstico de cancelaciones de Gartner, los datos de pilotos del MIT y la simple mecánica del error acumulado a través de los pasos. Ninguna de ellas trata realmente de la capacidad de la IA. Tratan de si alguien hizo el trabajo de mapear el flujo antes de automatizarlo. Ese trabajo es más lento que instalar un chatbot. También es la única versión que sigue funcionando seis meses después del lanzamiento, cuando por fin llega la primera excepción que la demo nunca mostró.