Los equipos de cumplimiento de los bancos deberían vincular cada caso de uso de agentes que pueda tener consecuencias importantes con los controles de riesgo que ya aplican. La publicación del marco para examinadores de la OCC el 4 de noviembre ofrece un motivo para revisar esa relación. Al mismo tiempo, el documento indica expresamente que no crea nuevas expectativas regulatorias ni se espera que los bancos lo utilicen para autoevaluarse. Como primer paso, se puede documentar de forma breve y verificable la relación entre la operación que realiza un agente, la persona actualmente responsable del control y la documentación que lo respalda.
Lo que publicó la OCC
El Boletín 2026-54 de la OCC presenta un marco para examinadores. Su término Super Intelligence incluye tecnologías que antes se denominaban IA. El anuncio indica que los examinadores no deberían tratar la IA como una categoría de riesgo independiente y que no se debería exigir a los bancos definir un apetito de riesgo específico para la IA. Reuters también informa de manera independiente sobre la publicación y su énfasis en las consecuencias, más que en la sofisticación del modelo.
El boletín rechaza la idea de nuevas expectativas de supervisión, estándares exigibles y requisitos prescriptivos. Esa precisión importa cuando una nota informativa interna se convierte en una solicitud de proyecto. Presentar esto como un nuevo marco obligatorio de control de IA describiría mal la fuente. El mapeo que aparece a continuación es un análisis de Maetra para organizar trabajo existente, no una lista de verificación de la OCC ni una conclusión sobre las obligaciones legales de ningún banco.
Empiece por la acción bancaria
Una entrada de inventario como «asistente basado en un modelo de lenguaje» deja al responsable de riesgo con muy poca información. Describa primero la operación que realiza el agente: preparar un análisis interno, redactar un mensaje para un cliente, cambiar el registro de un caso o iniciar una transacción. Después describa cómo comparten la tarea la persona y el agente.
Para un agente hipotético de atención al cliente, registre si solo puede sugerir una respuesta, guardar un borrador, enviar el mensaje o cambiar la cuenta del cliente. Esos permisos crean necesidades de revisión distintas, aunque todas las versiones utilicen el mismo modelo. Identifique el límite realmente desplegado y a la persona que puede modificarlo. Una capacidad prevista en la hoja de ruta debe ir en un campo separado de un permiso que esté activo hoy.
Mantenga la entrada lo bastante acotada como para poder inspeccionarla. Un agente con varias acciones materialmente distintas puede necesitar varios registros a nivel de acción. Una única etiqueta de «IA aprobada» para todo un departamento puede ocultar qué flujo de trabajo se revisó y qué incorporación posterior nunca llegó al responsable correspondiente.
Asigne cada caso a los controles existentes y a sus responsables
Maetra recomienda una ficha breve de correspondencias con seis campos:
- Caso de uso y acción: el propósito de negocio y la operación exacta que el agente puede realizar.
- Área de riesgo existente: la clasificación aplicable del propio banco, con una razón para el mapeo.
- Responsable del control: la persona responsable del control correspondiente, ya sea de acceso, gestión de cambios, revisión o supervisión.
- Límite operativo: los datos, sistemas, límites de transacción y puntos de control humano que actualmente restringen la acción.
- Referencia de evidencia: la configuración, prueba o registro de revisión que respalda el límite declarado.
- Disparador de revisión: el cambio que haría necesario volver a revisar la evidencia.
El valor está en las relaciones entre estos campos. El responsable de un control de acceso debería poder encontrar la configuración de permisos sin pedir al equipo del modelo que reconstruya una presentación. El responsable de negocio debería poder explicar por qué un efecto externo concreto sigue dentro del flujo de trabajo aprobado.
Algunas acciones afectan a varias áreas de riesgo ya existentes. Asigne un responsable coordinador y nombre a los responsables que contribuyen, en lugar de crear copias en competencia del mismo control. Registre los desacuerdos de forma explícita. Un mapeo no resuelto es información útil. Una hoja de cálculo ordenada con acuerdo implícito es menos útil.
Pruebe un límite con un ejemplo concreto
Considere un agente hipotético que prepara una instrucción de pago para que un empleado la revise. Pida al responsable técnico que demuestre, en un entorno de prueba apropiado, qué impide que el agente la envíe por sí mismo. La evidencia puede incluir una configuración de roles, los permisos de integración pertinentes y una prueba que muestre que el intento de envío fue rechazado.
Si el agente puede enviar dentro de un límite, registre ese límite diferente y al responsable encargado de ese límite. No reutilice la prueba de solo borrador como evidencia para el flujo de trabajo de envío. Una prueba satisfactoria también necesita una fecha y una referencia de configuración para que un cambio posterior de permisos no herede en silencio el resultado anterior.
Este enfoque ayuda a separar tres preguntas: qué se pretendía que hiciera el sistema, para qué se configuró realmente y qué mostró en verdad la prueba. Cuando esas respuestas difieren, describa la brecha antes de formular una nueva afirmación sobre las garantías que ofrece el sistema. La guía de Maetra sobre cómo mapear sistemas de IA a obligaciones de cumplimiento explica la tarea de mapeo más amplia.
Mantenga una respuesta proporcionada
Un recurso para examinadores publicado recientemente no justifica duplicar todos los procesos de riesgo. Empiece con un caso de uso significativo, encuentre a sus responsables existentes e identifique la evidencia que ya se mantiene. Añada referencias que falten o una prueba acotada cuando el registro actual no pueda responder a una pregunta concreta.
Maetra Comply permite relacionar los sistemas con los requisitos de los marcos aplicables y gestionar evidencias que pueden reutilizarse. Discover permite inventariar los agentes y sus capacidades para determinar qué debe abarcar ese mapeo. Ninguno de los dos establece el cumplimiento regulatorio de un banco ni sustituye su propia evaluación de los requisitos aplicables. Los equipos que exploran este trabajo pueden usar los marcos disponibles de Maetra para planificar un ejercicio de mapeo acotado.