El discurso sobre los agentes de IA cambió de lado en los últimos meses. Salió del “va a reemplazar al equipo” y entró en el “por qué el piloto no llega a producción”. El cambio no fue de ánimo: fue de evidencia. Y la evidencia apunta a un lugar que quien automatiza procesos reconoce de inmediato: el problema casi nunca es que el modelo sea tonto.
El número que cambió la conversación
En enero de 2026, Mercor publicó APEX-Agents, un benchmark que dejó los rompecabezas sintéticos y pasó a medir trabajo de verdad: tareas de banca de inversión, consultoría y derecho corporativo, del tipo que consume horas de un profesional. El resultado: los modelos de punta completan menos del 25% de esas tareas. Con ocho intentos en la misma tarea, el número sube a cerca del 40%, es decir, ni la insistencia cierra la cuenta.
La parte más útil del informe no es el marcador, es el diagnóstico. Los agentes fallan por administrar la ambigüedad, localizar el archivo correcto y mantener el contexto a lo largo del flujo, no por falta de capacidad bruta. Traducido a nuestra realidad: no se equivocan en la cuenta, se equivocan en cuál cuenta había que hacer, con qué hoja de cálculo, y olvidan a mitad de camino lo que ya habían decidido.
Del lado de quien paga la factura, la lectura es parecida. Gartner proyecta que más del 40% de los proyectos de IA agéntica serán cancelados hasta fines de 2027, y enumera tres motivos: costo que escala, valor de negocio que no aparece y control de riesgo insuficiente. En mayo de 2026, Gartner fue más específico sobre el tercero: hasta 2027, el 40% de las empresas debería rebajar o apagar agentes autónomos por brechas de gobernanza descubiertas solo después del incidente en producción.
Fíjese en la frase. No es “descubiertas en el piloto”. Es después del incidente.
Los cuatro huecos que aparecen siempre
Al reunir lo que el benchmark mide y lo que los analistas ven que se rompe, los modos de falla se repiten:
Ambigüedad. La tarea que recibe la persona está subespecificada, y la resuelve preguntando o usando un contexto que nadie escribió. El agente lo resuelve inventando, y sigue adelante con la invención como si fuera verdad.
Contexto que se evapora. El flujo tiene seis etapas; en la cuarta, la decisión de la segunda ya se perdió. Cuanto más largo es el proceso, mayor es la probabilidad de que el agente se contradiga sin darse cuenta.
Permiso demasiado amplio. Para “funcionar”, el agente recibe acceso a todo. Entonces funciona, y el día en que se equivoca, se equivoca con alcance total. Es la diferencia entre un bug y un incidente.
Ausencia de rastro. Cuando sale mal, nadie logra responder por qué ocurrió aquello. Sin rastro no hay corrección; hay adivinación, y el mismo error vuelve.
Lo que hago en mis flujos
Aquí entra la parte que no es opinión: es lo que sostiene este proyecto mientras usted lee.
El error tiene un lugar permitido. En Fluxonar, el borrador puede nacer con apoyo de un modelo de lenguaje, pero ningún post sale al aire sin que yo lo lea, lo edite y lo apruebe. El gate humano no es una etapa de calidad opcional: es la frontera que define dónde el error todavía es barato. Antes del merge, un texto erróneo cuesta cinco minutos. Después, cuesta credibilidad.
El contrato falla cerrado. Cada post pasa por un contrato de contenido en Zod que valida título, descripción, categoría y etiquetas contra una taxonomía cerrada. Una etiqueta fuera de la lista tumba el build, y ya lo tumbó, con un error mío, humano. Esa es la propiedad que importa: el contrato no distingue quién se equivocó, y por eso protege de los dos lados.
La automatización hace el trabajo tedioso, no el juicio. El robot que sigue los sitios oficiales recorre, compara versiones y avisa qué cambió. No decide qué hacer con el cambio. La decisión sigue siendo de quien responde por ella.
Nada de esto es sofisticado. Es la misma idea repetida: dejar que el agente proponga y el humano disponga, con un contrato ejecutable en el medio para que la mala propuesta ni llegue a la mesa.
Cuándo compensa el agente autónomo
La respuesta no es siempre no. La cuenta cierra cuando las cuatro condiciones aparecen juntas:
- la tarea es repetitiva y bien definida: poca ambigüedad sobre la cual inventar;
- el error es reversible y barato (borrador, alerta, sugerencia; no transferencia, no envío, no eliminación);
- existe rastro de lo que se hizo, revisable después;
- el permiso es del tamaño de la tarea, no del tamaño del sistema.
Cuando falta la segunda, el agente necesita un gate humano, y entonces no es autónomo, es asistido. Está bien: lo asistido resuelve la mayor parte de los casos reales de una operación pequeña, con una fracción del riesgo. Lo que no funciona es vender lo asistido como autónomo y descubrir la diferencia durante el incidente.
Lista de verificación antes de soltar un agente
Cinco preguntas. Si alguna no tiene respuesta, el agente todavía no está listo para actuar solo:
- ¿Cuál es el peor caso si se equivoca tres veces seguidas sin que nadie mire?
- ¿Qué puede tocar, y por qué necesita todo eso?
- ¿Cómo descubro que se equivocó: alguien avisa, o me entero por el cliente?
- ¿Dónde queda el registro de lo que decidió, en un formato que yo pueda leer después?
- ¿Qué regla tumba la ejecución antes del daño, y es código o es buena intención?
La pregunta 5 es la que separa los dos grupos. La buena intención escrita en el prompt no es control: es un pedido. El control es lo que falla cerrado por sí solo, sin depender de que el modelo esté en un buen día.
Fuentes
- Los modelos de punta completan menos del 25% de las tareas profesionales reales (banca de inversión, consultoría, derecho), y hasta ~40% con ocho intentos — Mercor, APEX-Agents (publicación primaria del benchmark), 21/01/2026, verificado el 2026-07-22.
- Más del 40% de los proyectos de IA agéntica cancelados hasta fines de 2027, por costo, valor de negocio y control de riesgo — Gartner (comunicado de prensa oficial), 25/06/2025, verificado el 2026-07-22.
- El 40% de las empresas debería rebajar o apagar agentes autónomos hasta 2027 por brechas de gobernanza identificadas solo después de incidentes en producción — Gartner (comunicado de prensa oficial), 26/05/2026, verificado el 2026-07-22.
