L'IA générative a changé la nature des pertes de données au sein d'une entreprise. Un employé n'a plus besoin de téléverser un fichier de calcul vers un site de partage de fichiers inconnu pour créer un risque. Il peut coller un dossier client, un extrait de code source, une clause contractuelle ou une prévision financière interne dans un assistant d'IA simplement parce qu'il souhaite de l'aide pour terminer une tâche légitime.
C'est là que la prévention des pertes de données par l'IA devient utile. La Data Loss Prevention (DLP) regroupe l'ensemble des contrôles servant à repérer les renseignements sensibles et à réduire le risque qu'ils soient partagés, téléversés, copiés ou transmis là où ils ne devraient pas aller. Lorsque les employés utilisent l'IA générative, la DLP doit tenir compte des invites, des fichiers téléversés, de l'activité dans le navigateur, des applications connectées et parfois même des réponses du modèle.
L'objectif n'est pas d'empêcher les employés d'utiliser l'IA. Les équipes de sécurité ont besoin d'un moyen de distinguer le travail ordinaire des situations où le partage de données crée un risque inutile.
Commencez par les données, pas par l'outil d'IA
Les équipes de sécurité peuvent facilement se concentrer sur les applications d'IA utilisées par les employés. Cette visibilité compte, mais elle ne répond pas à la question la plus importante : quelles informations quittent réellement l'organisation?
Un programme de DLP efficace pour l'IA commence par définir les données qui doivent être protégées. Cela peut inclure les renseignements personnels identifiables, les dossiers clients, les données de paiement, les renseignements sur les employés, le code source, les identifiants, les documents juridiques, la propriété intellectuelle ou les plans d'affaires confidentiels.
OWASP inclut les renseignements personnels, les détails financiers, les dossiers de santé, les identifiants de sécurité, les documents juridiques et les données commerciales confidentielles parmi les types de renseignements sensibles susceptibles d'être exposés par les systèmes fondés sur les grands modèles de langage. Il recommande des contrôles tels que la désinfection des données, la validation des entrées, les contrôles d'accès et des restrictions sur les sources de données accessibles aux systèmes d'IA.
Une fois ces catégories clarifiées, les équipes de sécurité peuvent décider de ce qui doit être bloqué, de ce qui doit déclencher un avertissement et de ce qui peut être autorisé lorsque des mesures de protection appropriées sont en place.
Examinez les façons dont les informations entrent dans les systèmes d'IA
Taper directement dans un robot conversationnel n'est qu'une voie parmi d'autres.
Les employés peuvent téléverser des PDF, des fichiers de calcul, des captures d'écran, des transcriptions de réunions, des fichiers sources ou des dossiers entiers. Des fonctions d'IA peuvent aussi être intégrées dans les navigateurs, les suites bureautiques, les plateformes de soutien à la clientèle, les outils de programmation et d'autres logiciels que les employés utilisent déjà.
C'est important, car une politique axée uniquement sur le copier-coller de texte peut laisser de grandes lacunes. Les équipes de sécurité devraient cartographier les principales façons dont les employés peuvent envoyer des informations de l'entreprise vers des services d'IA et déterminer lesquelles de ces voies sont visibles par les contrôles existants.
Le Generative AI Profile du NIST considère la confidentialité des données et la sécurité de l'information comme des risques à prendre en compte dans l'ensemble de l'utilisation des systèmes d'IA générative. Le cadre encourage également les organisations à documenter les usages prévus, les utilisateurs, les sources de données et le contexte dans lequel un système d'IA fonctionnera.
Pour une équipe de sécurité, cela se traduit par un inventaire concret : quels outils d'IA sont approuvés, lesquels sont simplement utilisés, quels types d'informations les employés manipulent et comment ces informations peuvent atteindre chaque outil.
Tout bloquer est généralement une mauvaise stratégie de DLP
Une règle de DLP qui bloque chaque invite contenant un nom ou un chiffre peut sembler sécuritaire, mais elle peut vite devenir inutilisable. Les employés rencontrent des noms, des références de comptes, des dates et d'autres données courantes dans leur travail quotidien. Si le système interrompt constamment des activités inoffensives, les gens seront plus enclins à ignorer les avertissements ou à chercher un autre moyen d'accomplir la tâche.
Les contrôles devraient plutôt refléter le contexte et la sensibilité.
Une invite contenant le nom d'un dirigeant public diffère d'une invite contenant le nom d'un client combiné à un numéro de compte et à un historique de transactions. Un court exemple de code diffère d'un dépôt propriétaire complet. Un communiqué de presse public diffère d'un plan d'acquisition non annoncé.
C'est ici que la classification devient particulièrement importante. Les équipes de sécurité devraient réfléchir aux combinaisons de données, de destination, d'utilisateur, d'action et de contexte d'affaires plutôt que de se fier à une simple correspondance de mots-clés.
Décidez quand avertir, caviarder ou bloquer
Toutes les actions à risque n'exigent pas la même réponse.
Un avertissement peut bien fonctionner lorsqu'un employé ne réalise peut-être pas qu'une invite contient des renseignements sensibles. Le caviardage peut être utile lorsque la tâche peut tout de même être accomplie après avoir retiré des éléments comme des noms, des adresses courriel, des identifiants ou des identifiants d'accès. Le blocage convient mieux lorsque l'information est hautement sensible ou que la destination n'est pas approuvée.
Par exemple, imaginez qu'un employé colle un billet de soutien dans un outil d'IA et que le billet contient l'adresse courriel, le numéro de téléphone et l'identifiant de compte d'un client. Plutôt que de bloquer la tâche entière, un contrôle pourrait repérer ces champs et permettre à l'employé de continuer après les avoir retirés.
La meilleure réponse dépend de la tolérance au risque de l'organisation, de ses obligations réglementaires et de la finalité réelle du cas d'utilisation de l'IA.
Mesurez si les contrôles apportent une réelle valeur
La DLP pour l'IA devrait produire des informations utiles pour l'équipe de sécurité, et non seulement davantage d'alertes.
Suivez quels services d'IA les employés utilisent, quelles catégories de données sensibles sont détectées, où surviennent le plus souvent les violations, à quelle fréquence les utilisateurs passent outre les avertissements et quelles équipes rencontrent de façon répétée le même problème de politique. Ces tendances peuvent révéler où les employés ont besoin de meilleures directives ou là où un flux de travail d'IA approuvé serait plus sûr que des exceptions répétées.
Le NIST décrit la gestion des risques liés à l'IA comme une activité continue plutôt qu'un examen ponctuel. Cette approche est particulièrement pertinente pour l'IA générative, car les outils, les intégrations, le comportement des employés et les contrôles disponibles ne cessent d'évoluer.
Un programme pratique de prévention des pertes de données par l'IA combine donc visibilité, classification des données, application proportionnée et sensibilisation des employés. Les équipes de sécurité n'ont pas besoin d'inspecter chaque invite inoffensive. Elles ont besoin de suffisamment de contexte pour repérer les moments où des renseignements sensibles sont sur le point de franchir une frontière que l'organisation n'avait pas prévue.
La raison pour laquelle l'application doit se faire avant la soumission est simple : une fois qu'une invite atteint un service d'IA, elle ne peut plus être rappelée. Un avertissement qui se déclenche après l'envoi du dossier client est le constat d'un incident, pas un contrôle. C'est le principe sur lequel repose Sanitized AI. L'outil détecte les renseignements sensibles dans une invite et les caviarde avant que la soumission ne quitte les mains de l'employé, de sorte que la tâche est tout de même accomplie sans que le numéro de compte, l'identifiant d'accès ou la clause contractuelle ne franchisse une frontière que l'organisation n'a jamais voulu franchir.
Ce trimestre, choisissez un flux de travail d'IA à fort volume sur lequel vos équipes s'appuient déjà, comme des agents de soutien qui résument des billets ou des ingénieurs qui collent du code, et cartographiez précisément les catégories de données qui y circulent et là où vos contrôles existants peuvent les voir. Ce seul inventaire vous indiquera si vous avez besoin de meilleures directives, d'un flux de travail approuvé ou d'une application qui agit avant l'envoi de l'invite. Si vous souhaitez voir comment le caviardage avant soumission fonctionne face à vos propres scénarios, demandez une démonstration.