Cadre de Gouvernance IA : Comment en Construire un Efficace

L'IA atteint la plupart des organisations par plusieurs portes à la fois. Un assistant sous licence ici, une fonctionnalité IA activée dans un outil SaaS existant là-bas, et une poignée d'outils pour lesquels personne n'a ouvert de ticket.

Le cadre de gouvernance censé tout couvrir arrive généralement plus tard, si tant est qu'il arrive. Dans The Netwrix 2026 Data and Identity Security Report, 41 % des organisations utilisent déjà une IA agentique en production pour le compte des humains, tandis que 11 % ont opérationnalisé la gouvernance de l'IA via une revue continue, proactive et obligatoire.

La confiance révèle cet écart, et ce n’est pas joli. Seuls 18 % des organisations dont le chiffre d’affaires se situe entre 100 millions et 1 milliard de dollars se sentent très confiantes de réussir un audit indépendant de la gouvernance et des contrôles de l’IA, selon Grant Thornton.

Pendant ce temps, 42 % des responsables IT du marché intermédiaire interrogés dans The Netrio’s Mid-Market AI Readiness Report ont signalé un incident ou une exposition confirmée liée à la sécurité de l’IA au cours de l’année écoulée. Le cadre qui réduit cette distance relie chaque règle écrite à un contrôle que quelqu’un peut tester et à un enregistrement que quelqu’un peut consulter.

Qu'est-ce qu'un cadre de gouvernance de l'IA ?

Un cadre de gouvernance de l'IA est un ensemble structuré de politiques, rôles, processus et contrôles qui régissent la manière dont une organisation conçoit, déploie et utilise les systèmes d'IA. Cela inclut les assistants sous licence, les outils publics accessibles au personnel via un navigateur, les fonctionnalités d'IA intégrées aux applications SaaS et les modèles internes.

ISO/IEC 42001 fait référence à un système de gestion de l'IA, qui met l'accent sur la structure opérationnelle. Un cadre de gestion des risques liés à l'IA se concentre sur l'identification et le traitement des risques.

Ces trois documents sont souvent confondus, et la distinction détermine qui est responsable. Un framework définit la responsabilité et le processus à travers les étapes du cycle de vie. Une policy établit la règle, et une assessment teste l’efficacité de l’un ou l’autre à une date donnée.

Pourquoi un cadre de gouvernance de l'IA est important

Le cadre mérite sa place en transformant des décisions dispersées en quelque chose qu'un conseil, un régulateur ou un auditeur peut inspecter :

• Approbation basée sur des preuves : La sécurité peut valider un déploiement d'IA avec une liste nominative des accès de chaque outil et sous quelles identités, au lieu d'une simple assurance de son créateur.
• Une piste d’audit défendable : Évaluations des risques, rapports d’accès, historique de configuration et procès-verbaux du comité sont tous regroupés au même endroit lorsqu’on les demande.
• Rayon d’explosion contenu : La portée et les limites d’accès déterminent la quantité de données qu’une session d’IA compromise ou mal configurée peut atteindre.
• Approbations plus rapides, pas plus lentes : Un processus d'entrée permanent et des niveaux de risque permettent aux cas à faible risque de passer rapidement et dirigent le reste vers une véritable révision.
• Un seul programme au lieu de deux : Le risque IA se retrouve dans les registres, bibliothèques de contrôle et portes de revue déjà en place, donc rien n’est maintenu deux fois.

Chacun d'eux dépend de la même chose fondamentale : savoir ce que l'IA peut actuellement accomplir dans un environnement en direct.

Pourquoi les programmes de gouvernance existants prennent du retard face à l'IA

Trois forces frappent l’équipe de sécurité à peu près en même temps. Chacune creuse l’écart entre ce que la politique affirme et ce que l’environnement peut prouver.

L'IA arrive plus vite qu'elle n'est approuvée

L'utilisation devance la politique, et les chiffres ne sont pas proches. Le 2026 AI Pulse Poll d'ISACA a révélé que 90 % des professionnels de la confiance numérique estiment que les employés utilisent l'IA dans leur organisation, tandis que seulement 38 % de ces organisations disposent d'une politique formelle et complète sur l'IA.

