Fiabilidad de los Agentes de IA: Por Qué la Respuesta Final No es Suficiente

La salida correcta no demuestra un razonamiento correcto, una ejecución segura o un sistema confiable.

Durante años, la evaluación de la IA ha estado dominada por una pregunta engañosamente simple: ¿Fue correcta la respuesta? Para un chatbot, esto a veces puede ser suficiente. Para un agente capaz de buscar en sistemas, leer datos, llamar herramientas, modificar estados, ejecutar flujos de trabajo, escribir archivos, interactuar con APIs o tomar decisiones, no lo es.

Un agente puede producir la respuesta final correcta mientras hace varias cosas mal en el camino. Puede usar la fuente equivocada, malinterpretar una instrucción y luego compensar el error, acceder a información innecesaria, ejecutar una acción intermedia no autorizada, recuperarse silenciosamente de un error que debería haber provocado una escalada, o dejar efectos secundarios que nadie notó.

Eso crea uno de los problemas centrales de la IA agéntica: un resultado correcto no demuestra una trayectoria correcta.

La ilusión del resultado

El software tradicional nos da un modelo intuitivo de corrección. La entrada entra en un sistema determinista o mayormente determinista, se ejecuta la lógica, se produce la salida y las pruebas verifican el comportamiento esperado. Los sistemas basados en LLM debilitan esta suposición. Los sistemas agénticos van más allá.

• interpretación del modelo
• contexto recuperado
• selección de herramientas
• observaciones intermedias
• estado externo
• acciones previas
• planes generados por el modelo
• límites de permisos
• reintentos y comportamiento de respaldo
• interacción humana

Dos ejecuciones que parten de entradas casi idénticas pueden alcanzar el mismo resultado a través de caminos muy diferentes. Si la evaluación observa solo la salida final, la mayor parte del sistema permanece invisible.

Imagina que un agente de IA recibe la instrucción: Actualiza la dirección de facturación del cliente. La dirección finalmente se actualiza correctamente. Una evaluación convencional podría clasificar la tarea como exitosa.

1. El agente busca varios registros de clientes no relacionados.
2. Recupera más información personal de la necesaria.
3. Inicialmente modifica la cuenta equivocada.
4. Nota el error.
5. Revierte el cambio.
6. Actualiza la cuenta correcta.
7. Reporta éxito.

Estado final: correcto. Comportamiento del sistema: inaceptable. Un benchmark basado solo en resultados le da a esta ejecución un aprobado. Un sistema de aseguramiento de producción no debería.

La trayectoria es parte del producto

Por eso la trayectoria de un agente de IA debe convertirse en un objeto de ingeniería de primera clase. Una trayectoria es la secuencia de estados y acciones relevantes entre la solicitud original y el resultado final.

Intención → Contexto → Decisión → Herramienta → Acción → Observación → Decisión → Cambio de estado → Resultado

Zachary J. Stevens desarrolla esta idea en La trayectoria es el sistema, argumentando que la evaluación agéntica debe ir más allá de la respuesta final y examinar el camino completo de acción a través de un entorno cambiante.

Un resultado correcto no excusa una trayectoria inaceptable.— Zachary J. Stevens, La trayectoria es el sistema

La distinción importa enormemente. Por lo tanto, la confiabilidad no es simplemente salida correcta. Está más cerca de resultado aceptable + trayectoria aceptable + recuperabilidad + evidencia.

Una respuesta correcta puede ocultar un sistema roto

La mayoría de las evaluaciones basadas en benchmarks recompensan fuertemente a A y B y penalizan a C y D. Operativamente, sin embargo, B puede ser más peligroso que C. El agente C puede reconocer la incertidumbre, detener la ejecución y solicitar revisión humana. El agente B puede producir con confianza resultados correctos mientras viola suposiciones que nadie está monitoreando.

salida exitosa → mayor confianza → permisos más amplios → más automatización → mayor radio de explosión

Necesitamos evidencia, no confianza

Uno de los mayores errores en la adopción de IA es tratar la confianza del modelo, la satisfacción del usuario o la tasa de éxito histórica como evidencia de la fiabilidad del sistema. No son equivalentes.

• ¿Qué recibió el agente?
• ¿Qué contexto recuperó?
• ¿Qué herramientas llamó?
• ¿Por qué se permitió la acción?
• ¿Qué estado existía antes de la acción?
• ¿Qué cambió?
• ¿Qué fallos intermedios ocurrieron?
• ¿Se reintentó algo?
• ¿Se requirió aprobación humana?
• ¿Se podría haber detenido la ejecución?
• ¿Se puede revertir la acción?
• ¿Qué modelo, prompt y versiones de herramientas estuvieron involucrados?

