AI TRiSM : Définition et conseils pratiques

Que se passe-t-il lorsqu’un agent IA utilise une mauvaise source, accède à un champ confidentiel ou déclenche une action que personne ne peut annuler ?

En entreprise, cette question marque la frontière entre une simple expérimentation et un système réellement intégré aux opérations. Tant que l’IA produit un brouillon relu par un collaborateur, le risque reste relativement contenu. Lorsqu’elle échange directement avec un client ou agit dans un outil métier, une réponse erronée peut devenir un rendez-vous mal enregistré, une information sensible divulguée ou une promesse commerciale impossible à tenir.

L’AI TRiSM commence précisément à cet endroit. Son objectif n’est pas de ralentir les projets, mais de rendre explicites les règles qui permettent de les déployer sans perdre la maîtrise des données, des décisions et des actions.

AI TRiSM : de quoi parle-t-on exactement ?

AI TRiSM signifie « AI Trust, Risk and Security Management », soit la gestion de la confiance, des risques et de la sécurité de l’intelligence artificielle. Ce cadre associe gouvernance, surveillance, validation et mécanismes de protection afin que les systèmes d’IA restent fiables, sécurisés et conformes à leur périmètre d’utilisation[1].

Il couvre l’ensemble du système, et pas uniquement le modèle :

• les données reçues et consultées ;
• les instructions données au modèle ;
• les bases documentaires utilisées ;
• les applications et API connectées ;
• les actions que l’agent peut exécuter ;
• les règles de transfert vers un humain ;
• les journaux nécessaires à la détection et à l’analyse d’un incident.

L’AI TRiSM n’est donc ni un chatbot, ni un agent IA, ni un logiciel de cybersécurité. C’est la démarche qui permet de décider comment ces composants doivent être sélectionnés, configurés, testés et surveillés.

Ce n’est pas non plus une norme ou une obligation légale autonome. Mettre en place un programme AI TRiSM ne suffit pas à prouver qu’une entreprise respecte le RGPD ou l’AI Act. Le cadre aide plutôt à transformer des exigences internes, juridiques ou contractuelles en contrôles applicables.

Une méthode complémentaire consiste à organiser la gestion des risques autour de quatre fonctions : gouverner, cartographier, mesurer et gérer. La gouvernance traverse alors tout le cycle de vie, tandis que les risques sont régulièrement réévalués à partir du contexte réel d’utilisation[2].

Le bon niveau de contrôle dépend du pouvoir donné à l’agent

Prenons trois agents utilisant le même modèle de langage :

Le modèle peut être identique, mais le risque ne l’est pas. L’analyse doit donc porter sur le système complet et sur ses effets possibles, pas seulement sur la qualité moyenne des réponses.

Pourquoi les agents IA changent-ils la nature du risque ?

Un assistant conversationnel classique répond. Un agent IA peut, selon sa configuration, choisir un outil, rechercher une information, modifier un système tiers et poursuivre une tâche en plusieurs étapes.

Cette capacité d’action crée quatre points de vigilance.

Une réponse convaincante peut rester fausse

Imaginons un agent chargé de répondre aux questions relatives aux abonnements. Le client lui demande si une résiliation sera remboursée. L’agent produit une réponse précise et rassurante, mais s’appuie sur une ancienne version des conditions contractuelles.

La formulation semble crédible. Le problème ne sera peut-être détecté qu’au moment de la réclamation.

Les risques propres à l’IA générative comprennent notamment la production de contenus erronés présentés avec assurance, les atteintes à la confidentialité, les problèmes d’intégrité de l’information et les menaces contre la sécurité des systèmes[3].

Le contrôle utile ne consiste donc pas seulement à demander si la réponse « paraît bonne ». Il faut vérifier :

• la source mobilisée ;
• sa date de mise à jour ;
• le respect du périmètre autorisé ;
• le comportement de l’agent lorsqu’aucune réponse fiable n’est disponible.

Un accès pratique peut devenir excessif

Un agent qui prend un rendez-vous a besoin du nom du client, de ses coordonnées et des disponibilités pertinentes. Il n’a pas nécessairement besoin de consulter l’ensemble de son historique, ses anciennes réclamations ou les notes privées des commerciaux.

