Cadre de gouvernance de l’IA agentique de Singapour

Le Model AI Governance Framework for Agentic AI est le cadre de gouvernance de l’IA agentique publié par l’Infocomm Media Development Authority (IMDA) de Singapour pour déployer des agents IA de façon responsable. Il demande aux organisations d’évaluer et de borner les risques en amont, de rendre les humains réellement responsables, de mettre en place des contrôles techniques et des processus, et de permettre aux utilisateurs finaux d’exercer leur propre responsabilité. Pour le service client, cela signifie des permissions limitées, des points de validation, des tests, du monitoring et une information claire des clients.

En bref

• L’IMDA a lancé le cadre le 22 janvier 2026 ; le texte en vigueur est la version 1.5, publiée le 20 mai 2026 et mise à jour le 5 juin 2026.
• C’est un document d’orientation, pas une loi : il décrit des « bonnes pratiques émergentes », se présente comme un document évolutif et ne prévoit aucune sanction.
• Il cite les agents du service client parmi les agents qui interagissent avec les utilisateurs, et demande d’indiquer dans l’interface, au moment de l’interaction, que l’on parle à une IA.
• Le tableau de correspondance ci-dessous transforme chaque section en une étape pour un agent IA du service client et en preuves à conserver.
• Si vous servez des clients dans l’UE, l’AI Act (le règlement européen sur l’IA) est la couche contraignante qui s’ajoute ; les deux textes se recoupent surtout sur l’information des utilisateurs.

Cette explication est rédigée à partir de la source primaire et ne constitue pas un conseil juridique. Elle s’inscrit dans notre guide sur la gouvernance des agents IA.

Qu’est-ce que le Model AI Governance Framework for Agentic AI ?

Le Model AI Governance Framework for Agentic AI est un document de 53 pages de l’IMDA qui donne aux organisations « une vue d’ensemble structurée des risques de l’IA agentique et des bonnes pratiques émergentes pour gérer ces risques ». Il s’adresse aux organisations qui déploient des agents IA, qu’elles les construisent en interne ou utilisent des solutions agentiques de tiers.

La partie 1 explique ce qu’est un agent et ce qui peut mal tourner. La partie 2 est le cadre lui-même, en quatre dimensions :

1. 2.1 Évaluer et borner les risques en amont : cas d’usage adaptés (2.1.1) ; limites, identité et permissions de l’agent (2.1.2).
2. 2.2 Rendre les humains réellement responsables : responsabilités à l’intérieur et à l’extérieur de l’organisation (2.2.1) ; supervision humaine effective (2.2.2).
3. 2.3 Mettre en place des contrôles techniques et des processus : contrôles dès la conception (2.3.1), tests avant le déploiement (2.3.2), déploiement progressif, monitoring et gestion du changement ensuite (2.3.3).
4. 2.4 Permettre la responsabilité des utilisateurs finaux : transparence envers les utilisateurs qui interagissent avec les agents (2.4.2) ; formation des utilisateurs qui travaillent avec eux (2.4.3).

Le cadre de Singapour sur l’IA agentique est-il obligatoire ?

Non. Le cadre se présente comme un document d’orientation : il propose des « bonnes pratiques émergentes », la plupart des recommandations sont formulées sur le mode « les organisations devraient envisager », et il se décrit comme « un document évolutif ». Le communiqué de lancement indique qu’il « donne aux organisations des orientations sur la manière de déployer des agents de façon responsable ». Il ne prévoit ni sanction ni mécanisme de contrôle propre.

Le document n’emploie pas le mot « volontaire » : décrivez-le donc précisément en interne, comme des orientations non législatives émises par un régulateur. Vos obligations légales en matière de protection des données, de droit de la consommation et de règles sectorielles s’appliquent de toute façon, et le cadre est clair : « les organisations qui déploient des agents et les humains qui les supervisent restent responsables des actions des agents ».

Quels risques les agents IA créent-ils selon le cadre ?

Le cadre distingue cinq types de dommages causés par les agents : les actions erronées, les actions non autorisées, les actions biaisées ou injustes, les violations de données et la perturbation des systèmes connectés. Il y ajoute des risques systémiques liés à la vitesse et au volume, aux erreurs en cascade et aux configurations multi-agents. Chacun a un exemple simple au service client.

