Una marca verde puede esconder un proceso roto por dentro

Esta es la forma más peligrosa en que falla un agente de IA, porque es la que no vas a ver. El agente ejecuta una tarea de varios pasos. En algún punto a mitad de camino toma un desvío equivocado. Y aun así te entrega una respuesta final que pasa tu chequeo: se ve limpia, bien formateada, plausible, y está mal. La marca está verde. El proceso está roto por dentro. Y lo enviaste a producción.

Esto no es un caso raro de borde; los investigadores que estudian la fiabilidad de los agentes lo describen como un fallo central. En una tarea de varios pasos, un error intermedio puede pasar un chequeo de salida final mientras corrompe todo el flujo de trabajo. Su ejemplo es contundente: un agente de investigación recupera correctamente la información de un competidor, atribuye mal una característica de producto a la empresa equivocada en el paso tres y produce un resumen final que pasa un chequeo superficial mientras el error factual viaja escondido.

Quiero detenerme en esto, porque es la brecha entre «mi agente pasó sus pruebas» y «mi agente es fiable», y esas dos cosas no son lo mismo.

Por qué la respuesta final miente

Cuando pruebas software normal, revisar la salida suele ser suficiente: el código determinista que produce la respuesta correcta llegó ahí por el camino correcto. Los agentes rompen esa suposición. Son no deterministas, razonan en cadenas largas, y una cadena tiene muchas maneras de llegar a un final que se ve plausible estando equivocada en el camino.

Así que una respuesta final que pasa te dice menos de lo que te diría con código corriente. El agente puede acertar el formato y errar los hechos. Puede llegar a una conclusión que suena razonable a partir de un paso intermedio chapucero, igual que un estudiante puede caer en una respuesta de aspecto correcto gracias a errores que se cancelan entre sí. Peor aún, la salida segura y fluida es justo donde un modelo es más peligroso cuando está equivocado: el pulido que hace que la respuesta pase tu chequeo es el mismo pulido que esconde el razonamiento roto debajo.

Por qué este es el bug caro

Un fallo visible es barato: el agente da error, lo ves, lo arreglas. Este es caro precisamente porque parece un éxito. El resumen se le envía al cliente. El número fluye hacia el informe. La característica mal atribuida se vuelve un hecho que tu equipo repite. Para cuando alguien lo nota, el error ya se propagó por todo lo que estaba aguas abajo y confió en la marca verde.

Y se agrava con la matemática de la fiabilidad. Un flujo de trabajo de programación de 2026 promedia unos veinte pasos dependientes, y un chequeo de salida final solo mira el último. Diecinueve lugares para tomar un desvío equivocado, un solo lugar donde estás mirando. Así es como los agentes muestran buenos números en la demo y luego decepcionan en silencio en producción: la demo califica la respuesta, producción convive con el razonamiento.

Qué revisar en su lugar

El arreglo es dejar de calificar solo el destino y empezar a calificar el trayecto:

• Evalúa los pasos, no solo la salida. Evals o no se entregó: y para los agentes eso significa revisar el razonamiento intermedio, las llamadas a herramientas y las recuperaciones, no solo la cadena final.
• Haz que el agente muestre su trabajo. Un agente que expone su razonamiento intermedio y sus fuentes te permite a ti —o a otro modelo— atrapar el desliz del paso tres antes de que llegue al paso diez. Una caja negra que solo emite una respuesta final no te da nada que inspeccionar.
• Verifica los hechos contra la fuente. Para tareas de recuperación e investigación, comprueba que cada afirmación se remonte a lo que de verdad se recuperó. La mala atribución sobrevive a un chequeo de estilo; muere contra la fuente.
• Pon un punto de control antes de cualquier cosa irreversible. Si un paso envía, paga, borra o confirma, ahí es donde corresponde un humano o una validación dura, no al final del todo, después de que el proceso roto por dentro ya actuó.

Esto es más trabajo que leer la respuesta final. Ese es el punto: la respuesta final siempre fue lo barato de revisar, y los chequeos baratos son la razón por la que los procesos rotos por dentro llegan a producción.

En resumen

Una marca verde sobre la salida final se siente como prueba de que el agente funcionó. Para agentes de varios pasos, es una evidencia más débil de lo que parece: la salida puede estar limpia mientras el razonamiento que la produjo estaba equivocado, y esa brecha exacta es una de las principales formas en que fallan los agentes en producción. Califica solo el destino y serás ciego a la mayor parte del trayecto, que es donde viven los fallos.

Así que cuando evalúes un agente, desconfía un poco de la respuesta final limpia. Pregunta cómo llegó ahí, revisa los pasos que importan y verifica los hechos contra su fuente. El razonamiento es el producto; la respuesta es solo donde aflora. Un proceso roto por dentro con una marca verde encima sigue estando roto, y todo el trabajo consiste en atraparlo antes de que lo hagan tus usuarios.