Chaque connecteur agrandit le périmètre du système. Un accès CRM conçu pour fluidifier la conversation peut exposer davantage d’informations que le cas d’usage ne le justifie.

Lorsqu’un traitement porte sur des données à caractère personnel, celles-ci doivent être collectées pour des finalités déterminées et légitimes. Elles doivent également rester limitées à ce qui est nécessaire pour atteindre ces finalités[4].

La bonne question n’est donc pas : « L’agent peut-il se connecter au CRM ? » Elle est : « Quels champs peut-il lire ou modifier pour accomplir cette tâche précise ? »

Une mauvaise réponse peut entraîner une mauvaise action

Une hallucination contenue dans un brouillon peut être corrigée avant envoi. Une hallucination qui déclenche une action produit immédiatement un effet opérationnel.

Un agent peut, par exemple :

• créer un ticket dans la mauvaise catégorie ;
• prendre un rendez-vous avec un interlocuteur indisponible ;
• modifier le statut d’une opportunité ;
• envoyer un récapitulatif comportant une information erronée ;
• transférer la conversation au mauvais service.

Il convient alors de distinguer les actions réversibles des actions sensibles. Ajouter une note interne et valider un remboursement n’exigent pas le même niveau d’approbation.

Le système peut changer sans que le cas d’usage change

Même si l’agent conserve le même nom et la même interface, son comportement peut évoluer après :

• un changement de modèle ;
• une modification des instructions ;
• l’ajout d’une source documentaire ;
• l’activation d’une nouvelle intégration ;
• une modification des droits d’accès ;
• une mise à jour effectuée par un fournisseur.

Un test réussi lors du lancement ne garantit donc pas les performances futures. L’AI TRiSM traite la mise en production comme le début de la surveillance, et non comme la fin du projet.

Les contrôles AI TRiSM, du premier test à l’incident

Une démonstration réussie prouve que l’agent sait traiter quelques scénarios préparés. Elle ne montre pas comment il réagira à une demande ambiguë, à une source contradictoire ou à une tentative de contournement.

Les évaluations doivent avoir lieu avant le déploiement, puis régulièrement pendant l’exploitation[2].

Avant le déploiement : fixer les limites du terrain de jeu

L’équipe doit d’abord documenter :

• la mission exacte de l’agent ;
• les utilisateurs concernés ;
• les sources qu’il peut consulter ;
• les données qu’il peut collecter ;
• les outils auxquels il peut se connecter ;
• les actions qu’il peut exécuter ;
• les situations dans lesquelles il doit passer la main.

Pour un agent de prise de rendez-vous, le périmètre pourrait être le suivant : identifier le motif, consulter les créneaux, recueillir les coordonnées nécessaires et confirmer la réservation. Conseiller le client sur une clause contractuelle ou modifier son abonnement resterait interdit.

Les tests doivent ensuite couvrir les scénarios attendus, mais aussi les demandes incomplètes, contradictoires ou hostiles.

Pendant l’interaction : contrôler les entrées, les sorties et les actions

La surveillance en production ne consiste pas à relire manuellement chaque conversation. Elle vise surtout à détecter les événements qui méritent une intervention :

• tentative d’obtenir une information non autorisée ;
• réponse sans source suffisamment fiable ;
• succession inhabituelle d’appels à des outils ;
• volume anormal d’actions ;
• taux d’échec ou de transfert en hausse ;
• apparition de données sensibles dans une sortie ;
• contournement d’une consigne.

Les recommandations belges consacrées à l’utilisation sûre et responsable de l’IA conversationnelle rappellent que ces systèmes peuvent produire des erreurs. Elles mettent également en garde contre une confiance excessive dans leurs résultats, susceptible d’entraîner une automatisation mal maîtrisée[5].

Les protections doivent donc couvrir l’architecture dans laquelle l’agent évolue : droits d’accès, outils connectés, données transmises, mises à jour et actions exécutées.

Après une évolution : rejouer les scénarios critiques

