Les centres de données IA deviennent le nouveau problème de la shadow IA
La gouvernance IA descend dans la pile.
Depuis deux ans, la plupart des programmes de gestion des risques IA en entreprise se concentrent sur la couche visible : qui utilise ChatGPT, quelles équipes achètent des copilotes, quelles données les employés collent dans les prompts, et quels outils SaaS ont désormais des fonctionnalités IA activées par défaut.
Ce travail reste important. Mais il ne suffit plus.
Le NIST a mis à jour cette semaine sa page sur le programme IA avec un accent renforcé sur la sécurisation des centres de données IA, incluant un atelier en juillet sur l’architecture, la posture de sécurité et les normes émergentes. L’agenda ne concerne pas seulement des bâtiments remplis de GPU. Il inclut explicitement la formation de modèles IA, l’inférence, les workflows IA agentiques, le contrôle d’accès, les logiciels, le matériel, le stockage des données, la chaîne d’approvisionnement, la technologie opérationnelle, la sécurité du personnel et les défis réglementaires.
C’est la bonne direction, car le risque a évolué. L’IA d’entreprise n’est plus seulement une catégorie d’applications. Elle devient une infrastructure.
Et les défaillances d’infrastructure sont différentes.
L’ancien modèle de gouvernance IA était trop centré sur les applications
La plupart des organisations considèrent encore la gouvernance IA comme un problème d’inventaire logiciel.
Elles demandent :
- Quels outils IA sont approuvés ?
- Quels fournisseurs ont passé la revue de sécurité ?
- Quels employés utilisent des IA non approuvées ?
- Quels types de données sont autorisés dans les prompts ?
- Quels contrats incluent des restrictions sur la formation des modèles ?
Ce sont de bonnes questions, mais elles ne couvrent que la surface visible par l’utilisateur.
La prochaine génération de risques IA se situe sous ces questions. Elle vit dans l’environnement de calcul, la couche de routage des modèles, les magasins vectoriels, les frameworks d’orchestration, les passerelles API, les fournisseurs d’identité, les permissions des agents, les écosystèmes de plugins, les journaux, les systèmes de mémoire et les pipelines de récupération.
Une entreprise peut avoir une liste propre d’applications IA approuvées et ne pas avoir de réelle visibilité sur la manière dont les charges IA circulent dans son infrastructure.
C’est là que le nouveau vide de contrôle apparaît.
Les centres de données IA ne sont pas que des régions cloud plus grandes
Les responsables sécurité doivent résister à la tentation de traiter les centres de données IA comme des centres de données classiques avec du matériel plus coûteux.
L’infrastructure IA introduit un modèle opérationnel différent.
Les clusters de formation concentrent des données précieuses, des poids de modèles, de la propriété intellectuelle et du calcul haute performance en un seul lieu. Les systèmes d’inférence sont proches des workflows de production. Les systèmes agentiques connectent les modèles à des outils, fichiers, identités, bases de données, plateformes SaaS et actions métier. Les systèmes de récupération copient des connaissances sensibles d’entreprise dans des index qui ne sont pas forcément gouvernés comme les systèmes sources.
Le résultat est une pile où la frontière entre données, logiciels, identité et prise de décision devient floue.
Une compromission classique d’un centre de données peut exposer des systèmes ou des données. Une compromission d’infrastructure IA peut exposer des données, altérer le comportement du modèle, empoisonner le contexte de récupération, voler des actifs de modèle, abuser du calcul ou manipuler des décisions automatisées.
Cela rend la gouvernance plus difficile, mais aussi plus importante.
L’IA agentique rend le risque infrastructurel opérationnel
L’expression qui ressort dans le périmètre de l’atelier NIST est « workflows IA agentiques ».
Cela importe car les agents transforment l’IA d’une couche de recommandation en une couche d’exécution.
Un chatbot répond. Un agent agit.
Un agent peut lire des tickets, interroger un CRM, inspecter du code, rédiger des emails, mettre à jour des enregistrements, déclencher des workflows, ouvrir des pull requests et appeler des API internes. Quand ces actions passent par l’infrastructure d’entreprise, la question de sécurité n’est plus seulement « Le modèle était-il sûr ? »
La meilleure question est :
« Que pourrait faire ce système IA s’il était erroné, compromis, sur-permissionné ou manipulé ? »
Cette question traverse l’infrastructure, l’identité, la gouvernance et les processus métier.
Elle nécessite des contrôles que la plupart des programmes IA n’ont pas encore :
- Journaux d’actions pour les changements initiés par l’IA
- Limites de permission pour agents et outils
- Workflows d’approbation pour actions à fort impact
- Visibilité en temps réel sur l’accès aux modèles, outils et données
- Séparation entre expérimentation et exécution en production
- Voies de révocation pour la mémoire des agents et le contexte retenu
- Surveillance des injections de prompt, empoisonnement de récupération et usage anormal des outils
Ce ne sont pas des documents de politique. Ce sont des contrôles opérationnels.
L’IA fantôme ne restera pas au niveau du navigateur
L’IA fantôme a commencé avec des employés collant des données dans des outils grand public.
Cette version existe toujours. Mais le risque plus stratégique est désormais l’infrastructure IA fantôme : des équipes construisant agents, automatisations, copilotes internes et workflows alimentés par modèles plus vite que la gouvernance ne peut les voir.
Une unité métier peut ne pas penser déployer une infrastructure IA. Elle peut penser connecter une API modèle à un dépôt documentaire et une file de tickets. Un développeur peut ne pas penser créer un chemin d’automatisation privilégié. Il peut penser gagner du temps sur le triage. Un département peut ne pas penser créer un nouveau système de décision. Il peut penser améliorer l’efficacité du workflow.
L’intention n’est pas le problème. La visibilité l’est.
Si la sécurité ne voit pas le workflow, elle ne peut pas évaluer le risque. Si la gouvernance ne cartographie pas le chemin des données, elle ne peut pas appliquer la politique. Si l’audit ne peut pas reconstituer l’action, il ne peut pas prouver ce qui s’est passé.
C’est pourquoi la gouvernance IA doit passer de l’approbation d’outils à la visibilité des workflows.
Ce que les équipes sécurité doivent faire maintenant
La démarche immédiate n’est pas d’attendre des normes parfaites. Les normes aident, mais le risque est déjà en mouvement.
Les équipes sécurité et gouvernance doivent commencer par cartographier où l’infrastructure IA existe aujourd’hui, même si elle n’est pas étiquetée ainsi.
Cherchez :
- Applications internes appelant des API modèles
- Agents connectés à des outils SaaS ou systèmes internes
- Bases de données vectorielles ou couches de récupération contenant des données d’entreprise
- Automatisations de workflow utilisant les sorties LLM pour déclencher des actions
- Outils développeurs avec accès en écriture IA au code ou tickets
- Copilotes construits par les départements fonctionnant hors revue IT centrale
- Passerelles modèles, couches proxy ou outils d’observabilité utilisés par une seule équipe
Puis posez cinq questions pratiques de contrôle.
1. Quelles données ce système peut-il accéder ? 2. Quelles actions peut-il effectuer ? 3. Quelle identité utilise-t-il lorsqu’il agit ? 4. Où sont enregistrés prompts, sorties, mémoire et contexte de récupération ? 5. Qui peut révoquer l’accès ou arrêter le workflow en cas de problème ?
Si la réponse à l’une de ces questions est floue, le système n’est pas encore gouverné.
Le modèle gagnant est l’habilitation avec garde-fous
La mauvaise réponse est de bloquer tous les workflows IA jusqu’à approbation par un comité central. Cela pousse seulement les équipes vers des contournements.
La meilleure réponse est de créer des chemins balisés.
Donnez aux équipes des moyens approuvés de construire avec l’IA. Fournissez l’accès aux modèles via des passerelles gouvernées. Proposez des modèles standards pour la récupération, la journalisation, la permission et l’approbation humaine. Faites que le chemin sûr soit plus rapide que le chemin fantôme.
C’est ainsi que la gouvernance devient infrastructure, pas paperasserie.
C’est aussi là que se concentre Aona : aider les entreprises à passer d’une politique IA statique à une visibilité et un contrôle réels sur l’usage effectif de l’IA. Pas seulement quels outils ont été approuvés il y a six mois, mais où l’IA agit aujourd’hui, quelles données elle touche et quels workflows nécessitent des garde-fous.
La sécurité des centres de données IA peut sembler un sujet d’infrastructure de niche. Ce n’est pas le cas. C’est un signal que la gouvernance IA devient un problème d’architecture d’entreprise.
Les équipes qui comprendront cela tôt pourront adopter l’IA plus rapidement, avec moins d’angles morts. Celles qui continueront à traiter l’IA comme une liste d’applications découvriront l’infrastructure plus tard, probablement lors d’un audit, d’un incident ou d’une question du conseil d’administration à laquelle elles ne pourront répondre.
Ce n’est pas l’endroit où un RSSI veut se trouver.
