Humanos en el circuito para agentes de IA: cómo diseñar aprobaciones que reduzcan riesgo sin bloquear el trabajo

El problema: «un humano aprueba» no define un control suficiente

Un agente capaz de consultar sistemas internos, modificar registros, enviar comunicaciones o iniciar transacciones no deja de ser riesgoso porque exista una persona en algún punto del flujo. La supervisión solo funciona si la intervención humana es significativa: la persona debe poder entender la decisión propuesta, impedirla, corregirla o detener el proceso antes de que produzca un efecto que exceda la autonomía aceptada.

La frase «requiere aprobación humana» suele ocultar preguntas de diseño decisivas. No dice qué componente se aprueba —un objetivo, un plan, una acción concreta o un lote—; tampoco identifica a la persona con autoridad para aprobar, la información disponible, el tiempo máximo de respuesta ni el comportamiento por defecto ante el silencio. Sin esas definiciones, la aprobación puede convertirse en una formalidad o, en el extremo opuesto, en una cola que impide que el flujo aporte valor.

Conviene tratar la aprobación como un control de decisión, no como una interfaz. El control debe conectar una clase de acción con un nivel de riesgo, un responsable, un conjunto mínimo de evidencias, una regla de ejecución y un registro auditable. Los permisos técnicos siguen siendo necesarios: una aprobación no debería ampliar los privilegios del agente ni sustituir la autorización del sistema de destino.

Este enfoque complementa el diseño general de agentes que se estudia en la sección de aprendizaje, y debe coordinarse con las decisiones de evaluación y descubrimiento de herramientas. Sin embargo, el alcance aquí es más concreto: decidir dónde interviene una persona en una acción de un agente y cómo demostrar después que esa intervención fue efectiva.

Tres modalidades que no deben confundirse: aprobación previa, revisión posterior y parada de emergencia

La aprobación previa suspende una acción antes de que produzca un efecto externo. Es el patrón apropiado cuando el impacto potencial es elevado, la reversión es limitada, se tratan datos sensibles o aún no hay suficiente evidencia de que el agente actúa de forma fiable en ese caso. Su coste es el tiempo de espera y la carga del revisor, por lo que no debería imponerse indiscriminadamente.

La revisión posterior permite ejecutar una acción dentro de límites predeterminados y examinar después una muestra, una alerta o el conjunto de resultados. Es adecuada cuando el daño es acotado y reversible, existe un mecanismo de corrección probado y la organización puede detectar efectos no deseados con rapidez. No equivale a ausencia de control: requiere registros completos, umbrales de alerta, responsables de seguimiento y capacidad real de revertir.

La parada de emergencia es un mecanismo separado. Debe permitir pausar una ejecución concreta, deshabilitar una integración o retirar temporalmente la autonomía de una clase de acciones. Es necesaria incluso en flujos con aprobación previa, porque pueden aparecer incidentes sistémicos, señales de manipulación o un cambio en el contexto que haga inadecuado continuar. Las guías de gestión de riesgo agéntico recomiendan controles para guiar, corregir e interrumpir comportamientos autónomos, especialmente ante acciones de alto impacto o entradas ambiguas.

También existe una intervención de aclaración: el flujo se pausa para pedir información que falta, pero no para autorizar una acción ya bien especificada. Separarla de la aprobación evita que una respuesta informativa se interprete por error como consentimiento para ejecutar. Algunas plataformas de flujo de trabajo implementan pasos humanos que pueden suspender una ejecución pendiente y pedir una revisión o información adicional; el patrón técnico no determina por sí mismo la política de riesgo.

Construir una matriz de decisión: impacto, reversibilidad, sensibilidad, alcance y confianza empírica

No existe una lista universal de acciones que siempre requieran aprobación. La clasificación debe partir de la acción concreta y de su contexto. En una organización, actualizar una etiqueta interna puede ser inocuo; en otra, el mismo cambio puede activar una exclusión de servicio o alterar un registro regulado. Por ello, la matriz debe documentar el efecto que la acción produce en el sistema de destino, no solo el nombre de la herramienta.

Evalúe al menos cinco dimensiones. El impacto es la magnitud del perjuicio posible para personas, clientes, operación, finanzas o cumplimiento. La reversibilidad mide si se puede deshacer el efecto de manera completa, segura y con un coste razonable. La sensibilidad cubre los datos que se consultan, revelan o transforman. El alcance considera volumen, destinatarios, sistemas y duración. Por último, la confianza empírica no es una impresión sobre el modelo: es evidencia obtenida de pruebas y operación comparable de que el agente identifica correctamente el caso, propone parámetros válidos y no omite condiciones relevantes.

Una puntuación puede ayudar a ordenar decisiones, pero no debe automatizar una conclusión sin reglas de veto. Por ejemplo, una transacción irreversible o un acceso a datos especialmente sensibles puede exigir aprobación aunque la acción tenga alcance unitario y el agente haya rendido bien en pruebas. Del mismo modo, una acción de bajo impacto puede pasar a revisión previa si se presenta en un contexto anómalo, si el agente usa una herramienta nueva o si las señales de validación no están disponibles.