Sin estas respuestas, no hay una garantía operativa seria. Solo hay una salida. La observabilidad y la evidencia deben, por lo tanto, diseñarse dentro de la arquitectura del agente en lugar de agregarse después del despliegue.

Registrar no es lo mismo que controlar

Las organizaciones a menudo responden: Todo está registrado. Bien. Pero registrar solo no controla nada. Un registro te dice lo que sucedió. Un control determina si algo puede suceder.

El agente solicita DELETE /customer/123 ↓
Acción registrada ↓
DELETE ejecutado

Eso proporciona observabilidad. Compáralo con:

El agente solicita DELETE /customer/123 ↓
Evaluación de políticas ↓
Identidad actual verificada ↓
Parámetros de acción actuales comprobados ↓
Umbral de riesgo evaluado ↓
Aprobación humana si es necesaria ↓
Acción ejecutada ↓
Resultado verificado ↓
Evidencia almacenada

Ahora nos acercamos a un sistema de control. La diferencia es arquitectónica, no cosmética.

El permiso es necesario, pero no es garantía

Supongamos que un agente tiene permiso para enviar correos electrónicos. El control de acceso responde: ¿Puede este agente enviar correos? No responde: ¿Debería este correo en particular enviarse a esta persona en particular con este adjunto en particular en este momento?

CONTROL DE CAPACIDAD
¿Qué se le permite técnicamente hacer al agente? + GARANTÍA DE ACCIÓN
¿Es apropiada esta acción específica en el estado actual?

RBAC, alcances de OAuth, permisos de API e identidades de agentes definen el espacio de acciones posibles. No prueban que una acción dentro de ese espacio sea apropiada. Una arquitectura de agente sólida necesita ambas capas.

El Primer Paso Incorrecto Importa

Cuando un agente falla, la acción incorrecta final a menudo no es donde comenzó el fallo. El fallo real puede haber ocurrido mucho antes.

Recuperación incorrecta ↓
Suposición incorrecta ↓
Razonamiento plausible ↓
Llamada a herramienta válida ↓
Acción incorrecta

Si investigamos solo la acción final, corregimos el síntoma. Si inspeccionamos la trayectoria, podemos identificar el primer paso incorrecto. Eso convierte un fallo no atribuible en un problema de ingeniería concreto.

Las Pruebas de Agentes Deben Ir Más Allá de las Pruebas de Prompts

Los prompts importan, pero el comportamiento de un agente en producción surge de un sistema completo.

MODELO
+
PROMPT DEL SISTEMA
+
CONTEXTO
+
MEMORIA
+
RECUPERACIÓN
+
HERRAMIENTAS
+
PERMISOS
+
FLUJO DE TRABAJO
+
ESTADO EXTERNO
+
LÓGICA DE CONTROL

Cambiar cualquiera de estos puede cambiar la trayectoria. Por lo tanto, versionar solo el prompt es insuficiente.

versión_del_modelo
versión_del_prompt
versión_de_la_herramienta
versión_de_la_política
versión_de_recuperación
versión_del_flujo_de_trabajo
estado_del_entorno
id_de_ejecución

Los Criterios de Aceptación para Agentes Deben Incluir Comportamiento

Los criterios de aceptación tradicionales a menudo se ven así: Dado X, el sistema produce Y. Para sistemas agénticos, eso es incompleto. Los criterios de aceptación también deben definir restricciones sobre la trayectoria.

Resultado

La dirección del cliente se actualiza correctamente.

Autorización

El agente modifica solo al cliente explícitamente seleccionado.

Acceso a datos

No se accede a registros de clientes no relacionados.

Herramientas

Solo se utilizan operaciones CRM aprobadas.

Verificación

La nueva dirección se lee y se compara con el valor solicitado.

Fallo

La resolución ambigua de identidad detiene la ejecución.

Autoridad humana

Un humano puede rechazar la modificación antes de la ejecución cuando los umbrales de riesgo requieren aprobación.

Evidencia

La ejecución deja un rastro suficiente para reconstruir la decisión y la transición de estado.

Recuperación

El valor anterior sigue siendo recuperable.

El humano en el circuito no es suficiente

Agregar una casilla de aprobación humana no resuelve automáticamente el problema. Un humano solo puede controlar a un agente si la persona tiene visibilidad, autoridad, tiempo, contexto y capacidad de recuperación.

• Visibilidad: suficiente información para entender lo que está sucediendo.
• Autoridad: capacidad real de detener o modificar la acción.
• Tiempo: intervención antes de que ocurra la consecuencia.
• Contexto: evidencia suficiente para tomar la decisión.
• Capacidad de recuperación: capacidad de revertir o reparar la acción.

