La sécurité de l’IA au-delà du modèle : ce dont les entreprises doivent se préoccuper — et pourquoi

L’IA évolue rapidement, et la plupart des entreprises ne sécurisent qu’une fraction de leur surface de risque réelle. Ce rapport de recherche de NSS Labs, élaboré en collaboration avec F5, AWS et Microsoft, examine les vecteurs de menace, les lacunes en matière de gouvernance et les domaines de compétences les plus importants lorsque l’IA passe de l’expérimentation à la production.

Table des matières

Introduction : pourquoi la sécurité de l’IA constitue un enjeu de risque pour l’entreprise

Piliers fondamentaux d’une IA responsable en matière de sécurité

Pourquoi la sécurité des modèles ne suffit pas à elle seule

Définir le périmètre des responsabilités en matière de sécurité de l’IA

Le nouveau modèle de menace : pourquoi les hypothèses de sécurité traditionnelles ne tiennent plus

Les domaines de compétences qui comptent vraiment

Intégrité des entrées et contrôle des instructions

Gestion des risques liés aux sorties et à l’exfiltration de données

Résilience et robustesse du système

Précision des politiques et gestion des compromis

Vérification déterministe pour les décisions critiques en matière de sécurité

IA agentique et autorité déléguée

Observabilité, audit et analyse forensique

Pourquoi la sécurité de l’IA sans GRC est vouée à l’échec

Conclusion : gouverner l’IA à l’échelle de l’entreprise

TÉLÉCHARGEZ LA PARTIE 2 : Évaluer la sécurité de l’IA en entreprise : les questions auxquelles tout acheteur devrait pouvoir répondre

Résumé analytique

L’intelligence artificielle est rapidement passée du stade de l’expérimentation à celui du déploiement en production dans les environnements d’entreprise. Les modèles d’IA générative, les assistants conversationnels et les systèmes fondés sur des agents de plus en plus autonomes sont désormais intégrés aux applications destinées aux clients, aux processus de travail internes, aux chaînes de développement logiciel et aux processus d’aide à la décision. Par conséquent, les défaillances des systèmes d’IA présentent déjà des risques concrets sur les plans commercial, juridique, réputationnel et opérationnel, tout en constituant un défi majeur pour une gouvernance efficace.

Une grande partie de l’attention portée à la sécurité de l’IA se concentre sur les modèles d’IA eux-mêmes, notamment sur la manière dont ils sont entraînés, les données qu’ils contiennent et leur comportement dans des conditions contrôlées. Si la sécurité au sein du modèle d’IA est évidemment très importante, elle ne couvre qu’une fraction de la surface de risque. Dans les environnements de production, les vulnérabilités les plus lourdes de conséquences apparaissent souvent en dehors du modèle : dans les données auxquelles il est connecté, les outils qu’il peut utiliser, les autorisations dont il hérite et les pratiques de gouvernance — ou leur absence — qui encadrent son comportement.

Ce document présente les domaines qui devraient le plus préoccuper les entreprises lorsqu’elles évaluent des solutions de sécurité de l’IA, ainsi que les raisons pour lesquelles ces préoccupations sont importantes. Sans se concentrer sur des produits spécifiques ni sur les modalités des tests, il propose une vision de la sécurité de l’IA axée sur les capacités, sous l’angle de la gestion des risques d’entreprise, de la gouvernance et de la responsabilité. L’objectif est de fournir aux responsables de la sécurité des systèmes d’information (RSSI), aux acheteurs en entreprise et aux responsables de la gouvernance, des risques et de la conformité (GRC) des conseils concrets sur les questions à poser avant que des défaillances réelles de l’IA ne révèlent des réponses indésirables dans le cadre d’un examen réglementaire, juridique, client ou mené par le conseil d’administration.

Introduction : pourquoi la sécurité de l’IA constitue un enjeu de risque pour l’entreprise

L’utilisation de l’IA au sein des systèmes d’entreprise s’accélère, ce qui pose des défis majeurs aux personnes chargées de mettre en œuvre les contrôles destinés à l’encadrer. Les unités opérationnelles déploient des fonctionnalités basées sur l’IA afin d’améliorer la productivité, d’automatiser les décisions, d’accélérer le développement logiciel et de différencier les expériences client. Or, nombre de ces systèmes sont déployés bien avant tout examen formel en matière de sécurité, de risques ou de gouvernance. Ce rythme creuse l’écart entre innovation et responsabilité.

Sécuriser le modèle d’IA lui-même est essentiel, mais cela ne suffit pas. La plupart des entreprises appliquent déjà des contrôles directement au niveau du modèle : sélection rigoureuse des données d’entraînement ; recours à des techniques d’ajustement de la sécurité et d’alignement ; restriction des accès au modèle ; limitation du taux d’utilisation ; et utilisation de filtres de contenu et de mécanismes de refus intégrés. Ces mesures encadrent les résultats produits par le modèle et réduisent les usages abusifs les plus évidents, mais elles ne tiennent pas compte du fonctionnement des systèmes d’IA dans des environnements d’entreprise réels, où les résultats interagissent avec des données en temps réel, déclenchent des actions et s’inscrivent dans des contextes d’autorisation complexes.

