¿Cuándo debe un agente de IA requerir la aprobación humana?

No en cada paso. Si una persona tiene que aprobar cada lectura y cada llamada a una herramienta de bajo riesgo, pronto empezará a hacer clic de forma mecánica. La aprobación es útil donde un error del agente puede desencadenar una consecuencia real: financiera, externa, administrativa, legal, relacionada con la seguridad o difícil de revertir.

Hay otro punto importante: el nivel de control no debe depender de cuán confiado suene el modelo. Un modelo confiado aún puede estar equivocado. Elegimos el control basándonos en la consecuencia de la acción.

Un modelo de decisión: cinco preguntas antes de conceder autonomía

Para cada acción del agente, verificamos cinco características.

1. ¿Cambia la operación el estado?

Una lectura suele ser de menor riesgo que una escritura. No siempre —una lectura puede exponer datos sensibles— pero separar lectura de escritura es un punto de partida útil.

2. ¿La consecuencia sale del sistema interno?

Enviar un correo electrónico, publicar una entrada, habilitar un anuncio, emitir un documento o responder a un cliente es visible externamente. Un error se convierte inmediatamente en un problema de relación, costo o reputación.

3. ¿La operación crea costo o compromiso?

Un agente puede ejecutar una llamada a API correctamente y aun así tomar la decisión comercial equivocada. Presupuestos, compras, pagos, suscripciones o reservas de recursos necesitan un límite separado.

4. ¿Se puede revertir el cambio fácilmente?

Cambiar una etiqueta y eliminar una cuenta no están en la misma clase. Considere el costo de recuperación, el tiempo de recuperación, la pérdida de datos y el impacto en otros usuarios.

5. ¿Cambia la operación la seguridad o los permisos?

Conceder acceso de administrador, rotar un secreto, hacer un recurso público o cambiar la política de MFA merece control aunque la acción sea técnicamente reversible.

Una matriz práctica de autonomía

Nivel	Características de la acción	Ejemplos	Decisión predeterminada
A — autónomo	solo lectura, bajo impacto, alcance estrecho	estado del servicio, informe de costos, lista de tareas	el agente puede ejecutar
B — autónomo con auditoría	escritura reversible en un área restringida	añadir una etiqueta, guardar un borrador, crear una tarea	el agente puede ejecutar con permiso explícito y registro
C — aprobación antes del efecto	consecuencia externa, efecto financiero o cambio material	enviar un mensaje, publicar, habilitar una campaña	humano aprueba la operación específica
D — control estricto	destructivo, sensible a la seguridad, difícil de revertir	eliminar datos, cambiar acceso de admin, revocar una clave	alcance separado + aprobación + vista previa; a menudo verificación adicional

Este es un modelo operativo, no un estándar legal. Un sistema concreto debe adaptar los niveles a sus datos, regulaciones, consecuencias y mecanismos de recuperación.

La aprobación debe estar vinculada a una consecuencia específica

Un diálogo de aprobación deficiente se ve así:

El agente quiere realizar una acción. ¿Continuar? Sí / No.

La persona no sabe qué está autorizando.

Una vista previa mejor se parece más a:

Operación: HABILITAR CAMPAÑA
Cuenta: Brillnet Ads / [identificador legible]
Campaña: Búsqueda — Pulsar GRC
Presupuesto diario medio: PLN 80
Objetivo: Polonia
Cambio: PAUSADA → HABILITADA
Estado reversible: la campaña puede volver a pausarse; el gasto acumulado no se revierte
Consecuencia: tras la aprobación la campaña puede comenzar a generar gasto
Fuente de decisión: tarea #...

Solo entonces un botón “Aprobar” tiene un significado útil. En Google Ads un presupuesto diario medio no es un límite estricto del mismo día: para la mayoría de campañas, el límite de facturación diario es el doble de esa cantidad. La vista previa debe explicar esta consecuencia en lugar de prometer un techo de PLN 80.

