Gobernanza de agentes de IA: seguridad y auditoría para equipos de riesgo

Última actualización: Septiembre de 2026

Resumen rápido

Un agente necesita gobernanza, mientras que un modelo no, por tres razones: tiene permisos, realiza acciones y mantiene el contexto a lo largo de los pasos. Un modelo genera una puntuación sobre la cual actúa otro sistema; un agente es el sistema que actúa. Todo lo que es genuinamente nuevo sobre su gobernanza se deriva de esto, y la forma de destrabar una revisión de seguridad es presentarse con el artefacto que responda a cada límite, no con un documento de políticas.

¿Qué es la gobernanza de agentes de IA?

La gobernanza de agentes de IA es el conjunto de límites y registros que hacen que el comportamiento de un agente sea claro antes de actuar y reconstruible después de haber actuado. Los límites definen qué puede leer el agente, qué puede hacer sin ayuda y qué debe escalar. Los registros establecen qué vio, qué concluyó y quién asumió la responsabilidad del resultado.

Si está leyendo esto, probablemente se encuentre en una situación específica: la prueba de concepto funciona, los resultados son buenos y la revisión de seguridad no ha avanzado en tres semanas. Eso rara vez se debe a que el agente no sea seguro. Suele ser porque nadie ha puesto por escrito las cinco cosas que un revisor necesita ver, en el formato en que necesita verlas.

Esos cinco límites son: el acceso a datos, las acciones permitidas, el escalamiento, los límites del modelo y la responsabilidad.

Por qué gobernar un agente no es lo mismo que gobernar un modelo

Muchas instituciones ya cuentan con un marco de gestión de riesgos de modelos, y la primera pregunta útil es qué parte de este se puede aprovechar.

Se pueden transferir muchos aspectos, como la disciplina de validación, los hábitos de documentación, el monitoreo continuo del rendimiento y la comparación con alternativas. Si cuenta con un área madura de riesgo de modelos, no está empezando de cero.

Lo que no se puede transferir es todo lo que surge de estas tres diferencias:

• Un agente tiene permisos. Un modelo no tiene derechos de acceso. Recibe variables y devuelve un número. Un agente lee sistemas, y alguien tiene que definir a cuáles puede acceder.

• Un agente realiza acciones. Una puntuación no puede cerrar una alerta, solicitar un documento ni presentar un informe. Un agente sí puede, y el conjunto de cosas que puede hacer sin intervención humana es una decisión que alguien debe tomar de forma explícita.

• Un agente mantiene el contexto a lo largo de los pasos. Un modelo evalúa cada caso de forma independiente. Un agente acumula un estado, lo que significa que su comportamiento en el paso cuatro depende de lo que ocurrió en el paso uno, y reconstruir una decisión implica reconstruir una secuencia, no una sola inferencia.

Nada en un marco de riesgo de modelos le indica qué puede hacer un agente sin ayuda, porque una puntuación no tiene permisos y no puede actuar. Esa es la brecha que la gobernanza debe cubrir.

Los cinco límites que se evaluarán en una revisión

Asociar cada límite con el artefacto que lo resuelve suele ser el paso que falta. Una descripción general de la gobernanza explica que los agentes necesitan supervisión. Una revisión necesita saber qué documento guardar en la carpeta. Esta tabla es el recurso ideal para presentar en esa reunión.

Dónde se definen realmente los límites

Los límites no son un ejercicio de políticas que se realiza después de la implementación. En la práctica, el proceso consiste en mapear los datos y esquemas de la institución, configurar sus umbrales y políticas, y luego definir los flujos y permisos.

Ese orden es clave. Los permisos y flujos de trabajo se definen al configurar el agente, no se adaptan después de que surjan objeciones internas. Un modelo de gobernanza integrado a la fuerza a posteriori suele ser lo que frena las revisiones, ya que exige reconstruir el proceso a partir de las acciones en lugar de leerlo directamente desde la configuración.

Esto también responde a la pregunta más común de las instituciones: ¿puede funcionar esto con los sistemas de riesgo que ya tenemos? Los umbrales y las políticas son suyos. El agente opera dentro de los límites que defina la institución.

La forma de implementación también es importante aquí, ya que define quién se encarga de cada control. Los agentes de Oscilar pueden funcionar de manera independiente sobre la infraestructura existente o como parte de nuestra plataforma unificada, y la distribución de responsabilidades varía en cada caso. El tema de la integración se analiza a fondo en cómo agregar agentes de IA sin reemplazar su arquitectura de riesgo actual.

Qué dicen las normativas vigentes en este momento

Las pautas actualizadas de gestión de riesgos de modelos de EE. UU. excluyen explícitamente a la IA generativa y agente de su alcance. El comunicado de la OCC señala que "los modelos de IA generativa y agente son novedosos y evolucionan rápidamente. Por lo tanto, no entran en el alcance de estas pautas". Esto pertenece al comunicado de prensa de la OCC NR 2026-29, publicado el 17 de abril de 2026, con pautas relacionadas en el Boletín de la OCC 2026-13.