El resultado de la matriz debería ser una de cuatro políticas: ejecución automática dentro de límites; aprobación previa por una persona responsable; doble aprobación con roles distintos; o prohibición de ejecución por el agente. La última categoría no indica necesariamente que la tarea esté vetada para la organización, sino que requiere un procedimiento humano o una integración distinta.

Diseñar la solicitud de aprobación para que sea revisable

Un revisor no debería tener que reconstruir el razonamiento completo del agente ni confiar en una explicación persuasiva para tomar una decisión. La solicitud debe presentar los hechos y los límites de la acción de forma verificable. Su objetivo es permitir detectar errores en el destinatario, el alcance, los datos, la autorización o la consecuencia prevista.

Incluya el objetivo operativo, la acción exacta que se pretende ejecutar, la herramienta o sistema de destino, los parámetros vinculantes, los datos que se consultarán o revelarán y una previsualización del efecto. Cuando sea posible, presente la alternativa más segura o menos intrusiva, como guardar un borrador en vez de enviar, limitar el lote o solicitar una aclaración. Indique también qué ocurrirá si la persona rechaza, modifica o no responde.

La interfaz debe distinguir con claridad entre aprobar la acción tal como está definida, pedir cambios y rechazarla. Un campo de texto libre puede ser útil para una excepción, pero no debe permitir que una instrucción ambigua se convierta en autorización amplia. Si el revisor modifica un parámetro esencial, el agente debe generar una nueva propuesta o ejecutar un flujo determinista validado; no debe reinterpretar libremente la modificación.

Una buena solicitud también declara la procedencia del contexto: qué fuentes internas o entradas del usuario sustentan la propuesta, qué comprobaciones se realizaron y qué incertidumbres siguen abiertas. Mostrar esa información no significa exponer datos innecesarios al revisor. La visibilidad debe respetar la minimización de datos y las restricciones de acceso del propio rol.

Asignar responsables, suplencias y escalados

La persona que revisa debe tener autoridad real sobre el efecto de la acción. Un responsable de operaciones puede aprobar una actualización de inventario dentro de su ámbito, mientras que el acceso a datos personales puede requerir a un propietario de datos o un rol de seguridad. Asignar revisores solo por disponibilidad suele producir aprobaciones mecánicas o rechazos por falta de contexto.

Documente un propietario de la política para cada clase de acción, los roles autorizados a aprobar y las condiciones en que se exige separación de funciones. La doble aprobación tiene sentido cuando una sola persona no debería controlar por completo una decisión: por ejemplo, un rol conoce la necesidad operativa y otro valida el riesgo de cumplimiento. No debe usarse como respuesta automática a toda incertidumbre, porque duplicar revisiones sin objetivos diferenciados puede aumentar demora sin aumentar detección.

Defina suplencias con el mismo nivel de autoridad, pero evite reenviar automáticamente una solicitud a muchas personas. Una cola con responsables, plazo y escalado explícitos es más auditable. La solicitud debe expirar si cambian las condiciones que la sustentan, como la vigencia de un dato, el estado de un caso o el contenido de una integración.

Los marcos de gestión de riesgos de IA recomiendan asignar roles, responsabilidades y autoridades, documentar el riesgo y mantener monitorización posterior al despliegue. En un sistema con agentes, esa asignación debe cubrir tanto la decisión de permitir una acción como la capacidad de intervenir ante un incidente.

Gestionar silencios, rechazos y desacuerdos sin abrir vías de elusión

El silencio no es aprobación. La regla por defecto debería ser no ejecutar cuando una acción espera autorización y el plazo vence, salvo que una política documentada establezca una acción segura alternativa. Por ejemplo, un agente puede guardar un borrador, crear una tarea o solicitar datos adicionales, pero no convertir la ausencia de respuesta en permiso para enviar, cambiar o divulgar.

Un rechazo debe tener una semántica definida. Puede cerrar el caso, devolverlo al agente con parámetros explícitos que debe respetar, o derivarlo a una persona para ejecución manual. Es importante impedir que el agente reintente la misma acción con una formulación superficialmente distinta para obtener una aprobación nueva. Agrupe reintentos equivalentes, mantenga el vínculo con el rechazo anterior y exija una diferencia material identificable.

Los desacuerdos entre aprobadores también necesitan una salida: prevalencia de un rol de riesgo, remisión a un responsable de caso o bloqueo hasta una decisión humana con autoridad superior. El sistema debe conservar las decisiones y sus fundamentos operativos, sin atribuir certeza a una explicación generada por el agente.

Después de aprobar, valide que el artefacto ejecutado coincide con el aprobado. Compare identificador de acción, versión del plan, parámetros, destinatarios, herramientas y resultado. Si cualquiera de esos elementos cambia, solicite una aprobación nueva o aplique una ruta de cambio previamente autorizada y estrechamente limitada.