La aprobación no debe convertirse en un pase general para cambios futuros

Supongamos que una persona aprueba:

enviar este mensaje a 12 destinatarios

Si el agente cambia el contenido o la lista de destinatarios a 1 200 personas después de la aprobación, la aprobación original ya no debe aplicarse.

Una regla práctica es:

La aprobación está vinculada a una operación normalizada específica. Un cambio material en sus parámetros invalida la aprobación y requiere una nueva.

Una implementación puede enlazar el ID de aprobación a un hash de los parámetros de la operación, a una versión del recurso o a otra representación estable de lo que realmente se aprobó.

El modelo no debe decidir por sí mismo si se puede omitir la aprobación

Se puede pedir al modelo que estime el riesgo. Eso puede ser útil como una señal, pero no debe ser el único control.

Si la política es:

cuando el modelo considera una operación riesgosa, pide a un humano

entonces el modelo también controla el mecanismo destinado a contener el impacto de sus propios errores.

Un diseño más sólido es:

1. El modelo selecciona la herramienta y los parámetros.
2. La puerta de enlace clasifica la operación usando una política explícita.
3. El motor de políticas determina si se requiere aprobación.
4. Una persona aprueba cuando sea necesario.
5. Solo entonces se lleva a cabo la ejecución.

El modelo puede proporcionar la explicación. La clasificación final proviene de la política del sistema.

Ejemplo de nuestra propia automatización: preparar una campaña no es lo mismo que iniciar el gasto

En nuestro MCP interno de Brillnet Ads, separamos la capacidad de preparar o modificar una campaña de la capacidad de activar el gasto.

Una campaña recién creada tiene por defecto el estado PAUSED cuando no se suministra otro estado explícitamente. Guardar la configuración no es consentimiento para iniciar el gasto. Habilitar el efecto operativo requiere un permiso de operación explícito y una confirmación en la solicitud. Un campo de confirmación por sí solo no prueba que una persona haya revisado la acción. Esa evidencia requiere el mecanismo de aprobación independiente descrito arriba.

Esta pequeña separación produce un resultado útil:

• el agente puede completar la mayor parte del trabajo de preparación;
• una persona no tiene que introducir manualmente cada campo;
• el presupuesto no comienza solo porque el modelo decidió que la configuración estaba lista.

El mismo patrón se aplica a otros flujos de trabajo:

Preparación	Efecto que requiere una decisión separada
redactar un correo	enviarlo
proponer un rol de usuario	conceder acceso
plan de migración	ejecutar la migración
lista de archivos a eliminar	borrarlos
propuesta de cambio de precio	publicar el nuevo precio
pago preparado	autorizar el pago

Cuando la aprobación puede ser innecesaria

No toda automatización necesita ser semiautomática.

La aprobación humana a menudo aporta poco valor cuando se cumplen todas estas condiciones:

• la operación es solo lectura o de bajo impacto;
• el agente trabaja dentro de un alcance estrecho y preaprobado;
• la salida no se publica automáticamente;
• un error es fácil de detectar y reparar;
• no hay gasto ni compromiso externo;
• los permisos y configuraciones de seguridad no cambian;
• la acción deja suficiente evidencia de auditoría para reconstruir el resultado.

Ejemplo: un agente recupera el estado de una campaña cada día y prepara un informe interno. Exigir que un humano apruebe cada lectura no aumenta la seguridad en proporción al coste operativo.

Cuando recomendamos la aprobación como mínimo

En nuestros proyectos, no concedería ejecución autónoma sin un análisis separado para operaciones que:

• envían comunicaciones a clientes o al público;
• inician o aumentan gasto;
• eliminan o sobrescriben datos sin una ruta de recuperación simple;
• conceden, amplían o revocan permisos;
• modifican secretos, configuraciones de seguridad o MFA;
• aceptan términos legales en nombre de una organización;
• actúan sobre un recurso identificado de forma ambigua;
• desencadenan otro sistema que a su vez puede realizar acciones de alto impacto.