Dans le contexte de la sécurité de l’IA, l’IA responsable (RAI) désigne le cadre global de gouvernance et de gestion du cycle de vie, ainsi que les politiques et les pratiques techniques visant à garantir que les systèmes d’intelligence artificielle restent sûrs, sécurisés, résilients et dignes de confiance tout au long de leur cycle de vie. Elle ne se limite pas à prévenir les attaques : elle vise également à garantir la robustesse des systèmes face aux préjudices involontaires, aux atteintes à la vie privée et aux biais, tout en maintenant une supervision humaine.

Piliers fondamentaux d’une IA responsable dans le domaine de la sécurité

Considéré spécifiquement sous l’angle de la sécurité, le cadre de l’IA responsable se traduit par plusieurs domaines de contrôle concrets : garantir la résilience des systèmes d’IA face aux erreurs, aux entrées inattendues et aux attaques adverses intentionnelles ; sécuriser le pipeline d’entraînement et de déploiement afin de préserver la confidentialité et de protéger les données ; maintenir la transparence et l’auditabilité ; et mettre en place des processus de gouvernance définissant les usages acceptables et les responsabilités.

Dans le cadre de l’IA responsable, les capacités de sécurité centrées sur les modèles atténuent de manière proactive certaines vulnérabilités propres à l’apprentissage automatique, telles que :

• Empoisonnement des données : manipulation des données d’entraînement afin de corrompre le modèle
• Inversion/extraction de modèle : vol de modèles propriétaires ou divulgation de données d’entraînement sensibles
• Attaques adversariales : injection de petites modifications imperceptibles dans les données d’entrée afin de provoquer des décisions erronées
• Injection de prompt : tromper l’IA générative pour lui faire contourner les limites prévues par les politiques et les instructions

Ces contrôles de sécurité des modèles sont nécessaires pour garantir un niveau de sécurité minimal, mais ils fonctionnent en grande partie sans tenir compte du contexte de l’entreprise et sont généralement opaques à toute validation indépendante ou externe. Les entreprises ont souvent une visibilité limitée sur la manière dont ces contrôles sont mis en œuvre ou dont ils se comportent dans des cas limites.

Dans les déploiements à l’échelle de l’entreprise, le modèle d’IA n’est qu’un composant d’un système plus vaste comprenant des couches de récupération, des connecteurs aux données de l’entreprise, des signaux d’identité et d’autorisation, ainsi que l’appel d’outils susceptibles de modifier considérablement l’état des systèmes en aval. La surface de risque de l’entreprise est principalement déterminée par ces intégrations et les composants environnants du système d’IA. Même un modèle correctement aligné peut être utilisé de manière non sécurisée s’il est connecté à des données inappropriées, s’il dispose d’autorisations excessives pour utiliser des outils, si l’application des politiques manque de cohérence ou si la surveillance ne permet pas de détecter les utilisations abusives.

C’est là que les contrôles externes de sécurité de l’IA à l’exécution (également appelés garde-fous pour l’IA, pare-feu pour l’IA ou systèmes de protection de l’IA) deviennent essentiels. Les garde-fous à l’exécution sont des contrôles techniques spécifiques, appliqués en temps réel en dehors du modèle afin de faire respecter les politiques de sécurité et les limites comportementales au moment où l’interaction avec l’application fait apparaître les risques pour l’entreprise. Ces contrôles observent et encadrent le comportement de l’IA en s’appuyant sur le contexte global du système, notamment l’identité de l’utilisateur, la sensibilité des données, l’état de l’application et les exigences de gouvernance. Les contrôles à l’exécution permettent d’assurer l’auditabilité, la résilience et la responsabilisation, constituant ainsi le socle d’une sécurité de l’IA adaptée aux entreprises.

La terminologie varie selon les fournisseurs et les frameworks, mais, en pratique, le principe est simple : la sécurité des modèles réduit les risques intrinsèques qui leur sont associés, tandis que les garde-fous appliqués lors de l’exécution gèrent les risques pour l’entreprise au point d’interaction.

Pourquoi la sécurité des modèles ne suffit pas à elle seule

Au niveau le plus élémentaire, les mécanismes de sécurité des modèles peuvent bloquer les invites malveillantes, filtrer les contenus interdits et faire respecter des règles d’utilisation simples. Ces capacités sont nécessaires, mais de nombreuses défaillances majeures de l’IA en entreprise ne résultent pas d’un manque de règles, mais d’un manque de contexte, de résilience et de visibilité.

Par exemple, un système d’IA peut respecter toutes les politiques de contenu définies tout en divulguant des informations sensibles par agrégation, inférence ou combinaison inappropriée de contextes. De même, un système peut appliquer correctement les règles dans des conditions normales, mais connaître des défaillances imprévisibles en cas de forte charge, d’interruptions partielles ou de défaillances de dépendances.

Pour faire face à ces risques, il est nécessaire de mettre en place des contrôles à l’exécution qui tiennent pleinement compte du système dans son ensemble et s’inscrivent dans un cadre de gouvernance. Cela implique notamment d’appliquer des politiques fondées sur les rôles et la sensibilité des données, de limiter l’utilisation des outils et les pouvoirs délégués, de gérer les modes de défaillance de manière prévisible et de produire des éléments probants à l’appui des enquêtes, des audits et de la conformité.