La séquence explique la majeure partie du déficit. Le rapport d’enquête RSM AI a révélé qu’environ un tiers des organisations de taille moyenne passent aux pilotes ou à la production avant que les contrôles de gouvernance ne soient en place, 16 % n’atteignant la gouvernance qu’après un problème. Ce qui s’accumule est une pile d’approbations ponctuelles et d’exceptions non documentées. Cela tient tant que quelqu’un ne demande pas de preuves.

Les délais de conformité ont commencé à passer

Les normes sont arrivées en premier et ont fixé l'attente en matière de structure. ISO a publié ISO/IEC 42001 le 18 décembre 2023 en tant que norme internationale pour les systèmes de gestion de l'IA, et la plupart des équipes l'associent au NIST AI RMF en tant que complément volontaire.

Ensuite, le calendrier de l’UE a changé, et pas dans la direction prévue par la plupart des équipes. Le Digital Omnibus on AI, adopté en tant que Règlement (UE) 2026/1744 le 8 juillet 2026, a repoussé la plupart des obligations à haut risque au 2 décembre 2027 pour les systèmes autonomes de l’annexe III et au 2 août 2028 pour les systèmes intégrés dans les produits de l’annexe I.

Deux dates n'ont pas changé et sont désormais passées. Les obligations de transparence de l'article 50 et les pouvoirs d'exécution de la Commission sur les modèles d'IA à usage général s'appliquent depuis le 2 août 2026, selon le AI Act enforcement timeline. Les systèmes génératifs déjà sur le marché avant cette date ont jusqu'au 2 décembre 2026 pour respecter l'obligation de marquage de l'article 50(2), qui est la prochaine échéance réelle pour la plupart des équipes.

L'IA amplifie la dette de permissions que vous avez déjà

Un outil d'IA utilise les accès déjà existants. Les directives de Microsoft sur le partage excessif sont claires à ce sujet : Copilot hérite des permissions et protections existantes de Microsoft 365, donc les sites avec des permissions excessives, les accès hérités et les étiquettes de sensibilité manquantes doivent être corrigés avant le déploiement.

Des années de partage ad hoc que personne ne remarquait deviennent consultables dès qu’une invite peut y accéder. Corriger cette couche en premier est aussi là où le bénéfice apparaît, car les organisations avec une identité unifiée et une gouvernance des données ont près de cinq fois plus de chances de déclarer une préparation complète à l’IA.

Les six piliers d’un cadre de gouvernance de l’IA opérationnel

La plupart des cadres publiés enterrent la visibilité de l'accès aux données dans des domaines plus larges tels que la confidentialité ou la gouvernance des données. Cela constitue un pilier à part entière car la certification et l'audit en dépendent, et les procédures d'audit IA d'ISACA demandent spécifiquement les journaux d'accès, les processus de gestion des changements et les politiques basées sur les rôles.

1. Portée et inventaire

La portée définit à quoi s'appliquent tous les autres contrôles. Elle nomme les systèmes d'IA et les cas d'utilisation en jeu, ainsi que les objectifs commerciaux, l'appétit pour le risque et les obligations réglementaires associés à chacun.

La clause 4.3 de l’ISO/IEC 42001 exige que le périmètre soit disponible en tant qu’information documentée. Une déclaration de périmètre sans inventaire de soutien échoue au premier échantillon.

2. Parcours de propriété et d'approbation

La responsabilité incombe à des personnes nommées. Un sponsor exécutif, un responsable de la gouvernance, la sécurité, la protection des données et les responsables des unités commerciales détiennent chacun un droit de décision spécifique.

Le contrôle A.3.2 de la norme ISO/IEC 42001 l'exprime clairement, exigeant que « les rôles et responsabilités pour AI soient définis et attribués selon les besoins de l'organisation. » Le test pratique est de savoir si quelqu'un peut dire qui approuve un nouveau cas d'utilisation et qui peut le désactiver.

3. Politique associée aux contrôles

La politique couvre l’utilisation acceptable, les types de données interdits, les exigences d’intervention humaine, les attentes en matière de transparence et la gestion des incidents. Une politique fonctionne lorsque chaque ligne nomme le contrôle qui l’applique.

