Cinq idées fausses sur la sécurité de l’IA : Voici où le risque réel existe

Dans tous les déploiements  d’ IA que j’ai examinés dans une gamme d’industries, un modèle se démarque : Les organisations recherchent un risque au mauvais endroit. Leur concentration a tendance à se concentrer sur le modèle lui-même, y compris ses données de formation, ses contrôles de sécurité et son comportement. Mais dans la pratique, c’est rarement là où les choses se décomposent.

Plusieurs des vulnérabilités les plus percutantes émergent dans le système environnant : comment les invites sont construites, comment les données externes sont obtenues et fiables, à quoi le modèle est autorisé à accéder et sous quelles identités il fonctionne. C’est là que les systèmes d’IA sont le plus souvent exposés : entre les composantes, où la gouvernance est généralement la plus faible.

Le problème le plus profond est l’écart entre les attentes et la réalité. Les organisations anticipent un type de défaillance, mais les systèmes de production échouent de manière entièrement différente. Le risque émerge dans cette discordance — dans des hypothèses qui ne survivent pas à l’échelle, à l’autonomie ou à l’intégration.

Les mêmes idées fausses sur la sécurisation de l’IA apparaissent encore et encore. Il vaut la peine d’examiner les cinq qui comptent le plus.

Idée fausse n° 1 : Si le modèle est sécurisé, le système est sécurisé

C’est l’erreur la plus courante que je vois, et c’est facile à faire. Le modèle semble nouveau, donc les équipes se concentrent sur les garde-corps et les tests, puis supposent que le travail est terminé.

Mais ce n’est pas ainsi que ces systèmes échouent. Le modèle n’est qu’un composant d’une infrastructure beaucoup plus grande, et la plupart des défaillances se produisent là où il se connecte aux données, aux outils et à d’autres systèmes. Se concentrer uniquement sur le modèle est comme installer une porte de haute sécurité dans un bâtiment sans murs.

Comment le corriger : Pour sécuriser un système d’IA, pensez à l’environnement complet comme à la surface d’attaque. Mapper l’ensemble du flux de données, des entrées à la récupération et à la mémoire, et des outils aux sorties, et régir les invites, les agents, les magasins vectoriels, les identités et les connecteurs comme actifs détenus, avec des points de contrôle, une responsabilité et une politique clairs, comme vous le feriez pour tout autre système critique.

Conception erronée no 2 : L’injection rapide n’est qu’un autre problème d’entrée

Les équipes de sécurité ayant des antécédents Web recherchent souvent des outils familiers lorsqu’elles voient un nouveau problème. Lorsqu’il s’agit de sécuriser l’IA, cet instinct peut les mener dans la mauvaise direction.

L’injection rapide ressemble à l’injection du langage de requête structuré (SQL), où les systèmes traitent les entrées malveillantes comme une commande, mais se comporte très différemment. Les logiciels traditionnels peuvent appliquer une séparation claire entre les instructions et les données. Les modèles de grande langue ne peuvent pas le faire de manière fiable. Ils traitent les instructions et les données comme le même flux de texte et portent des jugements probabilistes sur lequel.

Le National Cyber Security Centre (NCSC) du Royaume-Uni est clair à ce sujet : L’injection rapide est structurellement différente de l’injection SQL et doit être abordée différemment.

Comment le réparer : Les filtres et les détecteurs aident, mais ils ne résolvent pas le problème par eux-mêmes. Les mesures de protection les plus efficaces sont l’architecture. Restreindre l’accès à l’outil, appliquer le moindre privilège, isoler le contenu non fiable et valider les appels et les paramètres de l’outil de façon déterministe. Exiger une approbation explicite pour les actions sensibles, l’exécution du bac à sable et la surveillance agressive. Ces mesures réduisent à la fois la probabilité et l’impact des compromis, mais elles n’éliminent pas les risques. Si le risque résiduel demeure inacceptable, le cas d’utilisation n’est pas bien adapté à un modèle linguistique de grande envergure.

Conception erronée no 3 : Les résultats de l’IA ne sont que du texte – ils ne créent pas de risque réel

Les premiers déploiements d’IA ont récompensé l’autonomie. Cette charpente a été transportée dans des environnements de production où elle n’appartient pas.

Les résultats de l’IA peuvent sembler un texte inoffensif, mais restent rarement de cette façon. Dès qu’ils sont transmis à un autre système, ils peuvent mener à des actions réelles : envoyer des courriels, interroger des bases de données, exécuter un code ou supprimer un enregistrement. Dans ce contexte, une injection rapide réussie hérite de tout ce que le système peut faire.

C’est là que le risque devient réel : Les capacités du système deviennent les capacités de l’attaquant.

Le projet de sécurité des applications Web ouvertes identifie l’agence excessive comme l’un des risques les plus graves en matière d’IA agentique, tandis que la NCSC note que c’est précisément là que l’injection rapide cesse d’être une nuisance et commence à être une violation.

