Le sujet de la gouvernance de l'IA vient d'atterrir sur votre bureau
L'AI Act européen (règlement (UE) 2024/1689) est entré en vigueur le 1er août 2024, avec une application progressive jusqu'en 2026 et 2027. La première vague d'obligations (interdiction des pratiques d'IA à risque inacceptable, transparence pour les modèles d'IA à usage général) s'applique déjà depuis février 2025. Les exigences relatives aux systèmes d'IA à haut risque entreront pleinement en vigueur à partir d'août 2026.
Si vous êtes RSSI, vous êtes désormais, de fait, le responsable de la gouvernance de l'IA dans la plupart des organisations. Non pas parce que la réglementation le dit, mais parce que :
- Vous gérez déjà des cadres de classification des risques.
- Vous menez déjà des évaluations techniques des systèmes avant leur déploiement.
- Vous disposez déjà d'une gestion des risques fournisseurs pour les prestataires SaaS.
- Vous produisez déjà des éléments de preuve pour les auditeurs.
Ce sont exactement les primitives opérationnelles que l'AI Act attend des organisations pour leurs systèmes d'IA. La gouvernance de l'IA est en grande partie une extension des pratiques existantes de sécurité et de gestion des risques, à condition de la mener de façon délibérée plutôt que par accident.
Le modèle par niveau de risque
L'AI Act classe les systèmes d'IA en quatre niveaux, avec des obligations très différentes :
- Risque inacceptable : interdit purement et simplement. Exemples : notation sociale par les autorités publiques, identification biométrique en temps réel dans les espaces publics (avec des exceptions limitées), reconnaissance des émotions sur le lieu de travail et à l'école, IA manipulant le comportement par des techniques subliminales.
- Haut risque : obligations importantes. Exemples : IA dans les infrastructures critiques, l'éducation et la formation professionnelle, l'emploi et la gestion des travailleurs, l'application de la loi, la migration et le contrôle aux frontières, l'administration de la justice, certaines catégorisations biométriques, certains dispositifs médicaux.
- Risque limité : obligations de transparence. Exemples : chatbots, systèmes de reconnaissance des émotions (là où ils sont autorisés), contenus générés par IA (les deepfakes doivent être signalés comme tels).
- Risque minimal : aucune obligation spécifique. La majorité des usages internes de l'IA à des fins de productivité relève de cette catégorie.
La première tâche pratique pour tout RSSI est de classifier les systèmes d'IA utilisés au sein de l'organisation. La plupart des RSSI découvrent avec surprise que leur organisation utilise bien plus d'IA que ne le pense la direction, y compris de l'IA embarquée dans des produits SaaS qui peut désormais entrer dans le périmètre réglementaire.
Les obligations liées au haut risque (le poste qui pèse sur le budget)
Pour les systèmes d'IA à haut risque, le règlement impose un ensemble de contrôles substantiel :
- Système de gestion des risques tout au long du cycle de vie de l'IA.
- Gouvernance des données : les données d'entraînement, de validation et de test doivent répondre à des critères de qualité.
- Documentation technique démontrant la conformité.
- Tenue de registres : journalisation automatique des événements.
- Transparence et information des déployeurs.
- Supervision humaine : mesures permettant une supervision humaine effective.
- Exactitude, robustesse et cybersécurité : niveau approprié à l'usage prévu.
- Évaluation de la conformité : contrôle interne ou évaluation par un tiers selon la catégorie d'IA.
- Marquage CE avant la mise sur le marché des produits.
- Système de surveillance post-commercialisation.
Beaucoup de ces obligations s'appuient sur des capacités déjà existantes (gestion des risques, documentation technique, journalisation, surveillance) étendues à l'IA. Les obligations réellement nouvelles sont l'évaluation de la conformité, le marquage CE (pour les fournisseurs d'IA) et les exigences de gouvernance des données spécifiques à l'IA.
ISO 42001 : la réponse en système de management
L'ISO/IEC 42001:2023 est la norme de système de management dédiée à l'IA. Publiée fin 2023, elle est l'équivalent, pour l'IA, de l'ISO 27001 : un cadre pour gouverner de façon systématique le développement et le déploiement de l'IA, avec une certification possible auprès d'organismes accrédités.
Pour la plupart des organisations de sécurité, la question stratégique est la suivante : faut-il étendre l'ISO 27001 pour couvrir l'IA, ou adopter l'ISO 42001 comme système de management distinct ?
La réponse dépend de l'intensité d'usage de l'IA dans l'organisation :
- L'IA est accessoire à l'activité : étendez le SMSI ISO 27001 existant pour couvrir l'IA comme une catégorie de système d'information. Ajoutez les risques spécifiques à l'IA au registre des risques, et les clauses spécifiques à l'IA aux politiques concernées. Aucun système de management distinct n'est nécessaire.
- L'IA est centrale au produit ou à l'activité : mettez en place un système de management ISO 42001 en parallèle de l'ISO 27001. Les deux normes partagent la plupart de leurs éléments fondamentaux mais ont des périmètres, des contrôles et des publics distincts. La certification confère de la crédibilité auprès des régulateurs européens et, de plus en plus, auprès des clients entreprises.
Le modèle de l'IA sur site
La décision la plus déterminante pour un RSSI en 2026 est de savoir où l'IA traite les données.
Les services d'IA en cloud public (OpenAI, Anthropic, Google, AWS Bedrock) sont extraordinairement performants mais posent trois problèmes :
- Sortie des données. Le contenu sensible (contrats, politiques, données clients, code source) quitte votre périmètre de contrôle. Cela recoupe le RGPD (article 28 sur la sous-traitance des données), DORA (risque lié aux tiers TIC), NIS2 (sécurité de la chaîne d'approvisionnement) et les obligations de transparence de l'AI Act.
- Dépendance à un fournisseur et risque de concentration. De nombreuses entités régulées suivent désormais formellement le risque de concentration sur les fournisseurs d'IA, les traitant comme des tiers TIC critiques.
- Auditabilité. Lorsqu'une API externe traite vos données, la piste d'audit est partielle et reste chez le fournisseur.
L'alternative, l'exploitation de LLM sur site ou en environnement isolé via des cadres comme Ollama ou vLLM, a mûri rapidement. Les modèles à poids ouverts (Llama 3.x, Qwen, DeepSeek) ont comblé une grande partie de l'écart de capacités avec les modèles fermés les plus avancés pour la plupart des usages en entreprise : génération de documents, analyse d'écarts, revue de contrats, synthèse. Pour le raisonnement général le plus exigeant, les modèles fermés restent en tête, mais l'écart se réduit chaque trimestre.
Une architecture pratique en 2026 pour de nombreux RSSI en environnement régulé :
- IA sur site pour tout traitement touchant des données sensibles : politiques, contrats, éléments de preuve de conformité, contenu du support client, documents internes.
- IA publique (avec accords fournisseurs et AIPD) pour les flux non sensibles : recherche, assistance au code avec filtres appropriés, marketing.
- Interdictions explicites de l'IA publique pour certaines catégories de données, clairement énumérées dans la politique et appliquées via des solutions DLP.
Ce modèle est de plus en plus requis pour les entités soumises à DORA et NIS2, et il est favorable au titre de l'AI Act car il apporte nativement l'auditabilité et les obligations de supervision humaine.
Comment opérationnaliser sans ralentir
Modes d'échec courants des RSSI face à la gouvernance de l'IA :
- Tout bloquer jusqu'à ce qu'une politique existe. Ralentit l'innovation, favorise le recours à l'IA fantôme (shadow AI).
- Tout approuver parce que les métiers le demandent. Le risque s'accumule silencieusement, avec une mauvaise surprise pour le régulateur.
- Construire un processus lourd pour des usages à faible risque. Gaspille des ressources sur le mauvais bout de la courbe de risque.
L'alternative pragmatique, proportionnée au niveau de risque :
- Pour les usages internes à risque minimal (aide à la rédaction, productivité de base) : publiez une politique d'usage acceptable, formez le personnel, ne mettez pas en place de contrôle bloquant.
- Pour les usages à risque limité orientés client (chatbots, génération de contenu) : exigez de la transparence, une journalisation de base et une fiche modèle (model card) documentée.
- Pour les usages à haut risque au sens du règlement : exigez un processus complet de gestion des risques, une documentation technique, une conception de la supervision humaine et une revue préalable au déploiement.
- Pour les usages à risque inacceptable : interdisez-les, journalisez-les et surveillez les tentatives clandestines.
Ce qu'un inspecteur ou un conseil d'administration va demander
Les questions que posent aussi bien les superviseurs que les comités d'audit en 2026 :
- Disposez-vous d'un inventaire des systèmes d'IA utilisés, classés par niveau de risque au sens de l'AI Act ?
- Disposez-vous d'une politique de gouvernance de l'IA, approuvée par le conseil d'administration au cours des 12 derniers mois ?
- Avez-vous évalué les fournisseurs d'IA tiers en tant que tiers TIC (DORA / NIS2) ?
- Où les systèmes d'IA à haut risque traitent-ils des données personnelles, et comment cela est-il conforme au RGPD ?
- Quelle est votre procédure de réponse aux incidents spécifiques à l'IA (hallucination causant un préjudice, dérive du modèle, injection de prompt) ?
- Comment garantissez-vous la supervision humaine lorsqu'elle est requise ?
- Quel est votre programme de formation pour le personnel utilisant l'IA ?
Si vous pouvez répondre avec assurance à ces sept questions, vous êtes en bonne position aussi bien pour les obligations relatives au haut risque d'août 2026 que pour l'orientation réglementaire plus large.
Pour conclure
L'AI Act européen n'est pas le fardeau de conformité existentiel qu'on présente parfois. Pour l'IA à risque minimal ou limité, qui représente la grande majorité des usages organisationnels de l'IA, les obligations sont modestes et largement couvertes par les pratiques de sécurité existantes. Pour l'IA à haut risque, les obligations sont réelles mais opérationnellement gérables lorsqu'elles sont traitées comme une extension d'un SMSI existant plutôt que comme un projet de conformité séparé.
Les RSSI qui peinent sur la gouvernance de l'IA en 2026 sont ceux qui n'ont jamais commencé. Ceux qui réussissent ont posé deux gestes simples dès 2024 : un inventaire de l'IA, et une politique d'usage acceptable écrite. Tout le reste en a découlé de façon incrémentale.