L’exemple de conflit multi-agents choisi par l’IMDA elle-même est un cas de support : « un agent du support client peut proposer des remboursements pour résoudre rapidement les réclamations, tandis qu’un agent de protection du chiffre d’affaires peut bloquer les remboursements au-delà d’un certain seuil ». Si vous évoluez vers un service client agentique où des agents se passent la main, ce conflit est une question de conception.

Comment chaque partie du cadre s’applique-t-elle à un agent IA du service client ?

Chaque dimension se traduit par quelques décisions pour l’équipe support : quelles intentions l’agent peut traiter et avec quelles permissions, qui en est responsable et qui approuve quoi, comment il est testé et surveillé, et ce que l’on dit aux clients et au personnel. Les étapes suivent l’ordre des sections du cadre.

2.1 Évaluer et borner les risques en amont

Le cadre évalue le risque selon l’impact (domaine et cas d’usage, données sensibles, systèmes externes, lecture ou écriture, réversibilité) et la probabilité (autonomie, complexité de la tâche, exposition aux systèmes externes, solution fournie par un tiers, complexité du système). Appliquez-le par intention, pas par bot :

• Classez vos intentions par niveau. Le suivi de commande est en lecture seule. Un remboursement est une action d’écriture qui engage de l’argent. La clôture d’un compte est difficile à annuler.
• Appliquez le principe du moindre privilège : « les outils et accès aux données minimaux nécessaires ». Un accès en lecture pour le suivi de commande, pas des droits d’administrateur dans le helpdesk.
• Encadrez les tâches de processus par une procédure écrite (SOP) plutôt que par le libre jugement de l’agent. Les parcours de remboursement et de résiliation en sont l’exemple type.
• Prévoyez comment mettre l’agent hors ligne pour une intention ou un canal, nommez qui peut le faire, et testez-le.
• Donnez à l’agent sa propre identité, rattachée à un responsable humain, avec des permissions jamais supérieures à celles de la personne qui l’autorise.

2.2 Rendre les humains réellement responsables

Nommez un responsable des cas d’usage et des limites, une équipe pour la conception, les tests et le monitoring, et un responsable sécurité pour les garde-fous et les tests d’intrusion (red teaming). Si l’agent vient d’un fournisseur, le cadre vous demande de régler la sécurité, la performance et la protection des données dans le contrat, et d’exiger des informations et une journalisation de l’usage des outils et de l’historique des accès. Notre checklist de sécurité pour la QA par IA contient des questions d’achat à réutiliser.

Exigez une validation aux « points de contrôle importants » : les actions à fort enjeu, les actions irréversibles (le cadre cite l’envoi de communications et les paiements), les comportements atypiques et les limites définies par l’utilisateur. Auditez ensuite les validateurs avec deux indicateurs : le taux de rejet humain, pour lequel « un taux faible peut signaler une validation automatique », et le temps de réponse, pour lequel un temps court « peut signaler un biais d’automatisation ou une lassitude de la revue ».

2.3 Mettre en place des contrôles techniques et des processus

Préférez les contrôles imposés par le système aux contrôles inscrits dans le prompt. L’exemple du cadre : « plutôt que de demander à un agent de ne pas utiliser certains outils, on peut mettre en place des contrôles d’accès au niveau des outils ». Placez le plafond de remboursement dans l’API de remboursement, pas dans le prompt système.

Avant le lancement, testez l’exécution des tâches, le respect des règles (y compris l’orientation vers une validation humaine), l’appel des outils et la robustesse, sur l’ensemble du processus, de façon répétée et sur des données variées. Notre guide sur les tests d’agents IA en fait un plan de test. Après le lancement, déployez progressivement, surveillez en continu, fixez des seuils d’alerte avec une intervention définie pour chacun, conservez des logs impossibles à effacer et examinez les changements de modèles, d’outils et de règles selon leur risque. Le guide sur le monitoring des agents IA traite de la conception des alertes.

2.4 Permettre la responsabilité des utilisateurs finaux

