Luttez contre l’empoisonnement des données avec ces 5 étapes
En matière de cyberattaques, l’empoisonnement des données ne pouvait pas mieux porter son nom. Cela sonne mal, surtout lorsque le monde de l’entreprise considère de plus en plus les données comme l’équivalent numérique d’un métal précieux.
Et c’est logique, car l’empoisonnement des données est effectivement dangereux. Ce terme fait référence à un risque émergent pour l’IA dans lequel un attaquant — externe ou interne — corrompt délibérément les jeux de données d’apprentissage afin d’influencer le fonctionnement ou les résultats du modèle. Cela peut inclure l’ajout de données erronées, la manipulation de données existantes ou la suppression de données correctes.
Si vous développez des produits SaaS pilotés par l’IA — par exemple, une application d’automatisation marketing intégrant un outil LLM — vous devez examiner de près la façon dont vous protégez vos modèles.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Dans cet article, je partage des conseils d’experts sur les stratégies essentielles pour minimiser le risque d’empoisonnement des données dans vos bases d’entraînement IA.
Qu’est-ce que l’empoisonnement des données ?
Un exemple d’empoisonnement des données, fourni par le NIST qui, à l’instar de nombreuses autres organisations soucieuses de la sécurité, porte manifestement attention à cette menace : « [Les attaquants peuvent insérer] de nombreux exemples de langage inapproprié dans des archives de conversations, de sorte qu’un chatbot interprète ces exemples comme un usage suffisamment courant pour les reprendre dans ses propres échanges avec les clients. »
Du coup, votre fidèle chatbot d’assistance client commence à utiliser des grossièretés (ou des mots encore pires) lors des discussions avec de vrais clients humains. Ce n’est probablement pas ce que l’on a en tête lorsque l’on parle d’utiliser l’IA pour stimuler la productivité, l’efficacité ou l’innovation.
Quel que soit le cas d’usage, les CTO qui intègrent de l’IA générative ou d’autres applications à base d’IA dans leurs produits SaaS doivent impérativement protéger leurs données d’entraînement de toute manipulation malveillante — ajout, suppression ou modification susceptible d’affecter la performance du modèle, l’expérience utilisateur, la réputation de la marque, et plus encore.
Par ailleurs, les experts s’accordent généralement à dire que la prévention constitue la meilleure attitude face à l’empoisonnement des données. Il est d’ordinaire plus facile d’empêcher l’incident que d’en atténuer les conséquences.
Comment lutter contre l’empoisonnement des données – 5 principes pour minimiser les risques
1. Connaissez vos données.
Renforcer vos défenses contre l’empoisonnement des données commence par comprendre ce que vous protégez : on ne protège bien que ce que l’on connaît.
« La première étape pour contrer l’empoisonnement des données dans des produits SaaS utilisant l’IA est d’avoir une compréhension claire des données sur lesquelles vous entraînez votre modèle, » explique Ian Ahl, SVP de P0 Labs, le département de recherche sur les menaces de l’éditeur de solutions de sécurité des identités Permiso. « Il est essentiel d’entraîner les modèles sur des données que vous pouvez maîtriser. »
De quel type de données s’agit-il ? Quelle est leur provenance ? Qui y a accès ? Si vous n’avez pas de réponses claires à ce genre de questions, vous êtes probablement plus exposé au risque d’attaque par empoisonnement.
Une solide connaissance de vos données d’apprentissage est également une condition préalable à une bonne gouvernance des données, sujet que nous détaillerons plus loin. Il va donc de soi qu’il doit exister des contrôles sur la manière dont les personnes, les équipes et les processus interagissent avec les données d’entraînement et les utilisent.
« En examinant les données elles-mêmes, vous pouvez instaurer un contrôle plus strict sur les utilisateurs qui les mettent à jour et des garde-fous rigoureux sur la façon dont les clients peuvent y accéder, » indique Ahl. « C’est une supervision combinée des personnes, des processus et des données. »
2. Réexaminez votre stratégie de transformation des données.
Vous devez également réfléchir — et éventuellement repenser — à la façon dont vos données passent de leur source d’origine à vos modèles, autrement dit votre pipeline de données.
« Les décisions que prennent les CTO concernant la stratégie de transformation des données ont un impact direct sur la sécurité de leurs produits SaaS alimentés par l’IA, car elles déterminent à quel point les pipelines de données peuvent être vulnérables à l’empoisonnement, » explique Dave Jenkins, VP Produit et Recherche chez Iterate.ai.
Jenkins précise en particulier que nous sommes en train d’opérer une transition majeure entre l’architecture ETL (Extract, Transform, Load) et l’architecture ELT (Extract, Load, Transform) des pipelines de données. Plusieurs facteurs motivent cette évolution, mais l’un des avantages de la deuxième approche est qu’elle limite davantage le risque de problèmes comme l’empoisonnement des données.
« L’une des raisons est que lorsque la transformation intervient très tôt dans le pipeline, et que le modèle n’est pas encore bien calibré ou que les jeux de données sont incomplets, comme c’est parfois le cas avec ETL, les données problématiques sont intégrées au plus tôt, » explique Jenkins. « Les erreurs et hallucinations peuvent alors se multiplier, et retrouver — et corriger — la source des données corrompues devient quasiment impossible. »
Pour cette raison, Jenkins ajoute qu’il vaut mieux éviter que des applications transforment par elles-mêmes les données avant de les intégrer à un data lake. Le modèle ELT inverse l’ordre des opérations et offre davantage de contrôle ainsi qu’un processus de transformation plus unifié.
« En déplaçant plutôt toutes les transformations dans un environnement d'entrepôt de données comme Snowflake, les CTO et leurs équipes gagnent en visibilité et en contrôle pour développer leurs produits, » affirme Jenkins.
3. Priorisez une bonne gouvernance des données.
La visibilité et le contrôle sont essentiels, mais ils restent incomplets sans des politiques solides et une gouvernance appliquée à vos pipelines et processus de données.
« Bien sûr, réussir cela nécessite aussi une gouvernance claire, » souligne Jenkins. « Les CTO doivent spécifier où les transformations de données par l’IA peuvent avoir lieu. Ils voudront disposer de pistes d’audit, de cadres de validation, de jeux de données de référence pour les tests comparatifs et, idéalement, de bacs à sable pour tester et retester les transformations afin d’identifier toute erreur ou hallucination avant la mise en production. »
Ahl rapporte que la gouvernance doit également inclure les personnes, notamment à travers des politiques claires et des garde-fous quant à qui peut interagir avec les données d’entraînement, quelles données ils peuvent utiliser, et ainsi de suite : « Toute personne pouvant ajouter des fichiers pour entraîner un modèle, qu’il s’agisse d’un utilisateur ou d’une équipe, doit être soumise à des contraintes sur les données qu’elle peut exploiter. »
4. Renforcez votre posture globale de sécurité.
Il est également important de rappeler que l’IA en général élargit encore la surface d’attaque de nombreuses organisations. L’empoisonnement des données n’est qu’une menace potentielle – certes importante. Tout ce qui précède doit donc s’inscrire dans une stratégie de sécurité plus large.
Si vous négligez déjà les fondamentaux de la sécurité comme la gestion des correctifs, l’hygiène des mots de passe, la gestion des identités et le principe du moindre privilège, il va de soi que vos modèles d’IA et vos données d’entraînement seront encore plus vulnérables aux risques.
5. Envisagez l’entraînement de modèles adverses.
Lorsqu’apparaissent de nouvelles menaces comme l’empoisonnement de données, de nouvelles stratégies et outils défensifs voient généralement le jour. C’est le cas maintenant avec l’IA, qui a engendré tout un éventail de nouveaux risques, et pas seulement l’empoisonnement des données. Ceux-ci sont parfois regroupés sous le terme « IA antagoniste », ou utilisation malveillante de l’apprentissage automatique ou d’autres formes d’IA pour attaquer des systèmes d’IA concurrents. L’empoisonnement de données constitue une forme d’IA antagoniste.
Il est possible ici d’inverser la tendance en recourant à l’entraînement adversarial, qui apprend à vos modèles à repérer d’éventuels schémas et anomalies pouvant indiquer un empoisonnement de données ou d’autres formes d’IA antagonistes, puis à agir pour les atténuer.
L’entraînement adversarial continue de s’imposer comme approche clé de la sécurité de l’IA. Par exemple, cet article académique propose un cadre pour atténuer les biais qui auraient pu être acquis lors des collectes de données dans le secteur de la santé, où les conséquences potentielles de l’empoisonnement de données et d’autres attaques sont particulièrement graves. Un autre article propose un cadre d’entraînement adversarial spécifiquement pour se défendre contre l’empoisonnement de données.
Need expert help selecting the right tool?
Et maintenant ?
Si vous intégrez des fonctionnalités d’IA générative ou autres capacités pilotées par l’intelligence artificielle à votre portefeuille SaaS, il est indispensable de garantir l’intégrité, la fiabilité et la sécurité de vos données d’entraînement.
Faute de cela, vous accroissez les risques d’empoisonnement des données et d’autres problèmes – des problèmes qu’il est généralement plus facile de prévenir que de corriger a posteriori.
Avant de partir, abonnez-vous à notre newsletter pour recevoir nos derniers éclairages !