Sans gouvernance, observabilité et résilience, la sécurité des modèles ne peut à elle seule offrir le niveau d’assurance requis pour les systèmes d’IA déployés à l’échelle de l’entreprise. Les organisations les plus matures considéreront donc la sécurité de l’IA comme un enjeu systémique et de gouvernance, et non comme un problème limité aux seuls modèles.

Auteurs

Bob Walder - Analyste principal, NSS Labs
lan Foo - Directeur de la technologie et vice-président exécutif des produits, NSS Lab

Contributeurs

Cette étude a été réalisée en collaboration avec des leaders du secteur de la sécurité, du cloud et de l’IA.

Cameron Delano - Architecte de solutions senior, F5
Jeanette Hurr - Architecte de solutions monde, F5
Riggs Goodman III - Architecte de solutions principal, sécurité et confidentialité de l’IA, AWS
Raj Bagwe - Architecte de solutions senior, AWS
Zachary Riffle - Architecte sécurité, Microsoft

Définir le périmètre des responsabilités en matière de sécurité de l’IA

Les organisations qui utilisent des services d’IA sont confrontées à des risques fondamentalement différents de celles qui développent des modèles personnalisés ou les entraînent de A à Z. Définir le périmètre de mise en œuvre permet de déterminer quels contrôles de sécurité sont gérés en interne et lesquels sont pris en charge par le fournisseur.

Cinq périmètres de mise en œuvre

1. Au niveau le plus élémentaire, les applications d’IA destinées au grand public telles que ChatGPT, Claude ou Gemini confient la quasi-totalité des responsabilités en matière de sécurité au fournisseur. Celui-ci assure la sécurité du modèle, la protection de l’infrastructure, les garde-fous de base et la protection des données. L’organisation se concentre sur la définition de politiques d’utilisation acceptable, le contrôle de l’accès des utilisateurs et la validation des résultats en fonction du contexte métier. Les efforts de sécurité visent principalement à empêcher les employés de saisir des données sensibles et à surveiller les violations des politiques.
2. Applications d’entreprise dotées de fonctionnalités d’IA, telles que Salesforce Einstein ou Microsoft Copilot, reposent sur un modèle de responsabilité partagée. Les fournisseurs assurent la sécurité des modèles, les contrôles au niveau des applications et la sécurité des intégrations, tandis que le client gère les accès fondés sur les rôles, la classification des données et les autorisations liées aux workflows. La sécurité se concentre alors sur l’intégration des identités, la gouvernance des données et la journalisation des audits permettant de démontrer une utilisation appropriée.
3. Les organisations qui déploient des modèles de fondation préentraînés via des plateformes telles qu’Amazon Bedrock ou Azure OpenAI assument une responsabilité nettement plus importante en matière de sécurité. Si les fournisseurs gèrent la sécurité des modèles et l’infrastructure, le client est responsable de l’ingénierie des prompts, de l’architecture de récupération, du filtrage des résultats et des autorisations accordées aux outils. La sécurité s’étend alors à l’intégrité des entrées, à la prévention des risques liés aux résultats et à une observabilité complète de l’ensemble du système.
4. Les modèles affinés alourdissent encore la charge de l’organisation en matière de sécurité. Les fournisseurs gèrent uniquement l’infrastructure et la sécurité du modèle de base, tandis que le client prend en charge la sélection des données d’entraînement, la sécurité de l’affinage, les contrôles de déploiement et l’ensemble de la sécurité lors de l’exécution. Les mesures de sécurité doivent couvrir la prévention de l’empoisonnement des données, l’évaluation des modèles et la mise en place de garde-fous complets tout au long du cycle de développement et de production.
5. Au niveau de complexité le plus élevé, les modèles entraînés en interne font peser la quasi-totalité de la responsabilité en matière de sécurité sur l’organisation. Les fournisseurs ne gèrent que l’infrastructure, tandis que le client prend en charge tous les aspects du développement des modèles, de la sécurité du pipeline d’entraînement, du déploiement et des contrôles à l’exécution. La sécurité couvre l’ensemble du cycle de vie, de la collecte des données à la surveillance en production et à la réponse aux incidents.

Comprendre la responsabilité partagée

Le périmètre de mise en œuvre détermine fondamentalement les obligations du client en matière de sécurité. Pour les applications d’IA grand public, la plupart des responsabilités liées à la sécurité incombent au fournisseur, tandis que l’organisation se concentre sur l’encadrement de l’utilisation de ces services par ses employés. Les applications d’entreprise accroissent la responsabilité du client en matière d’intégration des identités et de gouvernance des données, tandis que les fournisseurs sécurisent l’infrastructure sous-jacente. Les modèles de fondation préentraînés transfèrent une part importante de la responsabilité en matière de sécurité à l’organisation, notamment pour l’ingénierie des prompts, l’architecture de récupération des données et les contrôles complets lors de l’exécution. Enfin, avec les modèles affinés et entraînés en interne, la quasi-totalité des responsabilités liées à la sécurité incombe au client, de la sélection des données d’entraînement à la surveillance en production et à la réponse aux incidents.