Cette section cite directement le service client. Le cadre demande de « déclarer d’emblée dans l’interface utilisateur que les utilisateurs interagissent avec des agents, au moment de l’interaction, plutôt que de l’écrire uniquement dans une documentation séparée », et d’indiquer aux utilisateurs ce que l’agent peut faire, comment leurs données sont utilisées et quelle personne contacter. Pour le personnel, il ajoute une formation aux modes de défaillance et une mise en garde contre la « perte de savoir-faire » : gardez assez de personnes capables de faire tourner le processus quand l’agent est indisponible.

Quelles preuves une équipe support doit-elle conserver pour chaque partie du cadre ?

Conservez des preuves que quelqu’un pourrait vérifier sans vous poser de question : un registre, une décision signée, un résultat de test, un log, une capture d’écran. Le cadre ne prescrit aucun document : ce tableau est donc notre traduction de chaque section en preuve qu’une équipe support pourrait présenter à un auditeur, à un régulateur ou à son propre conseil d’administration.

La plupart de ces preuves se périment, parce que le cadre traite le monitoring comme une activité continue. Et un petit échantillon est une preuve fragile pour un agent qui répète un même comportement des milliers de fois : c’est un argument pour vérifier chaque conversation au regard des règles avec une grille d’évaluation pour agent IA.

Comment fixer des points de validation sans provoquer de lassitude face aux alertes ?

Fixez les validations par niveau de risque, pas par nombre d’actions, puis vérifiez que les validateurs réfléchissent encore. Le cadre prévient qu’une validation humaine continue « peut aussi entraîner un biais d’automatisation et une lassitude face aux alertes », et cite deux signaux : un taux de rejet faible et des temps de réponse courts. Il ne donne aucun seuil : c’est à vous de fixer les vôtres.

Une illustration, avec des chiffres que nous avons choisis pour montrer le calcul (pas des données d’une entreprise). L’agent IA d’un distributeur traite 40 000 conversations par mois :

Valider chaque remboursement de niveau 2 représente 10 000 demandes par mois, soit environ 455 par jour ouvré sur 22 jours. Personne n’en examine autant avec soin. Si 20 % des remboursements dépassent 50 dollars, les validations tombent à 2 000 par mois, soit environ 91 par jour.

Auditez-les ensuite. Supposons que les validateurs aient rejeté ou modifié 14 demandes sur 2 000, soit un taux de rejet de 0,7 %, avec un temps de décision médian de 3 secondes. Ensemble, ces chiffres correspondent à ce que le cadre décrit comme une validation automatique. Une règle de décision que nous suggérons : quand le taux de rejet est inférieur à 2 % et le temps de décision médian inférieur à 10 secondes, faites réexaminer à l’aveugle un échantillon de 50 demandes approuvées. Si les examinateurs en modifieraient plusieurs, raccourcissez les demandes, ajoutez le risque et le niveau de confiance que le cadre demande, ou déplacez le plafond.

Le niveau 1 n’a aucun validateur : l’évaluation après coup de chaque conversation est donc le seul contrôle sur 70 % du volume. Le guide sur l’évaluation des agents IA explique comment évaluer ces résultats.

Comment le cadre se compare-t-il à l’AI Act pour le service client ?

L’AI Act est une loi contraignante ; le cadre de Singapour est un document d’orientation. Pour un agent IA du service client, ils se recoupent surtout sur l’information des utilisateurs : l’article 50, paragraphe 1, de l’AI Act exige depuis le 2 août 2026 que les personnes soient informées qu’elles interagissent avec une IA, et le cadre demande la même chose au moment de l’interaction.

En pratique, l’AI Act fixe le minimum européen, essentiellement l’information des utilisateurs pour un agent en contact avec les clients, tandis que le cadre de Singapour vous dit comment exploiter un agent qui réalise des actions. Dans les deux marchés, construisez un seul ensemble de contrôles conforme à l’AI Act et utilisez la structure du cadre pour le reste. Notre article sur l’AI Act et le service client détaille les dates, les niveaux et les amendes.

Quand ce cadre n’est pas pour vous

