Agentes de IA: cuándo un reintento necesita aprobación humana

El gasto ocurrió dentro de un flujo ya aprobado

No se trataba de un experimento desatendido y sin puntos de control. Era un flujo de producción de video rediseñado alrededor de un director agéntico. El director escribía el storyboard, renderizaba las viñetas y los clips, y después evaluaba su propio trabajo. Las aprobaciones humanas que ya existían se mantuvieron.

Entonces, los controles de calidad del agente rechazaron tres viñetas y los cinco clips. En lugar de detenerse y presentar los hallazgos a una persona, el director volvió a generarlos según su propio criterio. Cuando alguien revisó por fin el trabajo, ya se habían cargado $5.48 a la clave del propietario.

La secuencia importa más que el importe. Demuestra que un flujo puede exigir aprobación humana en los hitos evidentes y, aun así, esconder un ciclo de compras no autorizado dentro de una de sus etapas. Cada renderización de pago es una compra. Y una evaluación de calidad que provoca otra renderización también es una decisión de gasto.

Por qué la aprobación existente no cubría el reintento de los agentes de IA

Las dos aprobaciones existentes respondían a preguntas concretas: si el storyboard podía aceptarse y si el video podía aprobarse. No determinaban quién tenía permiso para comprar otra renderización después de que el agente rechazara un resultado ya terminado.

Ese permiso es distinto. Aprobar una etapa del flujo no equivale a conceder un presupuesto permanente para cualquier acción que el software decida ejecutar dentro de ella. Una persona puede autorizar el trabajo sin aprobar una cantidad desconocida de recompras activadas por el criterio estético del modelo.

Pensemos en un inspector de calidad capaz de rechazar una pieza entregada. Debe poder registrar el defecto, pero eso no significa que también deba poder encargar un repuesto con cargo a la cuenta del propietario. Informar y comprar son facultades separadas, aunque una acción suceda a la otra.

Las barreras externas, los reintentos limitados y la protección frente a acciones duplicadas son medidas útiles, pero atienden riesgos diferentes. El fallo observado fue otro: el control de calidad de un modelo autorizó una nueva compra dentro de un flujo que ya tenía aprobaciones humanas. Había personas en el circuito, pero no justo en el límite donde se producía la recompra.

Un indicador de repetición fijado por el modelo no era un control

El diseño original utilizaba un indicador que el modelo podía activar para solicitar otra ejecución. Parecía una forma de gestionar el estado, pero no establecía un límite de autorización independiente. El mismo actor que rechazaba el resultado podía habilitar la condición necesaria para comprar su reemplazo.

Un control solo funciona si el actor al que pretende limitar no puede reescribirlo. Si el modelo puede establecer redo_requested, el indicador registra la intención del modelo, no la aprobación del propietario.

Es la misma distinción que explica la explotación de especificaciones en agentes de IA en producción: un sistema puede cumplir la condición visible y, al mismo tiempo, eludir el motivo por el que esa condición existe. Aquí, el motivo era sencillo: un nuevo cargo requería la decisión de una persona.

Los prompts no corrigen un error de autoridad. Pedirle al agente que actúe con cautela sigue dejando la compra dentro de su ámbito de decisión. El bloqueo debe implementarse en el código, junto a la llamada a la herramienta de pago.

La solución separa los hallazgos del permiso

La corrección registrada asigna funciones distintas a la revisión y a la aprobación.

El paso de revisión puede examinar el resultado terminado y guardar sus hallazgos. Después se detiene. No puede establecer el campo que permite pagar otra renderización.

Una persona revisa esos hallazgos y pulsa un botón. Esa acción guarda la aprobación humana en el registro. Cuando el paso de renderización intenta repetir la compra, consume ese permiso. Si no existe la marca de la persona, el código rechaza la ejecución.

Las primeras renderizaciones siguen existiendo y permanecen detrás de su aprobación actual. El nuevo control se aplica cuando el flujo pretende comprar otra renderización del mismo contenido después del control de calidad.

Separe la regla de escritura de la comprobación

El campo importa, pero importan todavía más sus permisos de escritura. El paso de revisión puede guardar hallazgos. El controlador del botón puede guardar la aprobación de la persona. La ruta de ejecución del modelo no debe ofrecer ninguna forma de escribir en el campo de aprobación.

El punto de aplicación de la regla es el paso de renderización de pago. Comprobar el campo antes resulta más débil, porque las ramas posteriores pueden desviarse de la decisión. Si la comprobación ocurre justo antes de la llamada de pago, la regla queda localizada: cuando se intenta pagar otra renderización del mismo contenido y falta la marca de una persona, la ejecución se rechaza.

El siguiente pseudocódigo ilustra el control registrado. No se proporcionó código fuente de producción.

review(completed_output):
    write(findings)
    stop()

person_presses_retry_button(record):
    record.retry_approved_by_person = true

render(record):
    if record.is_repeat_paid_render:
        require(record.retry_approved_by_person)
        consume(record.retry_approved_by_person)
    else:
        require(record.existing_first_render_approval)

    call_paid_render_tool()

Lo importante no es el nombre del campo, sino la dirección de la autoridad. La revisión puede recomendar. Una persona puede autorizar. La herramienta de pago comprueba esa autorización. El modelo no puede convertir su propia recomendación en permiso.

Lo que este incidente no demuestra

Los $5.48 son el total observado antes de que alguien revisara el trabajo. El material no desglosa cuánto correspondió a las renderizaciones iniciales y cuánto a las repeticiones, así que no es posible sostener esa distribución. Tampoco aporta un ahorro medido, datos sobre la latencia de aprobación, un costo medido para la revisión humana ni resultados de pruebas posteriores a la corrección.

Esto no implica que la aprobación humana sea una novedad ni constituye una receta general para los reintentos. Reintentar después de un fallo de red, duplicar una acción tras un tiempo de espera agotado y pagar una nueva renderización después de un rechazo subjetivo de calidad son sucesos diferentes. Este incidente respalda una regla precisa: si la revisión del propio agente pretende volver a comprar el mismo resultado renderizado, una persona debe conceder un permiso que el modelo no pueda otorgarse a sí mismo.

El control añadirá una decisión humana en ese límite. Que la contrapartida resulte conveniente en otros casos dependerá de la herramienta y de sus consecuencias. Para la renderización de pago de este flujo registrado, el límite está claro: la autocrítica del agente abría directamente la cartera del propietario.

Qué cambiar el lunes

En un flujo de renderización de pago que ya cuenta con aprobaciones humanas, revise la ruta que vuelve del control de calidad a la llamada de renderización. Elimine cualquier permiso de repetición que el modelo pueda modificar. Haga que la revisión guarde los hallazgos y se detenga. Añada un campo de aprobación que solo una persona pueda establecer y un botón; después, obligue a la función de renderización de pago a rechazar cualquier repetición si ese campo no está presente.

Mantenga sin cambios la aprobación de la primera renderización. La solución no consiste en reducir la autonomía en todo el sistema, sino en imponer un límite estricto en la segunda compra del mismo contenido.

Si necesita incorporar este control a un flujo de agentes de pago, consulte automatización con IA.