Por separado, la OCC, la Junta de Gobernadores de la Reserva Federal y la FDIC tienen previsto publicar una solicitud de información para analizar la gestión de riesgos de modelos en general, considerando especialmente el uso de la IA por parte de los bancos, incluida la IA generativa y agente. Al momento de escribir este artículo, no se ha publicado, no hay un periodo de comentarios abierto y no se trata de una solicitud específica sobre IA agente.

La lectura clave de esto: la exclusión elimina una lista de verificación, pero no quita ninguna de las preguntas de los auditores. Nadie le ha dicho a las instituciones que pueden dejar de preocuparse por cómo se prueba, monitorea o supervisa un agente. Simplemente han preferido, por ahora, no detallar el método exacto. La obligación sigue en pie pero sin una receta fija, lo que resulta más complejo que tener un manual de reglas, y es por eso que los artefactos de la tabla anterior son más valiosos que una simple equivalencia de cumplimiento.

La norma SR 11-7 sigue siendo el marco adecuado para analizar esto. Es una expectativa bajo la cual operan las instituciones, y la plataforma de Oscilar está diseñada para adaptarse a ella: un historial de auditoría completo por decisión con razonamiento guardado, un diseño que incluye al humano en el proceso, y monitoreo de sesgos y desviaciones. Esto es una intención de diseño, no una certificación, y vale la pena mantener esa diferencia en cualquier conversación con las áreas de control.

El registro de auditoría y qué debe contener

Decir "tenemos un registro de auditoría" no es suficiente para superar una revisión. La pregunta de fondo es si ese registro puede reconstruir una decisión y si una persona puede comprenderlo fácilmente.

Una arquitectura útil consta de dos niveles. Por un lado, un registro con datos técnicos, donde cada motivo de rechazo y cada resultado se vincula con los datos de origen. Por el otro, una vista simplificada generada a partir de ese registro: paneles de casos fáciles de leer para un analista, en lugar de códigos técnicos.

Se necesitan estos dos niveles porque un revisor planteará dos preguntas. ¿Puede demostrarlo? se responde con el registro técnico de datos. ¿Puede su analista leerlo de verdad? se responde con la vista simplificada. La mayoría de las soluciones solo resuelven la primera pregunta, pero la segunda es la que define si el control funciona en el día a día y no solo en teoría.

Lo que debe incluir el registro por cada decisión:

• Los datos que recibió el agente

• El razonamiento que guardó

• La acción que realizó

• El modelo y la versión que generaron el resultado

• La persona que lo revisó, aprobó o modificó

La razón para diseñarlo así no es solo por orden. Debe estar en condiciones de justificar cualquier decisión que se haya tomado, y la participación humana es el mecanismo que hace posible esa defensa, no solo una característica atractiva en una presentación. Conviene notar lo lejos que está esto de la idea de que los agentes "resuelven el trabajo automáticamente".

En una conversación sobre gobernanza, prometer autonomía total puede jugar en su contra.

Este mismo registro estructurado es de donde se toman los datos para evaluaciones y ajustes futuros, ya que cada dato de un caso queda vinculado a su decisión. Este concepto se desarrolla detalladamente en cómo evaluar un agente de riesgo de IA antes de llevarlo a producción.

Quién asume la responsabilidad del resultado

La clave de la mayoría de las revisiones de agentes que se encuentran estancadas radica en esta pregunta, que suele ser el verdadero obstáculo más allá de cualquier control técnico.

La responsabilidad se asocia a un tipo de decisión, no a una decisión individual. Nadie firma la aprobación de cada alerta, ni ningún marco lo exige. Alguien debe ser el propietario de la política que resuelve una categoría de alertas, y esa autoría es lo que busca el revisor.

Es útil definir claramente tres roles antes de la revisión, ya que son los que se consultarán:

• Quién es el responsable de la política: los umbrales y las acciones permitidas

• Quién es el responsable del modelo: su validación y su rendimiento continuo

• Quién es el responsable de la excepción: los casos que se escalan y las decisiones modificadas

Para decirlo de forma directa: "el agente tomó la decisión" no es una respuesta que un revisor acepte, ni tampoco una que la institución deba dar. La participación humana en el proceso es una decisión de asignación de responsabilidades antes que una función de interfaz de usuario.

Monitoreo de un agente en producción

La obligación de supervisión continua es real, y aquí es donde la falta de normativas detalladas se siente más. Los auditores querrán saber cómo se comprueba que el agente funciona, y ningún manual actual especifica cómo demostrarlo.

La solución ideal es contar con un monitoreo que detecte la desviación de datos, de variables y de conceptos, midiendo los indicadores clave de rendimiento (KPI) por segmento. El análisis por segmento es fundamental en este caso, ya que un agente puede mantener un buen rendimiento general pero fallar gravemente para un grupo específico de la población.

La complejidad particular de los agentes es que tienen más variables que pueden desviarse en comparación con un modelo simple. Sus entradas de datos, sus herramientas y el grupo sobre el cual actúan pueden cambiar de forma independiente y presentar síntomas diferentes. Este tema requiere un análisis detallado, el cual se desarrolla en monitoreo de desviación en agentes de riesgo de IA.

Qué presentar en la revisión