Ces contrôles sont des restrictions d'accès, data classification, l'une des solutions DLP déjà déployées, l'accès conditionnel et la journalisation. Une règle sans contrôle derrière est une phrase, pas une protection.

4. Visibilité des données et de l’identité

Ce pilier répond à deux questions concernant toute interaction avec l'IA. Quelles données l'outil pourrait-il atteindre, et quelle identité humaine, machine ou non humaine l'a invoqué ?

C'est aussi le pilier que la plupart des programmes ne peuvent pas prouver. Le rapport quantifie pourquoi, constatant que 74 % des organisations ne disposent pas d'une vue unique et unifiée des données sensibles et des identités pouvant y accéder. L'accès accordé et l'accès effectif sont des listes différentes, et elles divergent rapidement dans tout environnement avec un historique.

5. Gestion du cycle de vie

Le cycle de vie s’étend des données au développement du modèle, au déploiement, à la revue et à la mise hors service, avec une porte de décision à chaque transition. La mise hors service est la porte que presque personne n’atteint, et c’est celle dont les auditeurs s’inquiètent.

Gestion du cycle de vie d'Identity gère déjà les entrants, les mouvements et les départs pour les personnes, et les agents IA appartiennent à la même discipline. La sous-catégorie MANAGE 2.4 du NIST AI RMF exige des mécanismes et des responsabilités assignées pour supplanter, désengager ou désactiver les systèmes IA fonctionnant de manière incohérente avec l'utilisation prévue.

6. Mesure et amélioration

La mesure donne au comité de gouvernance des éléments sur lesquels décider. Les mesures qui méritent leur place sont le nombre d’incidents d’IA, les exceptions de politique, la couverture de l’évaluation des risques et l’efficacité du contrôle.

Les clauses 9 et 10 de l’ISO/IEC 42001 couvrent la surveillance, l’audit interne, la revue de direction et l’action corrective. Tout ce qui ne modifie pas une décision ne mérite pas d’être suivi.

Comment construire le framework en cinq étapes

Les piliers décrivent ce que contient le cadre finalisé. Sa construction suit un ordre différent, en commençant par l'IA déjà présente dans l'environnement plutôt que par la politique que quelqu'un souhaite rédiger. Suivez ces cinq étapes dans l'ordre.

1. Inventorier l'IA déjà en fonctionnement

Puisez dans trois sources, car aucun système unique ne sait tout. Les applications sous licence et les service principals proviennent de votre identity provider, les fonctionnalités d'IA intégrées proviennent des notes de version du fournisseur et des centres d'administration, et les outils non autorisés proviennent des journaux de sortie.

Attendez-vous à ce que la liste sanctionnée sous-estime fortement. Une enquête PagerDuty de 2026 a révélé que 66 % des professionnels de bureau ont utilisé l’IA au travail malgré la croyance que leurs politiques ne le permettaient pas, et seulement 20 % des organisations surveillent ou régulent entièrement la shadow AI.

Ensuite, classez ce que vous avez trouvé en niveaux de risque. La productivité interne, les services destinés aux clients et l’utilisation de données réglementées nécessitent chacun différents niveaux de contrôle, et le niveau détermine la quantité de travail restant qu’un système reçoit.

2. Assignez les propriétaires et créez le chemin d'approbation

Attribuez à chaque système d’IA un propriétaire nommé dans l’informatique, la sécurité, la protection des données ou la ligne métier qui l’utilise. Les équipes, comités et listes de diffusion ne comptent pas.

Ensuite, cartographiez le chemin de la demande, de l’évaluation des risques à la conception du contrôle, à la validation et à la date de révision. Notez qui accorde les exceptions et qui peut suspendre un système lorsque son risque change.

Restez honnête avec une access certification récurrente, qui confirme que les administrateurs, comptes de service, applications et agents IA ne détiennent que ce dont leur travail actuel a besoin. Active Directory service accounts sont généralement là où se cachent les droits obsolètes.

3. Associez chaque règle à un contrôle que vous pouvez tester

Prenez la politique ligne par ligne et écrivez le contrôle qui l’applique à côté. Si vous ne pouvez pas en nommer un, la règle n’est pas encore applicable et doit figurer sur la liste des lacunes.

