Les agents IA deviennent rapidement bien plus que de simples outils générant des réponses ou des recommandations. À mesure que les entreprises leur accordent un accès accru aux données, aux applications et à l’infrastructure, ces systèmes acquièrent également la capacité d’agir au nom des utilisateurs et des entreprises. Cette évolution rend les contrôles qui encadrent l’IA de plus en plus importants.
Gartner a récemment prédit que 40 % des applications d’entreprise intégrées à des agents IA spécialisés dans certaines tâches évolueront, d’ici 2027, au-delà d’agents individuels pour former des écosystèmes d’agents interconnectés. Cela rend la mise en place d’une gouvernance cohérente de plus en plus importante.
La gouvernance de l’IA ne peut pas se limiter à un document de politique, à un conseil dédié à l’IA ou à un processus d’examen des modèles. La mise en place de chacun de ces éléments est importante, mais aucun ne détermine ce qu’un système d’IA peut consulter, modifier ou exposer au sein d’un environnement d’entreprise.
En définitive, la gouvernance ne devient concrète que lorsqu’elle relie l’intention à l’application effective. La gouvernance de l’IA est devenue bien plus qu’un simple « problème d’IA » : elle s’est transformée en problème de sécurité réseau, de sécurité cloud, ainsi que d’identité, de segmentation et d’accès aux applications.
À mesure que les systèmes d’IA gagnent en autonomie, les politiques qui définissent les accès, la connectivité et le contrôle des changements deviennent plus importantes que jamais.
L’IA avance plus vite que les modèles de gouvernance
Ce n’est un secret pour personne : le déploiement et l’expérimentation autour de l’IA prennent de vitesse la gouvernance.
Dans les entreprises, les employés utilisent des copilotes ; les développeurs s’appuient sur l’IA pour générer et examiner du code ; les équipes opérationnelles testent des agents qui résument les tickets, recommandent des changements ou déclenchent des workflows ; et les équipes cloud explorent des automatisations capables de provisionner des ressources ou de modifier des configurations.
eSecurity Planet a déjà analysé comment l’IA agentique entre en production, avec des systèmes autonomes capables d’appeler des outils, d’accéder aux données de l’entreprise et d’exécuter des actions dans différents systèmes métier.
L’essor que connaît l’adoption de l’IA n’est pas intrinsèquement mauvais. Les entreprises avancent rapidement pour tirer parti des bénéfices de l’IA, mais l’expérimentation peut prendre de vitesse la gouvernance de sécurité nécessaire pour la garder sous contrôle.
De nombreuses entreprises ont confié la responsabilité de l’IA à un CIO, un CTO, un CISO ou un conseil transversal dédié à l’IA. S’il s’agit d’un point de départ raisonnable, les décisions de déploiement sont désormais prises dans les unités opérationnelles, les équipes de développement, les plateformes cloud, les fournisseurs tiers et par les utilisateurs. Une équipe centrale peut être propriétaire de la politique, sans pour autant avoir une vision claire des endroits où l’IA est utilisée, des données auxquelles elle peut accéder, des systèmes qu’elle peut influencer ou des contrôles qui encadrent son comportement dans l’ensemble de l’organisation.
Une politique sans contrôle n’est pas une gouvernance
La première réponse au risque lié à l’IA consiste souvent à rédiger une politique d’IA. Les organisations définissent les outils autorisés, les données qui ne doivent pas être saisies, les personnes habilitées à approuver leur utilisation et les cas d’usage qui nécessitent un examen. C’est un pas dans la bonne direction, mais l’action ne peut pas s’arrêter là. Une politique du type « on la définit puis on l’oublie » ne suffit tout simplement pas.
Une politique écrite montre que l’intention est là, mais elle ne permet pas de :
- Déterminer si un agent IA peut atteindre une base de données sensible
- Vérifier si une charge de travail cloud a hérité de droits d’accès plus larges que prévu
- Valider si la segmentation limite le rayon d’impact
- Confirmer si une règle de pare-feu autorise un chemin qui aurait dû être fermé depuis des mois
La gouvernance de l’IA peut échouer lorsque les organisations confondent les énoncés de politique avec des contrôles applicables.
Le problème devient plus sérieux à mesure que les systèmes d’IA passent de l’observation et du conseil à l’action. Des incidents récents ont également démontré les risques de sécurité créés par les agents IA autonomes lorsque les systèmes peuvent identifier des vulnérabilités de manière autonome, élever leurs privilèges et adapter leur comportement.
Un agent qui recommande des changements de pare-feu, ouvre des tickets, modifie des ressources cloud ou déclenche des workflows de remédiation crée un niveau d’exposition différent de celui d’un assistant en lecture seule.
La question n’est plus seulement de savoir si le modèle est fiable. Il faut aussi se demander ce que le système est capable de faire lorsqu’il se trompe, est compromis, dispose de droits excessifs ou fonctionne en dehors du périmètre prévu. Cette exposition est définie par l’identité et les autorisations avec lesquelles l’agent fonctionne, les systèmes qu’il peut atteindre et les actions qu’il est autorisé à effectuer.
C’est ici que la sécurité réseau devient un élément important de la gouvernance de l’IA. L’IA peut accélérer la découverte, la prise de décision et les changements opérationnels, mais pour que les organisations puissent profiter de ces avantages en toute sécurité, les équipes de sécurité doivent renforcer leur contrôle sur les politiques qui régissent l’accessibilité, les accès et l’exposition. Les systèmes d’IA fonctionnent dans le cadre des conditions d’accès configurées dans l’entreprise, et peuvent en hériter.
Les pare-feu, la segmentation, les contrôles cloud et les politiques d’identité font donc partie de la trame de contrôle qui détermine jusqu’où un système d’IA peut aller et ce qu’il peut faire.
La visibilité n’est pas le contrôle
La visibilité est nécessaire, mais elle ne suffit pas à limiter ce qu’un système d’IA peut faire. Un inventaire peut vous indiquer qu’un agent existe ; il ne peut pas prouver que l’agent n’accède qu’aux ressources prévues, que les systèmes connectés sont correctement segmentés, que les changements restent conformes à la politique ou que les contrôles continuent de fonctionner à mesure que l’infrastructure évolue.
La gouvernance de l’IA doit atteindre le plan de contrôle
La meilleure approche consiste à faire de la gouvernance de l’IA une extension de la gouvernance technologique existante, et non une discipline distincte reléguée à l’écart.
L’IA doit être classée en fonction de son autonomie et de ses accès. Sa gouvernance doit dépendre de ce qu’elle peut voir, décider et modifier. Ses autorisations doivent être mappées sur les contrôles existants en matière d’identité, de réseau, de cloud, de segmentation et d’applications.
Cela oblige les responsables de la sécurité à voir au-delà de la gouvernance des modèles. Le comportement du modèle est important. La gouvernance des données est importante. L’approbation humaine est importante. Mais le risque d’entreprise est également déterminé par les chemins réseau, les règles de pare-feu, les limites de segmentation, les droits cloud et les exceptions aux politiques. C’est à ces endroits que la gouvernance de l’IA devient applicable ou reste au stade des intentions.
« Il existe un parallèle utile avec Zero Trust. Le principe consistant à « ne jamais faire confiance, toujours vérifier » dépend de la capacité des organisations à traduire les politiques de sécurité en décisions d’accès évaluées et appliquées en continu. La gouvernance de l’IA est confrontée à un défi similaire : les politiques prennent tout leur sens lorsque les contrôles techniques déterminent les systèmes auxquels une charge de travail d’IA peut accéder, les identités qu’elle peut utiliser et les actions qu’elle est autorisée à effectuer.
Les responsables de la sécurité n’ont pas besoin de stopper l’adoption de l’IA pour la gouverner. Ils doivent rendre la gouvernance opérationnelle. Pour gérer efficacement les politiques, chaque responsable de la sécurité devrait envisager les mesures suivantes :
- Dresser l’inventaire de l’utilisation de l’IA dans les outils autorisés comme non autorisés
- Classer les systèmes en fonction de leur autonomie et de leurs accès
- Désigner les responsables métier, techniques et de sécurité
- Relier la politique aux points d’application des contrôles : politiques de pare-feu, contrôles cloud, autorisations d’identité, limites de segmentation, règles d’accès aux données et workflows de gestion des changements
- Valider en continu la conformité et l’efficacité
La gouvernance de l’IA ne doit pas devenir un frein à l’innovation. Lorsqu’elle est bien menée, elle donne aux organisations la confiance nécessaire pour avancer plus vite sans accroître aveuglément les risques. L’avenir de la gouvernance de l’IA ne se décidera pas uniquement au niveau des modèles. Il se décidera dans le plan de contrôle qui détermine ce que l’IA peut réellement faire.
À lire ensuite : découvrez comment les organisations peuvent instaurer la confiance dans les systèmes autonomes grâce à la gouvernance, à la supervision et à des garde-fous pratiques dans le guide d’eSecurity Planet consacré à la sécurité agentique et aux agents IA.