Patrones por tipo de acción y límites de ejecución

Para comunicaciones externas, separe la generación del borrador del envío. Puede ser razonable automatizar la clasificación y la preparación cuando el contenido queda interno; el envío requiere un umbral más alto si afecta a clientes, compromete una posición contractual o contiene datos sensibles. Los cambios de destinatario, idioma, adjuntos o listas de distribución deben tratarse como cambios materiales.

En cambios de código o configuración, una revisión humana del contenido no sustituye los controles del ciclo de entrega. La aprobación debe estar ligada a una versión identificable, pruebas disponibles, entorno de destino y plan de reversión. Un agente no debería ampliar el despliegue desde un entorno de prueba a producción mediante una aprobación obtenida para una validación limitada.

En actualizaciones de registros, establezca qué campos puede modificar el agente, qué fuentes son admisibles y cuándo debe mostrar la diferencia entre el valor actual y el propuesto. Las actualizaciones masivas requieren un control específico de alcance, criterios de selección y mecanismo de deshacer. Para acceso a datos, aplique mínimo privilegio, autorización en el sistema de destino y ejecución en el contexto autorizado; una aprobación en la capa del agente no debe conceder acceso que el sistema de origen deniega.

Las transacciones con impacto financiero, legal o físico suelen requerir una política restrictiva. La clasificación depende del contexto y de los controles existentes, pero la irreversibilidad, la posible afectación a terceros y la dificultad de reparación son señales fuertes para exigir doble aprobación o excluir al agente de la ejecución. Las recomendaciones de seguridad sobre agencia excesiva destacan el mínimo privilegio, la autorización en el sistema de destino, la supervisión de acciones de alto impacto y el registro de actividad.

Medir si el control detecta errores reales y ajustar la autonomía con evidencia

La existencia de aprobaciones no demuestra que el control funcione. Mida cuántas propuestas se rechazan o modifican por errores materiales, qué tipos de errores se detectan, cuántas acciones aprobadas deben revertirse y cuánto tarda la cola. Segmente estas métricas por clase de acción, integración, versión del flujo y responsable, porque un promedio global puede ocultar un problema concentrado.

La tasa de aprobación por sí sola es ambigua. Una tasa muy alta puede reflejar propuestas correctas y de bajo riesgo, pero también fatiga, falta de contexto o presión por despejar la cola. Investigue señales combinadas: aprobaciones con tiempos inusualmente breves, comentarios repetitivos, discrepancias encontradas en revisión posterior, tasa de anulaciones y diferencias entre revisores. Las muestras de calidad y la revisión de casos negativos ayudan a distinguir eficiencia de automatización indebida.

La confianza del agente debe actualizarse con resultados observados, no con una afirmación general de rendimiento. Para trasladar una clase de acción de aprobación previa a supervisión posterior, defina de antemano qué evidencia se exigirá: una población de casos comparable, errores materiales por debajo del umbral interno, reversión comprobada, detección posterior dentro del tiempo aceptable y ausencia de cambios relevantes en el modelo, herramientas o datos. Si cambian esos elementos, reevalúe la política.

Registre una traza que permita reconstruir el caso: solicitud original, contexto permitido, plan, acción propuesta, versión del agente y de las herramientas, aprobador, decisión, hora, parámetros ejecutados, respuesta del sistema de destino y resultado posterior. El registro debe ser protegido y accesible solo a los roles autorizados; recopilar más contexto del necesario puede crear un riesgo adicional de privacidad o seguridad.

Plan de implantación y checklist verificable de lanzamiento

Empiece por un flujo acotado, con una única clase de acción y un sistema de destino donde sea posible observar el resultado y revertirlo. Inventarie las acciones del flujo, no solo sus herramientas: consultar, redactar, actualizar, enviar, eliminar, escalar y ejecutar pueden requerir controles diferentes. Para cada una, describa el efecto, los permisos técnicos, los límites de parámetros y el responsable de la política.

Antes del despliegue, pruebe casos normales, entradas ambiguas, solicitudes maliciosas, herramientas que devuelven errores y cambios de parámetros después de aprobar. Verifique especialmente que el agente no puede ejecutar una acción distinta de la aprobada, que una solicitud expirada no se ejecuta y que la parada de emergencia tiene efecto sobre ejecuciones pendientes y nuevas.

Realice una fase controlada con evidencia suficiente para detectar patrones, sin prometer que una cantidad fija de casos sea válida para todos los riesgos. Revise semanalmente los rechazos, las anulaciones, los tiempos de espera, las solicitudes sin respuesta y los incidentes. Amplíe autonomía solo para una clase de acción concreta y solo cuando los resultados y los mecanismos de reversión justifiquen el cambio.

La política de aprobaciones es un documento vivo. Debe actualizarse cuando se añaden herramientas, cambian los datos disponibles, se modifica el modelo, se integra un nuevo sistema de destino o aparecen incidentes. La gobernanza debe conservar una versión de la política aplicable a cada ejecución para interpretar correctamente el registro histórico.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.