Eso no significa que la aprobación humana sea siempre el único control. Para acciones críticas debe ser una de varias capas.

Cuidado con la fatiga de aprobación

Si un sistema solicita aprobación 80 veces al día, los usuarios dejan de leer los avisos. La aprobación se convierte en un CAPTCHA para empleados.

Eso suele señalar uno de tres problemas de diseño:

1. la clasificación de riesgo es demasiado amplia;
2. el flujo de trabajo no agrupa cambios lógicamente relacionados;
3. el agente tiene muy poca autonomía segura en riesgos bajos, de modo que todo se escala.

La respuesta no es ocultar advertencias. Es diseñar mejores límites.

Qué debe hacer un mecanismo de aprobación útil

Mostrar la diferencia, no todo el objeto

Para configuraciones, muestre antes → después y los campos que cambian. No obligue al revisor a comparar dos pantallas manualmente.

Declarar la consecuencia

“Guardar cambio” es más débil que “Habilitar campaña — puede comenzar a generar gasto con un presupuesto diario medio de PLN 80”.

Tener un alcance y una vigencia

Una aprobación antigua no debe seguir autorizando una operación después de que el contexto cambie.

Rechazar una operación materialmente cambiada

Si los parámetros cambian después de la aprobación, la aprobación debe expirar.

Dejar un registro independiente

El registro de auditoría debe indicar quién aprobó qué, cuándo y bajo qué identificador de operación. No debe depender solo de un mensaje del modelo que diga “el usuario aceptó”.

Leer: rastros de auditoría de agentes de IA

Lista de verificación para una única acción de agente

Antes de conceder autonomía, responda:

• ¿Es la acción solo de lectura?
• ¿Cambia el estado del negocio?
• ¿Crea costo o un compromiso?
• ¿Es el resultado visible externamente?
• ¿Involucra datos personales o confidenciales?
• ¿Cambia roles, permisos o configuración de seguridad?
• ¿Es fácil de revertir?
• ¿El recurso objetivo es inequívoco?
• ¿Puede un reintento ejecutar la acción dos veces?
• ¿Puede el sistema mostrar una vista previa concreta antes de la ejecución?
• ¿La aprobación estará vinculada a los parámetros exactos?
• ¿Se puede verificar el estado resultante después de la ejecución?

Si una acción combina varias características de alto riesgo, un solo “OK” puede ser un control demasiado débil.

Ejemplo trabajado: una empresa de servicios envía un informe al cliente

Considere un flujo de trabajo propuesto en lugar de una implementación reportada. Un agente recupera registros aprobados, compara plazos y prepara un informe. El propietario de la cuenta sigue siendo responsable del contenido. El propietario del proceso define los datos permitidos y quién puede autorizar la entrega.

La preparación del borrador puede ejecutarse dentro del límite preaprobado. Antes de enviar, muestre al cliente, la dirección exacta del destinatario, asunto, mensaje y archivos adjuntos, junto con la versión de los datos de origen. El revisor debe poder inspeccionar el documento directamente. Confiar solo en el resumen del modelo debilita la revisión.

La aprobación cubre ese paquete específico. Añadir un destinatario, reemplazar un adjunto o cambiar una recomendación material invalida la aprobación. Una regla previamente definida puede permitir una corrección ortográfica, pero eso no debe convertirse en permiso para cambiar el sentido. El propietario del proceso define los cambios materiales; el componente de ejecución hace cumplir el límite.

Qué debe contener el registro de aprobación

Asocie la aprobación con la persona, rol, inquilino, herramienta, recurso objetivo, versión de datos, parámetros, vencimiento e identificador de tarea. Distinga entre propuesto, pendiente, aprobado, ejecutándose y resultados inciertos. El operador debe saber si un clic prepara una acción o la dispara.