Énoncez clairement les limites sans ambiguïté. Aucun accès d’IA générative aux informations personnelles identifiables (PII) non classifiées, avec des exceptions nommées pour les données juridiques et des ressources humaines.

L'accès privilégié doit être géré selon ses propres conditions. Les administrateurs configurant des services d'IA ont besoin d'une élévation, donc délivrez des identifiants just-in-time (JIT) à courte durée pour chaque session approuvée et appliquez zero standing privilege aux comptes qui intègrent ces services.

4. Intégrez l’IA dans les processus que vous utilisez déjà

Ajoutez des catégories de risque IA aux registres de risques existants, aux bibliothèques de contrôles et aux suivis de problèmes, puis faites passer les cas d'utilisation IA par les portes d'entrée, de gestion des changements et de revue de sécurité déjà en place. Les recommandations ISACA recommandent exactement cela, la gestion des risques IA complétant les programmes établis de cybersécurité, de risque et de confidentialité.

Traitez l'IA tierce et intégrée de la même manière, en enregistrant le fournisseur, les flux de données, la méthode d'intégration, les conditions de conservation, le propriétaire et le plan de sortie. Lorsque les revues d'accès nécessitent des outils, comparez les IGA tools aux systèmes déjà concernés.

5. Définissez le rythme, puis prouvez que cela fonctionne

Fixez la cadence des revues avant la première échéance et intégrez ces mesures dans les cycles existants d' IT risk assessment. Vérifiez quels outils de conformité déjà déployés peuvent générer des rapports avant d'acheter quoi que ce soit de nouveau.

Testez ensuite le cadre comme le ferait un auditeur. Choisissez un système d’IA, récupérez son propriétaire, son niveau de risque, son ensemble de contrôles, son rapport d’accès et sa dernière date de révision, puis voyez combien vous pouvez produire en une heure.

Aligner le cadre avec NIST AI RMF et ISO/IEC 42001

Un cadre construit de cette manière est finalement écrit dans votre propre vocabulaire. Les auditeurs, clients et régulateurs ne le demanderont pas ainsi. Ils demandent à quel standard vous vous alignez, et le mapping vous permet de répondre sans rien reconstruire.

La clause 5 de la norme ISO/IEC 42001 couvre la propriété et la politique d’IA, les clauses 6 et 8 couvrent l’évaluation des risques et des impacts, et les clauses 9 et 10 couvrent la mesure et l’amélioration. Quatre des six piliers mentionnés ci-dessus ont été renommés.

Le choix du premier à cartographier n’est pas un coup de hasard, et la raison se perd car les deux sont nommés ensemble. ISO/IEC 42001 est auditable et certifiable. Le NIST AI RMF ne l’est pas. Cette différence détermine ce que vous pouvez revendiquer et où vos preuves doivent être déposées.

Ce que l'AI RMF peut et ne peut pas faire pour un programme centré sur les données

Le noyau AI RMF organise la gestion des risques à travers Govern, Map, Measure et Manage, et ses sous-catégories sont des déclarations de résultats, pas des exigences. NIST ne publie aucun schéma d’évaluation de conformité, critères d’accréditation ou exigences pour les organismes de certification. Vous pouvez dire que votre programme est aligné avec AI RMF ou que les contrôles correspondent à ses sous-catégories. Vous ne pouvez pas dire « certifié NIST AI RMF ».AI RMF Core organizes risk management across Govern, Map, Measure, and Manage, and its subcategories are outcome statements, not requirements. NIST publishes no conformity assessment schemes, accreditation criteria, or certification body requirements. You can say your program aligns with the AI RMF or that controls map to its subcategories. You can't say "NIST AI RMF certified."

Il y a une deuxième limitation à connaître avant de cartographier quoi que ce soit. Parmi les 72 sous-catégories, aucune ne mentionne access control, identity, authentication, permissions ou data provenance. Ainsi, savoir quelles identities peuvent accéder à quelles données, ce que déclenche réellement un pack de preuves, se cartographie au AI RMF par interprétation plutôt que par accroche textuelle.

