Un agente no necesita pedir permiso para cada paso. Sí debe detenerse antes de una acción cuyo error sea difícil de deshacer, afecte a una persona o cambie dinero, datos, sistemas o una decisión comercial. Una buena aprobación muestra qué quiere hacer, con qué datos, qué cambiará y quién puede aceptarlo, corregirlo o cancelarlo.
La guía de OpenAI para construir agentes recomienda intervención humana cuando el sistema supera sus límites de fallo o pretende ejecutar una acción sensible, irreversible o de alto impacto. No significa que todas las tareas necesiten el mismo control. Significa decidir de antemano dónde termina la autonomía y dónde empieza la responsabilidad humana.
El problema no es que el agente actúe; es que nadie pueda detenerlo con criterio
Un agente puede preparar un borrador de correo, reunir datos de un CRM, clasificar una incidencia o proponer un siguiente paso. El problema aparece cuando pasa de preparar a ejecutar sin que nadie haya definido el alcance de esa decisión.
- El equipo descubre un correo, un cambio de CRM o una orden cuando ya se ha enviado o aplicado.
- La persona que aprueba recibe un texto sin contexto y solo puede pulsar «sí» o «no».
- El agente reintenta una acción fallida hasta consumir tiempo, coste o credibilidad.
- Nadie puede reconstruir qué datos utilizó, qué herramienta llamó o por qué entendió que tenía permiso.
- Se añade una revisión manual a todo y el sistema deja de ahorrar trabajo porque genera una cola de aprobaciones sin prioridad.
La solución no es revisar todo. Es separar las acciones que el agente puede preparar, las que puede ejecutar con límites y las que requieren una decisión explícita de una persona.
Cinco preguntas antes de definir un punto de aprobación
Evalúa una acción concreta, no una etiqueta amplia como «ventas» u «operaciones». «Enviar este email a un cliente», «modificar el estado de una oportunidad» o «aprobar un reembolso» son acciones que se pueden discutir y medir.
| Pregunta | Si la respuesta es sí | Diseño recomendado |
|---|---|---|
| ¿El error es difícil de deshacer? | Un correo, una cancelación o una modificación tiene consecuencias fuera del sistema. | Mostrar una propuesta y pedir aprobación antes de ejecutar. |
| ¿Afecta a dinero, datos sensibles o derechos de una persona? | El daño potencial no es solo técnico. | Limitar permisos, registrar la decisión y escalar a un responsable. |
| ¿El agente interpreta información incompleta o ambigua? | Puede elegir mal aunque el flujo habitual funcione. | Pedir aclaración o enviar el caso a revisión, no improvisar. |
| ¿La acción usa una herramienta con permisos amplios? | Un fallo pequeño puede tocar más registros de los necesarios. | Aplicar mínimo privilegio y una vista previa del cambio. |
| ¿Existe una señal objetiva de que el resultado es correcto? | Se puede comprobar el resultado después. | Automatizar con límites y revisar excepciones o muestras. |
Estas preguntas no sustituyen una evaluación específica de privacidad, seguridad, relaciones laborales, finanzas o regulación. Sirven para evitar una decisión más básica y frecuente: dejar que un agente haga una acción relevante porque «hasta ahora ha funcionado».
Cuatro niveles sencillos de autonomía
- Preparar. El agente reúne información y propone una acción, como un borrador de respuesta o los campos que faltan en una solicitud. La persona conserva la ejecución.
- Ejecutar con límites. El agente resuelve casos repetitivos dentro de una regla clara, como etiquetar una incidencia con datos completos. Define alcance, registro y salida ante excepción.
- Pedir aprobación. El agente presenta una acción antes de ejecutarla, como enviar un mensaje externo o cambiar una etapa sensible del CRM. La revisión necesita vista previa, evidencia, responsable y caducidad.
- Escalar y parar. El agente no sigue sin una persona responsable ante un pago, borrado, publicación, excepción de seguridad o decisión que afecta a una persona. Deja una pausa inmediata, contexto y ruta de escalado.
El nivel correcto depende del proceso. Una actualización de CRM puede ser rutinaria en una empresa y crítica en otra. Por eso el diseño empieza por el resultado y el riesgo, no por una lista fija de herramientas prohibidas.
Qué debe ver una persona antes de aprobar
Una aprobación que solo dice «¿continuar?» traslada el trabajo de pensar a quien revisa. Para reducir riesgo sin crear otra tarea opaca, el agente debería mostrar:
- Acción exacta: qué correo enviará, qué registro cambiará o qué herramienta llamará.
- Motivo y evidencia: qué información llevó a proponerla y qué falta si existe incertidumbre.
- Alcance: a quién afecta, qué campos cambia y qué volumen está implicado.
- Alternativas y reversión: qué ocurre si se rechaza, qué se puede deshacer y hasta cuándo.
- Responsable y traza: quién aprobó, cuándo, con qué versión de datos y qué hizo el sistema después.
El patrón human-in-the-loop del Agents SDK de OpenAI permite pausar una ejecución, presentar la intervención, aprobar o rechazar la llamada y reanudar el flujo. El detalle técnico depende de la plataforma; el principio operativo no: una aprobación debe ser una decisión informada y recuperable.
Diseña también cuándo parar sin pedir permiso
Hay casos en los que el agente no debería buscar una aprobación rápida: debería detenerse y escalar. Por ejemplo, cuando no reconoce la identidad o el permiso de quien pide una acción, faltan datos esenciales, supera el número de reintentos acordado o sale de la política definida.
Define antes del despliegue un máximo de reintentos, tiempo y coste; las herramientas y datos permitidos por rol; los eventos que obligan a parar; la persona o equipo que recibe la excepción; la evidencia que debe quedar registrada y cómo se corrige la causa antes de reactivar el flujo.
Esto evita dos extremos igual de caros: un agente que actúa sin control y una cola de aprobaciones que hace que cada caso tarde más que antes.
Ejemplo: un agente que prepara una respuesta comercial
Una empresa recibe solicitudes con datos incompletos. El agente puede leer la petición, extraer lo que falta, consultar información permitida y preparar una respuesta. No debería enviar una propuesta, modificar condiciones comerciales o crear un compromiso en el CRM sin una política clara.
El primer piloto puede funcionar así: el agente prepara el borrador, señala los datos que faltan y propone la siguiente acción. Una persona revisa los primeros casos y aprueba solo cuando hay información suficiente. El equipo mide cuántas respuestas se aceptan sin edición sustantiva, cuántas se escalan, cuánto tarda el ciclo completo y qué excepciones se repiten.
El resultado no es «el agente procesó cien correos». Es una respuesta comercial correcta, trazable y aprobada con menos trabajo de revisión que antes.
Cómo saber si el control humano está ayudando
El control humano es útil si reduce errores relevantes y enseña al equipo dónde debe mejorar el sistema. Registra al menos decisiones aprobadas, rechazadas y modificadas; motivos de rechazo; tiempo de espera y revisión; reintentos; acciones detenidas por límite; resultados correctos, correcciones y reversiones posteriores.
No trates el número de aprobaciones como éxito. Muchas aprobaciones pueden indicar que el agente no tiene límites claros o que la persona revisa sin información suficiente. El éxito es que el proceso termine mejor, con riesgo controlado y evidencia para ajustar el siguiente cambio. La guía de ROI de agentes de IA explica cómo incluir revisión, retrabajo y coste total en esa decisión.
Cuándo pedir un diagnóstico
Tiene sentido revisar el proceso cuando el equipo ya tiene agentes que usan correo, CRM, documentos o herramientas operativas, pero no sabe qué permisos darles, qué acciones deben detenerse o cómo demostrar que el resultado es fiable. DÍA UNO mapea el proceso, los roles humanos y digitales, los límites, las aprobaciones y la trazabilidad antes de aumentar autonomía o añadir otro agente.
Si todavía no sabes qué proceso conviene ordenar primero, empieza por el test de madurez. Si ya tienes un flujo concreto que necesita límites y un responsable claro, agenda un diagnóstico de orquestación.
Fuentes y límites
Esta guía traduce principios operativos de fuentes públicas a preguntas de diseño para una empresa. No es una política de cumplimiento ni sustituye una evaluación legal, de seguridad o de protección de datos para un caso concreto.