En julio de 2026, el programa BuildFin.ai de la Autoridad Monetaria de Singapur (MAS) publicó SAFR (Safeguards for Agentic Finance at Runtime), un documento técnico redactado con ocho miembros del sector: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC y Visa. SAFR es un enfoque de referencia para una capa de gobernanza en tiempo de ejecución: un punto de control situado entre un agente de IA y los sistemas sobre los que actúa, que evalúa cada acción propuesta antes de que se ejecute. El 9 de octubre de 2026, BuildFin.ai publicó la versión 1.1, que aclara el alcance y el enfoque de implementación, añade casos prácticos y reconoce a tres colaboradores más: DBS, Google y UOB. Dos días antes, la MAS había publicado sus directrices definitivas sobre gestión del riesgo de IA, que fijan las expectativas supervisoras junto a las que se sitúa SAFR.
La tesis del documento cabe en una línea: «no agentic action reaches execution without having been declared, authorised, and assessed» (traducción no oficial: ninguna acción agéntica llega a ejecutarse sin haber sido declarada, autorizada y evaluada).
Esta guía explica la especificación completa: los cuatro componentes de tiempo de ejecución, el sobre de gobernanza, los mandatos, las cuatro disposiciones y sus factores de calibración, la autorización por acción en flujos de varios pasos, los dos patrones de despliegue y la posición de SAFR respecto de las salvaguardas de los modelos (guardrails), las plataformas de cumplimiento y las infraestructuras de liquidación. Está escrita para responsables de cumplimiento, responsables de riesgo de IA y equipos de plataforma que estudian qué exigiría en la práctica adoptar SAFR.
Por qué existe SAFR
Las entidades financieras están desplegando agentes de IA que actúan. Inician pagos, envían órdenes de negociación, aprueban solicitudes de crédito, presentan informes regulatorios y liquidan siniestros de seguros, a menudo con alta frecuencia y sin que ninguna persona revise cada acción concreta. El documento señala cinco ámbitos de aplicación en los que la gobernanza preocupa especialmente: pagos, gestión de la liquidez, triaje de cumplimiento, evaluación crediticia y procesamiento posterior a la operación.
Existe además una dimensión sistémica. Cuando muchas entidades dependen de un número reducido de proveedores comunes de servicios de IA, sus agentes pueden comportarse de forma correlacionada. El Consejo de Estabilidad Financiera (FSB) ha identificado esta correlación como una posible vulnerabilidad sistémica.
En ese contexto, SAFR identifica tres carencias en la infraestructura de gobernanza que las entidades ya utilizan.
Carencia 1: garantía previa a la ejecución. La gestión del riesgo de modelo valida un sistema antes de su despliegue. La auditoría examina lo ocurrido a posteriori. Ninguna de las dos disciplinas detiene una decisión problemática de un agente en el momento previo a su ejecución.
Carencia 2: la interfaz de gobernanza entre personas y agentes. Hoy el escalado a una persona es improvisado (una notificación, una alerta por correo electrónico, un indicador en un panel), sin plazo, sin formato de decisión estándar y sin registro de auditoría. El documento lo describe como «the appearance of human oversight without the substance of it» (traducción no oficial: la apariencia de supervisión humana sin su sustancia).
Carencia 3: fragmentación. Cada despliegue construye sus propias salvaguardas. Los resultados no son interoperables y no pueden auditarse con un formato coherente en toda la entidad.
SAFR propone una respuesta a las tres: un punto de control permanente en la ruta de ejecución, un contrato de escalado estructurado con plazos y registros de decisión, y un formato de gobernanza único y coherente para todos los agentes.
¿Qué es SAFR?
En palabras del propio documento, SAFR «defines data structures, evaluation logic, and escalation contracts for agentic AI deployment. It sits between the agent and the systems it acts on, evaluating proposed actions before execution, while working alongside existing payment rails, settlement protocols, compliance engines, and core banking systems» (traducción no oficial: define estructuras de datos, lógica de evaluación y contratos de escalado para el despliegue de IA agéntica. Se sitúa entre el agente y los sistemas sobre los que actúa, evalúa las acciones propuestas antes de su ejecución y funciona junto a las infraestructuras de pago, los protocolos de liquidación, los motores de cumplimiento y los sistemas de core bancario existentes).
Tres límites importan a quien lo lea con responsabilidades de cumplimiento.
Primero, SAFR no tiene fuerza supervisora. La versión 1.1 es explícita: «It does not constitute regulatory guidance or supervisory expectations, nor does it prescribe or anticipate future directions for such guidance or expectations» (traducción no oficial: No constituye orientación regulatoria ni expectativas supervisoras, ni prescribe o anticipa la evolución futura de dichas orientaciones o expectativas). Cada entidad sigue siendo responsable de determinar cómo se ajusta su despliegue a las expectativas supervisoras aplicables y a sus requisitos internos de gobernanza.
Segundo, SAFR es una especificación sobre la que las entidades construyen. «It serves as an industry reference for institutions to implement within their own infrastructure, using their own rule configurations and governance arrangements» (traducción no oficial: Sirve como referencia del sector para que las entidades la implementen en su propia infraestructura, con sus propias configuraciones de reglas y sus propios mecanismos de gobernanza). No existe ningún servicio SAFR operado por la MAS al que suscribirse.
Tercero, el alcance de SAFR es la decisión en tiempo de ejecución. Define cómo se identifica, autoriza, evalúa y registra una acción propuesta en el momento de actuar. La validación de modelos, la gestión del ciclo de vida y los marcos generales de riesgo de IA quedan a su alrededor (ese ecosistema se trata más abajo).
La situación de SAFR en octubre de 2026
Dos documentos llegaron en la misma semana. El 7 de octubre de 2026, la MAS publicó sus directrices definitivas sobre gestión del riesgo de la inteligencia artificial (AIRG). Entran en vigor el 7 de octubre de 2027, incluyen expresamente a los agentes de IA y aplican los controles del ciclo de vida a más tardar el 7 de octubre de 2028. El 9 de octubre de 2026, BuildFin.ai publicó la versión 1.1 de SAFR.
Las directrices no mencionan SAFR, y la versión 1.1 afirma que SAFR no «prescribe or anticipate future directions» (traducción no oficial: prescribe ni anticipa la evolución futura) de las orientaciones regulatorias ni de las expectativas supervisoras. La MAS no se ha comprometido a hacer obligatorio SAFR; el siguiente paso que ha anunciado sobre agentes es una consulta en 2027 sobre qué orientaciones adicionales en materia de IA agéntica serían útiles. SAFR es una referencia voluntaria, y las AIRG son el documento con el que supervisa la MAS.
En la práctica, ambos documentos se conectan. Las AIRG piden a las entidades financieras que den a los revisores «the necessary authority and ability to intervene» (traducción no oficial: la autoridad y la capacidad necesarias para intervenir), que escalen resultados a revisión humana «where pre-defined conditions … are met» (traducción no oficial: cuando se cumplan condiciones predefinidas…) y que supervisen, cuando proceda, «actions taken, tools used» (traducción no oficial: las acciones ejecutadas, las herramientas utilizadas). Un punto de control de tipo SAFR produce exactamente esos registros para cada acción de un agente. Las fechas y los pasajes específicos sobre agentes se tratan en Las directrices de la MAS sobre gestión del riesgo de IA ya son definitivas.
| Versión | Fecha | Cambios |
|---|---|---|
| 1.0 | 3 de julio de 2026 | Primera publicación, redactada con ocho miembros del sector |
| 1.1 | 9 de octubre de 2026 | Aclara el alcance y el enfoque de implementación; añade casos prácticos; reconoce a DBS, Google y UOB junto a los ocho colaboradores originales |
Los cuatro componentes del tiempo de ejecución de SAFR
La arquitectura de SAFR consta de cuatro componentes que interactúan a través de una estructura de datos compartida, el sobre de gobernanza (Governance Envelope). Cada componente responde a una pregunta sobre una acción propuesta.
La identidad del agente (Agent Identity) vincula cada acción propuesta a un agente registrado y reconocido, y la verifica con la entrada de ese agente en el registro antes de cualquier otra evaluación. En un entorno cerrado, el registro de la propia entidad responde con una consulta directa. En redes abiertas, un agente puede estar inscrito en varias bases de datos de identidad (el registro interno de la entidad, el registro de agentes de una red de pagos, un directorio interinstitucional), y el componente determina qué registro es el autorizado para la acción concreta. Una verificación de identidad fallida produce un rechazo inmediato, que queda anotado en el registro de auditoría.
El repositorio de controles (Controls Repository) es donde la entidad codifica sus reglas. Los controles proceden de políticas de la organización, requisitos regulatorios, reglas de producto y mandatos o facultades otorgados por los usuarios. Los controles genéricos, como las comprobaciones de autorización y los límites de exposición, son deterministas. Los controles específicos de IA, como la calidad de la evidencia y la integridad del sobre, pueden implicar una evaluación probabilística o semántica. Cada control codifica cinco elementos: los tipos de acción permitidos, la lógica de decisión, las condiciones de escalado, un periodo de validez y la autoridad del principal que lo respalda.
El motor de disposiciones (Disposition Engine) evalúa de forma determinista cada acción incluida en el alcance frente a los controles recuperados y produce «a defined, binding outcome for every proposed consequential action calibrated to the specific risk it presents» (traducción no oficial: un resultado definido y vinculante para cada acción consecuente propuesta, calibrado según el riesgo específico que presenta). Los cuatro resultados posibles se explican en detalle más abajo.
El registro de auditoría (Audit Log) anota cada decisión de gobernanza en un formato de solo anexión y con evidencia de manipulación. Cada entrada recoge seis elementos: el sobre de gobernanza tal como se presentó, el mandato con el que se contrastó la acción, el resultado que produjo el motor de disposiciones, las reglas concretas aplicadas, el fundamento de ese resultado y el tiempo transcurrido en cada etapa. Según el documento: «The log is the authoritative record, independent of any party with an interest in how events are characterised after the fact» (traducción no oficial: El registro es la fuente autorizada, independiente de cualquier parte interesada en cómo se describan los hechos a posteriori).
El ciclo de vida une los cuatro componentes. Una acción propuesta se empaqueta en un sobre de gobernanza y se valida que esté completa y sea coherente. La identidad del agente se verifica con el registro correspondiente; si falla, la acción se rechaza de inmediato y el rechazo queda registrado. El repositorio de controles identifica qué controles comprobar. El motor de disposiciones determina los umbrales aplicables y devuelve uno de los cuatro resultados. El registro de auditoría recoge la traza de gobernanza completa de cada resultado, incluidas las acciones que siguieron adelante sin intervención.
| Componente | La pregunta que responde | Qué contiene o hace |
|---|---|---|
| Identidad del agente | ¿Qué agente propone esta acción y está reconocido? | Verifica cada acción con la entrada del agente en el registro antes de cualquier otra evaluación |
| Repositorio de controles | ¿Qué reglas se aplican a esta acción? | El reglamento configurable de la entidad: políticas, requisitos regulatorios, reglas de producto, mandatos de los usuarios |
| Motor de disposiciones | ¿Puede seguir adelante esta acción y en qué condiciones? | Evalúa la acción frente a los controles recuperados y devuelve uno de los cuatro resultados vinculantes |
| Registro de auditoría | ¿Qué se decidió exactamente y por qué? | Un registro inmutable, de solo anexión y con evidencia de manipulación de cada decisión de gobernanza |
El sobre de gobernanza
Antes de que se ejecute cualquier acción agéntica, se empaqueta con el contexto necesario para evaluarla. El sobre contiene tres clases de información.
El documento aborda de frente un problema de integridad del sobre. La traza de la acción y los detalles de la acción los declara el propio agente, de modo que una inyección adversaria sofisticada podría fabricar ambos a la vez: una traza verosímil alrededor de una acción no autorizada. La versión 1.1 expone la consecuencia sin rodeos: «The governance envelope should not be treated as self-verifying» (traducción no oficial: El sobre de gobernanza no debe tratarse como autoverificable). Cuando sea viable, los campos aportados por el agente «should therefore be checked against records captured independently of the agent, such as the initiating instruction, the actual action payload, and system-generated records of tool calls and data access» (traducción no oficial: deben contrastarse, por tanto, con registros capturados con independencia del agente, como la instrucción de origen, el contenido real de la acción y los registros generados por el sistema sobre llamadas a herramientas y accesos a datos), y el sobre debe vincularse al agente, la sesión y el mandato aplicable verificados, y protegerse frente a alteraciones posteriores. Las implementaciones necesitan una forma de verificar en origen que el sobre refleja lo que ocurrió realmente.
| Clase de información | Contenido |
|---|---|
| Acción | El tipo de acción, junto con el alcance y los parámetros de la acción propuesta |
| Traza de la acción | Los pasos que el agente ejecutó realmente hasta llegar a la propuesta: llamadas a herramientas, datos recuperados, comprobaciones realizadas |
| Metadatos de contexto | La identidad del agente, el mandato aplicable, el estado actual de la cuenta o del sistema y las restricciones de política vigentes |
Mandatos y autoridad basada en capacidades
«A mandate is the mechanism through which delegated authority is scoped and expressed in machine-readable form» (traducción no oficial: Un mandato es el mecanismo mediante el cual la autoridad delegada se acota y se expresa en un formato legible por máquina). Cuando un principal autoriza a un agente a actuar en su nombre, el mandato registra esa delegación de forma explícita: qué puede hacer el agente, con qué límites y en qué condiciones.
El diseño se inspira en la seguridad basada en capacidades, una tradición que el documento remonta al trabajo de Dennis y Van Horn de 1966 y que también sustenta OAuth 2.0. La propiedad clave: «An agent cannot extend the scope of a mandate through its own reasoning or inference. Authority is explicit, structured, and defined by the mandate, not inferred by the agent» (traducción no oficial: Un agente no puede ampliar el alcance de un mandato mediante su propio razonamiento o inferencia. La autoridad es explícita, estructurada y definida por el mandato, no inferida por el agente). Por convincente que sea la justificación de un agente para exceder sus límites, el mandato marca la frontera.
El documento cita el Agent Payments Protocol (AP2), con mandatos firmados criptográficamente, como ejemplo destacado del sector.
Las cuatro disposiciones de SAFR: Deny, Escalate, Auto-Execute y Observe
El motor de disposiciones resuelve cada acción incluida en el alcance en uno de cuatro resultados. Los cuatro alimentan el registro de auditoría.
Observe permite a una entidad mantener en marcha la automatización de bajo riesgo mientras construye un registro revisable de los casos que quiere examinar más adelante.
La disposición que recibe una acción es una cuestión de calibración, que se fija en la fase de diseño mediante los parámetros de gobernanza de los controles. El documento cita cinco factores de calibración: reversibilidad de la acción, materialidad financiera, gravedad del impacto en el cliente, sensibilidad regulatoria y novedad o anomalía, es decir, la desviación respecto de los patrones establecidos dentro del mandato. Los perfiles de mayor riesgo desplazan los resultados hacia Deny o Escalate.
| Disposición | Cuándo se aplica | Qué ocurre |
|---|---|---|
| Deny | La acción infringe una restricción regulatoria o de política estricta, o su perfil de riesgo supera los umbrales definidos | Se rechaza antes de ejecutarse y se registra un motivo concreto |
| Escalate | Dentro del alcance y por debajo de las restricciones estrictas, pero por encima del umbral de ejecución autónoma | Queda retenida a la espera de revisión humana antes de continuar |
| Auto-Execute | Dentro del alcance, por debajo de las restricciones estrictas y dentro de los umbrales de riesgo definidos | Sigue adelante sin necesidad de intervención humana |
| Observe | Por debajo del umbral de escalado, pero coincide con un patrón o una señal que la entidad ha configurado como merecedores de atención | Se ejecuta y se registra una observación estructurada para su revisión posterior |
Ninguna autoridad pasa de un paso al siguiente
Los procesos agénticos rara vez constan de una sola acción. Un agente enriquece datos, llama a herramientas, se adapta a resultados intermedios y propone su siguiente paso según lo que acaba de averiguar. La respuesta de SAFR es la gobernanza por acción: el flujo de control se aplica a cada acción del agente de forma independiente.
El documento es preciso sobre la consecuencia: «An Auto-Execute or Observe outcome at one step carries no authority into the next» (traducción no oficial: Un resultado Auto-Execute u Observe en un paso no confiere autoridad alguna para el siguiente). La autorización previa no se arrastra a medida que el agente se adapta a resultados intermedios y a condiciones cambiantes. El tercer paso de un flujo recibe la misma verificación de identidad, la misma recuperación de controles y la misma disposición que el primero. Para las entidades, esto elimina el escenario en el que un agente obtiene una aprobación al principio y luego deriva, plenamente «autorizado», hacia un terreno que nadie revisó.
Los dos patrones de despliegue de SAFR
SAFR describe dos formas de incorporar el punto de control a la arquitectura de una entidad.
El documento ofrece una pauta de secuenciación para las entidades que ya operan agentes: «For institutions with many existing agents, the gateway pattern serves as a practical starting point by establishing coverage first and native instrumentation can follow for new builds» (traducción no oficial: Para entidades con muchos agentes existentes, el patrón de pasarela es un punto de partida práctico porque establece primero la cobertura, y la instrumentación nativa puede llegar después para los nuevos desarrollos). Primero cobertura, después profundidad.
| Patrón | Cómo funciona | Indicado para |
|---|---|---|
| Integración nativa | El agente se instrumenta para emitir un sobre de gobernanza antes de cada acción propuesta; el validador SAFR lo evalúa frente al repositorio de controles y devuelve un resultado antes de que el agente actúe | Nuevos despliegues de agentes; la integración más estrecha, el registro más granular y la pista de auditoría más limpia |
| Integración por pasarela | Una pasarela SAFR intercepta las llamadas API salientes en la capa de infraestructura, envuelve cada llamada en un sobre de gobernanza y la evalúa sin cambios en el código del agente | Sistemas heredados, agentes de terceros, despliegues existentes |
Qué configuran las entidades: las cuatro categorías de control
SAFR deja el reglamento en manos de la entidad. Su tabla 1 define cuatro categorías de control que una implementación debe admitir.
Dos notas de diseño del documento destacan. Los límites de exposición deben reflejar los marcos de delegación de facultades que la entidad ya aplica a las personas, de modo que la autoridad de los agentes encaje en un vocabulario de gobernanza existente. Y la calidad de la evidencia funciona con independencia del importe: una acción con baja confianza se deriva a una persona aunque la cantidad en juego sea mínima.
| Categoría de control | Qué define la entidad |
|---|---|
| Autorización | Qué agentes pueden actuar en nombre de qué principales; quién puede delegar autoridad en quién y con qué profundidad; qué tipos de acción puede iniciar cada clase de agente |
| Límites de exposición | Umbrales de importe por acción y agregados; por debajo se permiten acciones autónomas; por encima se exige revisión humana o la acción se bloquea |
| Límites de frecuencia | Número máximo de acciones por ventana temporal; protege frente a agentes desbocados, errores en fuentes de datos e inyecciones de prompts adversarias que provocan una velocidad o un volumen anómalos |
| Calidad de la evidencia | Umbral mínimo de confianza y evidencia exigida para la ejecución autónoma; las acciones en las que la confianza declarada por el agente queda por debajo del umbral se derivan a revisión humana sea cual sea su importe |
Cómo operar la ruta de escalado
Una disposición Escalate vale lo que vale el proceso de revisión humana que la respalda. SAFR señala tres dimensiones operativas que las entidades deben diseñar de forma deliberada.
Volumen de escalados. Una función de escalado que genera más revisiones de las que la entidad puede tramitar con criterio frustra su propio propósito. Los umbrales deben calibrarse frente a la capacidad real de los revisores.
Plazo de revisión. Los escalados deben incluir una ventana de expiración. Si no llega ninguna decisión dentro de ella, la opción por defecto es bloquear la acción o escalarla a un revisor de mayor rango. La ventana debe reflejar la disponibilidad real de los revisores, incluida la cobertura nocturna y de fin de semana.
Autoridad del revisor. Los revisores deben tener autoridad clara para aprobar, modificar o rechazar la acción, y sus decisiones «carry the same institutional weight as the original agent decision» (traducción no oficial: tienen el mismo peso institucional que la decisión original del agente). Un revisor que solo puede dar el visto bueno reproduce la carencia que SAFR quiere cerrar.
La autoridad también tiene que ser visible. La primera vez que procesamos casos de AML en nuestros propios tenants de prueba como usuario de cumplimiento, un revisor podía abrir un caso escalado y verlo marcado como de solo lectura, sin ningún motivo. Decision Desk indica ahora por qué una persona no puede decidir: le falta un permiso, no pertenece al grupo de aprobadores o es quien creó la solicitud. Una separación creador-verificador que el revisor no ve parece una herramienta averiada.
Dónde se sitúa SAFR en la arquitectura
Una forma útil de leer SAFR es como una capa con vecinos definidos. El flujo: el agente de IA produce una acción propuesta (sus salvaguardas pueden condicionar esa salida); SAFR verifica la identidad y la autoridad del agente, evalúa la acción frente a los controles de forma determinista y devuelve Auto-Execute, Observe, Escalate o Deny; las infraestructuras financieras ejecutan la acción si y solo si fue aprobada.
Respecto de las salvaguardas de IA. El filtrado de contenido, las defensas contra la inyección de prompts y el filtrado de salidas suelen ser probabilísticos y gobiernan lo que produce el modelo. Determinar si una acción financiera propuesta está autorizada y puede ejecutarse es una cuestión distinta, y es la que resuelve SAFR. SAFR actúa después del filtrado de contenido y antes de la ejecución.
Respecto de las plataformas de cumplimiento. SAFR genera el registro de gobernanza estructurado que las plataformas de cumplimiento existentes pueden aprovechar. No replica sus evaluaciones.
Respecto de las infraestructuras de liquidación. Los esquemas de pago y las infraestructuras de liquidación mueven el dinero. SAFR gobierna la decisión de moverlo. Los controles de la capa de liquidación (reglas de las redes de tarjetas, estándares SWIFT, reglas ACH, el Machine Payments Protocol (MPP), Purpose Bound Money (PBM), controles de stablecoins) actúan después de que SAFR haya determinado si el agente puede actuar.
Respecto de un producto. SAFR es una especificación. La MAS no vende ningún servicio gestionado; cada entidad implementa el patrón en su propia infraestructura o adopta herramientas que lo implementan.
Quién redactó SAFR y el ecosistema que lo rodea
SAFR surgió de una línea de trabajo específica que la MAS creó en su programa BuildFin.ai para desarrollar recursos de implementación frente a los riesgos de la IA agéntica. La versión 1.0 se redactó con ocho miembros del sector: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC y Visa. La versión 1.1 reconoce a once colaboradores, con la incorporación de DBS, Google y UOB, y añade casos prácticos. El documento fundamenta la especificación en casos prácticos de los miembros, entre ellos: el Agentic Treasury Protocol de Ant International, Agent Pay y Agentic Tokens de Mastercard, Visa Intelligent Commerce, el Agent Wallet de Circle, ERC-8004, Circle Payments Network y Compliance Engine, OCBC con el Source of Wealth Assistant (SOWA) de Bank of Singapore junto a un agente interno de banca corporativa que elabora informes de mercado y de inteligencia de clientes, y el trabajo de Manulife en apoyo comercial con IA generativa. HSBC y J.P. Morgan Chase contribuyeron al documento sin casos prácticos con nombre propio.
SAFR también tiene vecinos definidos en la literatura sobre gobernanza. Project MindForge (la MAS con un consorcio de entidades financieras de banca, seguros y mercados de capitales) inició su fase 2 en noviembre de 2024 y publicó sus resultados en el Singapore FinTech Festival de noviembre de 2025: un Executive Handbook con 17 consideraciones repartidas en cuatro secciones (alcance y supervisión, gestión del riesgo de IA, gestión del ciclo de vida de la IA, facilitadores) y un Operationalisation Handbook que cubre el mínimo privilegio en el acceso de los agentes a herramientas y datos, la certificación de agentes, el reparto de responsabilidades en la fase de diseño, los interruptores de emergencia y los tiempos de expiración, y la trazabilidad mediante registros consultables. El Model AI Governance Framework for Agentic AI de IMDA (2026) estructura los sistemas agénticos en torno a cuatro componentes centrales (modelos, memoria, herramientas, acciones) y un modelo de gobernanza en cuatro partes (acotación de casos de uso, limitación del acceso, supervisión humana, responsabilidad según la jerarquía de principales). El AI RMF del NIST (2023) aporta el ciclo Map, Measure, Manage, Govern. SAFR es la capa específica del tiempo de ejecución de ese conjunto: las estructuras de datos, la lógica de evaluación y los contratos de escalado para el momento de actuar.
El documento termina con una invitación abierta: «FinTechs and financial institutions are invited to contribute to SAFR and the BuildFin.ai working group by sharing pilot findings, identifying gaps in the specification, and raising domain requirements not yet addressed» (traducción no oficial: Se invita a las fintech y a las entidades financieras a contribuir a SAFR y al grupo de trabajo de BuildFin.ai compartiendo resultados de proyectos piloto, señalando carencias en la especificación y planteando requisitos de dominio que aún no se han abordado).
Qué hacer a continuación
Para un equipo que evalúa su situación frente a SAFR, el primer paso útil es un análisis de carencias estructurado según las dimensiones del propio documento: inventario e identidad de los agentes, mandatos, controles, disposiciones, sobre y trazabilidad, operaciones de escalado, auditoría y evidencia, y patrón de despliegue. La lista de verificación de preparación para SAFR recorre unas 35 preguntas de tipo evaluador en esas ocho secciones y puntúa la preparación por sección, con una versión en hoja de cálculo editable para las sesiones de trabajo.
Los equipos que ya han superado la evaluación y planifican el desarrollo deben leer el artículo complementario, Cómo implementar SAFR: arquitectura, patrones y desarrollo propio frente a compra, que cubre la arquitectura de referencia, ejemplos de controles calibrados y un análisis de desarrollo propio frente a compra.
Cómo se corresponde KLA con SAFR
KLA Control Plane implementa el patrón SAFR y está disponible hoy: Agent Registry para la identidad del agente, Policy Builder para el repositorio de controles, KLA Policy Engine para el motor de disposiciones y Audit Trail para el registro de auditoría, con las cuatro disposiciones asignadas una a una: Deny a block, Escalate a require_approval, Auto-Execute a allow y Observe a warn. La correspondencia completa componente por componente, con los requisitos operativos y los indicadores de estado actuales, está en la página de implementación de SAFR.
Preguntas frecuentes
¿Qué significa SAFR?
SAFR significa Safeguards for Agentic Finance at Runtime (salvaguardas para las finanzas agénticas en tiempo de ejecución). Es un documento técnico publicado por el programa BuildFin.ai de la Autoridad Monetaria de Singapur (versión 1.0 el 3 de julio de 2026, versión 1.1 el 9 de octubre de 2026) que describe un enfoque de referencia para una capa de gobernanza en tiempo de ejecución de la IA agéntica en los servicios financieros.
¿Es obligatorio SAFR?
No. La versión 1.1 (9 de octubre de 2026) afirma que SAFR «does not constitute regulatory guidance or supervisory expectations, nor does it prescribe or anticipate future directions for such guidance or expectations» (traducción no oficial: no constituye orientación regulatoria ni expectativas supervisoras, ni prescribe o anticipa la evolución futura de dichas orientaciones o expectativas). La MAS no se ha comprometido a hacerlo obligatorio, y sus directrices definitivas sobre gestión del riesgo de IA (7 de octubre de 2026) no lo mencionan. Cada entidad sigue siendo responsable de determinar cómo se ajusta su despliegue a las expectativas supervisoras aplicables y a sus requisitos internos de gobernanza.
¿Qué relación tiene SAFR con las directrices de la MAS sobre gestión del riesgo de IA?
Las directrices, publicadas el 7 de octubre de 2026 y aplicables desde el 7 de octubre de 2027, fijan las expectativas supervisoras de la MAS sobre la IA, incluidos los agentes de IA. SAFR es una referencia voluntaria para el tiempo de ejecución. Un punto de control de tipo SAFR produce los registros de supervisión y seguimiento por acción que piden las directrices; cumplir las directrices no depende de adoptar SAFR. Consulte Las directrices de la MAS sobre gestión del riesgo de IA ya son definitivas.
¿Quién publicó SAFR?
El programa BuildFin.ai de la MAS, a través de una línea de trabajo creada para desarrollar recursos de implementación frente a los riesgos de la IA agéntica. La versión 1.0 se redactó con ocho miembros del sector: Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC y Visa. La versión 1.1 reconoce además a DBS, Google y UOB.
¿Cuáles son las cuatro disposiciones de SAFR?
Deny (la acción infringe una restricción estricta o supera los umbrales de riesgo y se rechaza antes de ejecutarse, con un motivo concreto registrado), Escalate (la acción queda retenida a la espera de revisión humana), Auto-Execute (la acción sigue adelante sin necesidad de intervención humana) y Observe (la acción se ejecuta y se registra una observación estructurada para su revisión posterior). Los cuatro resultados quedan anotados en el registro de auditoría.
¿Qué es un sobre de gobernanza?
La estructura de datos que empaqueta una acción propuesta por un agente con el contexto necesario para evaluarla antes de su ejecución. Contiene tres clases de información: la acción (tipo, alcance, parámetros), la traza de la acción (las llamadas a herramientas, la recuperación de datos y las comprobaciones que el agente realizó realmente) y los metadatos de contexto (identidad del agente, mandato aplicable, estado de la cuenta o del sistema, restricciones de política vigentes). Como su contenido lo aporta el agente, la versión 1.1 indica que el sobre «should not be treated as self-verifying» (traducción no oficial: no debe tratarse como autoverificable): cuando sea viable, sus campos deben contrastarse con registros capturados con independencia del agente.
¿Qué relación tiene SAFR con Project MindForge?
Ambos nacen de la colaboración entre la MAS y el sector. Project MindForge publica manuales generales sobre la gobernanza de la IA agéntica a lo largo de todo el ciclo de vida de la IA: un Executive Handbook con 17 consideraciones y un Operationalisation Handbook que cubre prácticas como el mínimo privilegio, la certificación de agentes, los interruptores de emergencia y la trazabilidad. SAFR es la referencia específica para el tiempo de ejecución: estructuras de datos concretas, lógica de evaluación y contratos de escalado para evaluar cada acción propuesta antes de que se ejecute.
¿Se aplica SAFR fuera de Singapur?
SAFR no tiene fuerza supervisora en ninguna jurisdicción, por lo que una entidad de cualquier país puede implementarlo como referencia del sector, sin dejar de ser responsable de ajustar el despliegue a las expectativas de sus propios supervisores. Para ver cómo se relaciona SAFR con la Ley de IA de la UE y con FINMA, consulte SAFR, la Ley de IA de la UE y FINMA: los reguladores convergen en la evidencia en tiempo de ejecución.
¿Hay que cambiar el código de los agentes para adoptar SAFR?
SAFR define dos patrones de despliegue. La integración nativa instrumenta el agente para que emita un sobre de gobernanza antes de cada acción propuesta, y el documento la recomienda para los nuevos despliegues. La integración por pasarela intercepta las llamadas API salientes en la capa de infraestructura y envuelve cada una en un sobre de gobernanza sin cambios en el código del agente; así pueden someterse a gobernanza los sistemas heredados, los agentes de terceros y los despliegues existentes. El documento sugiere empezar por la cobertura mediante pasarela en las entidades con muchos agentes existentes y añadir después la instrumentación nativa en los nuevos desarrollos.
Conclusiones clave
SAFR ofrece al sector un vocabulario común y concreto para gobernar a los agentes de IA en el momento en que actúan: verificación de identidad, mandatos explícitos, disposiciones deterministas y un registro de auditoría que se sostiene por sí solo. Es un enfoque de referencia voluntario, publicado para que las entidades lo implementen en su propia infraestructura, y la línea de trabajo que lo respalda solicita abiertamente resultados de proyectos piloto e informes de carencias. Las directrices definitivas de la MAS sobre gestión del riesgo de IA fijan las expectativas supervisoras; SAFR es una forma de producir la evidencia en tiempo de ejecución que piden.
La secuencia práctica para la mayoría de los equipos: puntúe su situación actual con la lista de verificación de preparación para SAFR y lea después la guía de implementación de SAFR para planificar el desarrollo.
Fuentes: Safeguards for Agentic Finance at Runtime, documento técnico v1.0 (3 de julio de 2026) y v1.1 (9 de octubre de 2026), MAS BuildFin.ai; MAS, Guidelines on Artificial Intelligence Risk Management, 7 de octubre de 2026. Pasajes citados © Monetary Authority of Singapore. SAFR es una referencia del sector y no constituye orientación regulatoria ni expectativas supervisoras. KLA es independiente de la MAS y de BuildFin.ai, y no está afiliada a ellas ni cuenta con su respaldo o certificación.