Trois familles de sous-catégories portent ce poids en pratique. L'ensemble tiers est le plus fort, avec GOVERN 6.1 couvrant les politiques pour le risque IA tiers, MANAGE 3.1 exigeant que « les risques et bénéfices de l'IA issus de ressources tierces soient régulièrement surveillés », et MAP 4.2 couvrant les contrôles internes des risques pour les composants tiers. MEASURE 2.7 et 2.10 sont les endroits où les preuves d'évaluation de la sécurité et de la confidentialité sont déposées. Pour la désaffectation, associez MANAGE 2.4 à GOVERN 1.7.

Pourquoi le crosswalk NIST doit être traduit avant un audit

NIST publie un crosswalk des sous-catégories AI RMF vers ISO/IEC 42001, ce qui fait gagner du travail réel. Il a aussi une propriété qui piège les équipes. Chacune de ses 202 références de contrôle pointe vers l'annexe B, et il ne cite aucun contrôle de l'annexe A.

Cette distinction détermine si votre cartographie résiste à un audit. L'annexe A est normative, ses contrôles indiquent « shall », et la Déclaration d'applicabilité en est dérivée. L'annexe B est un guide de mise en œuvre ; ses contrôles indiquent « should », et il est clairement indiqué que les organisations n'ont pas à justifier l'inclusion ou l'exclusion de ce guide dans la Déclaration d'applicabilité. Une ligne de correspondance qui envoie MANAGE 2.4 à « B.9.4 Intended use of the AI system » pointe vers un conseil, pas vers un contrôle auditable.

La traduction est mécanique car 42001 numérote les deux annexes en parallèle, donc B.9.4 est la directive pour A.9.4. La sauter est l'erreur courante. Une autre chose à savoir : le crosswalk cible ISO/IEC FDIS 42001, le projet final, plutôt que la norme publiée.

La clause que la plupart des programmes oublient

L'évaluation des risques et l'évaluation des impacts sont des obligations distinctes dans la norme 42001, et les confondre est la lacune la plus courante dans une Déclaration d'Applicabilité initiale. La clause 6.1.2 évalue le risque pour vos propres objectifs d'IA, avec probabilité, niveaux de risque et critères de risque. La clause 6.1.4 évalue l'impact externe sur les individus, groupes d'individus et sociétés, sans utiliser ce mécanisme de probabilité.

La relation est unidirectionnelle. La clause 6.1.4 exige que les résultats de l’évaluation d’impact soient pris en compte dans l’évaluation des risques, tandis que la note 6.1.2 indique qu’une organisation peut utiliser une évaluation d’impact pour évaluer les conséquences. Chacune comporte sa propre obligation d’information documentée ; l’annexe A.5 contrôle l’aspect impact, et la clause 8.4 exige de réaliser les deux à des intervalles planifiés ou lors de changements significatifs et de conserver les résultats. ISO/IEC 42005 fournit la méthode, bien qu’il s’agisse d’une directive et qu’elle ne puisse pas être certifiée.

La visibilité des données et de l’identité dépend des contrôles plutôt que des clauses. Parmi les 38 Annex A controls répartis en neuf catégories, A.7.5 Data provenance est celui qu’un programme centré sur les données souhaite, car il nécessite un processus documenté pour enregistrer la provenance des données IA.

Ce que la certification demande réellement

La certification se déroule en deux étapes selon ISO/IEC 17021-1, avec la compétence de l'organisme de certification définie par ISO/IEC 42006, publiée en juillet 2025. La phase 2 est celle pour laquelle on planifie, car elle évalue la mise en œuvre et l'efficacité sur site à l'aide d'artefacts tels que les évaluations des risques complétées et les journaux d'événements du système IA.

La phase 1 est celle qui surprend les gens. Elle évalue la préparation pour la phase 2, notamment si les audits internes et la revue de direction ont réellement été effectués et non simplement planifiés. Un cycle complet d'audit interne doit être derrière vous, ce qui repousse généralement la date réaliste de certification d'un trimestre par rapport à ce que les équipes supposent.

Liste de contrôle du cadre de gouvernance IA

Six questions mettent en lumière des lacunes qui deviennent des constats d'audit. Répondez à chacune en fonction de l'environnement que vous avez, pas de celui de la politique :