Ce modèle de responsabilité partagée reflète le fonctionnement actuel de la sécurité du cloud. Avant de planifier la sécurité de l’IA, il est essentiel de définir clairement le périmètre de mise en œuvre. Celui-ci détermine les capacités de sécurité qui doivent être développées en interne, celles qui sont gérées par le fournisseur et les domaines nécessitant une supervision conjointe. Sans une compréhension claire et une prise en compte effective de ce périmètre, les organisations risquent soit d’investir excessivement dans des contrôles déjà gérés par le fournisseur, soit de laisser subsister des lacunes critiques.

Le nouveau modèle de menace : pourquoi les hypothèses de sécurité traditionnelles ne tiennent plus

La sécurité traditionnelle des applications repose sur l’hypothèse que les entrées sont limitées, les chemins d’exécution prévisibles et les résultats déterministes. Les systèmes d’IA remettent en cause chacune de ces hypothèses et les rendent souvent caduques. Ils acceptent des entrées non structurées en langage naturel, génèrent des réponses non déterministes et conservent souvent le contexte au fil de plusieurs échanges. Même lorsque l’application qui les intègre est bien conçue, le modèle introduit un comportement probabiliste difficile à gérer en s’appuyant uniquement sur une modélisation classique des menaces.

Les déploiements modernes de l’IA sont également plus complexes qu’un simple schéma « requête en entrée, réponse en sortie ». Dans les entreprises, les systèmes d’IA sont généralement connectés à des documents internes, des bases de données, des API et des services externes. Une architecture courante est la génération augmentée par récupération (RAG), dans laquelle le modèle récupère dynamiquement du contenu externe lors de l’exécution (comme des documents de politique interne, des articles de base de connaissances ou des dossiers clients) afin de répondre à des questions complexes avec davantage de précision que ne le permettraient les seules données d’entraînement du modèle.

De nombreux déploiements iront encore plus loin en utilisant des systèmes autonomes ou fondés sur des agents, capables de décider des prochaines étapes sans intervention ni instruction humaine directe. Ces agents d’IA déterminent leurs actions en interagissant avec des outils externes, c’est-à-dire des interfaces programmatiques qui étendent les capacités de l’IA au-delà de la génération de texte. Les outils sont des fonctions distinctes qui permettent aux systèmes d’IA d’interagir avec des systèmes externes et d’effectuer des actions, telles que l’interrogation de bases de données, l’appel d’API REST, l’exécution de code, l’accès à des systèmes de fichiers ou l’utilisation d’applications d’entreprise. Contrairement à la génération augmentée par récupération (RAG), qui extrait des informations contextuelles afin d’éclairer les réponses, les outils permettent aux systèmes d’IA d’agir et de modifier l’état des systèmes en aval.

Chaque outil constitue un périmètre de sécurité doté de ses propres autorisations et de son propre « rayon d’impact » : lorsqu’un agent d’IA accède à un outil, il hérite de la capacité à effectuer toutes les actions permises par celui-ci. Si ces fonctionnalités améliorent l’efficacité et le passage à l’échelle, elles élargissent également la surface d’attaque d’une manière peu familière à de nombreuses équipes de sécurité et difficile à maîtriser au moyen des contrôles traditionnels.

Un vieux dicton affirme qu’« il n’y a rien de nouveau sous le soleil ». Cela vaut autant pour les menaces de sécurité que pour tout le reste dans la vie. Les ingénieurs en sécurité de l’IA doivent donc être tout aussi conscients des surfaces d’attaque plus anciennes, telles que les dépassements de mémoire tampon et les techniques de contournement au niveau du réseau, que de celles propres à l’IA. Dans le même temps, il est clair que les menaces pesant sur les systèmes d’IA vont bien au-delà des exploits classiques.

Elles comprennent la manipulation des instructions (injection de prompt), l’empoisonnement du contexte par le biais de contenus récupérés, l’exfiltration de données via les résultats générés, l’utilisation abusive de pouvoirs délégués dans les systèmes dotés d’outils, ainsi que les attaques par dégradation qui compromettent la fiabilité plutôt que la confidentialité. Par exemple, de combien de façons différentes une IA pourrait-elle encoder ou dissimuler un numéro de sécurité sociale américain (SSN) ? En outre, de combien de façons pourrait-on tromper une IA pour l’amener à divulguer de telles informations, sachant qu’il est potentiellement possible de demander à ces systèmes d’incarner la personne dont les données à caractère personnel sont extraites ?

Ces schémas de menace sont documentés dans des référentiels et des méthodologies de test standardisés élaborés par des organismes de test indépendants reconnus. Ces référentiels proposent des taxonomies structurées des vulnérabilités propres à l’IA que les entreprises doivent comprendre et traiter.

Les domaines de compétences qui comptent vraiment

Lors de l’évaluation de solutions de sécurité de l’IA destinées à des scénarios de déploiement en entreprise, il convient de se concentrer sur un nombre restreint de domaines de capacité directement liés aux risques réels. Ces capacités reflètent la manière dont les systèmes d’IA sont utilisés en production et dont les défaillances surviennent en pratique. Elles doivent fonctionner comme des couches intégrées, et non comme des contrôles autonomes.

