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. Ils ont 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.

Beaucoup 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.

Conception erronée no 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 la façon dont 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 aux 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 réparer : 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é avec des arrière-plans 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 faire 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 la 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 architecturales. Restreindre l’accès à l’outil, appliquer le privilège le moins élevé, 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 de grande langue.

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 déploiements

précoces de l’IA récompensent l’autonomie. Cet encadrement a été transporté dans des environnements de production où il n’appartient pas.Les résultats d’

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 des codes 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 une agence excessive comme l’un des risques les plus graves de l’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 la corriger : 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 n° 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 les corriger : 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 par 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é Souvent, les

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

Le fournisseur assure 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 les corriger : Soyez explicite sur ce que vous possédez, planifiez 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.

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 fondements ne sont pas particulièrement compliqués; ils sont simplement appliqués de manière inégale.

Au minimum, vous devriez avoir :

• Une posture de sécurité de l’IA claire et approuvée par la direction et un appétit pour les risques définis, alignés 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, magasins vectoriels, connecteurs, comptes de service et plug-ins), avec des 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
• Des contrôles d’intégrité solides sur votre chaîne d’approvisionnement et votre pipeline de données, y compris la provenance, la signature, la numérisation, la lignée, la version et, et, le cas échéant, l’accès géré à l’outil
• de confidentialité pour les agents, avec une surveillance des couches de
• validation
• 
  

à Reconnaissez cela tôt, et vous serez en avance sur ceux qui ne l’apprendront qu’après une pause.

Ce n’est pas 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 l’é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 idée claire de l’endroit où se trouve le risque dans votre pile d’IA.