La pregunta difícil de una aplicación con agentes no es qué modelo usar. Es dónde va la línea: qué decide el agente solo y qué tiene que firmar una persona. Casi todo el mundo responde igual, con una bandeja de aprobaciones, y es la respuesta correcta. Lo que se cuenta menos es que esa bandeja falla de dos maneras opuestas, y que arreglar una empeora la otra.

La pieza que hoy todos montan igual

Los marcos de agentes la traen de serie. En el SDK de agentes de OpenAI, las aprobaciones son “el camino de intervención humana para las llamadas a herramientas”: el modelo puede decidir que hace falta una acción, pero la ejecución se detiene hasta que alguien apruebe o rechace, y por dentro “la corrida registra una interrupción de aprobación en lugar de ejecutar la herramienta”. En LangGraph la primitiva se llama interrupt(), guarda el estado y, según su documentación, “espera indefinidamente” a que alguien reanude; la recomiendan antes de acciones críticas como llamadas a una API, cambios en una base de datos o transacciones financieras.

En esa primera cita está lo que separa una aprobación real de una aparente: no se le pide al modelo que espere, es el ejecutor el que no corre.

Primer fallo: la bandeja es una cola, y la cola se come el producto

Si cada acción pide firma, la persona pasa a ser el límite de capacidad del sistema. Las dos documentaciones son honestas con esto: una espera indefinidamente, la otra recomienda que, si la revisión va a tardar, guardes el estado y reanudes más tarde. Con un puñado de casos se aguanta; con volumen, no. Una acción que espera en una bandeja es una acción que no ocurrió a tiempo, y hay muchas cuyo valor caduca, como un mensaje que debía salir mientras la conversación seguía viva.

El arreglo tentador es bajar la reja hasta que el trabajo fluya, que es justo lo que la reja existía para impedir. Lo que decidimos fue mover la pregunta: aprobación por excepción y no por acción. El dueño firma una vez las condiciones dentro de las cuales se puede negociar, y lo que cabe en ellas sale solo; lo que se sale, un descuento mayor, más cuotas o una fecha fuera de plazo, pide la firma y dice por qué. Si no hay condiciones configuradas, o si no se puede medir si la acción cabe, se pide la firma igual. La persona no desaparece, se mueve: deja de autorizar actos uno por uno y pasa a autorizar la política, que es la decisión que de verdad pide criterio y la única que escala.

Segundo fallo: un freno que el modelo puede rodear

El otro fallo tira hacia el lado contrario y es más silencioso. La persona rechaza un plan y, antes de llegar al siguiente, aparece uno nuevo en su lugar. Nada caído, ningún error en los registros.

La causa es que el rechazo viajaba hasta el modelo como texto que vuelve a su contexto, y el texto es una petición. Un modelo que obedece casi siempre no es un control, es un colaborador con buena voluntad: basta con que de vez en cuando lea el “no” como “ese no, prueba con otro” para que la bandeja se llene sola. Con un agravante que solo se ve operando: cuando un agente delega en otro, la reanudación pasa por dos niveles y la instrucción tiene que ganar en ambos.

Lo grave no es el trabajo extra, es hacia dónde empuja. Aprobar es un clic y se termina; rechazar es un clic y vuelve a empezar. Lo que fija cuántos rechazos hacen falta no es el número de planes pendientes, sino la paciencia de quien revisa. El Reglamento Europeo de IA le pone nombre a lo que viene después: su artículo 14 exige que quien supervisa pueda ser consciente de la tendencia a confiar automáticamente o en exceso en los resultados del sistema, el sesgo de automatización. Una pantalla cuyo camino barato es el sí no previene ese sesgo, lo fabrica, y deja constancia de que hubo revisión humana.

Lo primero que intentamos fue mejorar la redacción del veredicto que volvía al modelo. Funcionó casi siempre, que es justo la nota que no sirve para un control. La decisión fue sacarlo del texto: tras un rechazo, durante el resto de ese turno la herramienta que propone planes no se ejecuta, y no porque se le pida al modelo que no la llame, sino porque el código que la ejecuta se niega. El siguiente plan solo sale cuando la persona vuelve a escribir. Es lo que OWASP llama mediación completa: implementar la autorización en los sistemas posteriores en lugar de depender de que un modelo decida si una acción está permitida.

Dónde va la línea

A la IA se le deja ejecutar dentro de un margen que alguien definió antes; a la persona, definir ese margen y resolver lo que se sale. Tres preguntas para cualquier flujo con supervisión humana. ¿Se aprueban actos o políticas? Si son actos, la pantalla mide capacidad y no criterio, y el cuello de botella llega con el primer cliente grande. ¿Cuánto cuesta decir que no frente a decir que sí? Si el no cuesta más, la pantalla ya eligió por la persona. ¿Dónde vive el freno, en el texto que lee el modelo o en el código que decide si la herramienta corre? Solo el segundo se cumple sin depender de que el modelo colabore.

Operamos agentes en producción con dueño humano y aprobación por herramienta, y esto es de lo que solo aparece usándolos. Misma lección que cuando un agente dijo haber verificado una identidad sin hacerlo: lo que el modelo dice que hizo no es lo que ocurrió, y lo que se le pide que no haga no es lo que no hará.