Les modèles d’IA ne peuvent pas, à eux seuls, faire respecter de manière fiable les périmètres de sécurité de l’entreprise : par conception, ils interprètent les entrées comme des instructions et ne disposent pas de mécanismes natifs et auditables de contrôle des accès. Les défenses monocouches créent des failles exploitables : une forte intégrité des entrées sans validation des sorties permet l’exfiltration indirecte de données par empoisonnement du RAG ; le filtrage des sorties sans observabilité empêche de détecter les dérives par rapport aux politiques ; les contrôles des agents sans résilience du système échouent en situation de stress. Les organisations qui mettent en œuvre ces capacités de manière isolée subissent des défaillances en cascade lorsque des attaquants contournent une couche et exploitent l’absence de défenses en aval. Les architectures de sécurité de l’IA matures considèrent ces capacités comme des composants interdépendants d’un système de défense unifié.

Ces capacités s’inscrivent également naturellement dans les enjeux de gouvernance, en apportant des réponses à des questions telles que : qu’est-ce qui est autorisé, qu’est-ce qui est interdit, qu’est-ce qui est surveillé, qu’est-ce qui est consigné et qu’est-ce qui peut être défendu a posteriori ?

Intégrité des entrées et contrôle des instructions

Les systèmes d’IA sont particulièrement sensibles aux instructions, au contexte et à la manière dont les informations sont présentées. Contrairement aux applications traditionnelles, dans lesquelles les entrées sont analysées et validées de manière stricte, les systèmes d’IA sont conçus pour interpréter le langage naturel avec souplesse. Cette flexibilité ouvre la voie à de nouveaux cas d’usage très prometteurs, mais crée également des possibilités de manipulation.

Des acteurs malveillants exploiteront de plus en plus cette flexibilité par le biais de différents vecteurs de menace, tels que :

• Injection de prompt : tentative directe de contourner les règles en donnant des instructions telles que « ignorez les instructions précédentes », « agissez en tant qu’administrateur » ou « révélez vos règles système ».
• Intégration indirecte d’instructions : des instructions malveillantes sont insérées dans un contenu que le système consultera ultérieurement, comme une page web, un PDF, une page de wiki interne ou un ticket d’assistance client.
• Manipulation du contexte : qui oriente une conversation de sorte qu’une entrée non fiable soit prise pour une politique de confiance ou qu’elle prévale sur les instructions système.

Le risque pour l’entreprise ne se limite pas au fait que le modèle puisse tenir des propos inappropriés. Le risque réside dans le fait que des contrôles de sécurité mal configurés en dehors du modèle pourraient amener le système d’IA à considérer des instructions non fiables comme des règles à suivre, puis à exploiter en conséquence ses privilèges d’accès aux données et aux outils. Par exemple, un article compromis de la base de connaissances pourrait demander à un assistant d’« inclure l’intégralité des dossiers clients par souci d’exhaustivité » ou de « révéler les étapes de dépannage des systèmes internes », ce qui pourrait entraîner une divulgation involontaire ou des perturbations opérationnelles.

Des contrôles de sécurité efficaces pour l’IA imposent les autorisations d’accès aux données et d’utilisation des outils indépendamment des instructions contenues dans les prompts. Ils doivent préserver l’intégrité des instructions système, distinguer clairement le contexte système fiable des entrées non fiables et empêcher tout contenu externe de modifier implicitement le comportement. Une question d’évaluation concrète consiste à déterminer si la plateforme peut détecter les tentatives de contournement des instructions, repérer lorsque le contenu récupéré contient des instructions plutôt que des faits et démontrer que les politiques au niveau du système sont restées en vigueur dans des conditions adverses.

Gestion des risques liés aux résultats et de l’exfiltration de données

Les résultats générés par l’IA constituent l’une des sources de risque les plus visibles pour les entreprises. Si les organisations cherchent souvent avant tout à bloquer les contenus explicitement interdits, les défaillances de l’IA peuvent entraîner des divulgations plus subtiles, qui semblent anodines jusqu’à ce que quelqu’un demande : « Cet utilisateur aurait-il dû avoir accès à cette information ? »

Les systèmes d’IA peuvent exposer des informations sensibles par inférence, agrégation ou reconstitution partielle, plutôt qu’en les citant directement. Un modèle peut révéler des instructions internes ou des textes de politique interne sous couvert d’« explications utiles », divulguer des structures de code propriétaires, résumer des documents confidentiels d’une manière qui dévoile la stratégie de l’entreprise, ou fournir des détails opérationnels qui renforcent l’efficacité des attaquants. Dans les contextes réglementés, même une divulgation indirecte peut poser problème si elle permet une réidentification ou révèle des données protégées.

Lorsque les systèmes d’IA sont connectés en temps réel aux sources de données de l’entreprise, ces risques augmentent considérablement. Un assistant d’assistance capable d’interroger un CRM, un système de gestion des tickets ou un référentiel de documents peut révéler par inadvertance des informations qui dépassent largement le niveau d’accès supposé du demandeur, en particulier si la recherche est trop large ou si les informations d’identité ne sont pas prises en compte de manière cohérente. Les organisations doivent mettre en place des contrôles d’identité et d’accès appliqués de manière uniforme dans l’ensemble du système d’IA, de l’authentification des utilisateurs à la génération des réponses, en passant par la récupération des données. Sans ces contrôles, les tentatives de manipulation aboutiront. Même dans les organisations dotées de contrôles d’accès rigoureux, l’IA peut brouiller les frontières en combinant plusieurs sources dans une seule réponse narrative.

