L’adoption accélérée de l’intelligence artificielle dans les systèmes d’information d’entreprise crée un angle mort de gouvernance que les DSI et RSSI ne peuvent plus ignorer. Contrairement aux logiciels traditionnels, les systèmes IA introduisent des comportements non déterministes, une opacité décisionnelle et des vecteurs de risque inédits : du biais algorithmique aux attaques adversariales. Structurer une gouvernance IA formelle n’est plus une option ; c’est une obligation réglementaire (AI Act, NIS2) et un prérequis pour maîtriser le risque opérationnel.
Pourquoi la gouvernance IA est distincte de la gouvernance IT classique
Les référentiels existants (COBIT, ISO 27001, ITIL) ne couvrent pas les spécificités des systèmes IA. Trois dimensions les distinguent structurellement.
L’opacité des décisions. Un système IA peut produire une décision correcte en moyenne mais erronée dans un contexte particulier, sans qu’aucun log technique ne permette d’en expliquer la cause. L’explicabilité (XAI) n’est pas un bonus fonctionnel ; c’est une exigence réglementaire pour les systèmes à risque élevé au sens de l’AI Act.
La dérive temporelle des modèles (model drift). Un modèle entraîné sur des données de 2023 peut se dégrader silencieusement en 2026 si la distribution des données en production évolue. Contrairement à un bug logiciel, cette dégradation est graduelle et difficile à détecter sans monitoring statistique dédié. Les métriques de performance métier (précision décisionnelle, taux de rejet, distribution des scores) doivent être instrumentées et alertées au même titre que la disponibilité d’un service critique.
La dépendance à la chaîne d’approvisionnement IA. L’utilisation de modèles tiers (API OpenAI, Azure OpenAI, Mistral, AWS Bedrock) transfère une partie du risque à des fournisseurs externes. Les conditions d’utilisation, les politiques de rétention des données et les niveaux de service de ces fournisseurs doivent être intégrés dans la gestion des risques tiers (third-party risk management).
L’ANSSI rappelle dans ses recommandations de sécurité pour les systèmes d’IA (2024) que la surface d’attaque d’un système IA couvre à la fois le modèle lui-même, ses données d’entraînement, son infrastructure d’inférence et ses interfaces applicatives.
Cadre réglementaire : AI Act, NIS2, RGPD et DORA
La gouvernance IA en Europe s’inscrit dans quatre textes qui se superposent sans se remplacer.
| Texte | Portée IA | Obligation principale | Échéance |
|---|---|---|---|
| AI Act (UE 2024/1689) | Systèmes IA mis sur le marché UE | Classification par risque, documentation technique, registre EU | Août 2026 (Annexe III risque élevé) |
| NIS2 (UE 2022/2555) | Entités essentielles et importantes | Gestion des risques SI incluant les composants IA | Délai transposition oct. 2024 (France en retard) |
| RGPD (UE 2016/679) | Traitements de données personnelles | Analyse d’impact (AIPD) pour décisions automatisées | En vigueur |
| DORA (UE 2022/2554) | Secteur financier | Résilience opérationnelle numérique, gestion des fournisseurs IA | Janvier 2025 |
L’AI Act classifie les systèmes IA en quatre niveaux de risque. Pour les DSI, l’enjeu pratique est d’identifier les cas d’usage internes qui tombent dans la catégorie risque élevé (Annexe III) : systèmes RH automatisés (recrutement, évaluation de performance), scoring crédit, systèmes de sécurité d’infrastructure critique, gestion des identités biométriques. Ces systèmes exigent une documentation technique complète, un registre de conformité, des tests avant mise en service et une supervision humaine formalisée. Les obligations de l’Annexe III s’appliquent à partir d’août 2026 (24 mois après publication du règlement). Les systèmes relevant de l’Annexe I section B (dispositifs médicaux, aéronefs) disposent d’un délai supplémentaire jusqu’en août 2027.
La CNIL a publié en 2024 des recommandations spécifiques sur l’articulation RGPD et IA, rappelant que toute décision automatisée affectant significativement une personne physique déclenche les obligations de l’article 22 du RGPD, indépendamment de l’AI Act.
Structure d’un comité IA opérationnel
Un comité IA efficace ne se réduit pas à un comité de pilotage stratégique. Il doit avoir une capacité décisionnelle opérationnelle sur les cas d’usage, les achats de solutions IA et les dérogations à la politique IA.
Composition minimale recommandée :
| Rôle | Responsabilité IA | Fréquence d’implication |
|---|---|---|
| DSI (sponsor) | Arbitrages budgétaires, alignement stratégie SI | Comités trimestriels |
| RSSI | Validation sécurité, gestion des risques IA, audit | Validation obligatoire avant tout déploiement |
| DPO | Conformité RGPD/AI Act, AIPD, droits des personnes | Validation si données personnelles impliquées |
| Architecte SI | Intégration technique, choix d’infrastructure | Phases de conception et déploiement |
| Représentant métier | Expression du besoin, validation fonctionnelle | Phase de cadrage et recette |
| Juriste/Compliance | Contrats fournisseurs IA, responsabilité civile | Achat de solutions, incidents |
Le comité doit formaliser un processus d’homologation IA calqué sur le modèle d’homologation ANSSI (RGS) : dossier de sécurité, analyse de risques, tests, décision formelle, revue périodique. Chaque système IA en production doit figurer dans un registre interne avec son niveau de risque AI Act, son responsable technique et sa date de dernière évaluation.
Frameworks de gestion des risques IA : NIST AI RMF et ISO 42001
Deux référentiels structurent aujourd’hui la gestion des risques IA en entreprise.
NIST AI RMF 1.0 (janvier 2023) est organisé autour de quatre fonctions : GOVERN, MAP, MEASURE, MANAGE. Il est volontaire, technologiquement neutre et compatible avec les normes ISO 27001 et NIST CSF existantes. Le DSI ou RSSI qui utilise déjà le NIST CSF trouvera une logique de décomposition similaire.
ISO/IEC 42001:2023 est le premier standard international de système de management pour l’IA. Il est certifiable (comme ISO 27001) et fournit un cadre d’audit externe pour les organisations souhaitant démontrer leur maturité IA à des tiers (clients, régulateurs, partenaires). Son annexe A liste 38 contrôles couvrant la politique IA, les objectifs, les ressources, les opérations et l’amélioration continue.
L’ENISA recommande dans son cadre multicouche pour la cybersécurité de l’IA (2023) d’aborder la sécurité des systèmes IA sur cinq couches : données, modèle, application, infrastructure et organisation. Chaque couche a ses propres vecteurs d’attaque documentés dans MITRE ATLAS, le pendant de MITRE ATT&CK pour les systèmes IA.
Risques spécifiques IA : ce que les référentiels classiques ne couvrent pas
La gestion des risques IA doit intégrer des catégories absentes des politiques de sécurité traditionnelles.
Prompt injection et manipulation de modèle. Les systèmes basés sur des LLM (Large Language Models) sont vulnérables aux injections de prompts malveillants, permettant à un attaquant de contourner les guardrails ou d’exfiltrer des données. MITRE ATLAS documente ces techniques sous l’identifiant AML.T0051 (LLM Prompt Injection).
Data poisoning. Un attaquant qui accède aux pipelines d’entraînement ou de fine-tuning peut corrompre un modèle de façon persistante et difficile à détecter (AML.T0020 dans MITRE ATLAS). Ce risque est particulièrement critique pour les modèles ré-entraînés sur des données internes.
Hallucination et fiabilité décisionnelle. Un modèle peut produire des sorties plausibles mais factuellement fausses. Dans un contexte de décision automatisée (scoring risque, génération de rapports financiers, diagnostic), ce risque doit être quantifié et des garde-fous humains formalisés.
Risque fournisseur IA. L’utilisation d’API IA tierces introduit des risques de confidentialité (les données envoyées au modèle peuvent être utilisées pour l’entraînement selon les conditions d’utilisation), de disponibilité (dépendance à un SLA tiers) et de conformité (transfert de données hors UE). Une clause contractuelle DPA (Data Processing Agreement) est obligatoire si des données personnelles transitent.
Pour aller plus loin sur les obligations spécifiques aux DSI, l’article AI Act : obligations pour les entreprises détaille les exigences de documentation et de registre par catégorie de risque.
Intégration dans les processus SI existants
La gouvernance IA ne doit pas être un silo. Elle s’intègre dans les processus de gestion du changement, de gestion des actifs et de gestion des incidents existants.
CMDB et gestion des actifs. Chaque système IA (modèle, pipeline, API tierce) doit être un CI (Configuration Item) dans la CMDB avec ses attributs spécifiques : version du modèle, date d’entraînement, fournisseur, niveau de risque AI Act, données d’entraînement utilisées. Cela conditionne la capacité à répondre aux audits réglementaires. L’article 12 de l’AI Act impose en outre une journalisation automatique des opérations des systèmes à risque élevé sur toute leur durée de vie, conservée et accessible aux autorités de surveillance nationales sur demande.
Change management. Un changement de version de modèle (migration GPT-4 vers GPT-4o, mise à jour d’un modèle interne) doit suivre un processus de change avec évaluation d’impact, tests de régression comportementaux et validation RSSI/DPO si applicable. La dérive comportementale entre deux versions d’un même modèle peut être significative sans changement de version majeure chez le fournisseur.
Gestion des incidents. Les incidents liés à l’IA (hallucination ayant causé une décision erronée, fuite de données via un prompt, comportement discriminatoire) doivent être tracés dans le processus ITIL existant, avec une catégorie dédiée pour permettre le reporting réglementaire. NIS2 impose une alerte précoce sous 24 heures et une notification complète sous 72 heures pour les incidents significatifs des entités essentielles.
Les interactions entre gouvernance IA, souveraineté des données et choix d’infrastructure cloud sont développées dans les sections cloud et cybersécurité entreprise de cet observatoire.
Feuille de route pratique pour les DSI
La mise en place d’une gouvernance IA formelle peut être structurée en trois phases sur 12 mois.
Phase 1 (0-3 mois) : inventaire et classification. Recenser tous les systèmes IA en production et en projet. Appliquer la grille de classification AI Act. Identifier les cas d’usage à risque élevé au sens de l’Annexe III. Constituer le comité IA avec les rôles formalisés.
Phase 2 (3-6 mois) : politique et processus. Rédiger la politique IA d’entreprise (usage acceptable, données autorisées, fournisseurs homologués). Définir le processus d’homologation IA. Intégrer les systèmes IA dans la CMDB avec leurs attributs réglementaires. Former les équipes aux risques spécifiques IA en intégrant les scénarios MITRE ATLAS dans les exercices de threat modeling.
Phase 3 (6-12 mois) : conformité et maturité. Réaliser les AIPD manquantes avec le DPO. Mettre en place le registre de conformité AI Act pour les systèmes à risque élevé. Déployer le monitoring statistique de dérive sur les systèmes critiques. Évaluer l’opportunité d’une certification ISO 42001. Intégrer les métriques IA dans les tableaux de bord de gouvernance SI.
La gouvernance IA n’est pas un projet à périmètre fixe mais un processus continu. Le rythme d’évolution des modèles, des réglementations et des vecteurs d’attaque impose une revue au minimum annuelle de l’ensemble du dispositif. Les DSI qui traitent ce sujet dès maintenant se donnent le temps de construire une posture robuste avant que les contrôles réglementaires ne se renforcent.