La revisión de accesos de un agente de IA es una decisión periódica y firmada sobre si cada agente debe conservar, perder o cambiar cada derecho que tiene. Los bancos ya aplican este ciclo a las personas: extraen todas las autorizaciones, envían cada línea a un revisor responsable, registran si se certifica o se revoca, retiran lo revocado y conservan la evidencia. Los agentes necesitan el mismo ciclo con una partida más amplia. Un derecho de un agente abarca la herramienta, la acción, el importe, los datos, el entorno, el control de aprobación previo a la acción y la fecha en que termina el derecho.
Esta guía explica cómo llevar a cabo esa campaña. La guía de permisos de agentes de IA explica cómo diseñar los derechos y la guía de control de accesos cubre el modelo operativo desde la identidad hasta la revocación. Este artículo parte de unos derechos ya concedidos y explica cómo un revisor certifica la autorización de cada agente de IA. Información general, actualizada a 23 de octubre de 2026; no sustituye al asesoramiento jurídico ni de auditoría.
Qué certifica el revisor
Una revisión de accesos de usuarios pregunta si una persona sigue necesitando un rol. La revisión de un agente plantea una pregunta más larga: ¿sigue necesitando este agente cada acción que puede realizar, con este límite, sobre estos datos, con este control de aprobación, bajo este propietario y hasta esta fecha? El nombre de un rol rara vez la responde. Dos agentes con el mismo rol pueden tener herramientas, límites de importe y excepciones distintos.
Certifique la autoridad efectiva, es decir, los derechos que el agente puede ejercer hoy. Compare cuatro vistas de cada derecho: lo que pidió el propietario, lo que se aprobó, lo que está configurado en el proveedor de identidad, la pasarela de herramientas y la política, y lo que el agente usó durante el periodo revisado. Un derecho aprobado y configurado que nunca se usó es candidato a retirarse. Un derecho que se usó sin haberse aprobado es una incidencia.
| Campo | Qué ve el revisor | Pregunta que debe responder |
|---|---|---|
| Agente y Release | Nombre del agente, identificador en Agent Registry, Release actual, propietario responsable | ¿Sigue el propietario en su puesto y sigue siendo responsable? |
| Acción | Herramienta y operación, por ejemplo payments.create_transfer | ¿Sigue necesitando el proceso de negocio esta acción? |
| Límite | Importe por acción y por día, reglas de destino, límite de frecuencia | ¿Es el límite más bajo que permite que el proceso funcione? |
| Data Boundary | Sistemas, campos, regiones y finalidades que el agente puede leer o escribir | ¿Lee el agente algo que ya no usa? |
| Control de aprobación | La regla de política que devuelve require_approval y la función del revisor a la que se dirige | ¿Sigue vigente el control y es correcta la función? |
| Credencial | Identidad, token o secreto, emisor, vida útil, último uso | ¿Está la credencial limitada a este agente y sigue siendo necesaria? |
| Uso en el periodo | Número de acciones permitidas, con aviso, aprobadas, rechazadas y bloqueadas | ¿Coincide el uso observado con la finalidad declarada? |
| Fecha de fin | Caducidad del mandato o de la excepción | ¿Debería terminar el derecho antes de lo previsto? |
Aplique el ciclo de recertificación bancaria
Una campaña de recertificación tiene una población fija, una fecha de corte fija, revisores designados, un plazo y un paso de corrección que alguien comprueba. Mantenga esa estructura. Cambie la partida y añada dos pruebas que las revisiones de personas rara vez necesitan: la prueba de que el control de aprobación sigue enviando la acción al revisor y la prueba de que la revocación detiene la siguiente acción.
| Fase | Trabajo | Resultado |
|---|---|---|
| 1. Alcance | Fije la fecha de corte. Concilie Agent Registry con el proveedor de identidad, la bóveda de secretos, la pasarela de herramientas, los registros de servidores MCP y los registros de ejecución, para que la población incluya los agentes que nadie registró. | Lista de la población con el origen de cada entrada y los agentes encontrados fuera del registro |
| 2. Extracción | Exporte los derechos efectivos de cada agente como partidas, con el uso del periodo revisado. | Extracción firmada o con hash, con su hora de generación |
| 3. Asignación | Envíe cada agente a su propietario responsable. Envíe los derechos privilegiados y las excepciones a un segundo revisor ajeno al equipo propietario. | Asignación de revisores con comprobación de conflictos |
| 4. Decisión | Para cada línea: certificar, modificar, revocar o registrar una excepción con fecha de fin. | Una decisión, un motivo, un revisor y una hora por línea |
| 5. Corrección | Aplique cada modificación y revocación en el sistema que posee el derecho. | Justificante del cambio por línea, vinculado a la decisión |
| 6. Verificación | Vuelva a extraer y compare. Intente una acción revocada por agente en un entorno de pruebas o mediante una simulación de la política. | Comparación de cierre y un intento denegado por cada derecho revocado |
| 7. Cierre | El responsable de la campaña registra el alcance, el grado de finalización, las partidas vencidas, las incidencias y las limitaciones. | Registro de la campaña listo para la auditoría interna |
Fije la frecuencia según el riesgo y los eventos
Para las entidades financieras de la UE sujetas a DORA, la norma de gestión del riesgo de TIC fija un mínimo. El artículo 21, apartado 1, letra e), del Reglamento Delegado (UE) 2024/1774 de la Comisión exige procedimientos de gestión de cuentas que asignen funciones y responsabilidades para conceder, revisar y revocar derechos de acceso, que retiren los derechos sin demora indebida cuando ya no sean necesarios y que prevean su actualización cuando sea necesario y al menos una vez al año en los sistemas de TIC, y al menos cada seis meses en los que sustentan funciones esenciales o importantes. El artículo 21, apartado 1, letra a), exige que los derechos sigan los principios de necesidad de conocer, necesidad de uso y mínimo privilegio, y la letra c) exige que los usuarios sean identificables en todo momento por las acciones realizadas en los sistemas de TIC.
El reglamento trata los derechos de acceso a los activos de TIC en general y no menciona a los agentes de IA. Un agente que tiene credenciales para un sistema de TIC que sustenta una función esencial o importante tiene derechos de acceso a ese sistema. Pregunte a su función de cumplimiento si el mínimo de seis meses se le aplica. Muchos equipos revisan a los agentes con más frecuencia que a las personas, porque un agente puede usar un derecho miles de veces entre campañas.
| Perfil del agente | Revisión programada | Evento que activa una revisión inmediata |
|---|---|---|
| Mueve dinero, modifica registros de clientes o envía comunicaciones externas | Trimestral | Nueva herramienta, límite mayor, nueva Release, cambio de propietario, incidente o un patrón de acciones bloqueadas |
| Sustenta una función esencial o importante sin acceso de escritura | Cada seis meses | Nueva fuente de datos, nueva región o cambio de finalidad |
| Interno, solo lectura, sin datos personales | Anual | Cualquier solicitud de acceso de escritura |
Haga que cada decisión cambie algo
Una revisión que solo recoge aprobaciones demuestra poco. Cada decisión debe dejar rastro en la configuración o en un registro de excepciones con fecha.
| Decisión | Seguimiento obligatorio | Evidencia |
|---|---|---|
| Certificar | Sin cambios. El derecho conserva su fecha de fin actual. | Revisor, hora, motivo y la línea de la extracción certificada |
| Modificar | Reducir un límite, acotar un Data Boundary, adelantar una fecha de fin o añadir un control de aprobación. | Valores antes y después, justificante del cambio, versión de la política |
| Revocar | Retirar el derecho en el sistema que lo posee y revocar cualquier credencial que solo sirviera para él. | Justificante del cambio y un intento denegado tras la retirada |
| Excepción | Mantener un derecho que incumple una regla, con un control compensatorio y una fecha de fin no posterior a la siguiente campaña. | Responsable de la excepción, aprobador, control compensatorio, caducidad |
| Sin respuesta en plazo | Escalar al superior del propietario. Su política decide si el derecho se suspende al vencer el plazo final. | Historial de escalado y estado final del derecho |
Pruebas que detectan lo que una firma pasa por alto
Ejecute estas pruebas sobre la extracción antes de que la vean los revisores y muestre los resultados en la partida. Convierten una valoración subjetiva en una incidencia con una cifra.
- Derecho sin uso: concedido durante todo el periodo y nunca ejercido. Proponga revocarlo por defecto y pida al propietario que justifique mantenerlo.
- Uso no aprobado: el agente ejerció un derecho sin registro de aprobación. Abra una incidencia antes de cerrar la campaña.
- Combinación incompatible: un mismo agente puede crear un beneficiario y liberar un pago, o redactar y aprobar. Separe los derechos o ponga una función humana distinta en uno de los lados.
- Control desaparecido: un cambio de política desde la última campaña eliminó o debilitó una regla require_approval. Compare las versiones de la política línea por línea.
- Autorrevisión: el revisor es quien solicitó el derecho o quien patrocina el agente. Reasigne la revisión.
- Propietario huérfano: el propietario responsable se ha ido o ha cambiado de puesto. Suspenda los nuevos derechos hasta que un nuevo propietario acepte.
- Credencial compartida: un mismo secreto sirve a varios agentes. El uso no se puede atribuir, así que la línea no se puede certificar.
- Excepción vencida aún activa: la fecha de fin de la excepción ya pasó y el derecho sigue funcionando.
Ejemplo resuelto: revisión trimestral de un agente de pagos
El agente, las cifras y las identidades siguientes son sintéticos. Un agente de operaciones de tesorería prepara y libera pagos a proveedores. El periodo revisado va del 1 de julio al 30 de septiembre de 2026. Su propietario es el responsable de operaciones de tesorería; las líneas privilegiadas van a un segundo revisor de riesgo operacional.
| Partida | Observado en el periodo | Decisión | Seguimiento |
|---|---|---|---|
| payments.create_transfer hasta 50.000 EUR a beneficiarios existentes | 1.412 acciones permitidas, 0 bloqueadas | Certificar | Ninguno |
| payments.create_transfer por encima de 50.000 EUR, con require_approval hacia un verificador de tesorería | 37 solicitudes de aprobación: 35 aprobadas y 2 rechazadas | Certificar | Ninguno; control confirmado en la versión vigente de la política |
| beneficiaries.create | 3 usos, todos para un proyecto de alta de proveedores que terminó en agosto | Revocar | Derecho retirado; el intento en pruebas devolvió block |
| erp.read_invoices en todas las filiales | Lecturas en dos de cinco filiales | Modificar | Data Boundary reducido a esas dos filiales |
| Excepción: liberar transferencias intragrupo antes de repetir el control de sanciones | Concedida en junio con fecha de fin el 30 de septiembre de 2026 | Excepción vencida | Excepción cerrada; el derecho sigue ahora la regla estándar |
| Clave de API compartida con el agente de conciliación | El uso no se puede separar por agente | Incidencia | Nueva credencial por agente emitida; clave compartida revocada |
Dónde encaja KLA en una revisión de accesos
KLA no tiene un módulo de campañas de revisión de accesos. La revisión se lleva a cabo en su herramienta de gobierno de identidades o en un papel de trabajo. KLA Control Plane contiene varios de los datos que necesita el revisor y aplica la decisión de revocar en la ruta de acciones gobernadas. Esta sección describe el código fuente actual.
Los agentes que actúan a través de la ingesta de acciones de agentes de KLA trabajan bajo un mandato de agente: un registro versionado con un propietario responsable, un principal institucional, herramientas, operaciones y destinos permitidos, finalidades, entornos, límites sobre los parámetros de la acción y un periodo de validez con fecha de fin obligatoria. Quien crea un mandato no puede aprobarlo. Al listar los mandatos de un agente se obtiene ese alcance con sus fechas de validez y los actores de su ciclo de vida, lo que da al revisor las partidas de esa vía.
La decisión de revocar corresponde a la revocación del mandato. Solo las funciones de administrador del inquilino y de responsable de cumplimiento pueden revocar, y el motivo es obligatorio. La revocación bloquea las propuestas abiertas vinculadas a ese mandato con el código de motivo mandate_revoked y cancela sus Solicitudes de decisión pendientes. La siguiente acción que el agente propone con un mandato revocado o caducado se rechaza antes de registrarse como propuesta. Una acción ya admitida aún puede completarse. Cada revocación queda en un registro de ciclo de vida del mandato de solo anexión que incluye la exportación de evidencias.
Cada acción gobernada recibe uno de cuatro resultados de política: allow, warn, require_approval o block. Esos resultados dan los recuentos de uso de la partida. Decision Desk rechaza las decisiones del solicitante registrado, comprueba la función del revisor exigida y registra la decisión con una nota y las funciones del revisor en ese momento. Los derechos que están fuera de KLA, como los grupos del proveedor de identidad, los secretos de la bóveda o las cuentas en los sistemas de destino, siguen en sus sistemas propietarios y necesitan su propia extracción.
Una partida certificada solo se sostiene si la aplicación de la política comprueba la misma identidad del agente. En agosto de 2026, al redactar una regla de aprobación de pagos en nuestro propio inquilino de prueba, descubrimos que el alcance por agente de una política aún no se aplicaba en tiempo de ejecución. Cambiamos la evaluación de políticas para que compruebe la identidad del agente que actúa en cada llamada y falle de forma cerrada cuando falta esa identidad. Nuestras ejecuciones automáticas de aceptación en inquilinos de prueba usan además dos identidades, una para iniciar una ejecución gobernada y otra para decidir sus Solicitudes de decisión, porque Decision Desk rechaza la decisión del solicitante y exige un motivo para cada decisión.
Fuentes primarias
Revisión de las fuentes completada el 23 de octubre de 2026. El Reglamento Delegado (UE) 2024/1774 de la Comisión completa el Reglamento (UE) 2022/2554 (DORA) con normas técnicas de regulación sobre el marco de gestión del riesgo de TIC. Las referencias anteriores proceden de su artículo 21, «Control de acceso». El reglamento fija obligaciones para las entidades financieras sujetas a DORA; la tabla de frecuencias, los campos de la partida, las pruebas y el ejemplo de esta guía son patrones de aplicación sin fuerza jurídica. Confirme con su función de cumplimiento qué funciones clasifica como esenciales o importantes.
Preguntas frecuentes
¿Qué es una revisión de accesos de un agente de IA?
Es una campaña periódica en la que un revisor designado decide, para cada derecho que tiene un agente, si lo certifica, lo modifica, lo revoca o lo mantiene como excepción con fecha de fin. El derecho abarca la herramienta, la acción, el importe, los datos, el entorno, el control de aprobación, la credencial y la fecha de fin.
¿Con qué frecuencia deben revisarse los accesos de un agente de IA?
Fije la frecuencia según el riesgo y añada revisiones por eventos. Para las entidades financieras de la UE sujetas a DORA, el Reglamento Delegado (UE) 2024/1774 exige actualizar los derechos de acceso al menos una vez al año, y al menos cada seis meses en los sistemas de TIC que sustentan funciones esenciales o importantes. Los agentes que mueven dinero o modifican registros de clientes suelen revisarse cada trimestre.
¿Quién debe revisar las autorizaciones de un agente de IA?
El propietario responsable del agente revisa los derechos ordinarios. Un segundo revisor ajeno al equipo propietario revisa los derechos privilegiados y las excepciones. Quien solicitó un derecho no debe certificarlo.
¿Cómo se auditan y certifican los derechos de acceso de un agente de IA?
Concilie toda la población de agentes entre el registro, el proveedor de identidad, los secretos, las pasarelas y los registros. Extraiga los derechos efectivos con el uso del periodo. Envíe cada línea a un revisor, registre certificar, modificar, revocar o excepción, aplique los cambios, vuelva a extraer para confirmarlos e intente una acción revocada para demostrar que se deniega.
¿Qué evidencia espera un auditor de una revisión de accesos de agentes?
La población y cómo se concilió, la extracción con su hora de generación, las asignaciones de revisores, una decisión por línea con motivo y hora, los justificantes de cada modificación y revocación, la comparación de la nueva extracción, los intentos denegados de los derechos revocados, el registro de excepciones y el cierre de la campaña con sus limitaciones.
¿En qué se diferencia la revisión de accesos de un agente de la de un usuario?
El ciclo es el mismo. La partida es más amplia, porque un derecho de un agente incluye límites de importe, alcance de datos, el control de aprobación previo a la acción y una fecha de fin. Los datos de uso son más ricos, de modo que se pueden medir los derechos sin uso y el uso no aprobado. La revocación también debe probarse, porque un agente puede volver a actuar en segundos.
Conclusiones clave
Lleve a cabo la campaña de agentes con la misma disciplina que los bancos aplican a las personas: una población fija, un revisor para cada línea, una decisión que cambia algo, una comprobación de que el cambio surtió efecto y un registro firmado. Empiece con la lista de comprobación de revisión de autorizaciones, haga pasar a un agente de alto riesgo por las siete fases y conserve el registro de la campaña para la próxima auditoría.