Comment le réparer : C’est simple : Limitez ce que le système peut faire, appliquez l’accès le moins privilégié et traitez la sortie du modèle comme non fiable jusqu’à ce qu’elle passe la validation déterministe à la limite d’exécution. Cela ne rendra pas un agent compromis inoffensif, mais il réduira considérablement le rayon de sablage.

Conception erronée no 4 : L’utilisation de données externes rend l’IA plus fiable et plus sécurisée

La génération augmentée par récupération (RAG), où les modèles tirent des données externes, améliore la précision, mais ne rend pas les systèmes plus sécurisés. Les recherches publiées par USENIX montrent que la corruption d'un petit nombre d'entrées de la base de connaissances est suffisante pour manipuler de manière fiable les sorties RAG à grande échelle.

Chaque source de données que vous connectez devient un point d’entrée potentiel. Si ces données ne sont pas fiables, désuètes ou manipulées, elles peuvent influencer le rendement du modèle de manière difficile à détecter.

Comment le réparer : Il s’agit à la fois d’un problème de modèle et d’un problème de données et de chaîne d’approvisionnement. Traiter les sources externes comme des dépendances qui nécessitent une gouvernance. Appliquer des contrôles pour la provenance, la validation, l’accès en écriture, le balayage d’ingestion, la version, la séparation des sources et la gestion des changements.

Conception erronée no 5 : L’IA gérée signifie que le fournisseur gère la sécurité

Les gens confondent souvent les services  gérés avec la sécurité externalisée. En réalité, la responsabilité est partagée, mais les responsabilités de sécurité des clients demeurent importantes.

Le fournisseur sécurise le service lui-même. Vous êtes responsable de tout ce qui l’entoure : Quelles données entrent, qui y a accès, ce que le modèle est autorisé à faire et comment les sorties sont utilisées.

Comment le réparer : Soyez explicite sur ce que vous possédez, cartographiez clairement la responsabilité partagée et ne supposez pas qu’elle est sécurisée parce qu’elle est gérée. Passez en revue les contrôles du fournisseur, puis comblez vous-même les lacunes en matière d’identité, de traitement des données, de configuration, de surveillance et d’intégration de la sécurité.

Ce que chaque déploiement devrait avoir en place

La plupart des organisations que j’évalue peuvent énumérer l’IA qu’elles ont déployée. Beaucoup moins de personnes peuvent me dire qui en est propriétaire, quelles données elles touchent, ce dont elles sont capables ou ce qui se passe en cas d’échec. Cela indique un problème de gouvernance.

Les fonds de teint ne sont pas particulièrement compliqués; ils sont appliqués de manière inégale.

Au minimum, vous devriez avoir :

• Une posture de sécurité claire et approuvée par la haute direction et une tolérance au risque définie, alignée sur des cas d’utilisation et des types de données spécifiques
• Un inventaire complet de vos actifs d’IA (modèles, invites, agents, ensembles de données, stockages vectoriels, connecteurs, comptes de service et modules d’extension), avec les propriétaires désignés
• Des modèles de menace qui définissent les limites de confiance et appliquent la politique à des points de contrôle prévisibles
• Solides contrôles d’intégrité dans l’ensemble de votre chaîne d’approvisionnement et de votre pipeline de données, y compris la provenance, la signature, la numérisation, la lignée, la version et, le cas échéant, les registres gérés
• Accès à l’outil le moins privilégié pour les agents, avec surveillance humaine en boucle pour les actions à impact élevé
• Couches de validation sur les sorties avant que quoi que ce soit ne soit exécuté, écrit ou exposé aux utilisateurs
• Évaluation et surveillance continues intégrées à la gestion du changement
• Livres de route des incidents qui sont testés en pratique, y compris les scénarios de confinement, de sécurité-désactivation et de retour en arrière

Mettez-les en place et vous appliquez la même discipline technique que celle attendue de tout système critique.

Le résultat net sur la sécurité de l’IA

La sécurité de l’IA va au-delà de la sécurité des systèmes ou des modèles. Reconnaissez cela tôt, et vous serez en avance sur ceux qui ne l’apprendront qu’après une pause.

Il ne s’agit pas d’un exercice ponctuel. Les systèmes d’IA évoluent constamment et la sécurité doit suivre le rythme. Cela signifie des tests continus, y compris une équipe rouge, qui tente délibérément de briser le système pour comprendre ses faiblesses.

Et si vous ne pouvez pas clairement tenir compte de votre exposition entre les modèles, les intégrations, les pipelines de données et les agents, cette incertitude fait elle-même partie du risque.

Réservez votre évaluation des risques de sécurité de l’IA de NTT DATA dès aujourd’hui et obtenez une image claire de l’emplacement des risques dans votre pile d’IA.