Une nouvelle base documentaire peut améliorer la couverture des réponses tout en introduisant des contradictions. Une intégration supplémentaire peut enrichir le service tout en donnant accès à de nouvelles données.

Chaque changement significatif doit donc déclencher une série de tests proportionnée à son impact :

• les scénarios métier critiques fonctionnent-ils toujours ?
• les anciennes restrictions restent-elles effectives ?
• l’agent utilise-t-il la bonne version des documents ?
• les règles de transfert vers un humain sont-elles préservées ?
• les nouvelles permissions sont-elles strictement nécessaires ?

Pour les entreprises belges qui déploient un système d’IA, les recommandations officielles insistent notamment sur la vérification régulière des résultats, la conservation des enregistrements, le signalement des incidents et la suspension de l’utilisation si la situation l’exige[6].

En cas d’incident : comprendre avant de relancer

Suspendre temporairement un agent ne suffit pas. L’entreprise doit pouvoir reconstruire la séquence :

1. Quelle demande a été formulée ?
2. Quelles sources et données l’agent a-t-il consultées ?
3. Quelle version du modèle et des instructions était utilisée ?
4. Quels outils ont été appelés ?
5. Quelle action a été exécutée ?
6. Quel contrôle aurait dû l’arrêter ?
7. Qui peut autoriser la remise en service ?

Sans ces éléments, la correction risque de masquer le symptôme sans traiter la cause.

Fiche opérationnelle pour déployer l’AI TRiSM en six étapes

Le déploiement ne commence pas par l’achat d’une plateforme de gouvernance. Il commence par six décisions que l’entreprise doit être capable d’expliquer.

1. Recenser les agents, les modèles et les connecteurs

L’inventaire doit couvrir les outils officiellement déployés, mais aussi les fonctions d’IA intégrées à des logiciels déjà utilisés.

Pour chaque système, consignez :

• le fournisseur et la version ;
• la finalité ;
• le propriétaire métier ;
• les données traitées ;
• les outils connectés ;
• les actions possibles ;
• les populations concernées ;
• la date de la dernière évaluation.

Un inventaire limité au nom des fournisseurs ne permet pas de comprendre le risque. Deux équipes peuvent utiliser le même service avec des permissions et des conséquences radicalement différentes.

2. Classer les cas d’usage selon leur impact

Le classement peut reposer sur quatre questions :

• L’agent échange-t-il directement avec un client ?
• Manipule-t-il des données personnelles ou confidentielles ?
• Peut-il modifier un système ou déclencher une action ?
• Une erreur peut-elle produire une conséquence difficile à corriger ?

Un agent qui reformule une note interne appartient à une catégorie différente d’un agent qui qualifie un prospect, réserve un créneau et met à jour le CRM.

Cette classification détermine l’intensité des tests, de la surveillance et de la validation humaine. Elle évite d’imposer un processus disproportionné aux usages faibles tout en sous-estimant les agents les plus autonomes.

3. Attribuer les décisions, et pas seulement les tâches

La responsabilité ne peut pas rester dispersée entre le métier, l’IT, le service juridique et le fournisseur.

Le propriétaire métier décide de la finalité et du niveau de service acceptable. Le responsable technique contrôle les intégrations, les permissions et le fonctionnement. Le responsable de la sécurité, le DPO et les spécialistes des données ou de la conformité interviennent selon le risque.

Un arbitre doit enfin pouvoir répondre à trois questions : qui suspend l’agent, qui valide la correction et qui autorise son redémarrage ?

4. Limiter les données et les actions accessibles

Appliquez le principe du moindre privilège à l’agent comme à un collaborateur :

• accès aux seuls champs nécessaires ;
• lecture seule lorsqu’une modification n’est pas indispensable ;
• séparation entre environnement de test et production ;
• durée de conservation adaptée ;
• validation humaine pour les actions sensibles ;
• identifiants distincts permettant d’attribuer les actions à l’agent.

Commencer avec un périmètre étroit facilite aussi l’analyse des résultats. L’autonomie peut ensuite être élargie lorsque les contrôles ont fait leurs preuves.

5. Tester les scénarios réels et les tentatives de contournement

