Blog
•
14 min de lecture
Pas toujours. Une suite GRC d’entreprise gère déjà l’attestation des politiques, les tests de contrôles, la gestion des problèmes et le flux de travail d’audit, et ces fonctions s’appliquent telles quelles aux systèmes d’IA. Ce qu’elle ne gère pas nativement, c’est le dossier propre à l’IA : la détection, les métadonnées des modèles et des agents, les preuves versionnées et la correspondance entre des réglementations de l’IA qui se recoupent. La réponse dépend de la part de ce dossier que vous devez produire.
Que gère déjà bien une suite GRC existante en matière d’IA ?
Les disciplines et principes fondamentaux de la GRC s’appliquent à l’IA sans modification. ServiceNow décrit les flux de travail de conformité de Integrated Risk Management en ces termes : « gérer les politiques, automatiser les tests de contrôles et instruire les problèmes », et annonce qu’il permet de « centraliser les preuves d’audit ». Archer réunit des produits de gouvernance des politiques, de gestion des audits, de conformité réglementaire et de gestion des risques d’entreprise dans un même système d’enregistrement. Un programme de gouvernance de l’IA a besoin de tout cela dès le premier jour et ne devrait rien en reconstruire. Six de ces fonctions se transposent directement à la gouvernance de l’IA :
Attestation des politiques. Une politique d’utilisation acceptable de l’IA générative est une politique comme une autre : la publier, recueillir les attestations, suivre les exceptions.
Gestion des problèmes et des constats. Un constat de biais issu de la revue d’un modèle est un problème assorti d’un responsable, d’une échéance et d’un plan de remédiation.
Flux de travail d’audit. L’audit interne gère déjà son plan, ses travaux sur le terrain et ses rapports dans la suite.
Bibliothèques de contrôles. Un contrôle qui restreint l’accès aux systèmes de production s’applique à un point de terminaison d’inférence comme à une base de données.
Taxonomie des risques d’entreprise. Le risque lié à l’IA doit remonter dans la taxonomie des risques opérationnels que le conseil d’administration consulte déjà, et non dans une taxonomie parallèle.
Approbations existantes. Achats, revue de sécurité, évaluation de la protection des données et comité des changements sont des circuits établis : une demande d’IA doit les emprunter, et non les contourner.
Les acteurs historiques ont eux aussi évolué. ServiceNow AI Control Tower affirme pouvoir « inventorier automatiquement tout agent d’IA, modèle et serveur MCP, qu’ils soient internes ou tiers » et propose du contenu pour l’EU AI Act, le NIST AI RMF et le California AI Transparency Act. Collibra AI Governance offre « un registre unifié pour chaque actif d’IA », des modèles d’évaluation pour l’EU AI Act et le NIST AI RMF, ainsi qu’un lignage « depuis les ensembles de données sources jusqu’à l’entraînement des modèles, l’inférence, le déploiement et l’utilisation ». OneTrust AI Governance promet de « détecter et inventorier les systèmes d’IA, modèles, agents, ensembles de données, fournisseurs, projets et cas d’usage », avec des modèles d’évaluation pour l’EU AI Act, le NIST AI RMF et l’ISO 42001. Archer propose également une offre AI Governance. Pour l’acheteur, la question n’est donc plus de savoir si la suite dispose d’un module IA, mais si ce module est assez approfondi pour le parc d’IA dont il a la charge, et où le dossier propre à l’IA doit se trouver.
Que ne peut pas faire, par construction, un module GRC pour les systèmes d’IA ?
Un modèle de données GRC s’articule autour des politiques, des contrôles, des risques, des problèmes et, dans le cas de ServiceNow, des éléments de configuration de la CMDB. Or un bon programme de gouvernance de l’IA a besoin d’objets pour lesquels ces modèles n’ont pas été conçus. Nous observons six lacunes dans les entreprises qui tentent de piloter leur gouvernance de l’IA avec ces outils ; chacune est détaillée ci-dessous.
La détection est la première. Un enregistrement GRC existe parce que quelqu’un l’a créé. Or l’IA entre par des fonctionnalités qu’un éditeur SaaS a activées, des abonnements passés en notes de frais, des modèles intégrés aux produits des fournisseurs et des agents développés sur des plateformes internes, et aucun de ces canaux ne génère d’enregistrement. L’inventaire IA d’Enzai combine la détection de l’IA, les imports depuis les plateformes et les demandes de cas d’usage. Le guide consacré à la constitution d’un inventaire IA détaille ce que chaque méthode laisse échapper.
Les métadonnées des modèles et des agents sont la deuxième. Le modèle de base et sa version, le fournisseur, la configuration des prompts, les données d’ajustement précis, le niveau d’autonomie et les autorisations d’outils sont des attributs d’un système d’IA, et un enregistrement de contrôle n’a de champ pour aucun d’entre eux.
La correspondance des référentiels entre des réglementations de l’IA qui se recoupent est la troisième. Un même système d’octroi de crédit peut relever de l’annexe III de l’EU AI Act, entrer dans un périmètre ISO 42001 et être soumis à la fois au NIST AI RMF et à la loi de l’État où réside le client. Or ces réglementations évoluent. Le Colorado a abrogé puis réadopté sa loi sur l’IA sous la forme du SB 26-189, signé le 14 mai 2026, les droits des consommateurs s’appliquant à compter du 1er janvier 2027. L’omnibus numérique sur l’IA est entré en vigueur le 27 juillet 2026 et a reporté les obligations de l’annexe III au 2 décembre 2027. Une bibliothèque de contrôles tenue à la main prend du retard à chaque changement, et les preuves réunies pour un référentiel sont rarement réutilisées pour le suivant.
La surveillance continue du comportement des modèles est la quatrième. Les tests de contrôles sont périodiques. L’article 9, paragraphe 2, de l’EU AI Act décrit le système de gestion des risques des systèmes d’IA à haut risque comme « un processus itératif continu qui est planifié et se déroule sur l’ensemble du cycle de vie ». La dérive, la qualité des sorties et les signaux des garde-fous relèvent de la télémétrie, et non de résultats de tests trimestriels.
Les preuves rattachées à une version précise du modèle sont la cinquième. Lorsqu’un auditeur demande au regard de quoi un système a été validé, par qui et sur quelle version, la réponse doit désigner la version en production, et la collecte des preuves doit être relancée lorsque le fournisseur change de modèle de base. Un test de contrôle ne répond pas à cette question.
L’autonomie et la gestion des habilitations au niveau de l’agent constituent la sixième. Les outils qu’un agent peut appeler, ce qu’il peut faire sans confirmation et le seuil auquel la récursion est plafonnée sont des décisions qui évoluent à mesure que le périmètre de l’agent s’élargit. Le module de gouvernance de l’IA agentique d’Enzai classe chaque agent « selon ce qu’il peut faire sans supervision : lecture seule, proposition uniquement ou action » et bloque à la frontière les appels d’outils non autorisés.
Comment se comparent un module GRC et une gouvernance de l’IA dédiée ?
Critère | Suite GRC avec module IA | Couche de gouvernance de l’IA dédiée |
|---|---|---|
Système d’enregistrement pour les politiques, les risques, les problèmes et l’audit | Natif, mature, destiné au conseil d’administration | L’alimente. Ne doit pas le remplacer |
Détection de l’IA | Fondée sur l’enregistrement ; les modules récents ajoutent un inventaire automatisé | Plusieurs méthodes de détection, pour l’IA autorisée comme pour l’IA fantôme |
Modèle objet | Politique, contrôle, risque, problème, élément de configuration | Système d’IA, modèle, agent, cas d’usage, fournisseur, version |
Couverture des référentiels IA | Contenu fourni par l’éditeur ; les trois modules examinés pour cet article couvrent chacun deux ou trois référentiels propres à l’IA | Bibliothèque couvrant l’EU AI Act, l’ISO 42001, le NIST AI RMF, le RGPD, les réglementations des États américains, le FS AI RMF et l’OWASP Agentic Top 10, avec des preuves réutilisées d’un référentiel à l’autre |
Granularité des preuves | Par contrôle, par cycle de test | Par système, par référentiel, avec un score de conformité en temps réel |
Surveillance | Tests de contrôles périodiques et indicateurs clés de risque | Périmètre d’action des agents, dérive par rapport aux actions autorisées |
Gouvernance des agents | Émergente ; périmètre et profondeur variables selon l’éditeur | Niveaux d’autonomie, actions autorisées, topologie multi-agent |
Processus de demande et approbation | Circuits d’approbation existants de l’entreprise | Évaluation initiale de l’IA hiérarchisée selon les risques, avec transmission vers Jira, ServiceNow et Slack |
Responsable habituel | GRC ou fonction risques de deuxième ligne | Responsable de l’IA ou référent IA responsable, conjointement avec la GRC |
Contexte le plus adapté | Parc d’IA réduit, faible exposition réglementaire, responsabilités déjà bien établies | Agents en production, IA intégrée par les fournisseurs, périmètre annexe III ou ISO 42001, plusieurs juridictions |
La profondeur varie selon l’éditeur et la version : considérez chaque ligne comme une question d’évaluation, et non comme un verdict.
Quand l’extension de la suite GRC est-elle le bon choix ?
Si les trois conditions suivantes sont réunies dans votre entreprise, votre outil GRC existant peut être le bon choix.
Le parc d’IA est réduit et stable : quelques dizaines de systèmes, aucun agent disposant d’un accès en écriture, aucun système relevant d’une catégorie de l’annexe III ou d’un régime sectoriel à haut risque, et aucun projet de changement d’ici un an.
L’exposition réglementaire est faible : aucune activité à haut risque dans l’UE, aucune certification ISO 42001 envisagée, aucune attente des autorités de supervision visant explicitement l’IA.
Les responsabilités sont déjà bien établies : un responsable désigné en deuxième ligne pour le risque lié à l’IA, un processus de demande opérationnel et des responsables métier qui enregistrent ce qu’ils achètent.
Si ces trois conditions sont remplies, ajoutez des attributs IA au registre des risques existant, activez le module IA de l’éditeur et fixez une date de revue. Le coût d’une seconde plateforme est bien réel : une intégration de plus, une évaluation des risques fournisseur de plus, un identifiant de plus. Un programme au stade ad hoc ou reproductible du modèle de maturité de la gouvernance gagnera davantage à rédiger la politique et à identifier les systèmes qu’à s’équiper d’outils.
Un cas illustratif : un assureur régional disposant de huit fonctionnalités d’IA intégrées par ses fournisseurs, d’un modèle de détection de la fraude déjà couvert par la gestion du risque de modèle, et d’aucun agent. Pour l’instant, étendre la suite est la bonne décision.
Quand une couche de gouvernance de l’IA dédiée devient-elle nécessaire ?
Un seul de ces signaux suffit généralement.
Des agents sont en production avec l’autorisation d’agir. Un enregistrement de problème GRC ne peut pas exprimer « cet agent peut lire le CRM et proposer un remboursement, mais ne doit pas en exécuter », et cette liste change plus souvent que n’importe quelle politique.
Plusieurs réglementations de l’IA s’appliquent au même système, et elles ne cessent d’évoluer. Des preuves par système et par référentiel, avec une réutilisation multi-framework, sont le seul moyen de ne plus collecter sans cesse les mêmes éléments.
L’organisation est une banque. La lettre SR 26-2, publiée le 17 avril 2026 en remplacement de la SR 11-7, indique que les modèles d’IA générative et agentique « n’entrent pas dans le champ d’application de ces lignes directrices » (Réserve fédérale). Le cadre de gestion du risque de modèle d’une banque ne couvre donc pas formellement les systèmes qu’elle déploie le plus rapidement, et un cadre parallèle, conçu pour être rapproché ultérieurement, doit trouver sa place en dehors de l’outil de MRM comme du registre des problèmes GRC.
L’accumulation des demandes de personnalisation est le signe qui ne trompe pas. Si l’équipe GRC crée des tables sur mesure pour les modèles, les agents et les versions, la suite devient une plateforme de gouvernance de l’IA, une demande de changement après l’autre.
La certification ISO/IEC 42001 est envisagée. L’ISO/IEC 42001:2023, publiée en décembre 2023, « spécifie les exigences relatives à l’établissement, à la mise en œuvre, à la tenue à jour et à l’amélioration continue d’un système de management de l’intelligence artificielle ». Les auditeurs attendent la preuve que ce système a fonctionné dans la durée, pour chaque système d’IA inclus dans le périmètre.
Faut-il choisir, ou la couche de gouvernance de l’IA alimente-t-elle le système d’enregistrement GRC ?
Il ne s’agit pas de choisir l’un ou l’autre, et le croire fait perdre des affaires des deux côtés. Le modèle qui fonctionne repose sur un dossier réparti. La couche de gouvernance de l’IA détient les objets pour lesquels la GRC n’a pas été conçue : inventaire, métadonnées des modèles et des agents, correspondance des référentiels, preuves par système et évaluation initiale hiérarchisée selon les risques. La suite GRC reste le système d’enregistrement pour les risques d’entreprise, les politiques, les problèmes et l’audit.
Enregistrement | Emplacement | Transmis à la GRC sous forme de |
|---|---|---|
Système d’IA, modèle, agent, version | Couche de gouvernance de l’IA | Identifiant de référence sur le risque ou le problème associé |
Décision et approbation de la demande | Couche de gouvernance de l’IA | Tâche ou enregistrement d’approbation dans le flux de travail ITSM ou GRC |
Constat de revue de modèle | Couche de gouvernance de l’IA, rattaché à la version | Problème avec responsable et échéance |
Risque IA résiduel | Couche de gouvernance de l’IA, par système | Entrée dans la taxonomie des risques d’entreprise |
Politique et attestation | Suite GRC | Reste dans la GRC ; la couche IA y fait référence |
Plan d’audit et travaux sur le terrain | Suite GRC | Reste dans la GRC ; récupère à la demande les preuves par système |
La plateforme Enzai assure la transmission des flux de travail vers Jira et ServiceNow, et pousse les tâches et approbations issues des demandes vers les systèmes que vos équipes utilisent déjà. Le guide du processus de demande hiérarchisé présente la demande comme le point d’entrée unique pour le risque fournisseur, les achats, la sécurité et la protection des données : chaque fonction s’appuie ainsi sur un seul dossier au lieu de reposer les mêmes questions.
L’EU AI Act trace la même frontière. En vertu de l’article 17, paragraphe 4, un fournisseur qui est un établissement financier soumis à des exigences de gouvernance interne au titre du droit de l’Union en matière de services financiers est réputé satisfaire à l’obligation de système de gestion de la qualité au moyen de cette gouvernance existante, à l’exception de trois éléments : le système de gestion des risques de l’article 9, la surveillance après commercialisation de l’article 72 et le signalement des incidents graves de l’article 73. Le règlement part donc du principe que le cadre de gouvernance de l’entreprise reste en place et que les éléments propres à l’IA viennent s’y ajouter.
Et si l’outil en place est un ensemble de tableurs, et non une suite ?
Le cas des tableurs, fréquent dans les équipes qui visent l’ISO 42001, est différent. Un tableur est un inventaire tout à fait correct pour les vingt premiers systèmes. Il atteint ses limites dès que plusieurs personnes le modifient, que des preuves doivent être rattachées à une version et qu’un auditeur demande qui a modifié une notation de risque, et quand. Une organisation sans suite GRC ne devrait pas en acquérir une pour gouverner l’IA : la couche de gouvernance de l’IA représente l’achat le plus modeste, elle détient le dossier que l’auditeur demandera et elle se connecte à l’outil de ticketing déjà en place. Une organisation dotée d’une suite qui gouverne encore l’IA dans des tableurs a un dossier réparti sans la connexion, et c’est la construction de cette connexion qui constitue le projet.
Ce que cela implique sur le plan opérationnel
La démarche est la même, quelle que soit la décision.
Recensez le parc avant de décider. Lancez la détection et consignez dans un inventaire, pour chaque système, son niveau d’autonomie, son périmètre réglementaire et son responsable. Le nombre et la composition tranchent la question.
Formalisez la répartition. Décidez quels objets relèvent de la suite GRC (politiques, risques d’entreprise, problèmes, audit) et lesquels de la couche IA (systèmes, modèles, agents, versions, preuves par système), puis diffusez cette répartition pour qu’aucune équipe ne tienne deux copies.
Rattachez chaque système à chaque réglementation applicable et datez les évolutions : 2 décembre 2027 pour l’annexe III, 1er janvier 2027 pour les droits des consommateurs au Colorado, SR 26-2 pour les systèmes génératifs et agentiques d’une banque. C’est avec une bibliothèque de référentiels et une réutilisation multi-framework des preuves que l’on cesse de travailler sur tableur.
Définissez les transmissions. Une approbation devient une tâche dans le flux de travail existant, un constat devient un problème, un risque résiduel entre dans la taxonomie. Testez la transmission sur un système avant de la généraliser ; les comparatifs avec ServiceNow et Collibra précisent ce qui reste où.
Fixez les déclencheurs qui imposeront de revoir la décision : le premier agent doté d’un accès en écriture, le premier système relevant de l’annexe III, la première réunion de cadrage ISO 42001.
Enzai est conçu pour la partie du dossier propre à l’IA et pour les transmissions vers les outils GRC et ITSM que vous utilisez déjà. Pour découvrir comment la gouvernance automatisée de l’IA se connecte à une suite existante, échangez avec l’équipe Enzai.
Certifié ISO 27001 depuis 2023, audité chaque année par NQA
Traitement des données aligné sur le RGPD
Données clients hébergées sur AWS dans plusieurs régions
Utilisez votre propre modèle d’IA via une connexion privée
Identifiez l’IA utilisée par vos équipes, examinez-la avant sa mise en service, évaluez-la au regard des règles applicables et contrôlez ce que les agents peuvent faire. Conçu pour les organisations réglementées.