“Que el agente lo haga solo” suena eficiente hasta que la acción es enviar una oferta equivocada, cancelar un pedido o conceder acceso a un expediente. La autonomía no es una propiedad general del agente. Se concede acción por acción.
Un mismo sistema puede buscar información sin permiso previo, preparar un correo para revisión y exigir aprobación para enviarlo. Diseñar esos niveles es más sensato que elegir entre “automático” y “humano en el circuito”.
Cinco niveles, no un interruptor
Una escala sencilla ayuda a conversar con negocio y riesgo:
| Nivel | Comportamiento | Ejemplo |
|---|---|---|
| 0. Recomienda | Explica opciones; no modifica sistemas | Priorizar incidencias |
| 1. Prepara | Crea un borrador o simulación | Redactar una respuesta |
| 2. Ejecuta con aprobación | Pausa antes de actuar | Emitir un reembolso |
| 3. Ejecuta con supervisión | Actúa dentro de límites y se revisa por muestreo | Clasificar tickets |
| 4. Ejecuta por excepción | Opera y escala solo anomalías | Reconciliar operaciones de bajo importe |
El nivel puede variar por importe, cliente, país o tipo de dato. Una devolución de 15 euros quizá sea automática; una de 1.500, no.
Impacto y reversibilidad
La primera pregunta es qué sucede si el agente se equivoca. Dinero, derechos, seguridad, reputación y obligaciones regulatorias elevan el impacto. Después preguntamos si la acción se puede deshacer de forma completa y rápida.
Enviar una propuesta interna es reversible. Publicarla en redes no lo es del todo, aunque pueda borrarse. Leer un documento autorizado tiene poco impacto inmediato; copiarlo a un sistema externo cambia la exposición. Estas diferencias deben expresarse en controles técnicos, no solo en instrucciones.
El marco de NIST pide relacionar el contexto, la tolerancia al riesgo, las mediciones y las decisiones de continuar o detener (NIST AI RMF). La autonomía es una de esas decisiones y debe revisarse cuando cambia el contexto.
Detectabilidad y tiempo para corregir
Un error visible antes de producir efecto admite más autonomía. Si una consulta genera un total que puede compararse con una regla contable, el sistema puede bloquear inconsistencias. Si el fallo solo aparecerá meses después, la supervisión por muestreo ofrece poca protección.
También importa el tiempo disponible. Un agente de voz debe decidir en segundos; una revisión contractual puede esperar una aprobación. Si la persona no puede responder dentro del proceso, colocar un botón de aprobación crea un cuello de botella, no control.
La solución puede ser cambiar la acción: preparar, agrupar o programar, en lugar de ejecutar en tiempo real.
Datos, permisos y alcance
Cuanto más sensible sea la información y más amplios los permisos, menor debería ser la autonomía inicial. Un agente no necesita acceso de administrador para actualizar un campo del CRM. Debe actuar con identidad propia o delegada, permisos mínimos y registros atribuibles.
El alcance limita consecuencias. Topes de importe, destinatarios permitidos, plantillas aprobadas, horarios y entornos restringidos convierten una acción abierta en una operación gobernable. Las reglas se aplican fuera del modelo.
Una instrucción que dice “solo reembolsa importes pequeños” es ambigua. Una herramienta que rechaza valores superiores a 100 euros es un control.
Evidencia antes de ampliar
La autonomía debe ganarse con resultados en producción: tasa de éxito, errores por gravedad, escalados, correcciones y comportamiento en excepciones. No basta con precisión media. Necesitamos saber si el agente reconoce cuándo no sabe.
Una progresión razonable empieza en modo sombra: el agente propone y comparamos con la decisión humana. Después prepara borradores, ejecuta con aprobación y, para subconjuntos estables, pasa a supervisión por muestreo. Cada transición tiene umbrales y posibilidad de retroceso.
La revisión humana tampoco es infalible. Si aprueba cientos de acciones idénticas, aparecerá fatiga de automatización. Es mejor concentrar la atención en casos ambiguos, de alto impacto o fuera de distribución.
Diseñar una aprobación que sirva
El SDK de agentes de OpenAI permite pausar una ejecución ante llamadas sensibles, guardar el estado y reanudar tras aprobar o rechazar (OpenAI Agents SDK). El mecanismo técnico es solo la mitad.
La persona debe ver qué acción se propone, sobre qué objeto, con qué parámetros, qué evidencia la respalda y qué ocurrirá al aprobar. También necesita poder modificar o rechazar con una razón. Una alerta que dice “el agente quiere usar execute_action” traslada el riesgo sin aportar contexto.
La aprobación debe ocurrir justo antes de la consecuencia. Si se pide al inicio de un trabajo de veinte pasos, el agente puede terminar ejecutando algo que el revisor nunca vio.
El coste de supervisar también cuenta
La supervisión no es gratuita. Una aprobación de dos minutos aplicada a mil operaciones consume más de treinta horas y puede borrar el ahorro del proyecto. Por eso el diseño económico debe incluir tiempo de revisión, escalados y correcciones, no solo inferencia y licencias.
Esto no justifica retirar controles antes de tiempo. Obliga a mejorar su precisión. Podemos agrupar operaciones homogéneas, mostrar solo las diferencias relevantes, automatizar comprobaciones deterministas y reservar la decisión humana para aquello que realmente exige juicio. Si una persona tiene que releer todo el expediente para aprobar, el agente apenas ha cambiado el trabajo.
También conviene fijar un objetivo para el propio control: cuánto tarda, qué porcentaje rechaza y cuántos fallos detecta que habrían tenido consecuencia. Si nunca cambia una decisión, quizá está mal situado. Si cambia demasiadas, el nivel de autonomía es prematuro o la propuesta del agente necesita mejorar.
Una política por acción
Para cada herramienta o acción registramos:
- impacto máximo y reversibilidad;
- datos que lee y escribe;
- límites deterministas;
- nivel de autonomía por segmento;
- condiciones de aprobación o escalado;
- evidencia exigida;
- métricas y responsable de revisión;
- mecanismo de parada y reducción de nivel.
Así evitamos que una ampliación aparentemente menor —por ejemplo, añadir una herramienta de envío— cambie de hecho el perfil de riesgo de todo el agente.
La pregunta correcta no es cuánta autonomía “merece” la IA. Es qué autoridad necesita para crear valor en este paso y cuál es la menor autoridad que lo permite. A menudo, quitar una sola acción irreversible hace que el resto del sistema pueda avanzar mucho más rápido.
Preguntas frecuentes
¿Human in the loop significa aprobar todo?
No. Puede revisar excepciones, muestras o acciones de alto impacto. Aprobar cada paso reduce velocidad y suele degradar la atención.
¿Cuándo usamos modo sombra?
Cuando podemos comparar propuestas con decisiones reales sin que el agente actúe. Es útil para construir evidencia y descubrir casos límite.
¿Puede bajar la autonomía?
Sí. Incidentes, cambios de modelo, nuevas fuentes o degradación de métricas deben activar límites más estrictos o volver a aprobación.
¿Quién define el nivel?
El propietario del proceso junto con tecnología y las funciones de riesgo correspondientes. El proveedor del modelo no conoce la consecuencia empresarial.
¿Cómo medimos si la supervisión funciona?
Observe rechazos, correcciones, tiempo de decisión, errores que atraviesan el control y fatiga del revisor. Un 100 % de aprobaciones puede ser una señal de control inútil.