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 a 8 de octubre 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. |
Matriz de decisiones de aprobación
Escriba una fila por cada clase de acción gobernada. Cada fila responde a ocho preguntas antes de que la primera solicitud llegue a un revisor: qué acción, qué umbral la envía a una persona, quién puede decidir, cuánto tiempo sigue siendo válida la decisión, qué cambios en los datos de entrada la anulan, qué provoca un rechazo, qué ocurre cuando nadie decide y qué evidencia debe contener el registro.
Las filas siguientes son puntos de partida sintéticos para un taller de políticas. Cada umbral, función y plazo es una regla operativa configurable. Sustitúyalos por valores de su propio apetito de riesgo, su plantilla y sus horas de corte.
| Acción | Umbral | Función del revisor | Caducidad | Cambio material en los datos | Rechazo | Revisor no disponible | Evidencia |
|---|---|---|---|---|---|---|---|
| Pago a un beneficiario existente | Más de 50.000 EUR por pago o 200.000 EUR al día | Verificador de tesorería ajeno al equipo solicitante | 2 horas, y nunca después de la hora de corte de pagos | Importe, cuenta del beneficiario, fecha valor o divisa | El pago no se envía; el agente registra el motivo y abandona esa vía | Escalar al verificador suplente antes de la caducidad; al caducar, no se envía nada | Resumen de la orden, versión de la política, resultado de sanciones, verificador y función, hora de la decisión, referencia bancaria |
| Pago a un beneficiario añadido en los últimos 30 días | Cualquier importe | Verificador de tesorería y, por encima de 10.000 EUR, operaciones de fraude | 1 hora | Cualquier dato del beneficiario, incluido el nombre | El pago no se envía; el beneficiario pasa a verificación | Caduca; un pago fraccionado cuenta para la misma solicitud | Registro del cambio de beneficiario, referencia de la llamada de confirmación, ambas decisiones |
| Actualización de la resolución de un crédito | Por encima del límite del gestor (20.000 EUR en el ejemplo resuelto más abajo) | Analista sénior de riesgos | 1 hora | Importe, datos de la solicitud, resultado del buró o versión de la política | La solicitud vuelve a la cola de análisis con el motivo | Reasignar a un analista habilitado con todo el historial | Resumen de la solicitud, regla aplicada, revisor, referencia de la justificación, recibo del sistema central |
| Carta al cliente que comunica una decisión desfavorable | Toda decisión desfavorable | Responsable del caso con autoridad sobre la decisión | Fin de la jornada laboral | Decisión, motivos, destinatario o canal | El borrador vuelve al agente con las correcciones del revisor | Retener la carta y avisar al jefe de equipo al caducar | Resúmenes del borrador y del texto final, motivos mostrados, cambios del revisor, acuse de envío |
| Cambio de autorizaciones del agente: nueva herramienta, más datos o un límite mayor | Todo cambio | Propietario responsable y un aprobador de gobierno de accesos que no lo haya solicitado | 24 horas | Herramienta, alcance, límite, entorno o duración | La autorización se mantiene como estaba | Caduca; el solicitante presenta una nueva solicitud | Autorización antes y después, solicitante, ambos aprobadores, fecha de efecto, fecha de la próxima revisión |
| Exportación de datos restringidos de clientes | Cualquier exportación fuera del Data Boundary asignado | Propietario de los datos y delegado de protección de datos | 4 horas | Campos, número de filas, destinatario, finalidad o región | No hay exportación; se registran la solicitud y el motivo | Caduca; las nuevas exportaciones con esa finalidad esperan a la revisión | Lista de campos, número de filas, destinatario, finalidad, referencia de la base jurídica, decisión |
Separe las obligaciones legales de las reglas operativas
Una matriz reúne dos tipos de requisito. Una obligación legal procede de una ley o de una norma vinculante y se aplica con independencia de lo que prefiera la organización. Una regla operativa es un valor que la organización elige para cumplir esa obligación o su propio apetito de riesgo. Manténgalas en columnas separadas para que un cambio de umbral nunca se interprete como un cambio en la ley.
En el Reglamento de IA de la UE, el artículo 14 fija las capacidades de supervisión que debe permitir un sistema de IA de alto riesgo, y el artículo 26, apartado 2, exige a los responsables del despliegue que encomienden la supervisión a personas con la competencia, la formación, la autoridad y el apoyo necesarios. El Reglamento (UE) 2026/1744 fijó la aplicación de estas obligaciones del capítulo III el 2 de diciembre de 2027 para los sistemas del anexo III y el 2 de agosto de 2028 para los del anexo I. Ninguno de los dos artículos fija un importe, un número de revisores o un plazo de caducidad. Esos valores los fija la organización.
| Elemento de la matriz | Tipo | Fuente o responsable |
|---|---|---|
| Las personas pueden vigilar, interpretar, anular e interrumpir un sistema de IA de alto riesgo | Obligación legal para proveedores (artículo 14) y responsables del despliegue (artículo 26) de sistemas de alto riesgo, desde las fechas indicadas | Reglamento de IA de la UE |
| Supervisión encomendada a personas competentes, formadas y con autoridad | Obligación legal para los responsables del despliegue de sistemas de alto riesgo (artículo 26, apartado 2) | Reglamento de IA de la UE |
| Umbrales de importe, límites diarios y ventanas para nuevos beneficiarios | Regla operativa | Responsable del apetito de riesgo, tesorería, operaciones de fraude |
| Plazos de caducidad y puntos de escalado | Regla operativa | Propietario del proceso |
| Aprobación por dos personas para pagos | Regla operativa, salvo que la normativa sectorial o la política de control interno la hagan obligatoria | Política de control interno; confirme los requisitos sectoriales |
| Campos de evidencia y plazo de conservación | Mixto: las obligaciones de registro fijan el mínimo y la lista de campos es una elección operativa | Obligaciones de registro y propietario de la evidencia |
Casos de excepción y qué ocurre después
La mayoría de los fallos de aprobación se producen en los bordes de la matriz. Pruebe cada caso siguiente con una solicitud real antes de poner la matriz en producción y conserve el resultado.
Dos de estos casos aparecieron en nuestros propios inquilinos de prueba. Un revisor que no podía decidir solo veía «Solo lectura». La causa era una separación de funciones correcta: el revisor pertenecía a un grupo de revisión y el caso se dirigía a otro grupo de aprobación. Cambiamos Decision Desk para que indique el motivo, por ejemplo que el usuario no pertenece al grupo de aprobadores exigido. Explique siempre a un revisor bloqueado por qué lo está.
En esos mismos inquilinos, una política precargada cuyas reglas no coincidían con los datos reales del agente recurrió a su decisión por defecto y denegó la ejecución. Fallar de forma cerrada era lo correcto, pero la ruta de aprobación que queríamos probar nunca llegó a ejecutarse. Pruebe cada fila de la matriz con una entrada registrada antes de confiar en ella. También aprendimos a mantener el enrutamiento rutinario fuera de las colas de incidentes: en un momento dado, la mayoría de nuestros incidentes eran simples envíos require_approval a Decision Desk, así que cambiamos el disparador para que solo las decisiones block abran un incidente.
| Caso | Qué debe ocurrir | Comportamiento de KLA en el código actual | Evidencia |
|---|---|---|---|
| El agente cambia el importe después de la aprobación | La aprobación cubre solo los parámetros revisados. La solicitud modificada necesita una nueva evaluación. | La pasarela de gobernanza compara un hash de los argumentos de la herramienta con el hash aprobado y bloquea la llamada cuando no coinciden. | Ambos resúmenes de argumentos, la decisión original, el motivo del bloqueo |
| El solicitante intenta aprobar su propia solicitud | La decisión se rechaza y pasa a otra persona habilitada. | Decision Desk rechaza las decisiones del solicitante o creador registrado y le indica que debe decidir otro aprobador. | Intento rechazado, revisor habilitado, decisión final |
| Nadie decide antes del plazo | La acción no se ejecuta. La caducidad nunca equivale a una aprobación. | Decision Desk rechaza aprobar o rechazar después del plazo. Un verificador habilitado puede escalar, lo que reabre el plazo de decisión y registra el escalado. Una aprobación de flujo de trabajo que caduca marca la ejecución como TIMEOUT, salvo que el flujo esté configurado para omitir el paso. | Plazo, historial de escalado, estado final |
| El revisor rechaza | La acción no se ejecuta y el agente recibe el motivo. | El rechazo se registra con el revisor, sus funciones en el momento de decidir y una nota obligatoria. | Decisión, motivo, revisor, hora |
| La evaluación de la política falla o agota el tiempo | La acción no continúa. Una acción relevante falla de forma cerrada. | La ingesta de acciones de agentes devuelve un error que indica que la acción no se ejecutó. La pasarela aplica block en producción y require_approval en los demás entornos, y nunca allow. | Código de fallo, hora, estado del servicio de políticas |
| Un incidente detiene la ejecución con una solicitud pendiente | Una aprobación tardía no debe reanudar la ejecución. | Una señal kill hace que la ejecución en espera cancele su solicitud pendiente y termine sin reanudar la acción. | Orden del incidente, solicitud cancelada, estado de la ejecución |
| El agente fracciona un pago para quedar por debajo del umbral | Los límites agregados detectan el fraccionamiento. | Configure un límite diario o por destino en la política. KLA evalúa cada acción con las reglas que usted publica. | Regla agregada aplicada y acciones relacionadas |
| El sistema posterior rechaza una acción aprobada | Registre el fallo. Un reintento con datos modificados necesita una nueva solicitud. | La aprobación y el resultado de la herramienta son registros separados dentro de la misma ejecución. | Aprobación, resultado fallido de la herramienta, decisión sobre el reintento |
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 las fuentes completada el 8 de octubre 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.