Un agente de IA necesita aprobación antes de su ejecución cuando la acción propuesta cruza el umbral de autoridad, consecuencia, reversibilidad, datos, novedad, confianza o impacto posterior de una organización. Se pueden permitir acciones de rutina dentro de la autoridad explícita. Una acción permitida con una señal de revisión puede proceder con una advertencia. Una excepción consecuente debe detenerse para un humano autorizado. Se debe detener una acción prohibida, no autorizada, mal formada, obsoleta o no verificable.
Esta guía responde a la pregunta operativa en todos los sectores. Utiliza permitir, advertir, require_approval y bloquear como modelo de decisión práctico para acciones de agentes individuales. La [guía del artículo 14 de la Ley de IA de la UE] (/blog/eu-ai-act-article-14-human-oversight-requirements) cubre la tarea independiente basada en la regulación: implementar las capacidades de supervisión humana necesarias para los sistemas de IA de alto riesgo. Esta guía es información general, actualizada hasta el 28 de julio de 2026, y no reemplaza el asesoramiento legal, de riesgos o técnico.
La regla de aprobación de los cuatro resultados
Evalúe el efecto secundario propuesto antes de que llegue a la herramienta o al sistema posterior. Aplique todas las reglas relevantes y luego conserve el resultado más sólido. Un bloque no puede debilitarse mediante una regla de autorización de contrapartida, y una aprobación requerida no puede desaparecer porque el monto esté por debajo de un umbral financiero.
El resultado describe el comportamiento de ejecución. permitir libera la acción dentro de la autoridad actual. advertir lo libera y crea un seguimiento definido. require_approval mantiene la acción exacta hasta que un humano autorizado decida. bloquear evita que la acción alcance el efecto secundario gobernado.
| Resultado | Usar cuando | Comportamiento de ejecución | Excepciones y precedencia |
|---|---|---|---|
| permitir | La acción es rutinaria, está dentro de la autoridad delegada, tiene pocas consecuencias, es reversible, utiliza datos aprobados, proviene de una versión conocida y tiene un contexto completo. | Ejecutar y conservar el expediente ordinario de actuaciones y políticas. | Se permite anular cualquier activador de bloqueo, aprobación o advertencia. El contexto de identidad, política o evidencia faltante nunca se permite de manera predeterminada. |
| advertir | La acción sigue estando permitida y es reversible, pero está cerca de un umbral, es inusual, se ha observado recientemente o se ha seleccionado para un muestreo de seguridad. | Ejecute, registre la señal y enrute el seguimiento definido sin mantener el efecto secundario. | Utilice require_approval cuando el retraso después de la ejecución dejaría un efecto material o difícil de revertir. Utilice el bloque cuando no exista autoridad o contexto requerido. |
| requiere_aprobación | La acción es material, difícil de revertir, afecta los derechos, está cerca de un límite de autoridad, sensible, novedosa, de baja confianza o capaz de crear un efecto posterior significativo. | Mantenga la acción exacta y el conjunto de parámetros. Reanudar solo después de que un revisor elegible lo apruebe antes de que caduque y el contexto vinculado permanezca actualizado. | Un revisor no puede aprobar una acción prohibida. Una solicitud vencida o modificada sustancialmente requiere una nueva evaluación y una nueva Solicitud de Decisión. |
| bloquear | La acción está prohibida, está fuera de la autoridad, apunta a un límite de datos prohibido, no supera un control obligatorio, conlleva un contexto no válido o no se puede evaluar o evidenciar de forma segura. | Deténgase antes del efecto secundario gobernado y registre el motivo. | Cambiar la acción o política a través del proceso de cambio gobernado. La autoridad innovadora debe ser un camino político separado, con plazos determinados y con su propia evidencia y revisión retrospectiva. |
Mapear los siete insumos de aprobación a la política
Los umbrales pertenecen a la organización propietaria de la acción. Comience con un inventario de acciones y defina bandas comprobables para las siete entradas. El monto financiero por sí solo no es suficiente: un cambio de derecho de valor cero o la divulgación de datos restringidos pueden conllevar más riesgos que una gran transferencia reversible entre cuentas controladas.
Mantenga las entradas como reglas separadas. Una puntuación combinada puede ocultar un hecho decisivo. Un destino prohibido debe permanecer bloqueado incluso cuando todas las demás entradas parecen rutinarias.
| Aporte | Permitir o advertir a la banda | Requerir banda de aprobación | banda de bloque |
|---|---|---|---|
| Riesgo y derechos afectados | Consecuencias bajas dentro del propósito aprobado; advertir sobre una anomalía acotada. | Consecuencia material para el cliente, trabajador, paciente, ciudadano, seguridad o cumplimiento. | Uso prohibido, riesgo residual inaceptable o acción fuera del propósito aprobado. |
| Cantidad o exposición | Dentro de un límite explícito por acción, diario y de destino. | Cerca o por encima de un límite de fabricante, o se cruza un umbral de exposición agregada. | Por encima de la autoridad absoluta, la liquidez, las sanciones o los límites de la contraparte. |
| Reversibilidad | Lectura, borrador, simulación o actualización interna reversible de forma fiable. | Comunicación externa, pago, eliminación, presentación, cambio de derechos o vía de compensación costosa. | No hay un camino de recuperación seguro para las condiciones actuales. |
| Sensibilidad de los datos | Campos aprobados dentro del límite de datos asignado. | Acceso restringido a los datos, divulgación, exportación, riesgo de reidentificación o un nuevo destinatario. | Categoría prohibida, destino, propósito, región o autoridad legal faltante. |
| Novedad y cambio | Versión, herramienta, ruta, destino y patrón operativo conocidos. | Nueva rampa de lanzamiento, primer uso de una herramienta o destino, secuencia inusual o cambio de configuración de material. | Componente no aprobado, destino desconocido o versión no verificable. |
| Confianza y calidad de la evidencia | Banda de confianza validada con evidencia fuente completa y actual. | Puntuación límite, fuentes contradictorias, falta de pruebas no obligatorias o señal de fuera de distribución. | Faltan pruebas obligatorias, están obsoletas más allá de las políticas, aportes mal formados o no hay una base de decisión confiable. |
| Impacto aguas abajo | Efecto interno, acotado y sin compromiso externo. | Crea un compromiso legal, financiero, de seguridad, de cliente, operativo o multisistema. | No se puede confirmar el efecto en cascada o incontrolado, la dependencia prohibida o la contención. |
Humano en el circuito, en el circuito y al mando.
Estas etiquetas describen las disposiciones operativas. Son términos de diseño útiles y no son resultados definidos por la Ley de IA de la UE. Elija el acuerdo que le dé a la persona responsable suficiente tiempo, contexto y autoridad para el riesgo de la acción.
| Acuerdo | papel humano | Mejor ajuste | prueba de control |
|---|---|---|---|
| Humano en el circuito | Decide sobre una acción específica propuesta antes de su efecto secundario. | Acciones consecuentes, difíciles de revertir, excepcionales o que afectan derechos. | La acción permanece en vigor hasta que la persona adecuada revise el contexto vinculado y decida antes de que expire. |
| Humano al tanto | Supervisa la ejecución limitada y puede intervenir, pausar, revertir o escalar. | Actividad material pero reversible con detección confiable y una ventana de intervención probada. | Un simulacro realista demuestra que la persona puede detectar la condición y alcanzar el estado seguro antes de que el daño se vuelva material. |
| Humano al mando | Posee el mandato, la tolerancia al riesgo, la política, los límites operativos, la autoridad de parada, el reinicio y la responsabilidad. | Cada sistema de agente implementado, incluidos los sistemas cuyas acciones rutinarias no reciben revisión individual. | Los propietarios designados pueden cambiar la autoridad, suspender el sistema, encargar una revisión, escuchar apelaciones y probar esas decisiones. |
Utilice la separación entre creador y verificador para acciones consecuentes
El creador crea o patrocina la solicitud. Para una acción de agente, el registro del autor debe identificar al agente, su propietario responsable, el principal solicitante y el efecto secundario exacto propuesto. El verificador es una persona distinta y calificada con autoridad para esa clase de acción. El verificador revisa la evidencia y elige aprobar, rechazar, solicitar cambios o escalar.
Hacer cumplir la separación en el momento de la decisión. Un nombre de grupo en una definición de flujo de trabajo no prueba que la persona que actuó fuera elegible o independiente. Resolver la identidad actual, rol, delegación, conflictos y origen de solicitud cuando se tome la decisión.
- Vincular la solicitud. Hash o vincular de otro modo la acción, los parámetros, el destino, las entradas de la política y la evidencia del revisor para que la aprobación no se pueda reproducir para una solicitud modificada.
- Resolver elegibilidad. Verifique la identidad del revisor, su rol activo, su límite de autoridad, su estado de capacitación y cualquier conflicto o relación con el solicitante.
- Hacer posible un juicio independiente. Muestre los hechos originales, la incertidumbre, las limitaciones, los motivos de las políticas, las alternativas y las consecuencias posteriores sin preseleccionar la aprobación.
- Registre una decisión. Capture la identidad, la instantánea del rol, la decisión, el motivo, la referencia fundamentada, el tiempo y el resumen de evidencia que vio el verificador.
- Revalidar antes del lanzamiento. Rechazar la aprobación obsoleta cuando la acción, evidencia, política, identidad, autoridad, destino o estado comercial relevante haya cambiado.
- Adjunte el resultado. Conserve el recibo de ejecución real y el efecto posterior bajo los mismos identificadores de ejecución y decisión.
Brinde al revisor el contexto necesario para decidir
Una Solicitud de Decisión útil responde a la decisión en una breve narrativa, con detalles estructurados disponibles para su verificación. El revisor debe comprender qué sucederá, por qué la política desvió la acción, qué hechos siguen siendo inciertos, qué autoridad tienen y cuándo la solicitud queda obsoleta.
| Contexto | Contenido mínimo útil | Por qué cambia la decisión |
|---|---|---|
| Acción y consecuencia | Acción exacta, objetivo, parámetros materiales, parte afectada, sistemas posteriores y efecto comercial esperado. | El revisor ve el compromiso que está autorizando. |
| Identidad y autoridad | Solicitante principal, agente, propietario responsable, función de revisor requerida, límite de autoridad y regla de creador-verificador. | El revisor puede comprobar si tanto la solicitud como la decisión están autorizadas. |
| Resultado de la política | Resultado, reglas coincidentes, códigos de motivo, versión de política, valores evaluados y alternativas seguras. | El revisor ve por qué la acción se detuvo y qué restricciones siguen siendo vinculantes. |
| Evidencia e incertidumbre | Referencias de fuentes, actualidad, hechos faltantes o contradictorios, confianza, limitaciones y ayudas de interpretación. | El revisor puede cuestionar la recomendación y reconocer el sesgo de automatización. |
| Tiempo y recuperación | Tiempo solicitado, vencimiento, nivel de servicio, ruta de escalada, reversibilidad, ruta de compensación y procedimiento de estado seguro. | El revisor conoce el plazo de decisión y el coste de la demora o el error. |
Establecer niveles de servicio, vencimiento, delegación y reasignación.
Un nivel de servicio es un objetivo operativo. La caducidad es un límite de autorización. Conjunto tanto de las consecuencias, la reversibilidad, la volatilidad de la evidencia y el tiempo disponible para prevenir el daño. No hay una duración universal que se ajuste a todas las acciones.
Una parada de emergencia debe permanecer inmediatamente disponible para un operador autorizado y no debe esperar detrás de una cola de aprobación. Para solicitudes ordinarias, las bandas de ejemplo siguientes son puntos de partida para un taller de políticas. Reemplácelos con valores específicos del sistema y pruébelos en condiciones reales de dotación de personal.
- Delegación: otorga a una persona designada una clase de acción limitada, un límite de valor, un entorno, un período de vigencia y una ruta de escalada. Preservar quién delegó la autoridad.
- Reasignación: requiere un reemplazo elegible, registra el cesionario anterior y el motivo, y mantiene visible la evidencia original y el vencimiento.
- Caducidad: invalida la capacidad de aprobación. Nunca convierta el tiempo de espera de la cola en una aprobación implícita.
- Estancamiento: vencen anticipadamente cuando cambian los insumos de materiales, la política, la identidad, el destino, la cantidad o los parámetros solicitados.
- Control no disponible: retener o bloquear según la política de cierre fallido de la acción y localizar al operador responsable.
| Clase | Objetivo de respuesta de ejemplo | Comportamiento de caducidad | acción de cola |
|---|---|---|---|
| Contención de emergencia | Acción inmediata del operador; página el rol del incidente responsable. | La autoridad de detención es de corta duración y la recuperación requiere una aprobación actual por separado. | Evite la cola ordinaria a través de la ruta de incidentes regulada y conserve las pruebas de rotura de cristales. |
| Consecuente decisión previa a la ejecución | Minutos u horas, según la ventana de espera segura. | Rechazar la ejecución al vencimiento. Reevaluar y emitir una nueva Solicitud de Decisión. | Escalar antes de la fecha de vencimiento a un verificador igual o más autorizado. |
| Excepción reversible material | Horas dentro del día de funcionamiento. | Caducará cuando la evidencia o el estado del negocio ya no puedan ser tratados como actuales. | Reasignar con historial completo; conservar el cesionario original y el motivo. |
| Revisión de aseguramiento sin bloqueo | Objetivo de día hábil definido. | Cerrar o escalar el elemento de revisión sin cambiar la acción ya permitida. | Realice un seguimiento de la revisión vencida como una falla de aseguramiento. |
Diseñar anulaciones, apelaciones y paradas de emergencia como rutas separadas
Una anulación cambia una decisión o resultado bajo autoridad explícita. Una apelación solicita una función autorizada diferente para revisar una decisión. Una parada de emergencia interrumpe el funcionamiento activo o en cola y lleva el sistema a un estado seguro definido. Combinar los tres en un solo botón de administración oscurece la autoridad, el tiempo y la evidencia.
| Camino | Autoridad y momento | evidencia requerida |
|---|---|---|
| Anular | Autoridad nombrada para la clase de acción, con un motivo y cualquier regla de dos personas. Evalúe antes de que se ejecute la acción modificada. | Resultado original, decisión de reemplazo, referencia de autoridad, código de motivo, justificación, vinculación de la acción, tiempo y estado resultante. |
| Apelar | Un papel independiente de la decisión original cuando la política lo requiera. Definir el estado provisional seguro y el objetivo de respuesta. | Solicitud y decisión original, apelante, fundamentos, revisor de apelación asignado, evidencia considerada, resultado, remedio y notificación. |
| parada de emergencia | El operador autorizado puede actuar inmediatamente. La recuperación sigue una aprobación separada después de que se verifica la contención. | Detener actor, motivo, tiempo, alcance, propagación, trabajo cancelado y en curso, acción de credencial, residuo posterior, estado seguro y aprobación de reinicio. |
Reconocer modos de falla del flujo de trabajo de aprobación
Puede existir una pantalla de aprobación mientras falla el control. Pruebe la ruta completa desde la creación de la solicitud hasta el efecto descendente, incluidas las interrupciones, los reintentos, los picos de carga de trabajo y la recuperación.
- Sello de goma: los revisores aprueban demasiado rápido o repiten razones idénticas. Mida la latencia, la concordancia, las anulaciones y la carga de revisores; utilizar muestras independientes.
- Autoaprobación: el solicitante, el agente patrocinador o el operador en conflicto pueden aprobar. Resolver identidades y conflictos en el momento de la decisión.
- Aprobación obsoleta: la evidencia, el monto, el destino, la política o los parámetros cambian después de la revisión. Vincular y revalidar la solicitud antes de su ejecución.
- Espera huérfana: ningún revisor elegible posee el artículo o la cola lo pierde. Supervise la asignación, la antigüedad, la escalada y el vencimiento como estado de control.
- Repetir o duplicar la ejecución: una aprobación libera varias llamadas o un reintento repite el efecto secundario. Utilice decisiones de un solo uso y claves de idempotencia.
- Efecto descendente parcial: una acción de varios pasos falla después de un compromiso externo. Registre cada efecto y ejecute la ruta de compensación o incidente.
- Evidencia escrita demasiado tarde: el efecto secundario se produce antes de que la póliza o el registro de aprobación sean duraderos. Fallo cerrado cuando no se puede escribir el registro requerido.
- Detención falsa: la interfaz dice detenido mientras los trabajadores, las colas, las credenciales o los reintentos continúan. Pruebe la propagación y concilie cada operación en vuelo.
Ejemplo resuelto: una disposición de crédito sintética
El [Esquema de registro de auditoría del agente de IA] público (/resources/ai-agent-audit-log-schema) incluye un registro sintético completo para un agente de revisión de crédito que propone una actualización de disposición de 24 000 EUR. El ejemplo muestra cómo la aprobación se conecta con el efecto posterior real. Las figuras y las identidades son sintéticas.
| Escenario | Registro observado | Significado del control |
|---|---|---|
| Pedido | Un agente de revisión de crédito propone credit.application.set_disposition para una aplicación tokenizada dentro de un límite de datos crediticios restringido de la UE. | La acción solicitada, el propósito, el recurso, la cantidad, el entorno, la versión del agente, el modelo, el mensaje y las versiones del orquestador están vinculados a una ejecución. |
| Política | La versión de política 4.2.1 coincide con la revisión manual por encima de 20000 y devuelve require_approval con el motivo cantidad_requires_senior_underwriter. | El importe de 24.000 EUR supera el límite del fabricante. La ejecución permanece retenida para el rol de suscriptor senior requerido. |
| Contexto del revisor | La Solicitud de Decisión incluye el contexto de acción exacto, el resultado de la política, el alcance de los datos restringidos, las versiones de los componentes y un resumen de la evidencia presentada. | El verificador puede verificar la solicitud y detectar una posterior sustitución del paquete de pruebas. |
| Expiración | La solicitud se crea a las 09:14:29 UTC y caduca a las 10:14:29 UTC. | La autoridad de aprobación dura una hora. La ejecución después de ese punto requiere una solicitud recién evaluada. |
| Decisión | Un asegurador senior autenticado por el personal lo aprueba a las 09:14:31 UTC con el motivo, evidencia_de_aplicación_verificada y una referencia justificativa. | El registro vincula al revisor, el rol requerido, la decisión, el motivo, el resumen de evidencia y el tiempo. |
| Ejecución | La llamada a la herramienta gobernada comienza después de la aprobación, utiliza una clave de idempotencia y tiene éxito con resúmenes de argumentos y resultados. | La aprobación precede al efecto secundario de la herramienta y sólo puede liberar la acción vinculada. |
| Efecto aguas abajo | El registro bancario central sintético informa credit_disposition_updated con resúmenes antes y después del estado. | La ruta de aprobación lleva un registro explícito de los resultados comerciales después de la decisión política. |
| Evidencia | El linaje ordenado une eventos de solicitud, política, aprobación, herramienta y finalización. El registro vincula los artefactos de políticas y herramientas y lleva un resultado de verificación de integridad válido. | Un auditor puede probar el orden, la identidad, la vinculación de la acción, el resultado y la integridad de los registros. La integridad de las fuentes sigue siendo una prueba de garantía separada. |
Utilice un esquema de evidencia mínima
Utilice identificadores estables y campos legibles por máquina para que un revisor o auditor pueda unir la decisión a la ejecución sin depender de marcas de tiempo o capturas de pantalla. KLA publica un [esquema JSON, ejemplos y verificador] (/resources/ai-agent-audit-log-schema) neutral para este registro.
| grupo de evidencia | Campos mínimos | Pregunta respondida |
|---|---|---|
| Envoltura y alcance | versión_esquema, id_evento, ocurrido_en, grabado_en, secuencia, id_correlación, id_ejecución, organización, entorno, clase de retención | ¿Qué registros y límites operativos están bajo revisión? |
| Actores y versiones | solicitante, agente, propietario_responsable, identidad de servicio o usuario delegado, versión del agente, modelo, mensaje, orquestador | ¿Quién o qué actuó, bajo la responsabilidad de quién, utilizando qué versiones? |
| Acción solicitada | acción, propósito, recurso, límite de datos, cantidad cuando sea relevante, destino, solicitud_en, resumen de argumentos | ¿Qué efecto secundario exacto se propuso? |
| Política | decision_id, id_política y versión, resúmenes de políticas y entradas, permitir o advertir o requerir_aprobación o bloqueo, reglas coincidentes, códigos de motivo, evaluado_at | ¿Por qué el control produjo este resultado? |
| Aprobación | request_id, request_at, expires_at, require_role, resumen de evidencia presentada, revisor, decisión, motivo, referencia fundamentada, decidido_at, reasignación, anulación o apelación cuando se utiliza | ¿Un ser humano elegible decidió sobre la evidencia actual antes de la ejecución? |
| Ejecución y efecto | herramienta y versión, clave de idempotencia, tiempo de inicio y finalización, resumen de resultados, referencias de efectos posteriores, resúmenes antes y después, resultado comercial, reversión o referencia de incidente | ¿Qué se ejecutó y qué cambió fuera del plano de control? |
| Linaje e integridad | ID de eventos ordenados, manifiesto de evidencia y resúmenes de artefactos, tratamiento de privacidad, hash de registros, firma, estado de verificación y códigos de falla | ¿Se puede reproducir el registro, manejarlo correctamente y comprobar si hay cambios? |
Cómo implementa KLA la ruta de control de aprobación
El Plano de control KLA gobierna las acciones de los agentes instrumentados. El motor de políticas KLA evalúa una llamada de herramienta propuesta según las reglas publicadas y devuelve permitir, advertir, require_approval o bloquear. Un resultado require_approval retiene la llamada propuesta y crea una Solicitud de decisión para Decision Desk. Un bloque impide que la llamada gobernada llegue a la herramienta.
Para las solicitudes de decisión del plano de control, Decision Desk verifica el permiso de decisión, el rol de revisor requerido, el estado pendiente, la identidad del solicitante y del creador, y el tiempo de vencimiento. Impide que los solicitantes y creadores registrados decidan su propia solicitud y rechaza aprobar o rechazar acciones después del plazo establecido. Un verificador elegible puede escalar una solicitud vencida. Registra el actor de la decisión, la instantánea del rol, el resultado, el motivo y el tiempo. Estos controles de separación y vencimiento se basan en que la solicitud incluya las identidades actuales del fabricante y una fecha de vencimiento. Asegúrese de que cada ruta de producción los suministre y pruebe la ruta de control total.
Lineage Explorer y Audit Trail exponen los registros de políticas, decisiones humanas y ejecución. Evidence Room puede empaquetar registros seleccionados en un Sealed Evidence Bundle con firmas, hashes de artefactos y una raíz de Merkle que admite comprobaciones de integridad fuera de línea. La organización aún posee la clasificación de acciones, la competencia de los revisores, la dotación de personal, el análisis legal, la instrumentación completa, la integridad de las fuentes, la intervención en todos los trabajadores y sistemas posteriores, y el diseño de estado seguro.
Referencias técnicas
Lea los contratos de componentes y el registro de ejecución unido detrás de la ruta de aprobación que se describe aquí.
Fuentes primarias y frescura.
Revisión de la fuente completada 28 de julio de 2026. [El artículo 14 de la Ley de IA de la UE] (https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14) requiere una supervisión humana efectiva para los sistemas de IA de alto riesgo y el monitoreo de nombres, el conocimiento del sesgo de automatización, la interpretación, el desprecio, la anulación, la reversión, la intervención y las capacidades de interrupción segura. El artículo 26(2) exige que quienes implementan sistemas de alto riesgo asignen la supervisión a personas con la competencia, la capacitación, la autoridad y el apoyo necesarios. Considerando 73 explica el papel de la intervención informada y las limitaciones operativas incorporadas.
El Reglamento (UE) 2026/1744 cambió las fechas de aplicación de las normas de alto riesgo del Capítulo III al 2 de diciembre de 2027 para los sistemas del artículo 6(2) y el Anexo III y al 2 de agosto de 2028 para los sistemas del Artículo 6(1) y el Anexo I. No reemplazó el texto de control del Artículo 14.
El NIST AI RMF Core exige roles diferenciados entre humanos y IA, procesos de supervisión documentados, revisión independiente y mecanismos de apelación, anulación, desmantelamiento, respuesta a incidentes y recuperación. Apéndice C del NIST señala que la necesidad de supervisión humana depende del contexto. El [Principio de IA de la OCDE sobre valores centrados en el ser humano] (https://oecd.ai/en/dashboards/ai-principles/P6) exige la agencia humana y salvaguardias de supervisión apropiadas al contexto y al estado del arte.
La tabla de cuatro resultados, el marco de siete entradas, los ejemplos de nivel de servicio y el esquema de evidencia de esta guía son patrones de implementación. No conllevan ningún umbral legal universal. Vuelva a confirmar la ley aplicable, la orientación regulatoria, las reglas del sector, los hechos del sistema y el texto fuente actual antes de confiar en ellos.
Preguntas frecuentes
¿Qué acciones de los agentes de IA requieren la aprobación humana?
Requerir aprobación cuando una acción es material, difícil de revertir, afecta los derechos, sensible, novedosa, cercana a un límite de autoridad, de baja confianza o capaz de crear un efecto posterior significativo. Bloquear acciones prohibidas, no autorizadas, obsoletas, con formato incorrecto o no verificables.
¿Cuál es la diferencia entre humano en el circuito, humano en el circuito y humano al mando?
El ser humano en el bucle decide una acción específica antes de su ejecución. La persona sobre el bucle monitorea la actividad limitada y puede intervenir dentro de una ventana probada. El ser humano al mando posee el mandato, los límites, las políticas, la autoridad de parada, el reinicio y la responsabilidad del sistema.
¿Cómo debería funcionar la separación entre creador y verificador para un agente de IA?
Identifique al agente, al propietario responsable y al principal solicitante como parte fabricante. Enrute la solicitud vinculada exacta a un verificador calificado distinto. Verifique la identidad, el rol actual, la autoridad, la delegación y los conflictos cuando el verificador lo decida, luego revalide la solicitud antes de la ejecución.
¿Qué contexto necesita un revisor de agentes de IA?
Muestre la acción y consecuencia exactas, la identidad del solicitante y del agente, los límites de autoridad, el resultado y los motivos de la política, la evidencia y la actualidad de la fuente, la incertidumbre y las limitaciones, las alternativas, el vencimiento, la ruta de escalada y la ruta de recuperación.
¿Cuándo debería caducar una aprobación?
La aprobación expirará cuando finalice el período de retención segura o cuando cambien evidencia material, política, identidad, autoridad, destino, monto, parámetros o estado comercial. Una solicitud vencida no debe ejecutarse; evaluar la acción nuevamente y emitir una nueva solicitud.
¿Puede un humano anular una decisión de bloqueo?
Un revisor no debe convertir una acción prohibida en una aprobación dentro de la misma solicitud. Una excepción de emergencia legítima necesita una vía política separada, estrecha y con plazos determinados, con autoridad, razón, evidencia, límites de contención y revisión retrospectiva.
¿Cómo deberían funcionar las apelaciones y las paradas de emergencia?
Dirija una apelación al rol independiente definido por la política y mantenga el sistema en un estado provisional seguro. Deje que un operador autorizado invoque una parada de emergencia de inmediato, registre la propagación y los residuos y solicite una aprobación actual por separado antes de reiniciar.
¿Qué prueba que la aprobación se produjo antes de la ejecución?
Utilice un registro correlacionado con eventos ordenados de solicitud, política, aprobación, herramienta y finalización. Vincule la acción y la evidencia con resúmenes, registre la autoridad del revisor y el vencimiento, use una clave de idempotencia, adjunte el recibo posterior y verifique la integridad del registro.
Conclusiones clave
Un control de aprobación útil le da a cada acción consecuente un resultado claro, mantiene la solicitud exacta en espera cuando se requiere un juicio, le da al verificador suficiente contexto y autoridad, expira las decisiones obsoletas y adjunta el efecto posterior real al registro de evidencia. [Descargue el manual de flujo de trabajo de aprobación de agentes de IA] (/downloads/ai-agent-approval-workflow-playbook.md) para definir las reglas para una acción, luego pruebe la ruta completa en condiciones normales, vencidas, reasignadas, duplicadas, de interrupción y de parada de emergencia.