Safeguards for Agentic Finance at Runtime (SAFR) es un enfoque de referencia para una capa de gobernanza en tiempo de ejecución de la IA agéntica en los servicios financieros, publicado en julio de 2026 por el programa BuildFin.ai de la MAS y redactado con Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC y Visa. La versión 1.1, publicada el 9 de octubre de 2026, aclara el alcance y el enfoque de implementación y suma a DBS, Google y UOB a los colaboradores reconocidos. SAFR es voluntario: la versión 1.1 afirma que «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), y la MAS no se ha comprometido a hacerlo obligatorio. La referencia supervisora en Singapur son las directrices definitivas sobre gestión del riesgo de IA que la MAS publicó el 7 de octubre de 2026. El documento técnico «defines data structures, evaluation logic, and escalation contracts for agentic AI deployment» (traducción no oficial: define estructuras de datos, lógica de evaluación y contratos de escalado para el despliegue de IA agéntica). La implementación queda en manos de cada entidad: SAFR «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).
Esta guía cubre las decisiones de ingeniería que exige la implementación: la arquitectura de referencia, la elección entre despliegue nativo y por pasarela, qué codificar en los controles, la calibración de las disposiciones, las operaciones de escalado, la capa de evidencia, un mandato y un registro de decisión de ejemplo, y un análisis de desarrollo propio frente a compra. Para el marco en sí (los cuatro componentes, el sobre de gobernanza, los mandatos y el ecosistema en torno a SAFR), empiece por SAFR, explicado. Para la correspondencia de KLA componente por componente, consulte la página de implementación de SAFR.
La arquitectura de referencia de SAFR
SAFR «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: 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). El objetivo de diseño, en palabras del documento: «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). Una implementación es una cadena de etapas con un orden fijo y un registro de auditoría que anota cada una de ellas.
La cadena funciona así. El agente propone una acción. Antes de que nada se ejecute, la propuesta se empaqueta en un sobre de gobernanza que contiene tres clases de información: la acción en sí (tipo, alcance, parámetros), la traza de la acción (los pasos que el agente ejecutó realmente para llegar a la propuesta, incluidas las llamadas a herramientas, los datos recuperados y las comprobaciones realizadas) y los metadatos de contexto (identidad del agente, mandato aplicable, estado actual de la cuenta o del sistema y restricciones de política vigentes). Se valida que el sobre esté completo y sea coherente. A continuación, la identidad del agente se verifica con el registro autorizado; si la verificación falla, la acción se rechaza de inmediato y el rechazo queda anotado en el registro de auditoría. El repositorio de controles identifica qué controles de la entidad se aplican. El motor de disposiciones evalúa la acción frente a esos controles y devuelve uno de los cuatro resultados vinculantes: Deny, Escalate, Auto-Execute u Observe. Las infraestructuras financieras ejecutan la acción si y solo si el resultado lo permite, y el registro de auditoría recoge la traza de gobernanza completa de cada resultado, incluidas las denegaciones.
La integridad del sobre es un problema de diseño de primer orden. La traza y los detalles de la acción los declara el propio agente, y una inyección adversaria sofisticada puede fabricar ambos a la vez. La versión 1.1 lo dice 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 deben contrastarse 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 verificados. En la práctica, esto lleva a capturar el sobre en un punto que el agente no puede falsificar (dentro de la ruta de ejecución o en el perímetro de red), y es el argumento más sólido para elegir el patrón de despliegue de forma deliberada.
| Componente | Función | Nota de implementación |
|---|---|---|
| Identidad del agente | 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 entornos cerrados, una consulta directa al registro de la propia entidad; en redes abiertas, el componente debe determinar cuál de varios registros (interno, de una red de pagos, interinstitucional) es el autorizado |
| Repositorio de controles | El reglamento configurable de la entidad, basado en políticas de la organización, requisitos regulatorios, reglas de producto y mandatos aportados por los usuarios | Los controles genéricos (comprobaciones de autorización, límites de exposición) son deterministas; los controles específicos de IA (calidad de la evidencia, integridad del sobre) pueden implicar una evaluación probabilística o semántica |
| Motor de disposiciones | Evalúa de forma determinista cada acción incluida en el alcance frente a los controles recuperados | 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) |
| Registro de auditoría | Un registro inmutable, de solo anexión y con evidencia de manipulación de cada decisión de gobernanza | Recoge los cuatro resultados; consulte más abajo la sección sobre la capa de evidencia |
Nativo o pasarela: cómo elegir el patrón de despliegue
El documento técnico define dos patrones de integración, y la mayoría de las entidades acabarán usando ambos. SAFR, explicado describe la mecánica de cada patrón, la emisión del sobre desde el agente y la interceptación por pasarela en la capa de infraestructura; la decisión de implementación es cuándo elegir cada uno.
La versión 1.1 añade una precisión sobre la topología: SAFR «does not require implementation as a single central platform within an institution» (traducción no oficial: no exige implementarse como una única plataforma central dentro de una entidad). Sus componentes pueden funcionar como servicio central, dentro de cada despliegue de agentes, como servicios institucionales compartidos o de forma híbrida, siempre que cada acción incluida en el alcance pase por las funciones SAFR necesarias antes de ejecutarse y que todas las implementaciones sigan estándares comunes para los sobres, los resultados de disposición, la semántica de los controles y la auditabilidad.
La pauta de secuenciación procede directamente del documento: «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). En concreto: las nuevas capacidades llevan instrumentación nativa desde el primer día y el parque existente queda detrás de una pasarela. Conecte ambos patrones a un único repositorio de controles, un único motor de disposiciones y un único registro de auditoría, para que un parque mixto produzca un registro de gobernanza único y coherente.
| Patrón | Cuándo elegirlo |
|---|---|
| Integración nativa | Nuevos despliegues de agentes, en los que instrumentar el agente ofrece la integración más estrecha, el registro más granular y la pista de auditoría más limpia |
| Integración por pasarela | Sistemas heredados, agentes de terceros y despliegues existentes, en los que la cobertura tiene que llegar sin cambios en el código del agente |
Qué codificar en los controles SAFR
Un control SAFR 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 en cuyo nombre actúa el agente. Los controles se basan en cuatro fuentes: políticas de la organización, requisitos regulatorios, reglas de producto y mandatos aportados por los usuarios.
El mandato es el punto de anclaje. «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): qué puede hacer el agente, con qué límites y en qué condiciones. «An agent cannot extend the scope of a mandate through its own reasoning or inference» (traducción no oficial: Un agente no puede ampliar el alcance de un mandato mediante su propio razonamiento o inferencia). El diseño procede de la seguridad basada en capacidades, el modelo que sustenta OAuth 2.0; el documento cita el Agent Payments Protocol (AP2), con sus mandatos firmados criptográficamente, como ejemplo destacado del sector.
El documento agrupa los controles en cuatro categorías:
| Categoría | Qué codificar | Qué probar |
|---|---|---|
| Autorización | Vínculos entre agente y principal, profundidad de delegación y una lista de tipos de acción permitidos por clase de agente, todo ello resoluble en el momento de la evaluación | Un tipo de acción que no figura en la lista se deniega aunque lo proponga un agente correctamente registrado; una delegación más profunda que la codificada se deniega |
| Límites de exposición | Umbrales por acción y ventanas agregadas tomados del marco de delegación de facultades existente, con las bandas Auto-Execute, Escalate y Deny expresadas como importes explícitos | Una acción que superaría el margen restante de una ventana agregada se escala aunque su propio importe esté dentro de la banda por acción |
| Límites de frecuencia | Un número máximo de acciones por ventana temporal para cada clase de agente, con un resultado definido para las acciones que superen el límite | Una ráfaga por encima del límite, sea cual sea su causa (agente desbocado, error en una fuente de datos, inyección adversaria), se deniega y se marca para su investigación |
| Calidad de la evidencia | La evidencia exigida para cada tipo de acción y el umbral mínimo de confianza declarada para la ejecución autónoma; la calibración de tesorería de más abajo exige un registro de factura conciliado para cada pago | Una acción cuya confianza declarada quede por debajo del umbral se deriva a revisión humana sea cual sea su importe; pruébelo con una coincidencia de evidencia deliberadamente débil |
Calibración de controles para un agente de pagos de tesorería
Así queda esa calibración para un agente de pagos de tesorería. Los valores son ilustrativos; fije los suyos a partir de su marco de delegación de facultades.
En un agente de triaje de cumplimiento (enriquecimiento de alertas, propuestas de disposición de riesgos, preparación de comunicaciones a las autoridades), los controles que soportan la carga son los umbrales de calidad de la evidencia: el cierre automático de una alerta exige que se cumpla el contrato de evidencia en el umbral o por encima de él, las disposiciones de alto riesgo propuestas se escalan a un revisor designado y cualquier acción que suprimiría una alerta abierta se deniega directamente. Recorremos ese proceso de principio a fin, a través de los cuatro componentes, en SAFR para AML y triaje de cumplimiento.
| Control | Valor ilustrativo |
|---|---|
| Autorización | La clase de agente treasury-payments puede iniciar pagos a proveedores y pagos intragrupo con Operaciones de Tesorería como principal. Profundidad de delegación 1: el agente puede ostentar autoridad delegada y no puede subdelegarla en ningún otro agente |
| Límite de exposición por acción | Auto-Execute por debajo de US$25,000. Escalate de US$25,000 a US$250,000. Deny por encima de US$250,000, el techo de la delegación de facultades de la mesa |
| Ventana de exposición agregada | US$500,000 por periodo móvil de 24 horas; un pago que superaría el margen restante de la ventana se escala |
| Límite de frecuencia | Máximo de 20 inicios de pago por hora; las acciones que superan el límite se deniegan y se marcan para su investigación |
| Calidad de la evidencia | Cada pago debe hacer referencia a un registro de factura conciliado; una coincidencia por debajo del umbral de confianza se escala a revisión humana sea cual sea el importe |
| Periodo de validez | Mandato válido durante el trimestre en curso; las acciones propuestas fuera del periodo de validez se deniegan |
Calibración de las cuatro disposiciones
Cada acción incluida en el alcance se resuelve en uno de los cuatro resultados del motor de disposiciones:
Los cuatro resultados alimentan el registro de auditoría. La asignación depende de cinco factores de calibración que cita el documento: 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. La calibración se fija en la fase de diseño mediante los parámetros de gobernanza de los controles; por eso el plan piloto de más abajo reserva una semana completa para ajustarla con tráfico real.
Observe merece una atención de diseño deliberada: permite que un control nuevo funcione con tráfico real y genere material de revisión estructurado mientras la ejecución continúa, el entorno natural para los umbrales que piensa endurecer después de ver el comportamiento real.
Calibre con datos históricos. Cuando realizamos en octubre de 2026 un ejercicio de incorporación bancaria en nuestros propios tenants de prueba, con perfiles guionizados para el administrador del banco, el responsable de cumplimiento y el aprobador, concluimos que los casos de prueba de políticas construidos a mano con muchos campos son poco prácticos: un responsable de cumplimiento no va a escribir pruebas unitarias para una política. Lo que funciona es reproducir las ejecuciones recientes con los controles en borrador y mostrar el cambio respecto de lo que ocurrió, por ejemplo cuántas acciones más habrían pasado a revisión humana. Esa cifra responde a la cuestión de la capacidad de los revisores, y debe llegar a las personas que van a atender la cola.
| Disposición | Qué codificar | Qué probar |
|---|---|---|
| Deny | Las restricciones regulatorias y de política estrictas, y los umbrales de riesgo por encima de los cuales una acción se rechaza directamente; en la calibración de tesorería, los importes superiores a US$250,000, el techo de la delegación de facultades de la mesa | Una acción que infringe una restricción nunca llega a la infraestructura de pago, y su entrada en el registro de auditoría indica la regla que se activó y el motivo concreto |
| Escalate | Las condiciones de escalado de cada control, que marcan dónde termina la banda autónoma por debajo del techo de Deny; de US$25,000 a US$250,000 para el agente de tesorería | El tráfico simulado genera un volumen de Escalate que el equipo de revisión puede absorber, y cada escalado lleva una ventana de expiración cuyo resultado por defecto es el bloqueo o el paso a un revisor de mayor rango |
| Auto-Execute | La banda autónoma que deja abierta cada control: los tipos de acción, los importes y las condiciones en los que la ejecución sigue adelante sin ningún revisor de por medio | Cada acción ejecutada automáticamente de la muestra presenta una traza de gobernanza completa: sobre, reglas aplicadas, fundamento y tiempos por etapa |
| Observe | Los patrones y las señales configurados como merecedores de atención por debajo del umbral de escalado, cada uno de los cuales produce una observación estructurada mientras la acción se ejecuta | Las observaciones pueden recuperarse y consultarse cuando llega el momento de revisar los umbrales |
Operaciones de escalado: diséñelas antes de la puesta en producción
El documento describe el escalado habitual de hoy como una notificación, una alerta por correo electrónico o un indicador en un panel, sin plazo, sin formato de decisión estándar y sin registro de auditoría: «the appearance of human oversight without the substance of it» (traducción no oficial: la apariencia de supervisión humana sin su sustancia). Una implementación de SAFR lo sustituye por una operación diseñada en tres dimensiones.
Volumen. «An escalation function that generates more reviews than the institution can meaningfully process defeats its own purpose» (traducción no oficial: Una función de escalado que genera más revisiones de las que la entidad puede tramitar con criterio frustra su propio propósito). Dimensione los umbrales según la capacidad real de los revisores; si la simulación produce más resultados Escalate de los que el equipo puede absorber, corrija los controles antes del lanzamiento.
Plazo. Cada escalado debe llevar 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. Fije la ventana según la disponibilidad real de los revisores, incluida la cobertura nocturna y de fin de semana.
Autoridad. Los revisores necesitan autoridad clara para aprobar, modificar o rechazar, 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). Eso implica revisores individuales identificados, una justificación registrada en cada decisión y definiciones de funciones que encajen en la jerarquía de aprobación existente.
Vuelva a autorizar cada paso
En los procesos de varios pasos, el flujo de control se aplica a cada acción del agente de forma independiente. «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), porque el agente se adapta a resultados intermedios y a condiciones cambiantes mientras trabaja.
Esta sola frase tiene grandes consecuencias para la implementación. La ruta de evaluación debe ser lo bastante rápida para ejecutarse en cada acción, así que la latencia forma parte del presupuesto de ingeniería desde el principio. Los mandatos deben poder resolverse acción por acción. El diseño excluye almacenar aprobaciones en caché a nivel de sesión. Y un flujo de diez pasos produce diez trazas de gobernanza, cada una con su propio sobre, su disposición y su fundamento: exactamente lo que buscará un inspector que reconstruya la ejecución.
La capa de evidencia: el registro de auditoría de SAFR
Cada entrada del registro de auditoría 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. El registro es inmutable, de solo anexión y con evidencia de manipulación. El estándar del 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).
Ese estándar está por encima de lo que ofrece el registro habitual de las aplicaciones, y tres propiedades requieren ingeniería desde el principio: escrituras de solo anexión, para que los registros se acumulen y nunca cambien; evidencia de manipulación, en la práctica mediante encadenamiento criptográfico, para que cualquier alteración de un registro anterior sea detectable; y verificabilidad independiente, es decir, que un auditor pueda confirmar la integridad de un registro exportado sin acceder a la plataforma que lo produjo. Guarde la evidencia antes de devolver la disposición. Si una acción puede ejecutarse mientras su registro todavía está en tránsito, un fallo puede dejar acciones ejecutadas sin traza de gobernanza.
Un mandato y un registro de decisión de ejemplo
El ejemplo siguiente es sintético. Northbridge Bank es una entidad ficticia, y los nombres, importes e identificadores son ilustrativos. Utiliza la calibración de tesorería anterior y sigue un mandato desde la delegación hasta la evidencia.
El mandato. El responsable de Operaciones de Tesorería de Northbridge delega los pagos a proveedores y los pagos intragrupo en un agente registrado, treasury-payments, versión 3.2. El mandato es el límite escrito de esa delegación. La entidad lo redacta a partir de su marco de delegación de facultades existente, lo versiona y lo aprueba mediante la misma revisión que aplica a los cambios de política.
| Campo | Valor |
|---|---|
| Mandato | mnd-treasury-ops-2026q4, versión 2, aprobado por el responsable de Operaciones de Tesorería y por Riesgos de Tesorería |
| Principal | Operaciones de Tesorería, Northbridge Bank |
| Agente | treasury-payments, versión 3.2, inscrito en el registro de agentes con un responsable designado |
| Tipos de acción permitidos | Pago a un proveedor ya dado de alta; transferencia intragrupo entre cuentas del grupo incluidas en la lista |
| Límites por acción | Autónomo por debajo de US$25,000; aprobación humana de US$25,000 a US$250,000; nada por encima de US$250,000 |
| Ventana agregada | US$500,000 por periodo móvil de 24 horas; cualquier acción que superaría el margen restante requiere aprobación |
| Evidencia exigida | Una referencia conciliada a una factura o a un acuerdo intragrupo, con una confianza de coincidencia de al menos 0.90 para la ejecución autónoma |
| Señales que justifican revisión | Primer pago a un beneficiario en 90 días; datos bancarios del beneficiario modificados en los últimos 30 días |
| Fuera del mandato | Dar de alta beneficiarios, modificar los datos bancarios de un beneficiario, subdelegar en otro agente, pagar desde cuentas que no figuran en la lista |
| Validez | Del 1 de octubre al 31 de diciembre de 2026 |
El límite de la delegación y los cuatro resultados
Las dos últimas filas del mandato trazan el límite de la delegación. Todo lo que queda fuera se deniega, sea cual sea el razonamiento que ofrezca el agente, porque «an agent cannot extend the scope of a mandate through its own reasoning or inference» (traducción no oficial: un agente no puede ampliar el alcance de un mandato mediante su propio razonamiento o inferencia). Dentro del límite, los controles clasifican cada acción propuesta en una de las cuatro disposiciones de SAFR. KLA Control Plane expresa esos mismos cuatro resultados como allow, warn, require_approval y block.
Cuatro acciones que el agente propuso una misma mañana muestran cada resultado. Cada fila se evaluó por separado, sin ninguna autoridad heredada de la fila anterior.
| Acción propuesta | Qué encontraron los controles | Disposición SAFR | Resultado KLA |
|---|---|---|---|
| Pagar US$8,400 a un proveedor de material de oficina | Beneficiario existente, factura conciliada con 0.97, dentro de los límites por acción y agregados | Auto-Execute | allow: se ejecuta; la decisión queda registrada |
| Pagar US$19,600 a un proveedor logístico | Dentro de los límites y conciliada con 0.94, pero es el primer pago a este beneficiario en 112 días | Observe | warn: se ejecuta; la observación queda en cola para la revisión semanal de tesorería |
| Pagar US$118,000 a un proveedor de software | Factura conciliada con 0.96; importe dentro de la banda de aprobación | Escalate | require_approval: retenido para un revisor designado como Decision Request en Decision Desk |
| Pagar US$310,000 a un contratista de obras | Por encima del techo de US$250,000 de la delegación de facultades | Deny | block: rechazado antes de llegar a la infraestructura de pago; motivo registrado |
Un caso de aprobación de principio a fin
09:41. El agente propone el pago de US$118,000. El sobre contiene la instrucción de pago, la traza de la acción (consulta de la factura, consulta del contrato, comprobación del beneficiario) y el contexto: identidad del agente, versión 2 del mandato y el total acumulado en 24 horas hasta ese momento, US$212,000. La verificación de identidad es correcta. El control por acción devuelve Escalate; el control agregado es conforme y deja un margen de US$170,000 después de este pago.
09:41. La acción queda retenida. Una solicitud de revisión llega al grupo de aprobadores de tesorería con la acción propuesta, la factura y los controles que se activaron. Northbridge fija una expiración de cuatro horas para esta clase de escalado, con block como resultado por defecto.
10:17. Un responsable de tesorería abre la solicitud, compara la factura con la orden de compra y el contrato marco de servicios, y aprueba con la justificación «Renovación anual de licencia; la PO 4471 y la cláusula 6.2 del MSA coinciden con la factura INV-20931». La aprobación se aplica solo a este pago.
10:17. El pago se libera hacia la infraestructura de pago, que devuelve una referencia de pago. El registro se cierra con el resultado de la ejecución.
Dos decisiones de diseño de este caso proceden de un proceso de liberación de pagos retenidos que construimos en nuestro propio tenant de demostración para una sesión informativa con analistas en octubre de 2026, con pagos sintéticos. Primera: cada decisión humana tiene exactamente una puerta de aprobación. La primera vez que enviamos ese proceso a revisión fue rechazado porque dos pasos humanos llevaban además un indicador de aprobación independiente, lo que habría creado dos tareas de aprobación para una sola decisión; eliminamos los indicadores y dejamos una puerta por decisión. Segunda: la política envía a aprobación cualquier caso que ninguna regla haya previsto. En nuestra primera política de prueba de AML, el resultado por defecto sin coincidencia era block, y los casos imprevistos se detenían sin llegar nunca a un revisor.
Si el responsable no hubiera respondido antes de las 13:41, la solicitud habría expirado y la acción se habría bloqueado, con la expiración registrada. Si el responsable la hubiera rechazado, el agente habría recibido un block con el motivo del revisor, y una nueva propuesta para el mismo pago se evaluaría desde el principio.
La evidencia que deja el caso
SAFR enumera los elementos que debe recoger cada entrada de auditoría: el sobre tal como se presentó, el mandato con el que se contrastó la acción, el resultado, las reglas concretas aplicadas, el fundamento del resultado y el tiempo transcurrido en cada etapa. El caso de aprobación añade la decisión humana y el resultado de la ejecución. La tabla muestra el registro del pago de US$118,000.
La aprobación y la liquidación son registros separados. En la demostración de pagos retenidos, la aprobación de la liberación y el estado de liquidación confirmado son dos entradas distintas, y un pago solo está completo cuando se registra la referencia de liquidación. Los mantenemos separados porque una aprobación prueba una decisión y solo la infraestructura de pago puede confirmar que el dinero se movió.
Cualquier lectura honesta de este registro debe tener en cuenta tres límites. El registro muestra qué propuso el agente, qué reglas se aplicaron, quién decidió y qué devolvió la infraestructura de pago. No muestra que el proveedor recibiera los fondos; eso lo aportan los registros de liquidación y conciliación. Tampoco prueba que la factura sea auténtica; el control de calidad de la evidencia comprueba la coincidencia, y los controles antifraude están en otra parte del proceso de pago. Un auditor debería poder leer estos límites en el registro sin tener que preguntar.
| Campo del registro | Valor |
|---|---|
| Decisión | dec-2026-10-12-000418 |
| Acción propuesta | Pago a proveedor, US$118,000, beneficiario ven-0193, factura INV-20931 |
| Agente | treasury-payments, versión 3.2; identidad verificada a las 09:41:07 |
| Mandato | mnd-treasury-ops-2026q4, versión 2 |
| Reglas aplicadas | Banda de exposición por acción (Escalate); ventana agregada (conforme, margen de US$170,000 tras la acción); calidad de la evidencia (conforme, 0.96); estado del beneficiario (existente) |
| Resultado y fundamento | Escalate (require_approval): importe dentro de la banda de aprobación de US$25,000–US$250,000 |
| Decisión humana | Aprobada por un responsable de tesorería identificado a las 10:17:52, con justificación registrada |
| Resultado de la ejecución | Liberado a las 10:17:55; referencia de pago de la infraestructura registrada |
| Tiempos por etapa | Identidad 18 ms; controles 41 ms; espera de la decisión humana 36 min; liberación 3 s |
| Integridad | Añadido al registro con evidencia de manipulación; exportable con el resto de los registros del día para su verificación independiente |
Desarrollar o comprar la capa de tiempo de ejecución de SAFR
SAFR es un enfoque de referencia y deja abierta la elección del software. Una advertencia antes del análisis: KLA es un proveedor de esta categoría. KLA Control Plane implementa el patrón SAFR y está disponible hoy. Lea lo que sigue teniéndolo en cuenta.
Desarrollar internamente significa poner en marcha seis subsistemas:
Los seis subsistemas juntos son un desarrollo a escala de plataforma, y la unidad de planificación realista son trimestres de equipo. El trabajo continúa además después del lanzamiento: la calibración es una actividad operativa, porque los umbrales cambian con los volúmenes de operaciones, los cambios de producto y la capacidad de los revisores.
Desarrollar tiene sentido cuando se cuenta con un equipo de plataforma interno sólido que asumirá la capa como producto, cuando las infraestructuras de pago o de liquidación son tan específicas que un punto de control estándar no puede situarse delante de ellas, o cuando sistemas adyacentes que ya opera (gestión de permisos, gestión de casos, herramientas de políticas) cubren partes reales de la tabla anterior.
Comprar tiene sentido cuando la prioridad es lograr cobertura gobernada y evidencia exportable en un trimestre, cuando no hay un equipo de plataforma disponible para asumir seis subsistemas, o cuando los auditores pedirán registros verificables de forma independiente antes de lo que puede entregarlos una hoja de ruta interna.
La opción híbrida suele ser la respuesta honesta: comprar el punto de control de tiempo de ejecución (registro de agentes, motor de disposiciones, proceso de escalado, almacén de evidencia) y mantener internamente la redacción de los controles. Ese reparto coincide con el propio SAFR: el marco estandariza las estructuras de datos y los contratos, mientras que las configuraciones de reglas y los mecanismos de gobernanza siguen siendo de la entidad. En un modelo híbrido, sus equipos de riesgos y cumplimiento deciden qué dicen los controles, y el proveedor opera la maquinaria que los aplica y deja evidencia de su aplicación.
En lo que respecta a KLA: KLA Control Plane se corresponde componente por componente (Agent Registry, Policy Builder, KLA Policy Engine, Audit Trail), con las cuatro disposiciones expresadas como allow, warn, require_approval y block. La autorización por acción, la evaluación con cierre ante fallos (fail-closed) y los Sealed Evidence Bundles con verificación sin conexión ya están disponibles. Las ventanas de exposición agregadas, los límites de frecuencia por ventana, los umbrales de confianza como mecanismo de enrutamiento, los valores por defecto de expiración de escalados por clase y la pasarela independiente están en desarrollo. El mapa componente por componente, con indicadores de estado en cada requisito, está en nuestra página de implementación de SAFR.
| Subsistema | Qué exige |
|---|---|
| Registro de agentes | Identidades de agentes registradas y versionadas con responsables designados; determinación del registro autorizado; verificación en cada acción propuesta |
| Repositorio de controles | Políticas versionadas y legibles por máquina; un flujo de publicación gobernado con revisión y aprobación antes de que una política entre en vigor; cobertura de reglas regulatorias, de producto y derivadas de mandatos |
| Motor de disposiciones | Evaluación determinista que produce los cuatro resultados con códigos de motivo legibles por máquina; semántica fail-closed cuando el servicio de decisión no está disponible |
| Proceso de escalado | Enrutamiento a revisores designados con todo el contexto de la acción; aprobar, modificar o rechazar con justificación registrada; gestión de expiraciones; visibilidad de colas y plazos de respuesta |
| Almacén de evidencia | Almacenamiento de solo anexión y con evidencia de manipulación; herramientas de exportación; una vía de verificación que un tercero pueda ejecutar de forma independiente |
| Instrumentación | Emisión del sobre en cada agente para la integración nativa, o una pasarela de interceptación para el parque existente, además del trabajo de latencia necesario para que la evaluación por acción sea viable |
Un piloto de SAFR de cuatro semanas
Una primera implementación creíble cabe en cuatro semanas sobre un proceso acotado, y el plan sirve tanto si la capa subyacente se desarrolla internamente como si se compra o se combinan ambas opciones.
Antes de la primera semana, puntúe su situación. La lista de verificación de preparación para SAFR es un análisis de carencias interactivo en ocho secciones, desde la identidad del agente hasta el patrón de despliegue, que asocia a cada pregunta la evidencia que pediría un evaluador.
| Semana | Trabajo |
|---|---|
| 1 | Acotar un flujo de trabajo de un agente. Registrar el agente, definir su mandato y redactar los controles: alcance de la autorización, límites de exposición, límites de frecuencia, umbrales de calidad de la evidencia y condiciones de escalado |
| 2 | Procesar tráfico gobernado en simulación. Evaluar acciones reproducidas o históricas frente a los controles y calibrar las disposiciones hasta que el volumen de escalados se ajuste a la capacidad de los revisores |
| 3 | Pasar a producción con escalados. Enviar resultados Escalate reales a revisores designados, medir el plazo de respuesta frente a la ventana de expiración y ajustar los umbrales con el comportamiento real |
| 4 | Exportar la evidencia. Generar los registros de auditoría del periodo piloto, ejecutar una verificación independiente sobre la exportación y celebrar una sesión de decisión de continuidad con riesgos y cumplimiento |
Preguntas frecuentes
¿Cómo se adapta un parque de agentes existente?
Coloque una pasarela delante y dé instrumentación nativa a los nuevos desarrollos desde el primer día, la secuencia que recomienda el documento técnico. El trabajo de ingeniería se concentra en dos puntos: el punto de interceptación, que debe estar donde el agente no pueda falsificar el sobre, en el perímetro de red o dentro de la ruta de ejecución; y el presupuesto de latencia, porque la evaluación se ejecuta en cada acción propuesta. Conecte la pasarela al mismo repositorio de controles, motor de disposiciones y registro de auditoría que los desarrollos nativos, para que el parque mixto produzca un registro de gobernanza coherente.
¿Qué exige la integración nativa a nuestro código de agentes?
El agente se instrumenta para emitir un sobre de gobernanza antes de cada acción propuesta: el tipo, el alcance y los parámetros de la acción; la traza de la acción, y los metadatos de contexto. Un validador evalúa el sobre frente al repositorio de controles y devuelve un resultado antes de que el agente actúe. El documento recomienda la integración nativa para los nuevos despliegues de agentes: ofrece la integración más estrecha, el registro más granular y la pista de auditoría más limpia.
¿Cómo es un piloto de SAFR?
Cuatro semanas sobre un flujo de trabajo acotado: registrar el agente y redactar sus controles; calibrar las disposiciones con tráfico simulado o reproducido; ejecutar escalados reales con revisores designados y ajustar los umbrales; y, por último, exportar los registros de auditoría, verificarlos de forma independiente y celebrar una sesión de decisión de continuidad con riesgos y cumplimiento.
¿Exige SAFR una tecnología o un proveedor concretos?
No. SAFR define estructuras de datos, lógica de evaluación y contratos de escalado, y «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). SAFR no es un servicio gestionado. Las entidades pueden aplicarlo desarrollando, comprando o combinando ambas opciones.
¿Es obligatorio SAFR para las entidades reguladas por la MAS?
No. La versión 1.1 de SAFR (9 de octubre de 2026) afirma que no constituye orientación regulatoria ni expectativas supervisoras y que no anticipa su evolución futura, y la MAS no se ha comprometido a hacerlo obligatorio. Las expectativas supervisoras sobre la IA, incluidos los agentes, están en las directrices de la MAS sobre gestión del riesgo de la inteligencia artificial publicadas el 7 de octubre de 2026, que entran en vigor el 7 de octubre de 2027.
¿Qué debe contener un registro de decisión de SAFR?
Como mínimo, los elementos que SAFR enumera para cada entrada de auditoría: el sobre de gobernanza tal como se presentó, el mandato con el que se contrastó la acción, el resultado, las reglas concretas aplicadas, el fundamento del resultado y el tiempo transcurrido en cada etapa. Para una acción escalada, añada el revisor, la decisión, la justificación registrada y el resultado de la ejecución, e indique qué no prueba el registro, como la liquidación.
¿Quién fija los umbrales en una implementación de SAFR?
La propia entidad. SAFR «does not constitute regulatory guidance or supervisory expectations» (traducción no oficial: no constituye orientación regulatoria ni expectativas supervisoras), y las configuraciones de reglas y los mecanismos de gobernanza corresponden a quien lo implementa. En la práctica: los límites de exposición proceden del marco de delegación de facultades existente, los umbrales de escalado se dimensionan según la capacidad real de los revisores y la calibración de las disposiciones se fija en la fase de diseño con los cinco factores que cita el documento, desde la reversibilidad de la acción hasta la novedad. 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.
Conclusiones clave
El orden de implementación que funciona: elegir el patrón de despliegue (nativo para los nuevos desarrollos, pasarela para el parque existente), codificar los controles a partir del marco de delegación de facultades existente, calibrar las cuatro disposiciones en simulación, diseñar las operaciones de escalado según la capacidad real de los revisores y poner en marcha una capa de evidencia que un tercero pueda verificar. Después, demostrarlo en un proceso en cuatro semanas, con un registro de decisión como el del ejemplo anterior para cada acción consecuente.
Empiece por puntuar su situación actual con la lista de verificación de preparación para SAFR: un análisis de carencias interactivo y de acceso libre; la hoja de trabajo editable está disponible por correo electrónico. Si quiere una segunda opinión sobre la lista de carencias, reserve una revisión de carencias SAFR de 30 minutos. Y para ver componente por componente cómo implementar el marco SAFR con KLA Control Plane, con lo que ya está disponible y lo que está en desarrollo, consulte la página principal.
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 voluntaria del sector y no constituye orientación regulatoria. El ejemplo de Northbridge Bank es sintético. KLA es independiente de la MAS y de BuildFin.ai, y no está afiliada a ellas ni cuenta con su respaldo o certificación.