La pregunta más útil sobre capacidad de auditoría que nos han hecho provino de un banco durante una sesión de prueba de concepto. No preguntaron si se registraban las decisiones en producción, sino si existían registros de auditoría para las pruebas de ensayo.

La respuesta es que existen dos registros de auditoría independientes. Pero lo interesante de la pregunta es que un revisor no solo quiere pruebas de lo que el agente decidió cuando ya estaba en funcionamiento. Quiere ver el registro de lo que se hizo durante la etapa de pruebas; un documento de políticas demuestra la intención, mientras que un registro de pruebas demuestra la práctica. La distancia entre "diseñamos este control" y "pusimos en práctica este control" es exactamente donde se frenan las revisiones.

Por lo tanto, la lista de verificación para presentarse debe incluir los cinco límites:

1. Acceso a datos — el alcance documentado y la trazabilidad de los datos

2. Acciones permitidas — el conjunto de acciones explícitas, denegando todo lo demás por defecto

3. Escalamiento — la política, los umbrales y la evidencia de su cumplimiento

4. Límites del modelo — el registro del modelo y versión utilizado en cada decisión

5. Responsabilidad — el responsable asignado por tipo de decisión

6. Más el registro de pruebas — qué pruebas se realizaron antes de la puesta en marcha y qué resultados arrojaron

Nada de esto es complejo. En su mayoría, consiste en documentar decisiones que se tomaron de manera implícita durante la implementación. Por eso, las instituciones que superan las revisiones más rápido son las que definieron permisos y flujos de trabajo al configurar el agente, y no después.

La gobernanza no es un trámite molesto para implementar un agente; es lo que permite que esa implementación sea viable y exitosa.

Preguntas frecuentes

¿Qué es la gobernanza de agentes de IA?

La gobernanza de agentes de IA es el conjunto de límites y registros que hacen que el comportamiento de un agente sea claro antes de actuar y reconstruible después de haber actuado. Los límites definen qué puede leer el agente, qué puede hacer sin ayuda y qué debe escalar; los registros establecen qué vio, qué concluyó, qué modelo generó el resultado y quién asumió la responsabilidad del resultado.

¿Cómo se gobiernan los agentes de IA en los servicios financieros?

Definiendo cinco límites y respaldando cada uno con un artefacto: un alcance documentado de acceso a datos, un conjunto explícito de acciones permitidas (denegando por defecto lo que quede fuera de este), una política de escalamiento con umbrales definidos, un registro de modelo y versión para cada decisión, y un responsable asignado por tipo de decisión. En una institución regulada, estos elementos se integran al marco de riesgo de modelos existente en lugar de reemplazarlo.

¿Puede la gobernanza de agentes de riesgo de IA funcionar con los sistemas de riesgo actuales de una institución?

Sí, y los límites deben ser los de la propia institución. Los umbrales y las políticas se configuran durante la implementación en lugar de adoptarse de forma rígida de un proveedor. El proceso habitual consiste en mapear datos y esquemas, configurar umbrales y políticas, y finalmente establecer flujos y permisos. Los agentes pueden operar como una capa independiente sobre la infraestructura existente o como parte de una plataforma unificada, lo que define la distribución de responsabilidades sobre cada control.

¿Qué controles de gobernanza se necesitan para la IA agente?

Un alcance de acceso a datos con trazabilidad, un conjunto explícito de acciones permitidas, una política de escalamiento con umbrales, un registro de modelo y versión por decisión, responsables asignados por tipo de decisión, un registro de auditoría de dos niveles y un monitoreo continuo de desviaciones con métricas de rendimiento por segmento.

¿Las pautas de gestión de riesgos de modelos incluyen a los agentes de IA?

Actualmente no, en los EE. UU. Las pautas actualizadas de gestión de riesgos de modelos excluyen explícitamente de su alcance a la IA generativa y agente (el comunicado NR 2026-29 de la OCC del 17 de abril de 2026 señala que dichos modelos "no entran en el alcance de estas pautas"). La OCC, la Reserva Federal y la FDIC planean publicar una solicitud de información sobre la gestión de riesgos de modelos en general y el uso de IA en los bancos en particular, pero aún no se ha publicado ni tiene un periodo de consulta. Las preguntas de los auditores sobre pruebas, monitoreo y supervisión humana siguen vigentes.

¿Quién es responsable cuando actúa un agente de IA?

Una persona designada, responsable de la categoría o tipo de decisión en lugar de cada decisión individual. Deben identificarse tres roles de responsabilidad antes de una revisión: quién es el responsable de la política, quién del modelo y quién de las excepciones. La respuesta "el agente tomó la decisión" no es válida.

¿Cómo se gobiernan la revisión humana, la capacidad de auditoría y el rendimiento del agente?

La revisión humana se gobierna mediante una política de escalamiento con umbrales definidos y responsables asignados por tipo de decisión. La capacidad de auditoría se gestiona con un registro de dos niveles (un registro técnico de datos por decisión y una vista simplificada para analistas derivada de este). El rendimiento se gobierna mediante un monitoreo que cubre la desviación de datos, variables y conceptos, midiendo los resultados clave por segmento.