29 de agosto de 2026
La solicitud de aprobación de tu agente de IA es un límite de permisos
Si lo confirmas todo, los usuarios dejan de leer. Si solo confirmas la meta, el consentimiento se vuelve peligrosamente amplio. El límite útil está en la acción exacta que cambia algo en el mundo real.
Un usuario le dice a un agente de IA: «Borra el sandbox del Q3». El agente abre la configuración, encuentra el espacio de trabajo y llega al control de eliminación. Si pide confirmación después de cada clic, es inservible. Si toma la frase original como un consentimiento ilimitado, es temerario. Si al final pregunta «¿Continuar?», el usuario sigue sin saber qué va a pasar. La decisión de producto difícil no es si mantener a una persona en el circuito. Es dónde empieza ese circuito, qué está aprobando exactamente esa persona y cuándo deja de ser válida su aprobación.
Por eso una solicitud de aprobación debe tratarse como parte del modelo de permisos, no como una fricción de cortesía que se añade cuando el agente ya está construido.
Los dos extremos equivocados
El primer mal diseño confirma cada cambio de estado. ¿Abrir la página de facturación? Confirmar. ¿Elegir la pestaña anual? Confirmar. ¿Rellenar el nombre de la empresa? Confirmar. El producto parece prudente, pero tanta petición repetida entrena a los usuarios para aprobar por reflejo. El sistema ha producido un teatro del consentimiento: muchos clics y poca atención.
El diseño opuesto pregunta una sola vez, al principio: «Voy a limpiar el espacio de trabajo. ¿Continúo?». Suena eficiente hasta que la tarea se amplía a archivar registros, eliminar miembros y enviar un correo de resumen. El usuario aprobó una meta, no cada una de sus consecuencias. Una instrucción amplia en lenguaje natural se ha convertido en un rol de administrador temporal.
Los dos fallos nacen de usar la conversación como capa de autorización. La conversación sirve para establecer la intención. No sirve para definir la capacidad precisa que se está concediendo.
La taxonomía de modos de fallo agénticos que Microsoft publicó en 2026 hace explícita la versión de seguridad de este argumento. Recomienda una revisión humana determinista, una aprobación aparte para las subacciones con consecuencias, descripciones derivadas de las llamadas a herramientas subyacentes y niveles de aprobación basados en la reversibilidad y el radio de impacto. Quien tiene que imponer el límite es la aplicación, no el modelo.
Si cambiar una frase de la explicación del agente puede decidir que aparezca o no una revisión, la revisión la controla la prosa. Un límite de permisos real lo controla la acción que la aplicación está a punto de ejecutar.
Clasifica la consecuencia, no el botón
Los equipos suelen empezar con una lista de palabras peligrosas: eliminar, enviar, pagar, cancelar. Es útil, pero el texto de un botón no es una política. «Cancelar» puede cerrar un cuadro de diálogo o dar de baja una suscripción. «Quitar» puede borrar un filtro o revocar el acceso de una persona. «Continuar» puede ser el último control de una compra.
La clasificación necesita la acción, su objetivo y el estado que la rodea. Una política práctica puede empezar con cinco preguntas:
1. ¿Produce esta acción un efecto externo, como un mensaje, una invitación, una publicación o un cambio que se publica?
2. ¿Mueve dinero o crea un compromiso económico?
3. ¿Cambia quién puede acceder a los datos o qué permisos tiene?
4. ¿Elimina datos, cierra una cuenta o modifica una suscripción?
5. Si es un error, ¿puede el mismo usuario revertirla rápido y por completo?
Así se obtiene un límite más útil que «toda escritura requiere confirmación».
Acción propuesta · Comportamiento por defecto · Por qué
Leer una página, buscar, filtrar o abrir una pestaña · Seguir · Sin efecto externo duradero
Rellenar un campo de borrador no sensible · Seguir y mantener la acción visible · Reversible antes del envío
Cambiar una preferencia local que se puede deshacer fácilmente · Normalmente, seguir · Radio de impacto pequeño y recuperación sencilla
Enviar, publicar, invitar, compartir o cambiar accesos · Revisar la acción exacta · Afecta a otra persona o cruza un límite
Comprar, mejorar el plan, cancelar, cerrar o eliminar · Revisar justo antes de ejecutar · Impacto económico o difícil de revertir
Introducir credenciales o tomar una decisión regulada · Exigir el control directo del usuario o negarse · Aprobar no basta para que cualquier acción se pueda delegar
Se parece mucho al modelo de riesgo de herramientas de la guía de OpenAI para construir agentes, que recomienda puntuar las herramientas según el acceso de escritura, la reversibilidad, los permisos de la cuenta y el impacto económico. El paso importante es convertir esas propiedades en código y en política, no en otra instrucción que el modelo pueda interpretar con creatividad.
Pregunta justo donde está la consecuencia
La aprobación debe aparecer lo más tarde posible, pero antes del efecto externo.
Piensa en «Cancela mi suscripción Growth». El agente puede abrir la configuración, ir a facturación y consultar el plan actual sin interrumpir. Ninguno de esos pasos compromete al usuario. La revisión útil aparece cuando el agente ha encontrado el control real Cancelar suscripción y sabe a qué suscripción afecta.
Ese momento le da a la solicitud datos concretos. Puede nombrar la acción y su objetivo en lugar de parafrasear la petición inicial. Y evita pedir al usuario que apruebe una operación que quizá el agente ni siquiera consiga encontrar.
Aquí hay una distinción nítida:
– La aclaración llega cuando la acción prevista o su objetivo son ambiguos. «Quita a Alex» requiere una pregunta si hay dos miembros llamados Alex.
– La aprobación llega cuando la acción prevista está clara y la aplicación está lista para ejecutar un paso con consecuencias. Debe ser una decisión acotada: Aceptar o Rechazar.
Mezclar las dos da lugar a conversaciones exasperantes. El agente pregunta «¿Seguro que quieres continuar?» aunque todavía no sabe a qué registro se refería el usuario. O recoge primero la aprobación, se encuentra más tarde con otro control de confirmación y trata la respuesta anterior como permiso para esa nueva acción.
La secuencia más segura es: intención, resolución, revisión, ejecución. Una confirmación posterior del propio sitio es una nueva acción ejecutable y merece su propia decisión.
La solicitud debe describir la acción que se va a ejecutar
Un agente puede decir «Solo estoy ordenando el espacio de trabajo» mientras su siguiente llamada a una herramienta elimina a un miembro. Da igual que esa discrepancia sea maliciosa, inyectada o un simple error. La interfaz de aprobación no puede fiarse de la narración del agente para describir la autoridad que está pidiendo.
Construye el texto de la revisión a partir del objeto de ejecución. Muestra el control, el objetivo, el valor seleccionado, el destino y el alcance relevante que ha resuelto la aplicación. «Hacer clic en Eliminar cuenta de Acme» es útil. «Continuar con la limpieza», no.
La taxonomía de Microsoft llama a la versión débil «blanqueo de descripciones»: el agente presenta un resumen inofensivo que oculta una acción subyacente con más consecuencias. La defensa que propone es sencilla: generar la descripción de la aprobación a partir de la llamada a herramienta o del control de página reales, no de texto libre del modelo.
Esto importa aunque nadie esté atacando el sistema. Los modelos comprimen. Omiten matices. Se refieren al objeto equivocado con un «eso». La capa de ejecución ya tiene los argumentos exactos, así que la revisión debe usarlos.
– Aparece porque una política determinista ha clasificado la acción ejecutable, no porque el modelo haya decidido preguntar por iniciativa propia.
– Nombra la acción, el objetivo, el destino y el alcance en un lenguaje que el usuario pueda verificar.
– Ofrece una forma real de rechazar y no esconde el paso con consecuencias dentro de un lote.
– Autoriza un intento, no el resto de la conversación.
El consentimiento debe ser de un solo uso y estar ligado al estado
La pregunta que más se pasa por alto llega después de que el usuario hace clic en Aceptar: ¿qué autorizó exactamente ese clic?
Supón que la revisión mostraba «Eliminar sandbox del Q3». Mientras la tarjeta estaba abierta, la página se volvió a renderizar y el elemento subyacente apunta ahora al espacio de trabajo de producción. O cambió la ruta. O cambió el destinatario de un formulario. Si la aprobación se representa como un booleano llamado approved, el agente puede ejecutar la acción sobre un estado que el usuario nunca vio.
En su lugar, la aprobación debe vincularse a una huella de la acción pendiente. Esa huella puede incluir la identidad del elemento, el tipo de acción, la etiqueta del objetivo, el destino, el estado del formulario, el contenedor, el origen y la ruta. Justo antes de ejecutar, la aplicación compara la acción actual con la revisada.
Si ha cambiado algo relevante para la seguridad, la ejecución se detiene. La aprobación antigua queda consumida de todos modos, así que no puede reutilizarse si la página vuelve a su estado anterior. Si la ejecución sale bien, también queda consumida. Una revisión, un intento, un objetivo sin cambios.
No es ceremonia excesiva. Es el mismo principio de las peticiones firmadas y los tokens de un solo uso: la autoridad debe ser acotada, atribuible y de corta duración. Las recomendaciones de Microsoft para la capa de aplicación sostienen que la revisión humana debe impedir que los agentes se autoautoricen acciones con consecuencias, con disparadores impuestos por código y la posibilidad de intervenir durante la ejecución. El consentimiento ligado al estado es lo que permite que ese principio sobreviva en una interfaz dinámica.
La aprobación es una capa, no el sistema de seguridad
Ni la solicitud mejor diseñada puede cargar con todo el modelo de seguridad. Un usuario puede aprobar una mala acción porque el objetivo resulta confuso. Una inyección de prompts puede distorsionar el camino que llevó a la revisión. Una página comprometida puede presentar un contexto engañoso. Algunas tareas deberían quedar fuera de la autoridad del agente, haya o no consentimiento.
La ficha de sistema (system card) de ChatGPT agent de OpenAI presenta las confirmaciones junto al entrenamiento del modelo, los monitores automáticos, las capacidades restringidas y la supervisión activa en contextos sensibles. Esa estructura por capas es el modelo mental correcto. La aprobación limita el daño de un error. No demuestra que el razonamiento previo fuera sólido.
El resto del sistema sigue necesitando:
– acceso con mínimo privilegio a herramientas y datos;
– bloqueos deterministas sobre objetivos prohibidos y entradas sensibles;
– un control para detener una tarea de varios pasos;
– una lectura nueva de la interfaz después de cada acción;
– una auditoría final del resultado solicitado antes de declarar el éxito;
– registros que conecten la petición del usuario, la revisión, la ejecución y el resultado.
La auditoría final es especialmente importante. Aceptar significa «puedes intentar esta acción exacta». No significa que el clic haya funcionado, que haya cambiado el estado correcto ni que la tarea esté completa.
Qué elegimos para Barkan
En el modo Do de Barkan, la navegación rutinaria y el trabajo reversible en la interfaz pueden avanzar sin un desfile de confirmaciones. El widget se detiene localmente antes de las acciones clasificadas como eliminación de datos, cambios de cuenta o de suscripción, movimientos de dinero, comunicaciones externas o cambios de acceso. La revisión se dispara en la ruta de ejecución, no queda a discreción del modelo.
Una revisión aceptada queda ligada al objetivo de la acción en curso y al estado de la página, y se consume en el primer intento de ejecución. Si el objetivo cambia, la aprobación no puede reutilizarse. Si el sitio web abre su propia confirmación final, ese control se revisa como una acción aparte. Después de ejecutar las acciones, Barkan lee una vista renderizada nueva y dedica un turno aparte a la auditoría final antes de informar de que ha terminado.
Estas decisiones añaden fricción justo donde la queremos. Lo que buscamos no es la máxima autonomía ni la máxima cautela. Es el máximo trabajo útil dentro de un límite de permisos que el usuario pueda entender.
Mide el límite, no solo la aceptación
La tasa de aprobación, por sí sola, es una mala métrica de éxito. Una tasa de aceptación del 99 % podría significar que el agente siempre acierta. También podría significar que las solicitudes son tan frecuentes y vagas que los usuarios ya no las leen.
Mide el sistema como lo que es, un control:
– Cobertura de revisión: acciones con consecuencias que se interrumpieron antes de ejecutarse.
– Tasa de interrupciones innecesarias: acciones inofensivas que activaron una revisión.
– Tasa de decisión por categoría: aceptaciones y rechazos en eliminaciones, dinero, comunicaciones, accesos y cambios de cuenta.
– Rechazos por consentimiento caducado: intentos bloqueados porque el objetivo o el estado cambiaron durante la revisión.
– Finalización verificada: acciones aprobadas cuyo estado final previsto se confirmó después.
– Paradas y correcciones: tareas que los usuarios interrumpieron o redirigieron antes de un paso con consecuencias.
Después, examina ejemplos de los dos extremos: acciones con consecuencias que escaparon a la revisión y acciones inofensivas que molestaron a los usuarios. La política mejora reduciendo los dos grupos, no empujando cada tarea hacia más aprobaciones.
La solicitud de aprobación es el momento en que un producto de IA convierte una predicción en autoridad. Trátala con el rigor de una concesión de permisos. Deja que el agente avance rápido por el trabajo reversible, que se detenga en la acción exacta con consecuencias, que muestre lo que de verdad se va a ejecutar y que cada «sí» caduque tras un intento.
Barkan completa tareas de varios pasos en tu producto y se detiene en la acción exacta de alto impacto antes de ejecutarla.
«La mayoría de los usuarios no quieren otra respuesta. Quieren que les muestren el camino, o que se lo den hecho. Ese es todo el producto.»
Gabriel Lancelot
Cofundador de Barkan
