Un autor de Habr propone una «aceptación» para agentes de IA: el «listo» exige pruebas

El error más caro de un agente de IA en producción se parece a un éxito: un breve «listo» sin nada detrás. El autor de un artículo reciente en Habr propone desplazar el foco de la calidad de la respuesta a la aceptación del trabajo: qué debe ocurrir exactamente para poder dar la tarea por cerrada. La tesis de la introducción es contundente. A un asistente que sugiere formulaciones se le puede perdonar un párrafo desafortunado. A un agente que modifica datos de trabajo, ya no.

En el fragmento abierto del material no hay benchmarks ni metodologías concretas; quedan para la versión completa en Habr. Pero el planteamiento es certero y merece un análisis, porque justo ahí pasa hoy la frontera entre la demo y la producción.

Por qué el «listo» no demuestra nada

Un asistente genera un texto, una persona lo lee y decide qué hacer con él. El punto de control está integrado en el proceso. Un agente, en cambio, actúa por su cuenta: escribe en el CRM, corrige hojas de cálculo, ejecuta scripts, envía correos. Su informe «tarea completada» sigue siendo un texto generado, igual que cualquier otra respuesta del modelo. Puede coincidir con el estado del sistema o puede no coincidir.

Después, el escenario es conocido. Un compañero va a comprobarlo, descubre las discrepancias, lo rehace a mano y da explicaciones a los afectados. El coste del error pasa del agente a las personas, y lo hace de forma inadvertida: en las estadísticas de automatización la tarea figura como completada.

Aceptación en lugar de confianza

La lógica de la aceptación se toma de la ingeniería convencional. Los criterios de cierre de la tarea se fijan antes del lanzamiento y se comprueban contra el estado del sistema, no contra el resumen del agente. El registro se ha creado de verdad. El campo necesario ha cambiado. El número de filas afectadas coincide con el esperado. No se ha tocado nada más.

En la práctica de ingeniería suelen distinguirse tres niveles de esta verificación:

• resultado: se ha alcanzado el estado objetivo y se ve en el propio sistema;
• límites: la comparación del estado anterior y posterior muestra únicamente los cambios previstos;
• rastro: el registro de acciones del agente permite reconstruir qué hizo exactamente y en qué orden.

Los niveles se complementan. Un resultado sin comprobación de límites pasará por alto las modificaciones colaterales, y un registro sin comprobación del resultado se convertirá en un bonito relato de lo bien que habría ido todo.

Qué métricas conviene medir

Mientras la aceptación no se mide, la discusión se queda en las sensaciones. Este es el conjunto mínimo de indicadores para un equipo que incorpora un agente a un proceso de trabajo:

• proporción de falsos «listo»: tareas declaradas cerradas que no superaron la verificación;
• proporción de tareas aceptadas sin correcciones humanas;
• tiempo que dedica una persona a verificar una tarea;
• proporción de tareas cuya verificación está automatizada;
• número de reversiones de cambios en un periodo.

Lo importante es mirar estas cifras en conjunto. Si el agente cierra muchas tareas, pero el tiempo de revisión manual crece, el ahorro es ficticio.

Por dónde empezar en la práctica

Elija una tarea que el agente ya realice y, antes del siguiente lanzamiento, anote sus criterios de cierre de forma verificable. Si un criterio no se puede comprobar con un script o una consulta, es demasiado vago y habrá que reformularlo.

Después, separe al verificador del ejecutor. Una comprobación que lanza el mismo agente y que él mismo interpreta repite el problema original. Una simple consulta a la base de datos o la comparación de volcados anterior y posterior es más fiable que un autoinforme.

Por último, deje a una persona como supervisor por muestreo donde el error sale caro: cambios masivos de datos, operaciones de pago, envíos externos. Para todo lo demás basta con una aceptación automática con un umbral claro; si se supera, la tarea vuelve a la verificación manual.

La idea del autor de Habr se resume en una regla sencilla: el agente solo obtiene el derecho a decir «listo» junto con una prueba. Para un mercado en el que los agentes se incorporan en masa a los procesos de trabajo, es un estándar sensato y barato.