La gestion des risques liés aux résultats générés exige davantage qu’un simple filtrage par mots-clés. Les mécanismes de contrôle doivent comprendre quelles données sont exposées, pourquoi elles sont sensibles et dans quelles conditions leur divulgation est acceptable. Les entreprises doivent se demander si ces mécanismes fonctionnent avec le niveau de granularité approprié (catégories, niveaux de sensibilité, juridictions), si les politiques tiennent compte des rôles et si le système fournit des explications justifiables lorsqu’un résultat est bloqué ou modifié. Du point de vue de la gouvernance, il est indispensable de pouvoir démontrer que des mécanismes de contrôle des données sensibles existent et fonctionnent de manière cohérente.

Résilience et robustesse du système

Toutes les défaillances de l’IA ne sont pas spectaculaires. Certaines des plus préjudiciables surviennent discrètement, lorsque les systèmes se dégradent sous l’effet de contraintes. Des sessions prolongées, des entrées malformées (notamment celles dont la taille est démesurée), des requêtes répétées ou des tâches inhabituellement complexes peuvent nuire à la cohérence de l’application des règles sans provoquer de panne manifeste. Dans ces situations, le système continue de fonctionner, mais il peut le faire de manière non sécurisée ou avec des performances réduites.

Les systèmes dégradés ont souvent tendance à rester ouverts plutôt qu’à se fermer en cas de défaillance. Un classificateur de sécurité peut dépasser le délai imparti et être contourné ; une étape de récupération peut renvoyer des résultats plus larges que prévu ; les limites de débit peuvent être appliquées de manière incohérente ; ou l’appel d’un outil peut avoir lieu même lorsqu’un contrôle de conformité échoue. Dans les systèmes agentiques qui enchaînent plusieurs étapes, de légères dégradations peuvent se propager et entraîner des actions dangereuses plus en aval.

La résilience n’est pas seulement une qualité technique ; c’est aussi un enjeu de gouvernance. Un contrôle qui ne fonctionne que dans des conditions idéales n’en est pas un. Les équipes de sécurité doivent évaluer le comportement des contrôles de sécurité de l’IA dans des conditions non idéales, et déterminer si les défaillances sont détectées rapidement et gérées de manière prévisible. Cela comprend des tests de résistance portant sur les pics de volume, les schémas de requêtes malveillantes,

les interactions à contexte long et les défaillances de dépendances, telles que la latence du fournisseur d’identité, les interruptions du système de récupération ou les erreurs de connecteur.

Une plateforme de sécurité de l’IA mature doit aider les organisations à comprendre et à gérer les modes de défaillance, et pas seulement les modes d’attaque. Cela implique des paramètres par défaut sûrs, une gestion claire des erreurs, un comportement d’application des règles cohérent en cas de dégradation des sous-systèmes, ainsi qu’une télémétrie opérationnelle permettant aux équipes de sécurité de détecter cette dégradation avant qu’elle ne devienne un problème pour l’entreprise.

Précision des politiques et gestion des compromis

Les contrôles de sécurité techniquement efficaces, mais perturbateurs sur le plan opérationnel, sont rarement viables à long terme. Dans les environnements d’IA, cette tension est particulièrement forte, car les limites définies par les politiques dépendent souvent du contexte plutôt que d’une logique binaire. Par exemple, une même requête peut être légitime pour un rôle et interdite pour un autre, et une réponse peut être acceptable lorsqu’elle repose sur des sources publiques, mais inacceptable lorsqu’elle est issue de données internes. En définitive, la « bonne » politique relève d’une décision de gouvernance, et non d’une considération purement technique.

Des contrôles trop restrictifs peuvent entraver des activités commerciales légitimes et encourager le recours à des systèmes d’« IA fantôme », tandis qu’une application insuffisante des règles expose les organisations à des risques juridiques et réputationnels. Trouver le juste équilibre ne relève pas seulement d’un exercice d’ajustement, mais aussi d’une décision de gouvernance tenant compte de la tolérance au risque, du contexte de l’entreprise et des exigences en matière de responsabilité.

Les plateformes de sécurité de l’IA doivent offrir une visibilité sur les faux positifs et les faux négatifs, expliquer les raisons des décisions prises et permettre aux politiques d’évoluer dans le cadre d’un processus structuré de gestion des changements. Si un système bloque une requête, les organisations doivent savoir si ce blocage est dû à la présence de données sensibles, à une apparente tentative de contournement des instructions, à l’absence d’autorisation de l’utilisateur ou à la correspondance avec un schéma à haut risque. Sans cette transparence, les équipes ne peuvent ni ajuster les contrôles de manière responsable ni justifier les résultats auprès de la direction ou d’auditeurs externes.

Du point de vue de la gouvernance, des risques et de la conformité (GRC), la précision des politiques témoigne également du niveau de maturité. Les contrôles opaques, imprévisibles ou impossibles à ajuster deviennent des sources de risque, car ils ne peuvent pas être audités ni défendus efficacement. À l’inverse, des contrôles ajustables mais dépourvus de cadre rigoureux peuvent être affaiblis par des dérogations ponctuelles. Les plateformes matures permettent une gestion structurée des politiques, notamment grâce au versionnage, aux processus d’approbation, à l’application fondée sur les rôles et à des rapports permettant à la direction de vérifier si les risques diminuent au fil du temps.