Un jeu de tests utile ne contient pas uniquement les questions les plus fréquentes. Il comprend aussi :

• une demande hors périmètre ;
• une instruction ambiguë ;
• deux documents qui se contredisent ;
• une donnée manquante ;
• une tentative d’obtenir une information confidentielle ;
• une demande formulée avec colère ou ironie ;
• l’indisponibilité d’un outil connecté ;
• une situation qui exige un transfert immédiat.

Pour chaque scénario, précisez le résultat attendu. « L’agent doit bien répondre » n’est pas un critère mesurable. « L’agent refuse de communiquer le champ concerné, explique sa limite et transfère la demande » en est un.

6. Surveiller quelques indicateurs qui conduisent à une décision

Les tableaux de bord trop généraux masquent souvent les problèmes utiles. Mieux vaut suivre des indicateurs reliés à une action :

• taux de réponses incorrectes sur un échantillon contrôlé ;
• taux de transfert vers un humain ;
• taux de résolution sans reprise manuelle ;
• nombre d’actions bloquées ;
• nombre d’accès refusés ;
• taux de réussite des scénarios critiques ;
• incidents par version du système ;
• délai moyen de détection et de traitement.

Un taux de transfert élevé n’est pas nécessairement mauvais. Il peut montrer que l’agent respecte correctement ses limites. L’indicateur doit toujours être interprété au regard du risque et de la promesse faite au client.

AI TRiSM, AI Act et RGPD : comment les articuler en Belgique ?

Depuis le 2 août 2026, les obligations de transparence prévues par l’article 50 de l’AI Act s’appliquent à certains systèmes d’IA. Les utilisateurs d’un chatbot ou d’un autre système interactif doivent notamment être informés qu’ils échangent avec une machine plutôt qu’avec une personne[7].

Pour les systèmes conçus afin d’interagir directement avec des personnes, celles-ci doivent en principe être informées qu’elles échangent avec une IA, sauf lorsque cela ressort manifestement du contexte[8].

Cette exigence concerne directement certains agents conversationnels ou vocaux. Elle ne constitue toutefois qu’une partie de l’analyse.

Le RGPD continue de s’appliquer lorsque l’agent traite des données à caractère personnel. Il convient alors d’examiner notamment :

• la finalité et la base juridique du traitement ;
• les données réellement nécessaires ;
• la durée de conservation ;
• l’information des personnes ;
• les mesures de sécurité ;
• l’exercice des droits des personnes concernées ;
• la nécessité éventuelle d’une analyse d’impact.

En Belgique, l’Autorité de protection des données est l’autorité de contrôle compétente pour le RGPD. Sa brochure consacrée aux systèmes d’intelligence artificielle et au RGPD permet d’approfondir les principes de finalité, de transparence et de minimisation[4].

L’AI TRiSM sert à rendre ces exigences opérationnelles : contrôle d’accès, validation, journalisation, surveillance ou procédure d’incident. Il ne remplace pas l’analyse juridique.

De la même manière, tous les agents IA ne sont pas automatiquement classés comme systèmes à haut risque. Le classement dépend de leur finalité, de leur contexte d’utilisation et du rôle de l’organisation. Une analyse au cas par cas reste nécessaire.

Quelles questions poser à un fournisseur d’agents IA ?

Lors d’une démonstration, un agent répond généralement aux demandes prévues. La véritable évaluation commence lorsqu’on lui retire une information, qu’on lui présente deux sources contradictoires ou qu’on lui demande d’effectuer une action non autorisée.

Avant de choisir une solution, posez-vous les questions suivantes :

• Quelles données sont envoyées au modèle et où sont-elles traitées ?
• Ces données servent-elles à entraîner ou à améliorer d’autres modèles ?
• Peut-on limiter les accès par agent et par cas d’usage ?
• Les actions de l’agent disposent-elles d’une identité propre dans les journaux ?
• Quelles versions du modèle, des instructions et des sources sont traçables ?
• Comment tester une évolution avant son passage en production ?
• Quels contrôles fonctionnent pendant la conversation ?
• Une action sensible peut-elle exiger une validation humaine ?
• Comment l’agent transfère-t-il une interaction avec son contexte ?
• Comment récupérer les traces nécessaires lors d’un incident ?
• Peut-on suspendre rapidement un agent sans désactiver tout le service ?
• Quels engagements relèvent du fournisseur et lesquels restent à la charge du client ?

