En juillet 2026, le programme BuildFin.ai de l'Autorité monétaire de Singapour a publié SAFR (Safeguards for Agentic Finance at Runtime), un livre blanc rédigé avec huit membres de l'industrie : Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC et Visa. SAFR est une approche de référence pour une couche de gouvernance d'exécution : un point de contrôle qui se situe entre un agent d'IA et les systèmes sur lesquels il agit, et évalue chaque action proposée avant que cette action ne s'exécute. Le 9 octobre 2026, BuildFin.ai a publié la version 1.1, qui précise le périmètre et l'approche de mise en œuvre, ajoute des études de cas et remercie trois contributeurs supplémentaires : DBS, Google et UOB. Deux jours plus tôt, la MAS avait publié ses lignes directrices finales sur la gestion des risques liés à l'IA, qui fixent les attentes prudentielles aux côtés desquelles SAFR se place.
La thèse de l'article tient en une seule ligne : aucune action agentique n'est exécutée sans avoir été déclarée, autorisée et évaluée.
Cette fiche explicative couvre la spécification complète : les quatre composants d'exécution, l'enveloppe de gouvernance, les mandats, les quatre dispositions et leurs facteurs d'étalonnage, l'autorisation par action dans les flux de travail en plusieurs étapes, les deux modèles de déploiement et la position de SAFR par rapport aux garde-corps, aux plates-formes de conformité et aux rails de règlement. Il est rédigé à l'intention des responsables de la conformité, des responsables des risques liés à l'IA et des équipes de plateforme qui déterminent ce qu'exigerait réellement l'adoption de SAFR.
Pourquoi SAFR existe
Les institutions financières déploient des agents d'IA qui agissent. Ils initient les paiements, soumettent des ordres de négociation, approuvent les demandes de crédit, déposent des rapports réglementaires et règlent les réclamations d'assurance : souvent à haute fréquence, sans qu'aucun humain n'examine chaque action individuelle. Le document cite cinq domaines d'application dans lesquels les préoccupations en matière de gouvernance sont accrues : les paiements, la gestion des liquidités, le triage de la conformité, l'évaluation du crédit et le traitement post-transaction.
Il existe également une dimension systémique. Lorsque de nombreuses institutions s’appuient sur un petit nombre de fournisseurs de services d’IA communs, leurs agents peuvent se comporter de manière corrélée. Le Conseil de stabilité financière a identifié cette corrélation comme une vulnérabilité systémique potentielle.
Dans ce contexte, la SAFR identifie trois lacunes dans les institutions d'infrastructure de gouvernance déjà gérées.
Écart 1 : assurance pré-exécution. La gestion des risques du modèle valide un système avant le déploiement. L'audit examine ce qui s'est passé après coup. Aucune des deux disciplines ne détecte une décision problématique d'un agent juste avant son exécution.
Gap 2 : l'interface de gouvernance homme-agent. Aujourd'hui, la transmission à un humain est ponctuelle (une notification, une alerte par e-mail, un indicateur de tableau de bord) sans date limite, sans format de décision standard et sans enregistrement d'audit. Le journal y voit l’apparence d’une supervision humaine sans sa substance.
Écart 3 : fragmentation. Chaque déploiement construit ses propres garde-corps. Les résultats ne sont pas interopérables et ne peuvent pas être audités dans un format cohérent dans l’ensemble de l’institution.
SAFR est une réponse proposée à ces trois éléments : un point de contrôle permanent dans le chemin d'exécution, un contrat d'escalade structuré avec des délais et des enregistrements de décision, et un format de gouvernance cohérent pour chaque agent.
Qu'est-ce que le SAFR ?
Selon le document, SAFR définit les structures de données, la logique d'évaluation et les contrats d'escalade du déploiement de l'IA agentique. Il se place entre l'agent et les systèmes sur lesquels il agit, évalue les actions proposées avant leur exécution et fonctionne aux côtés des rails de paiement, des protocoles de règlement, des moteurs de conformité et des systèmes bancaires centraux existants.
Trois limites comptent pour quiconque le lit avec un mandat de conformité.
Premièrement, SAFR n'exerce aucune force prudentielle. La version 1.1 est explicite : SAFR ne constitue ni une orientation réglementaire ni une attente prudentielle, et ne préfigure aucune orientation future de ce type. Chaque institution reste responsable de déterminer dans quelle mesure son propre déploiement s’aligne sur les attentes prudentielles applicables et les exigences de gouvernance interne.
Deuxièmement, SAFR est une spécification sur laquelle les institutions peuvent s'appuyer. Il sert de référence sectorielle que chaque institution met en œuvre dans sa propre infrastructure, avec ses propres configurations de règles et modalités de gouvernance. Il n’y a pas de service SAFR exploité par MAS auquel s’abonner.
Troisièmement, SAFR est limité à la décision d'exécution. Il définit comment une action proposée est identifiée, autorisée, évaluée et enregistrée au moment de l'action. La validation des modèles, la gestion du cycle de vie et des cadres plus larges de risques liés à l'IA l'entourent (plus d'informations sur cet écosystème ci-dessous).
Le statut de SAFR en octobre 2026
Deux documents sont parus la même semaine. Le 7 octobre 2026, la MAS a publié ses Guidelines on Artificial Intelligence Risk Management (AIRG) finales. Elles prennent effet le 7 octobre 2027, incluent explicitement les agents d'IA dans leur champ et rendent les contrôles du cycle de vie applicables au 7 octobre 2028. Le 9 octobre 2026, BuildFin.ai a publié la version 1.1 de SAFR.
Les lignes directrices ne mentionnent pas SAFR, et la version 1.1 indique que SAFR ne préfigure pas les orientations futures des directives réglementaires ou des attentes prudentielles. La MAS ne s'est pas engagée à rendre SAFR obligatoire ; sa prochaine étape annoncée sur les agents est une consultation en 2027 sur les orientations supplémentaires utiles en matière d'IA agentique. SAFR est une référence volontaire, et l'AIRG est le document au regard duquel la MAS exerce sa supervision.
Les deux se rejoignent pourtant en pratique. L'AIRG demande aux institutions financières de donner aux examinateurs l'autorité et la capacité d'intervenir, de soumettre les résultats à un examen humain lorsque des conditions prédéfinies sont réunies et de surveiller, le cas échéant, les actions effectuées et les outils utilisés. Un point de contrôle de type SAFR produit exactement ces enregistrements pour chaque action d'agent. Les dates et les passages propres aux agents sont détaillés dans Les lignes directrices de la MAS sur la gestion des risques liés à l'IA sont définitives.
| Version | Date | Changements |
|---|---|---|
| 1.0 | 3 juillet 2026 | Première publication, rédigée avec huit membres du secteur |
| 1.1 | 9 octobre 2026 | Précise le périmètre et l'approche de mise en œuvre ; ajoute des études de cas ; remercie DBS, Google et UOB aux côtés des huit contributeurs d'origine |
Les quatre composants d'exécution SAFR
L'architecture de SAFR est composée de quatre composants interagissant via une structure de données partagée, l'enveloppe de gouvernance. Chaque composant répond à une question sur une action proposée.
L'identité de l'agent lie chaque action proposée à un agent reconnu et enregistré, vérifié par rapport à l'entrée de registre de cet agent avant toute autre évaluation. Dans un environnement en boucle fermée, le propre registre de l'institution répond par une recherche directe. Sur les réseaux ouverts, un agent peut être enregistré dans plusieurs bases de données d'identité (le registre interne de l'institution, le registre des agents d'un réseau de paiement, un annuaire inter-institutionnel) et le composant détermine quel registre fait autorité pour l'action en cours. Un échec du contrôle d'identité entraîne un rejet immédiat, enregistré dans le journal d'audit.
Le référentiel de contrôles est l'endroit où l'institution code ses règles. Les contrôles sont issus des politiques organisationnelles, des exigences réglementaires, des règles relatives aux produits et des mandats ou pouvoirs accordés par les utilisateurs. Les contrôles génériques tels que les contrôles d'autorisation et les limites d'exposition sont déterministes. Les contrôles spécifiques à l’IA, tels que la qualité des preuves et l’intégrité de l’enveloppe, peuvent impliquer une évaluation probabiliste ou sémantique. Chaque contrôle code cinq éléments : les types d'actions autorisés, la logique de décision, les conditions d'escalade, une période de validité et l'autorité principale derrière celle-ci.
Le moteur de disposition évalue chaque action dans le cadre de manière déterministe par rapport aux contrôles récupérés, produisant un résultat défini et contraignant pour chaque action conséquente proposée, calibré sur le risque propre à cette action. Les quatre résultats possibles sont abordés en détail ci-dessous.
Le journal d'audit enregistre chaque décision de gouvernance sous une forme inviolable en annexe uniquement. Chaque entrée capture six éléments : l'enveloppe de gouvernance telle que soumise, le mandat par rapport auquel l'action a été vérifiée, le résultat produit par le moteur de disposition, les règles spécifiques appliquées, la base de ce résultat et le temps écoulé à chaque étape. Selon le document, le journal fait autorité et reste indépendant de toute partie intéressée par la façon dont les événements seront qualifiés après coup.
Le cycle de vie relie les quatre ensemble. Une action proposée est présentée dans une enveloppe de gouvernance et validée pour son exhaustivité et sa cohérence. L'identité de l'agent est vérifiée par rapport au registre concerné ; un échec signifie un rejet immédiat et enregistré. Le référentiel de contrôles identifie les contrôles à vérifier. Le moteur de disposition détermine les seuils applicables et renvoie l'un des quatre résultats suivants. Le journal d'audit enregistre la trace complète de gouvernance pour chaque résultat, y compris les actions qui se sont déroulées sans intervention.
| Composant | La question à laquelle il répond | Ce qu'il contient ou fait |
|---|---|---|
| Identité de l'agent | Quel agent propose cette action et est-il reconnu ? | Vérifie chaque action par rapport à l'entrée de registre de l'agent avant toute autre évaluation. |
| Référentiel de contrôles | Quelles règles s'appliquent à cette action ? | Le règlement configurable de l'institution : politiques, exigences réglementaires, règles de produits, mandats des utilisateurs |
| Moteur de disposition | Cette action peut-elle avoir lieu et dans quelles conditions ? | Évalue l'action sur les contrôles récupérés et renvoie l'un des quatre résultats contraignants |
| Journal d'audit | Qu'est-ce qui a été décidé exactement et pourquoi ? | Un enregistrement immuable, inviolable et en annexe uniquement de chaque décision de gouvernance |
L'enveloppe de gouvernance
Avant qu'une action agentique ne soit exécutée, elle est emballée avec le contexte nécessaire pour l'évaluer. L'enveloppe contient trois classes d'informations.
L'enveloppe présente un problème d'intégrité auquel le papier est directement confronté. La trace de l'action et les détails de l'action sont tous deux déclarés par l'agent, ce qui signifie qu'une injection contradictoire sophistiquée pourrait les fabriquer ensemble : une trace d'apparence plausible enroulée autour d'une action non autorisée. La version 1.1 en tire la conséquence sans détour : l'enveloppe de gouvernance ne doit pas être tenue pour auto-vérifiante. Lorsque c'est possible, les champs fournis par l'agent doivent donc être vérifiés au regard d'enregistrements capturés indépendamment de lui, comme l'instruction initiale, la charge utile réelle de l'action et les traces système des appels d'outils et des accès aux données, et l'enveloppe doit être liée à l'agent, à la session et au mandat applicable vérifiés, et protégée contre toute modification ultérieure. Les mises en œuvre nécessitent un moyen de vérifier que l’enveloppe reflète ce qui s’est réellement passé, à la source.
| Classe d'informations | Contenu |
|---|---|
| Action | Le type d'action, ainsi que la portée et les paramètres de l'action proposée |
| Trace d'action | Les étapes réelles exécutées par l'agent pour arriver à la proposition : appels d'outils effectuées, données récupérées, vérifications effectuées |
| Métadonnées contextuelles | L'identité de l'agent, le mandat applicable, le compte actuel ou l'état du système et les contraintes de politique opérationnelle |
Mandats et autorité basée sur les capacités
Un mandat est le mécanisme qui délimite l'autorité déléguée et l'exprime sous une forme lisible par machine. Lorsqu'un mandant autorise un agent à agir pour son compte, le mandat consigne explicitement cette délégation : ce que l'agent peut faire, dans quelles limites, sous quelles conditions.
La conception s'appuie sur une sécurité basée sur les capacités, une lignée que le papier trace jusqu'au 1966 work de Dennis et Van Horn : la même tradition qui sous-tend OAuth 2.0. La propriété porteuse : un agent ne peut pas étendre la portée d'un mandat par son propre raisonnement ou ses propres inférences ; l'autorité est explicite, structurée et définie par le mandat, et l'agent ne la déduit pas. Aussi fluide que soit la justification d'un agent pour dépasser ses limites, le mandat est la frontière.
Le document cite le protocole de paiement des agents (AP2) comme exemple marquant du secteur, avec des mandats signés de manière cryptographique.
Les quatre dispositions SAFR : Refuser, Escalader, Exécuter automatiquement, Observer
Le moteur de disposition résout chaque action dans le cadre de l'un des quatre résultats. Tous les quatre alimentent le journal d’audit.
Observe permet à une institution de maintenir l'automatisation à faible risque tout en créant un dossier révisable des cas sur lesquels elle souhaite s'intéresser plus tard.
La disposition qu'une action reçoit est une question de calibrage, réglée au moment de la conception via les paramètres de gouvernance des contrôles. Le document cite cinq facteurs d'étalonnage : la réversibilité de l'action, la matérialité financière, la gravité de l'impact sur les clients, la sensibilité réglementaire et la nouveauté ou l'anomalie : c'est-à-dire un écart par rapport aux modèles établis au sein du mandat. Les profils à risque plus élevé orientent les résultats vers Refuser ou Escalader.
| Disposition | Quand elle s'applique | Que se passe-t-il |
|---|---|---|
| Refuser | L'action viole une contrainte réglementaire ou politique stricte, ou son profil de risque dépasse des seuils définis | Rejetée avant exécution, avec une raison spécifique enregistrée |
| Escalader | Dans la portée et en dessous des contraintes strictes, mais au-dessus du seuil d'exécution autonome | Maintenu en attente d'un examen humain avant de continuer |
| Exécution automatique | Dans la portée, en dessous des contraintes strictes, dans les seuils de risque définis | Procède sans nécessiter d'intervention humaine |
| Observe | En dessous du seuil d'escalade, mais correspond à un modèle ou à un signal que l'institution a configuré comme justifiant une attention | Exécute, tandis qu'une observation structurée est enregistrée pour un examen ultérieur |
Aucune autorité n'est reportée entre les étapes
Les processus agentiques sont rarement une action unique. Un agent enrichit les données, appelle des outils, s'adapte aux résultats intermédiaires et propose sa prochaine étape en fonction de ce qu'il vient d'apprendre. La réponse de SAFR est la gouvernance par action : le flux de contrôle s'applique indépendamment à chaque action d'agent.
Le document est précis sur la conséquence : un résultat d'exécution automatique ou d'observation à une étape ne vaut pas autorisation pour l'étape suivante. L'autorisation préalable n'est pas reportée car l'agent s'adapte aux résultats intermédiaires et aux conditions changeantes. La troisième étape d'un flux de travail subit les mêmes contrôles d'identité, récupération de contrôle et disposition que la première étape. Pour les institutions, cela met fin au scénario dans lequel un agent obtient une approbation très tôt puis dérive, pleinement « autorisé », vers un territoire que personne n’a examiné.
Les deux modèles de déploiement SAFR
SAFR décrit deux manières de placer le point de contrôle dans la pile d'une institution.
Le document propose des conseils de séquençage pour les institutions qui gèrent déjà des agents : pour celles qui comptent de nombreux agents, le modèle de passerelle est un point de départ pratique, car il établit d'abord la couverture, et l'instrumentation native peut suivre pour les nouvelles versions. La couverture d’abord, la profondeur ensuite.
| Modèle | Comment ça marche | Adapté à |
|---|---|---|
| Intégration native | L'agent est instrumenté pour émettre une Enveloppe de Gouvernance avant chaque action proposée ; le validateur SAFR l'évalue par rapport au référentiel de contrôles et renvoie un résultat avant que l'agent n'agisse | Déploiements de nouveaux agents ; intégration la plus étroite, enregistrement le plus granulaire, piste d'audit la plus propre |
| Intégration de la passerelle | Une passerelle SAFR intercepte les appels d'API sortants au niveau de la couche d'infrastructure, enveloppe chaque appel dans une enveloppe de gouvernance et l'évalue sans modification du code de l'agent | Systèmes existants, agents tiers, déploiements existants |
Ce que les institutions configurent : les quatre catégories de contrôle
SAFR laisse le règlement à l'établissement. Son tableau 1 defin présente quatre catégories de contrôle qu'une implémentation doit prendre en charge.
Deux notes de conception du document se démarquent. Les limites d’exposition doivent refléter les cadres d’autorité déléguée que l’institution gère déjà pour les humains, de sorte que l’autorité des agents s’intègre dans un vocabulaire de gouvernance existant. Et la qualité des preuves fonctionne indépendamment de leur valeur : une action peu fiable est dirigée vers un humain même lorsque le montant en jeu est insignifiant.
| Catégorie de contrôle | Ce que définit l'établissement |
|---|---|
| Autorisation | Quels agents sont autorisés à agir pour quels mandants ; qui peut déléguer son autorité à qui et dans quelle mesure ; quels types d'actions chaque classe d'agent peut initier |
| Limites d'exposition | Seuils par action et valeur globale ; en dessous d'eux, les actions autonomes sont autorisées ; au-dessus d'eux, un examen humain est requis ou l'action est bloquée |
| Limites de débit | Taux d'action maximum par fenêtre de temps ; protège contre les agents incontrôlables, les erreurs de flux de données et les injections rapides contradictoires qui provoquent une vitesse ou un volume anormal |
| Qualité des preuves | Seuil de confiance minimum et preuves requises pour une exécution autonome ; actions pour lesquelles la confiance déclarée de l'agent tombe en dessous du seuil d'accès à l'examen humain, quelle que soit la valeur |
Exploitation du chemin d'escalade
Une disposition d'escalade n'est aussi bonne que le processus d'examen humain qui la sous-tend. La SAFR cite trois dimensions opérationnelles que les institutions doivent délibérément concevoir.
Volume d'escalade. Une fonction d'escalade qui génère plus d'avis que ce que l'institution peut traiter de manière significative va à l'encontre de son propre objectif. Les seuils doivent être calibrés par rapport à la capacité réelle des examinateurs.
Vérifiez le délai d'exécution. Les escalades doivent inclure une fenêtre de délai d'attente. Si aucune décision n’y parvient, la valeur par défaut est de bloquer l’action ou de la transmettre à un réviseur senior. La fenêtre doit refléter une disponibilité réaliste des évaluateurs, y compris une couverture de nuit et de week-end.
Autorité de l'examinateur. Les examinateurs doivent avoir une autorité claire pour approuver, modifier ou refuser l'action, et leurs décisions ont le même poids institutionnel que la décision initiale de l'agent. Un critique qui ne peut qu’approuver automatiquement reproduit l’écart que SAFR s’efforce de combler.
L'autorité doit aussi être lisible. Quand nous avons fait passer pour la première fois des dossiers LCB-FT dans nos propres tenants de test en tant qu'utilisateur conformité, un examinateur pouvait ouvrir un dossier escaladé et le voir marqué en lecture seule, sans raison indiquée. Decision Desk indique désormais pourquoi une personne ne peut pas décider : une permission manquante, l'absence du groupe d'approbateurs, ou le fait d'être l'auteur de la demande. Une séparation maker-checker que l'examinateur ne voit pas ressemble à un outil en panne.
Où se trouve SAFR dans la pile
Un moyen utile de lire SAFR est de le considérer comme une couche avec des voisins définis. Le flux : l’agent IA produit une action proposée (ses garde-fous peuvent façonner la sortie) ; SAFR vérifie l'identité et l'autorité de l'agent et évalue l'action par rapport aux contrôles de manière déterministe, en renvoyant Auto-Execute, Observe, Escalate ou Deny ; les rails financiers s’exécutent si et seulement si l’action a été approuvée.
Par rapport aux garde-fous de l'IA. Le filtrage de contenu, les défenses contre l'injection rapide et le filtrage de sortie sont généralement probabilistes et régissent ce que produit le modèle. La question de savoir si une action financière proposée est autorisée et exécutable est une décision distincte, et c'est celle que SAFR prend. SAFR fonctionne après le filtrage du contenu et avant l'exécution.
Par rapport aux plateformes de conformité. SAFR génère le dossier de gouvernance structuré sur lequel les plateformes de conformité existantes peuvent s'appuyer. Il ne reproduit pas leurs évaluations.
Par rapport aux rails de règlement. Les systèmes de paiement et les rails de règlement déplacent de l'argent. Le SAFR régit la décision de le déplacer. L'application des règles au niveau du règlement (règles du réseau de cartes, normes SWIFT, règles ACH, protocole de paiement automatique (MPP), Purpose Bound Money (PBM), contrôles des pièces stables) fonctionne une fois que SAFR a déterminé si l'agent peut agir.
Par rapport à un produit. SAFR est une spécification. Il n'y a pas de service géré à acheter auprès de MAS ; chaque institution met en œuvre le modèle au sein de sa propre infrastructure ou adopte des outils qui le font.
Qui a écrit SAFR et l'écosystème qui l'entoure
SAFR est issu d'un flux de travail dédié MAS établi dans le cadre de son programme BuildFin.ai pour développer des ressources de mise en œuvre pour les risques d'IA agentique. La version 1.0 a été rédigée avec huit membres de l'industrie : Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC et Visa. La version 1.1 remercie onze contributeurs, avec DBS, Google et UOB, et ajoute des études de cas. Le document fonde la spécification sur des études de cas de membres, notamment : Agentic Treasury Protocol d'Ant International, Agent Pay et Agentic Tokens de Mastercard, Visa Intelligent Commerce, Circle's Agent Wallet, ERC-8004, Circle Payments Network et Compliance Engine, OCBC avec Source de Wealth Assistant (SOWA) de la Bank de Singapore, aux côtés d'un agent interne de marché bancaire d'entreprise et d'un agent d'information sur les clients, et le travail d'aide à la vente GenAI de Manulife. HSBC et J.P. Morgan Chase ont contribué à l'article sans études de cas nommées.
SAFR a également défini les voisins dans la littérature sur la gouvernance. Le projet MindForge (MAS avec un consortium d'institutions financières des secteurs de la banque, de l'assurance et des marchés des capitaux) a lancé sa phase le 2 in novembre 2024 et publiée au Singapore FinTech Festival en novembre 2025 : un manuel exécutif avec 17 Considerations réparties en quatre sections (portée et surveillance, gestion des risques de l'IA, gestion du cycle de vie de l'IA, catalyseurs) et un manuel d'opérationnalisation. couvrant le moindre privilège pour l'accès aux outils et aux données des agents, la certification des agents, la division des responsabilités au moment de la conception, les killswitchs et les délais d'attente, ainsi que la traçabilité via une journalisation consultable. Le modèle de gouvernance de l'IA de l'IMDA pour l'IA agentique (2026) encadre les systèmes agentiques autour de quatre composants principaux (modèles, mémoire, outils, actions) et d'un modèle de gouvernance en quatre parties (limite des cas d'utilisation, limitation d'accès, surveillance humaine, responsabilité de la hiérarchie principale). Le RMF AI du NIST (2023) contribue au cycle Cartographier, Mesurer, Gérer et Gouverner. SAFR est la couche spécifique à l'exécution de cette pile : les structures de données, la logique d'évaluation et les contrats d'escalade pour le moment de l'action.
Le document se termine par une invitation ouverte : « Les FinTech et les institutions financières sont invitées à contribuer au SAFR et au groupe de travail BuildFin.ai en partageant les résultats des projets pilotes, en identifiant les lacunes dans la spécification et en soulevant les exigences de domaine non encore satisfaites.
Que faire ensuite
Pour une équipe évaluant sa position par rapport au SAFR, la première étape productive est une évaluation structurée des lacunes dans les propres dimensions du document : inventaire et identité des agents, mandats, contrôles, dispositions, enveloppe et lignée, opérations d'escalade, audit et preuves, et modèle de déploiement. La Liste de contrôle de préparation SAFR passe en revue environ 35 assessor-style questions à travers ces huit sections et note l'état de préparation par section, avec une version de feuille de calcul modifiable pour les sessions de travail.
Les équipes ayant passé l'évaluation et commençant la planification de la construction doivent lire l'article complémentaire, Comment implémenter SAFR : architecture, modèles et construction par rapport à l'achat, qui couvre l'architecture de référence, des exemples de contrôle fonctionnels et une analyse de construction par rapport à l'achat.
Comment KLA correspond à SAFR
KLA Control Plane implémente le modèle SAFR, disponible aujourd'hui : Agent Registry pour l'identité de l'agent, Policy Builder pour le référentiel de contrôles, KLA Policy Engine pour le moteur de disposition et une piste d'audit pour le journal d'audit, avec les quatre dispositions mappées en tête-à-tête : refuser pour bloquer, escalader jusqu'à require_approval, exécuter automatiquement pour autoriser et observer pour avertir. Le mappage complet composant par composant, y compris les exigences de fonctionnement et les indicateurs d'état actuel, se trouve sur la [page de mise en œuvre SAFR] (/safr). Sources : source
Foire aux questions
Que signifie SAFR ?
SAFR signifie Safeguards for Agentic Finance at Runtime (garde-fous pour la finance agentique au moment de l'exécution). Il s'agit d'un livre blanc publié par le programme BuildFin.ai de l'Autorité monétaire de Singapour (version 1.0 le 3 juillet 2026, version 1.1 le 9 octobre 2026), décrivant une approche de référence pour une couche de gouvernance d'exécution pour l'IA agentique dans les services financiers.
Le SAFR est-il obligatoire ?
Non. La version 1.1 (9 octobre 2026) précise que SAFR ne constitue ni une orientation réglementaire ni une attente prudentielle, et qu'il ne préfigure aucune orientation future de ce type. La MAS ne s'est pas engagée à le rendre obligatoire, et ses lignes directrices finales sur la gestion des risques liés à l'IA (7 octobre 2026) n'y font pas référence. Chaque institution reste responsable de déterminer dans quelle mesure son déploiement s'aligne sur les attentes prudentielles applicables et ses exigences de gouvernance interne.
Quel est le lien entre SAFR et les lignes directrices de la MAS sur la gestion des risques liés à l'IA ?
Les lignes directrices, publiées le 7 octobre 2026 et applicables à partir du 7 octobre 2027, fixent les attentes prudentielles de la MAS en matière d'IA, y compris pour les agents d'IA. SAFR est une référence d'exécution volontaire. Un point de contrôle de type SAFR produit les enregistrements de contrôle et de surveillance par action que demandent les lignes directrices, mais le respect des lignes directrices ne dépend pas de l'adoption de SAFR. Voir Les lignes directrices de la MAS sur la gestion des risques liés à l'IA sont définitives.
Qui a publié SAFR ?
Le programme BuildFin.ai de la MAS, via un groupe de travail dédié établi pour développer des ressources de mise en œuvre pour les risques d'IA agentique. La version 1.0 a été rédigée avec huit membres de l'industrie : Ant International, Circle, HSBC, J.P. Morgan Chase, Manulife, Mastercard, OCBC et Visa. La version 1.1 remercie également DBS, Google et UOB.
Quelles sont les quatre dispositions SAFR ?
Refuser (l'action viole une contrainte stricte ou dépasse les seuils de risque et est rejetée avant l'exécution, avec une raison spécifique enregistrée), Escalader (l'action est suspendue en attente d'un examen humain), Exécuter automatiquement (l'action se déroule sans nécessiter une intervention humaine) et Observer (l'action s'exécute pendant qu'une observation structurée est enregistrée pour un examen ultérieur). Les quatre résultats sont enregistrés dans le journal d'audit.
Qu'est-ce qu'une enveloppe de gouvernance ?
Structure de données qui regroupe une action d'agent proposée avec le contexte nécessaire pour l'évaluer, avant son exécution. Il contient trois classes d'informations : l'action (type, portée, paramètres), la trace de l'action (l'outil appelle, récupère les données et vérifie l'agent réellement effectué) et les métadonnées de contexte (identité de l'agent, mandat applicable, état du compte ou du système, contraintes de politique opérationnelle). Son contenu étant fourni par l'agent, la version 1.1 indique que l'enveloppe ne doit pas être tenue pour auto-vérifiante : ses champs doivent être vérifiés, lorsque c'est possible, par rapport à des enregistrements capturés indépendamment de l'agent.
Quel est le lien entre SAFR et le projet MindForge ?
Tous deux sont issus de la collaboration MAS-industrie. Le projet MindForge publie des manuels généraux sur la gouvernance de l'IA agentique tout au long du cycle de vie de l'IA : un manuel exécutif avec 17 Considerations et un manuel d'opérationnalisation couvrant des pratiques telles que le moindre privilège, la certification des agents, les kill switch et la traçabilité. SAFR est la référence spécifique à l'exécution : structures de données concrètes, logique d'évaluation et contrats d'escalade pour évaluer chaque action proposée avant son exécution.
Le SAFR s'applique-t-il en dehors de Singapour ?
SAFR n'exerce aucune force de surveillance dans aucune juridiction, de sorte qu'une institution, où qu'elle soit, peut le mettre en œuvre comme référence du secteur tout en restant responsable de l'alignement du déploiement sur les attentes de ses propres régulateurs. Pour connaître les liens entre le SAFR et la loi européenne sur l'IA et la FINMA, voir SAFR, la loi européenne sur l'IA et la FINMA : les régulateurs convergent sur les preuves d'exécution.
Devons-nous changer le code de l'agent pour adopter SAFR ?
SAFR définit deux modèles de déploiement. Native Integration permet à l'agent d'émettre une enveloppe de gouvernance avant chaque action proposée, et le document le recommande pour les nouveaux déploiements. L'intégration de passerelle intercepte les appels d'API sortants au niveau de la couche d'infrastructure et les enveloppe chacun dans une enveloppe de gouvernance sans aucune modification du code de l'agent, ce qui permet de placer les systèmes existants, les agents tiers et les déploiements existants sous gouvernance. Le document suggère une couverture de passerelle d'abord pour les institutions comptant de nombreux agents existants, suivie d'une instrumentation native pour les nouvelles constructions.
Points clés à retenir
SAFR offre à l'industrie un vocabulaire commun et concret pour gouverner les agents d'IA au moment où ils agissent : vérification d'identité, mandats explicites, dispositions déterministes et enregistrement d'audit autonome. Il s'agit d'une approche de référence volontaire, publiée pour que les institutions puissent la mettre en œuvre au sein de leur propre infrastructure, et le groupe de travail qui la porte sollicite ouvertement des retours de projets pilotes et des signalements de lacunes. Les lignes directrices finales de la MAS sur la gestion des risques liés à l'IA fixent les attentes prudentielles ; SAFR est une manière de produire les preuves d'exécution qu'elles demandent.
La séquence pratique pour la plupart des équipes : évaluez votre état actuel avec la Liste de contrôle de préparation SAFR, puis lisez le Guide de mise en œuvre SAFR pour planifier la construction.
Sources : Safeguards for Agentic Finance at Runtime, livre blanc v1.0 (3 juillet 2026) et v1.1 (9 octobre 2026), MAS BuildFin.ai ; MAS, Guidelines on Artificial Intelligence Risk Management, 7 octobre 2026. Passages cités © Autorité monétaire de Singapour. SAFR est une référence du secteur et ne constitue pas une orientation réglementaire ou une attente prudentielle. KLA est indépendant et non affilié, approuvé ou certifié par MAS ou BuildFin.ai.