Vérification déterministe pour les décisions critiques en matière de sécurité

Les garde-fous probabilistes de l’IA détectent efficacement la plupart des violations de politiques, mais certaines décisions critiques en matière de sécurité exigent une certitude mathématique plutôt qu’un degré de confiance statistique. Les politiques d’autorisation, la validation de la conformité réglementaire et les contrôles des infrastructures critiques pour la sécurité ne peuvent tolérer l’incertitude inhérente aux systèmes d’apprentissage automatique.

Le raisonnement automatisé — qui s’appuie sur des techniques de vérification formelle — complète les garde-fous probabilistes en garantissant de manière démontrable l’exactitude de certains points de contrôle. Contrairement à la détection fondée sur l’apprentissage automatique, qui attribue des scores de confiance, le raisonnement automatisé démontre mathématiquement qu’une politique est respectée dans toutes les conditions possibles.

La vérification déterministe est importante dans les situations suivantes :

• Décisions d’autorisation : Vérifier que les politiques de contrôle d’accès sont correctement appliquées à tous les rôles utilisateur et à toutes les classifications de données
• Validation de la conformité : Démontrer que les exigences réglementaires (résidence des données au titre du RGPD, restrictions d’accès imposées par la HIPAA) sont respectées avant le déploiement
• Systèmes critiques pour la sécurité : Veiller à ce que les systèmes d’IA contrôlant des infrastructures physiques ou des transactions financières ne puissent pas enfreindre les contraintes de sécurité

Les organisations doivent déterminer quels contrôles nécessitent une preuve formelle plutôt qu’une simple détection : le filtrage des contenus et les garde-fous généraux bénéficient de la flexibilité du machine learning, tandis que l’application des autorisations et la validation de la conformité exigent la certitude offerte par la vérification formelle. Les plateformes matures de sécurité de l’IA combinent les deux approches : une détection probabiliste pour couvrir un large éventail de menaces et une vérification déterministe pour les contrôles qui ne doivent jamais échouer.

Les organisations doivent déterminer quels contrôles nécessitent une preuve formelle plutôt qu’une simple détection : le filtrage des contenus et les garde-fous généraux bénéficient de la souplesse du machine learning, tandis que l’application des autorisations et la validation de la conformité exigent la certitude offerte par la vérification formelle. Les plateformes de sécurité de l’IA matures intègrent les deux approches : une détection probabiliste pour couvrir un large éventail de menaces et une vérification déterministe pour les contrôles qui ne doivent jamais échouer.

IA agentique et autorité déléguée

À mesure que les systèmes d’IA évoluent, passant du rôle d’assistants passifs à celui d’acteurs à part entière des processus organisationnels, une nouvelle catégorie de risque apparaît : l’autorité déléguée. Les systèmes d’IA agentique peuvent utiliser des outils externes, appeler des API, modifier des enregistrements ou déclencher des processus de manière autonome. En pratique, ils agissent comme des employés numériques disposant d’un accès étendu et capables d’intervenir à grande vitesse.

Cela soulève des questions de gouvernance bien connues dans un contexte inédit. Quelles actions le système est-il autorisé à effectuer, et dans quelles conditions ? Comment les autorisations sont-elles limitées ? Comment éviter toute escalade ? Comment maintenir la séparation des tâches ? En l’absence de limites claires à l’autonomie, de petites erreurs peuvent se propager rapidement d’un système à l’autre. Un modèle qui interprète mal l’intention d’un utilisateur peut envoyer un e-mail aux mauvais destinataires, créer un ticket contenant des informations sensibles, approuver une action qui aurait dû faire l’objet d’une vérification ou modifier un enregistrement d’une manière qui entraîne des conséquences opérationnelles en aval.

Des contrôles efficaces doivent faire respecter le principe du moindre privilège, empêcher toute utilisation non autorisée des outils et garantir la responsabilisation. Cela implique de gérer explicitement les autorisations des outils, de restreindre les actions à fort impact (en particulier celles qui modifient l’état du système), d’exiger une confirmation pour les actions à impact modéré (comme rédiger des communications externes sans les envoyer, proposer des modifications de configuration sans les appliquer ou préparer des requêtes de données sans les exécuter) et d’imposer une approbation humaine pour les opérations sensibles (comme modifier des données financières, changer des autorisations d’accès, exécuter des commandes d’infrastructure privilégiées, lancer des communications externes au nom de l’organisation ou approuver des transactions). Cela implique également de détecter les enchaînements dangereux, dans lesquels une série d’actions individuellement autorisées aboutit à un résultat qui ne devrait jamais se produire sans supervision.

Une manière concrète d’évaluer cette capacité consiste à se demander si le système peut appliquer une autonomie graduée, par exemple en autorisant librement les actions sans risque, en exigeant une confirmation pour celles ayant un impact modéré et en interdisant ou en soumettant à un niveau de validation supérieur celles à fort impact. Les responsables de la gouvernance doivent considérer l’IA agentique comme une question de délégation, et non comme une question de modèle. Si vous n’accordiez pas à un employé débutant le pouvoir unilatéral d’effectuer une certaine action, vous ne devriez pas non plus l’accorder à un agent d’IA.