Le cas d’un agent vocal connecté aux outils métier

Un agent vocal illustre bien la nécessité de raisonner sur l’ensemble de la chaîne. Il ne produit pas seulement une réponse : il écoute une demande, collecte des informations, consulte éventuellement un outil et déclenche une suite d’actions.

Ces possibilités rendent plusieurs contrôles particulièrement concrets :

• quelles informations l’agent est-il autorisé à recueillir ?
• quels champs peut-il ajouter à la fiche client ?
• dans quels cas doit-il interrompre le scénario ?
• quelles actions nécessitent une confirmation de l’appelant ?
• à quel moment un conseiller doit-il reprendre la conversation ?
• quel contexte doit être transmis lors du transfert ?

Gouverner une IA, c’est décider ce qu’elle peut faire lorsque personne ne la regarde

Un agent IA fiable n’est pas seulement un agent qui passe le cap de la démonstration. C’est un système dont l’entreprise connaît les sources, les accès, les limites et les actions, y compris après une mise à jour ou lorsqu’une interaction sort du scénario prévu.

L’AI TRiSM donne une structure à cette maîtrise. Il relie chaque risque à un contrôle, chaque contrôle à un responsable et chaque décision à une preuve. Cette logique permet d’éviter deux écueils : bloquer tous les projets par prudence ou, à l’inverse, découvrir leurs limites une fois qu’un client en subit les conséquences.

Pour commencer, choisissez un seul agent IA et documentez quatre éléments : ce qu’il peut lire, ce qu’il peut dire, ce qu’il peut faire et ce qui doit provoquer un transfert vers un humain. Vous disposerez déjà d’une première base exploitable pour construire votre dispositif AI TRiSM.

FAQ sur l’AI TRiSM

Quelle différence entre AI TRiSM et gouvernance de l’IA ?

La gouvernance définit les responsabilités, les politiques et les décisions. L’AI TRiSM y ajoute les mécanismes d’évaluation, de surveillance et de sécurité nécessaires pour appliquer ces règles tout au long du cycle de vie.

AI TRiSM est-il une norme ou une certification ?

Non. Il s’agit d’un cadre de gestion de la confiance, des risques et de la sécurité. Une entreprise ne devient pas automatiquement conforme à une réglementation parce qu’elle déclare appliquer AI TRiSM.

Faut-il appliquer AI TRiSM à un projet pilote ?

Oui, mais de manière proportionnée. Un pilote doit au minimum disposer d’une finalité, d’un propriétaire, d’un périmètre de données, de critères de réussite et d’une condition d’arrêt.

Qui doit piloter AI TRiSM ?

Le pilotage doit associer un propriétaire métier et un responsable technique. Le RSSI, le DPO, le service juridique, les équipes data ou la conformité interviennent selon les risques du cas d’usage.

Un humain doit-il absolument valider toutes les actions d’un agent IA ?

Pas nécessairement. La validation humaine doit être concentrée sur les actions sensibles, difficiles à annuler ou susceptibles d’avoir une conséquence importante. Les actions simples et réversibles peuvent être automatisées avec une surveillance adaptée.

Mentions

[1] https://www.gartner.com/en/articles/ai-governance-trism

[2] https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

[3] https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

[4] https://www.dataprotectionauthority.be/publications/brochure-d-information-sur-les-systemes-d-intelligence-artificielle-et-le-rgpd.pdf

[5] https://ccb.belgium.be/fr/open-media/646/download?inline=

[6] https://economie.fgov.be/fr/themes/entreprises/ai-act/vous-utilisez-lia-au-sein-de

[7] https://economie.fgov.be/fr/themes/line/intelligence-artificielle/foire-aux-questions-concernant

[8] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?qid=1788662127473&uri=CELEX%3A02024R1689-20260727

Publié le 29 septembre 2026.