Aprobación humana en agentes de IA: el patrón que falta

La aprobación humana en escrituras riesgosas es un patrón de diseño que obliga a un agente de IA a detenerse y pedir confirmación explícita antes de ejecutar una acción difícil de revertir -borrar registros, mover dinero, desplegar código, enviar comunicaciones- mientras deja correr sin fricción las acciones de solo lectura. No es un interruptor de 'modo autónomo': es una clasificación acción por acción según su reversibilidad real.

Un agente que consulta el estado de una factura, lee logs o busca en un CRM no puede causar daño irreversible aunque se equivoque de consulta. El riesgo aparece en el momento en que ese mismo agente escribe: cancela una suscripción, modifica un precio en producción, elimina una cuenta de cliente o dispara un email masivo. La distinción read/write existe desde hace décadas en bases de datos y control de acceso, pero en el diseño de agentes de IA se olvida sistemáticamente porque toda la atención se pone en el prompt y no en el permiso subyacente. En la práctica, el patrón correcto asigna a cada herramienta del agente -cada función que puede invocar- una etiqueta de riesgo: lectura, escritura reversible (se puede deshacer con otro comando) o escritura irreversible (borrado físico, envío externo, pago). Solo la última categoría necesita frenar la ejecución y esperar una persona. Tratar todas las acciones por igual, ya sea aprobándolas todas o ninguna, es precisamente el error que analizamos a continuación.

La reacción instintiva de muchos equipos al desplegar su primer agente autónomo es exigir aprobación humana para cualquier acción, incluidas las de solo lectura. El resultado es un agente que interrumpe constantemente a una persona ya saturada, lo que convierte la medida de seguridad en el principal motivo para desactivarla a las pocas semanas. La alternativa igual de habitual -y más peligrosa- es activar el 'modo autónomo' sin ninguna puerta de confirmación, confiando en que el agente no se va a equivocar porque las pruebas iniciales salieron bien. Ninguno de los dos extremos sobrevive al contacto con producción: el primero muere por fricción, el segundo por un incidente real el día que el agente interpreta mal una instrucción ambigua y borra lo que no debía. El patrón de aprobación selectiva -solo en escrituras de alto impacto- es el punto intermedio que sí es sostenible operativamente, pero exige clasificar bien qué acciones entran en esa categoría, no delegar la decisión al propio agente.

La fatiga de aprobación es un problema de seguridad, no de UX

Cuando un sistema pide confirmación para todo, la persona que aprueba deja de leer el contenido de la confirmación al cabo de pocos días: el cerebro humano se habitúa a hacer clic en 'aceptar' porque estadísticamente casi todas las peticiones anteriores eran inocuas. Este fenómeno, bien documentado en la literatura de seguridad de sistemas bajo el nombre de fatiga de alertas, es exactamente igual de aplicable a la aprobación de acciones de un agente de IA. El resultado práctico es que la barrera de seguridad sigue existiendo sobre el papel -hay un botón de aprobar- pero ha dejado de proteger nada, porque nadie evalúa realmente el riesgo antes de pulsarlo. Diseñar bien este patrón significa, de forma contraintuitiva, reducir el número de aprobaciones solicitadas para que cada una que sí aparece se tome en serio. Un agente que pide confirmación tres veces al día para acciones genuinamente irreversibles es más seguro que uno que la pide treinta veces para cualquier cosa.

Por qué muchas herramientas 'autónomas' para pymes no lo implementan de verdad

Buena parte de los agentes y copilotos comerciales que se venden hoy a pymes españolas como 'IA autónoma' conceden acceso mediante OAuth con scopes amplios y genéricos -acceso completo a tu CRM, gestión total del calendario- en lugar de permisos granulares por tipo de acción. Esto no suele ser una decisión maliciosa: es más barato de construir un scope único que un sistema de permisos por operación, y la mayoría de proveedores prioriza el time-to-market frente al control fino de acceso. La consecuencia es que la 'aprobación humana' que ofrecen estas herramientas se reduce a un checkbox inicial al conectar la cuenta, no a una confirmación en el momento en que el agente va a hacer algo irreversible. OWASP incluye este problema en su categorización de riesgos para aplicaciones LLM bajo el nombre de exceso de agencia (Excessive Agency): un agente con más capacidad de la que su tarea requiere. Cuando evaluamos herramientas de IA para clientes, este es uno de los primeros puntos que revisamos, y con frecuencia es donde encontramos el mayor hueco entre el marketing y la arquitectura real.

El patrón completo tiene tres piezas que casi nunca se explican juntas. Primero, el alcance: el agente solo debería tener acceso a las herramientas estrictamente necesarias para su tarea, no a todo el sistema conectado. Segundo, la reversibilidad: cada acción de escritura se clasifica según si puede deshacerse sin intervención humana, y solo las irreversibles activan la pausa de aprobación. Tercero, y el que casi nadie implementa bien, el rastro de auditoría separado: cuando una persona aprueba una acción, el sistema debe registrar que fue una decisión humana y no del agente, algo que estándares como el intercambio de tokens de OAuth 2.0 (RFC 8693) permiten resolver a nivel de identidad, no solo de logging aplicativo. Sin esta separación, en una auditoría posterior es imposible distinguir qué hizo el agente por sí solo y qué hizo con luz verde humana, lo que complica cualquier investigación de incidente o cualquier ejercicio de cumplimiento normativo.

• Clasifica cada herramienta del agente en lectura, escritura reversible o escritura irreversible antes de darle acceso.
• Exige aprobación humana explícita solo para las acciones irreversibles o de alto impacto (borrado, pago, envío externo, despliegue).
• Registra la aprobación como evento de identidad separado del agente, no como una línea más de log de la aplicación.
• Limita el scope de cada credencial a las acciones concretas de la tarea, no a la API completa del sistema conectado.
• Revisa cada trimestre qué acciones se clasificaron como reversibles: lo que hoy se deshace fácil puede dejar de serlo cuando cambian los datos conectados.

No todas las pymes necesitan este nivel de control desde el primer día, y sería deshonesto recomendar montar una capa completa de aprobación granular para un agente que solo redacta borradores de email o resume documentos internos: ahí el coste de construir el sistema de permisos supera el riesgo real que se está mitigando. Tampoco es buena idea añadir una aprobación humana como parche cuando el problema de fondo es que el agente tiene acceso a sistemas que no necesita para su tarea; en ese caso la solución es reducir el scope, no añadir más fricción encima de un permiso mal diseñado. Hemos visto proyectos donde el equipo interno pedía 'que todo pase por aprobación' como respuesta genérica al miedo a la IA, y el resultado fue un agente inservible que nadie usaba a los dos meses. La pregunta que de verdad hay que responder antes de añadir cualquier aprobación es qué acción concreta se quiere frenar y por qué es irreversible, no cuántas capas de control suenan más seguras sobre el papel.

El patrón de aprobación humana no falla por falta de tecnología, falla casi siempre porque nadie se sentó a clasificar qué acciones del agente son realmente irreversibles. Esa clasificación es un ejercicio de una tarde, no un proyecto de meses, y suele ser la diferencia entre un agente que da confianza y uno que da miedo.