Observabilité, audit et analyse forensique

Lorsqu’un problème survient dans un système d’IA, la question la plus importante n’est pas simplement de savoir ce qui s’est passé, mais de déterminer si l’organisation est en mesure de démontrer clairement comment et pourquoi cela s’est produit. Dans les environnements d’entreprise, la capacité à fournir des preuves solides d’un problème fait toute la différence entre un incident qui peut être expliqué et clos, et un incident qui se transforme en un problème de gouvernance durable.

Sans une visibilité suffisante, les équipes de sécurité doivent s’appuyer sur des journaux incomplets, des hypothèses et leur intuition pour répondre aux incidents. Les efforts de gouvernance en pâtissent, car il est impossible de démontrer, de défendre ou d’améliorer les politiques et les contrôles si leur fonctionnement ne peut pas être examiné et mesuré a posteriori. Cela est particulièrement vrai pour les systèmes d’IA, où le non-déterminisme et le contexte peuvent rendre les résultats difficiles, voire impossibles, à reproduire.

Les plateformes de sécurité de l’IA doivent fournir une journalisation détaillée, une attribution claire et des alertes en temps utile. Les entreprises doivent également être en mesure de reconstituer de bout en bout les interactions avec l’IA : les données reçues en entrée ; le contexte d’identité et d’autorisation appliqué ; le contenu récupéré (le cas échéant) ; les instructions système en vigueur ; la sortie du modèle ; ainsi que les éventuels outils ou actions en aval déclenchés. Lorsqu’un contrôle intervient — en bloquant une requête, en modifiant une sortie ou en empêchant une action —, il doit consigner la raison de cette intervention et la politique en vertu de laquelle elle a été effectuée.

Du point de vue de la gouvernance, des risques et de la conformité (GRC), l’auditabilité est essentielle. Les organisations devront démontrer que des contrôles étaient en place, qu’ils ont fonctionné comme prévu, que les exceptions ont été gérées de manière appropriée et que les modifications ont fait l’objet d’un suivi dans le temps.

Pourquoi la sécurité de l’IA sans GRC est vouée à l’échec

Les systèmes d’IA fonctionnent à des vitesses et à des échelles qui dépassent les processus de gouvernance traditionnels. En cas de défaillance, les organisations seront jugées sur leur capacité à démontrer leur maîtrise, leurs intentions et leur responsabilité. Dans ce contexte, une sécurité de l’IA dissociée de la gouvernance, de la gestion des risques et de la conformité est fragile par nature.

Les autorités de régulation et les conseils d’administration devront savoir si les risques ont été identifiés, si les mesures de contrôle étaient proportionnées et si les décisions peuvent être expliquées. Les équipes de sécurité qui ne sont pas en mesure de fournir des preuves auront du mal à justifier les résultats obtenus, quelles qu’aient été leurs intentions.

Les fonctions de gouvernance, de gestion des risques et de conformité (GRC) jouent un rôle essentiel dans la traduction des contrôles techniques en pratiques d’entreprise solides et justifiables. Cela comprend la définition des usages acceptables, la documentation des décisions relatives aux risques, la validation de l’efficacité des contrôles, ainsi que la garantie que les modifications sont suivies, examinées et auditables dans le temps.

Conclusion : gouverner l’IA à l’échelle de l’entreprise

L’IA n’est plus une technologie périphérique ; elle devient une infrastructure essentielle qui façonne la manière dont les entreprises fonctionnent, rivalisent et prennent des décisions.

À mesure que les systèmes d’IA s’intègrent aux processus critiques de l’entreprise, les organisations doivent passer de manière réfléchie de l’expérimentation à la responsabilisation. Cela implique de définir des attentes plus claires à l’égard des fournisseurs de solutions de sécurité pour l’IA, notamment en matière de transparence sur les limites, de soutien à la validation indépendante et d’engagement en faveur d’une amélioration continue plutôt que d’une garantie ponctuelle.

La responsabilisation exige également un alignement interne. Les parties prenantes des équipes de sécurité, informatiques, juridiques, de gestion des risques et des métiers doivent s’accorder sur le niveau de tolérance au risque, les procédures d’escalade et les stratégies de réponse avant que des incidents ne surviennent. La sécurité de l’IA ne relève pas d’une seule équipe ; elle constitue une responsabilité partagée à l’échelle de l’entreprise.

Les organisations qui réussiront avec l’IA seront celles qui sauront allier innovation et rigueur. L’innovation seule ne crée pas d’avantage durable ; une réussite pérenne repose sur la compréhension, l’instrumentation et la gouvernance des risques à mesure que les systèmes montent en puissance. Une sécurité efficace de l’IA ne consiste pas à éliminer l’incertitude, mais à la gérer de manière transparente et responsable, selon des modalités capables de résister à un examen approfondi.

© 2026 NSS Labs. Tous droits réservés. Les conditions d’utilisation ainsi que la politique de NSS Labs relative aux droits d’auteur et aux citations sont disponibles ici : https://nsslabs.com/terms-of-service/