Un usuario que hace clic en Aprobar sobre algo que no puede inspeccionar de manera significativa no es una gobernanza sólida. Es teatro de aprobación.

La reversión debe convertirse en una capacidad nativa de la IA

El despliegue de software tradicional nos ha enseñado algo valioso: Nunca implementes lo que no puedes revertir. Deberíamos aplicar el mismo principio a las acciones agénticas.

REVERSIBLE
Puede deshacerse automáticamente. COMPENSABLE
No puede deshacerse directamente, pero puede ejecutar una acción compensatoria. IRREVERSIBLE
No puede restaurar de manera confiable el estado anterior.

Cuanto mayor es la irreversibilidad, más fuerte debe ser el requisito de control.

Leer documento público → baja consecuencia
Crear borrador → reversible
Modificar registro CRM → reversible pero con consecuencias
Enviar correo externo → prácticamente irreversible
Transferir dinero → alta consecuencia
Eliminar datos de producción → potencialmente catastrófico

El Agente Necesita un Plano de Control

USUARIO / INTENCIÓN DEL SISTEMA │ ▼ AGENTE DE IA │ acción propuesta │ ▼ ┌───────────────────┐ │ PLANO DE CONTROL │ ├───────────────────┤ │ Identidad │ │ Autorización │ │ Política │ │ Riesgo │ │ Estado │ │ Evidencia │ │ Autoridad humana │ │ Reversión │ └───────────────────┘ │ ¿aprobado? / \ NO SÍ │ │ DETENER ▼ HERRAMIENTA │ ▼ CAMBIO DE ESTADO │ ▼ VERIFICACIÓN

El LLM debe proponer. El plano de control debe gobernar. Esa separación es crucial. El modelo no debe ser la autoridad última que determine si su propia acción propuesta de alto impacto es segura.

De los Benchmarks a la Confianza Operativa

Los benchmarks siguen siendo útiles. Nos informan sobre la capacidad, comparan modelos, detectan regresiones y ayudan a estimar el rendimiento esperado. Pero la evaluación de la capacidad y la confianza operativa responden a preguntas diferentes.

Un benchmark pregunta: ¿Puede el sistema hacer esto? La garantía operativa pregunta: ¿Podemos permitir que el sistema haga esto aquí, bajo estas condiciones, con estos permisos y consecuencias?

La Fiabilidad Debe Medirse como una Propiedad del Sistema

1. Corrección del resultado: ¿Produjo el sistema el resultado esperado?
2. Corrección de la trayectoria: ¿Siguió una ruta aceptable?
3. Integridad del control: ¿Se respetaron los límites de autorización, política e intervención?
4. Recuperabilidad: ¿Pueden los fallos contenerse, revertirse o repararse?
5. Completitud de la evidencia: ¿Puede la ejecución reconstruirse y auditarse?

Fiabilidad Operativa
=
Resultado × Trayectoria × Control × Recuperabilidad × Evidencia

La multiplicación es intencional. Si una dimensión crítica se acerca a cero, una puntuación alta en otra parte no debería ocultarlo. Un resultado perfectamente correcto con integridad de autorización cero no es un sistema fiable al 80%. Es una ejecución inaceptable que casualmente produjo la respuesta correcta.

El Éxito es a Veces el Fracaso Más Peligroso

Los fracasos atraen la atención. El éxito a menudo no. Eso hace que las trayectorias de agentes exitosas pero no controladas sean particularmente peligrosas. Un fracaso evidente crea un incidente. Un defecto oculto en la trayectoria crea confianza. Y la confianza expande la autonomía.

Las organizaciones no deberían por tanto investigar solo ¿Por qué falló el agente? Deberían preguntarse periódicamente: ¿Por qué tuvo éxito el agente? ¿Tuvo éxito porque la arquitectura restringió y verificó de manera fiable la ejecución, o porque esta vez nada salió mal?

Conclusión

La industria se mueve rápidamente desde la IA que responde hacia la IA que actúa. Esa transición cambia lo que significa fiabilidad. Para un sistema de respuestas, evaluar la respuesta puede ser a menudo suficiente. Para un sistema de acciones, debemos evaluar la trayectoria.

Prompt ↓
La respuesta se convierte en Intención ↓
Trayectoria ↓
Acciones ↓
Cambios de estado ↓
Evidencia ↓
Resultado

La respuesta final sigue siendo importante, pero es solo el extremo visible de un sistema mucho más grande. Una vez que se permite que la IA afecte al mundo real, el camino hacia la respuesta se convierte en parte de la respuesta.