• Le programme nomme-t-il des propriétaires responsables et définit-il des cycles de révision avec des dates réelles ?
• Avez-vous identifié tous les systèmes d’IA utilisés et cartographié chacun par rapport aux données et identités qu’ils atteignent ?
• Vos politiques d’IA ciblent-elles des contrôles techniques spécifiques, couvrant les restrictions d’accès, DLP, l’accès conditionnel et la journalisation ?
• Le cadre est-il aligné sur NIST AI RMF, ISO/IEC 42001, ou les deux, afin que la couverture puisse être évaluée ?
• Pouvez-vous produire des évaluations des risques, des journaux de configuration, des rapports d'accès et des procès-verbaux de comité sur demande ?
• Avez-vous un plan pour mettre à jour le cadre au fur et à mesure que les outils, les réglementations et les risques évoluent ?

Tout ce à quoi vous ne pouvez pas répondre est une lacune qui nécessite un propriétaire, un plan de remédiation et une date de validation.

Comment Netwrix comble le fossé des preuves de gouvernance de l'IA

Le quatrième pilier est là où l'intention de gouvernance rencontre la réalité environnementale, et il s'appuie sur des données que les outils natifs conservent sous forme succincte ou dispersent à travers les portails. Netwrix fournit cette couche via des capacités de AI governance, et il est important d'être précis sur ce que fait chaque produit.

Rapporter ce que l'IA peut atteindre

Netwrix 1Secure répond à la question avant le déploiement tant que la décision est encore réversible, en rapportant les données sensibles auxquelles Copilot peut accéder avant que quelqu’un ne l’active. Après la mise en service, rapporte l’activité de Copilot, listant les utilisateurs, les horodatages et les ressources référencées, et signalant les réponses qui exposent des données sensibles. Il suit également les rôles, les permissions et les modifications dans Microsoft Entra ID.

Netwrix Access Analyzer gère la partie la plus difficile de la question. Il résout l’appartenance à des groupes imbriqués pour calculer l’accès effectif pour les utilisateurs d’Active Directory et Microsoft Entra ID, les sites SharePoint et les systèmes de fichiers, mettant en évidence les accès ouverts et les héritages cassés. Cela transforme le quatrième pilier d’une simple affirmation en un rapport par identité que vous pouvez transmettre.

Conservation des preuves au-delà de la fenêtre des journaux

Les frameworks sont audités des mois après la prise de décision, ce qui en fait un problème de rétention avant d’être un problème de reporting. Netwrix Auditor enregistre qui a changé quoi et quand avec des valeurs avant-après, et génère des rapports d’état à un instant donné à partir de clichés quotidiens de configuration.

Deux clients réglementés montrent la différence au moment de l'examen. First National Bank and Trust of Beloit maintient une conformité OCC continue pour 300 utilisateurs dans 17 sites, remplaçant une semaine complète de travail manuel avec des listes de contrôle par une heure de préparation.

Credissimo prouve la conformité au GDPR et à la norme ISO/IEC 27001 dans ses opérations de financement à la consommation, générant des rapports d’audit 85 % plus rapidement, en un jour au lieu d’une semaine.

Netwrix couvre la couche d'accès aux données, d'identité et de rapports d'audit dont le pilier quatre a besoin et que les plateformes plus larges de gouvernance de l'IA supposent que vous possédez déjà. Ces plateformes gèrent le flux de travail global ; le fournisseur d'IA conserve le contrôle du comportement du modèle ; et le cadre, le comité et les décisions restent entre vos mains.

Testez d'abord le framework sur un système

La direction fait confiance à un cadre lorsque les données actuelles d’accès, de configuration et d’activité éclairent ses décisions. Cela déconseille de lancer tout le programme en une seule fois. Choisissez un système à fort impact, puis mesurez l’exposition aux données sensibles, l’étendue des permissions, le volume des exceptions et l’exhaustivité du dossier de preuves.

Un assistant sous licence fonctionnant sur votre tenant existant constitue le meilleur prototype, car son modèle d'autorisations repose sur des décisions d'accès déjà en place et les outils de visibilité existent aujourd'hui. Appliquez les six piliers à ce système, voyez ce que les preuves démontrent réellement, puis étendez ce modèle au reste de l'inventaire IA.

Demandez une démo pour voir ce que vos outils d’IA peuvent atteindre, cartographier les identités derrière eux et conserver l’historique des modifications que votre prochain audit demandera.