Si votre bot ne fait que répondre à partir de votre propre centre d’aide et ne réalise aucune action, la plus grande partie du cadre demande peu de travail. Ses facteurs de risque classent l’accès en lecture seule et une base de connaissances maintenue en interne comme moins risqués : il vous faut surtout la mention de l’IA, un contact humain et des contrôles qualité sur les réponses.

Il ne décrit pas non plus de certification : « conforme au MGF » n’est donc pas une affirmation que quiconque peut vérifier pour vous ; ce que vous pouvez montrer, ce sont les preuves du tableau ci-dessus.

Où se situe le contrôle qualité dans le cadre ?

Le contrôle qualité couvre les parties qui exigent des preuves tirées de vraies conversations : le respect des règles après le lancement, les audits réguliers, la mention de l’IA et la boucle de retour que demande le cadre, « réinjecter les enseignements du monitoring dans les jeux de données d’entraînement et les cadres d’évaluation ». Les logs montrent ce que l’agent a fait ; une note qualité montre s’il avait raison.

Kaizo est une façon de prendre en charge cette partie. Il évalue 100 % des conversations de vos agents IA avec votre propre grille, celle-là même qui sert à évaluer votre équipe, et relie chaque note aux preuves dans la conversation ; voyez le contrôle qualité des agents IA. Réservez une démo pour le voir sur vos propres conversations.

Comment démarrer cette semaine

Vous pouvez couvrir la première dimension et une partie de la quatrième en cinq jours ouvrés, sans nouvel outil : ce que l’agent peut toucher, qui en est responsable, ce que voient les clients, et un premier audit de vos validateurs.

1. Jour 1 : listez chaque intention que traite l’agent et chaque outil qu’il peut utiliser ; indiquez pour chaque outil s’il est en lecture ou en écriture.
2. Jour 2 : classez chaque intention selon son impact et sa réversibilité ; signalez toute action d’écriture qui touche à l’argent ou aux comptes.
3. Jour 3 : nommez un responsable pour l’agent et pour chaque niveau ; écrivez qui peut le désactiver, et testez-le.
4. Jour 4 : ouvrez une conversation dans chaque canal et chaque langue ; faites une capture de la mention de l’IA et du chemin vers une personne.
5. Jour 5 : calculez le taux de rejet du mois dernier et le temps de réponse médian par validateur.

Questions fréquentes

Existe-t-il un PDF du cadre ?

Oui. L’IMDA le publie en PDF sur imda.gov.sg, sous le titre « Model AI Governance Framework for Agentic AI », version 1.5. Il compte 53 pages, avec des études de cas, des ressources complémentaires en annexe A et un appel à contributions en annexe B.

Le cadre s’applique-t-il aux entreprises hors de Singapour ?

Le cadre ne définit pas de champ d’application territorial. Il s’adresse à toute organisation qui souhaite déployer une IA agentique, construite en interne ou achetée. Les entreprises d’autres pays peuvent utiliser sa structure, mais ce sont leurs propres lois qui déterminent ce qui est obligatoire.

Le cadre impose-t-il qu’un humain valide chaque réponse d’un agent IA ?

Non. Il demande une validation aux points de contrôle importants, comme les actions à fort enjeu, irréversibles ou inhabituelles, et note qu’une supervision continue de chaque processus devient irréaliste à grande échelle. Les validations sont associées à un monitoring automatisé et à des seuils d’alerte.

Qu’est-ce qui est nouveau dans la version 1.5 ?

La version 1.5 intègre les retours de plus de 60 entreprises depuis la version 1.0. Elle ajoute des facteurs de risque comme la complexité du système et les solutions de tiers, les risques multi-agents, des pratiques contre le biais d’automatisation comme le suivi des taux de rejet, des orientations sur la gestion du changement et des études de cas.

Une entreprise peut-elle être certifiée au regard du cadre ?

Le document ne décrit aucun dispositif de certification ou d’audit. C’est un ensemble de pratiques recommandées : ce qu’une entreprise peut montrer de plus solide, ce sont ses propres preuves, à savoir ses niveaux de risque, ses journaux de validation, ses résultats de tests, ses enregistrements de monitoring et ses captures de la mention de l’IA.