Un hash de parámetros ayuda a detectar sustituciones. No prueba que una persona haya leído la vista previa. Una interfaz clara y un revisor autorizado siguen siendo esenciales. Una persona sin permiso para conceder acceso de administrador no debe obtener ese permiso a través de un cuadro de diálogo de aprobación de agente.

Para lotes, muestre el recuento de objetos, excepciones materiales y efecto total. Una aprobación puede cubrir un lote definido con precisión. No puede cubrir objetos adicionales arbitrarios seleccionados después de la aprobación. Esto reduce diálogos repetidos sin perder control del alcance.

Gestionar la ejecución incierta antes de reintentar

Un proveedor puede ejecutar una solicitud aunque su respuesta nunca llegue al agente. La falta de confirmación no es prueba de fallo. Reintentar puede enviar un segundo correo, crear un documento duplicado o generar coste adicional. Primero verifique el identificador de solicitud y el estado del proveedor.

Donde se admiten claves de idempotencia, asócielas a la operación y reutilícelas para la misma solicitud. De lo contrario, implemente detección de duplicados o pida al operador que decida tras comprobar el estado. Registre un resultado incierto con honestidad. Hacer clic dos veces no resuelve un resultado desconocido.

El silencio no es aprobación

Asigne un suplente y un canal de notificación para cada proceso. El vencimiento sin respuesta bloquea la operación en puerta. El agente puede seguir preparando otro trabajo autorizado y de bajo riesgo; no debe inferir consentimiento por silencio o por una fecha límite comercial.

Defina la parada de emergencia por separado. El permiso para detener un flujo de trabajo incorrecto puede ser más restringido que el permiso para iniciarlo. Preserve el estado de ejecución y la lista de acciones completadas. Restaurar la configuración no puede recuperar un mensaje al cliente que ya haya sido leído.

Verificar si la revisión cambia decisiones

Rastree correcciones, rechazos, tiempos de espera e intentos de ejecutar parámetros materialmente cambiados. Compare los tipos de operación por separado. Una aprobación lenta de comunicaciones al cliente no debe impedir la preparación autónoma de tareas internas.

Si cada propuesta se aprueba inmediatamente durante semanas, revise una muestra con el propietario del proceso. La política puede ser demasiado amplia, o las vistas previas pueden omitir información útil. Un alto recuento de aprobaciones no es evidencia de seguridad.

Mañana, seleccione una acción externa. Construya su vista previa, identifique a un revisor autorizado, defina vencimiento y verifique que cambiar el destinatario invalida la aprobación. Confirme que el rechazo no produce efecto externo.

Recomendaciones y límites de fuentes

OWASP cubre controles de acciones de alto impacto e integridad de aprobaciones. Las guías de autorización de transacciones abordan la verificación del lado del servidor de datos de transacciones significativas. NIST AI RMF es una guía voluntaria de gestión de riesgos. Nuestra matriz A‑D es una recomendación de ingeniería, no una obligación legal de aprobar cada acción de IA. La documentación interna del MCP de Ads, fechada el 28 de julio 2026, describe el diseño de control citado; no prueba de forma independiente la operación en producción para un cliente.

Límite

Este modelo de clasificación es nuestra práctica de ingeniería, no asesoramiento legal ni un estándar formal de evaluación de riesgos. Procesos regulados, médicos, financieros o críticos para la seguridad pueden requerir controles más estrictos.

Véase también MCP y agentes de IA: diseñando herramientas más seguras y Mínimo privilegio para agentes de IA.

Fuentes

• OWASP AI Agent Security Cheat Sheet. Accedido: 2026-10-02.
• OWASP Transaction Authorization Cheat Sheet. Accedido: 2026-10-02.
• NIST AI Risk Management Framework. Accedido: 2026-10-02.
• Google Ads Help — About spending limits. Accedido: 2026-10-02.