Données sensibles

Pour ce guide, les données sensibles sont un terme pratique pour l'information qui peut causer des dommages à la vie privée, à la sécurité, à l'entreprise ou personnelle si elle est exposée, mal utilisée ou partagée sans les contrôles appropriés.

Les données sensibles sont plus larges que l'information personnellement identifiable. Elles peuvent inclure des données personnelles, des identifiants, des dossiers financiers, des informations de santé, des détails d'emploi, des documents commerciaux confidentiels, des communications privées, des dossiers clients, du code propriétaire, des résultats de sécurité, et des détails des systèmes internes.

La signification légale exacte des données sensibles varie selon la juridiction, la politique, le secteur et le contexte. Cet article n'est pas un conseil juridique. Il donne une perspective pratique pour la sécurité dans l'utilisation de l'IA : avant de coller, de télécharger, de récupérer ou de générer autour d'informations, demandez-vous si l'exposition pourrait nuire à une personne, un client, un employeur, un partenaire, un produit ou un système.

Les outils d'IA rendent le partage de données plus informel. Un utilisateur peut coller un contrat, un ticket de support, un tableau de bord, un fichier source, une note médicale ou un message privé dans une boîte de discussion en quelques secondes. Cette rapidité est utile, mais elle peut contourner les vérifications normales qui s'appliquent à la même information par courriel, stockage, analyse ou systèmes clients.

Le NIST considère la gestion des risques liés à la confidentialité comme faisant partie de la gestion des risques d'entreprise, en portant une attention particulière à la manière dont les données sur les individus circulent dans les systèmes, les produits et les services [1]. L'IA générative ajoute davantage de questions de workflow : quelles données entrent dans l'outil, qu'est-ce que l'outil peut récupérer, qu'est-ce qui est conservé, qui peut consulter les journaux, et si la sortie pourrait révéler quelque chose de privé ou confidentiel [2].

L'OWASP décrit la divulgation d'informations sensibles comme un risque majeur pour les applications LLM et d'IA générative, y compris les informations personnelles, les détails financiers, les dossiers médicaux, les données commerciales confidentielles, les identifiants de sécurité et les documents juridiques [3]. Ces exemples sont utiles, mais ce n'est pas la liste complète. La bonne habitude est de penser en termes de dommages possibles et d'autorisation.

Le risque lié aux données sensibles peut entrer dans un flux de travail d'IA à plusieurs points. Un utilisateur peut coller des données dans une requête. Un produit peut récupérer des documents privés. Un outil peut appeler une base de données. Les journaux peuvent stocker la requête. La sortie du modèle peut révéler des détails sources. Un collègue peut partager la sortie plus largement que ce que les données initiales permettaient.

La bonne pratique commence par la minimisation des données. Utilisez la plus petite quantité d'informations nécessaire à la tâche. Supprimez les noms, les numéros de compte, les secrets, les adresses exactes, les identifiants internes et les sections inutiles des documents lorsqu'ils ne sont pas nécessaires. Le cadre de confidentialité du NIST décrit la gestion des données de manière cohérente avec la stratégie de risque organisationnelle et identifie explicitement la minimisation des données comme un principe de confidentialité [1].

Les outils approuvés comptent. Les différents produits d'IA ont des termes, des paramètres de conservation, des contrôles d'administrateur, des options d'utilisation d'entraînement, un comportement de journalisation et des accords de traitement des données différents. Les utilisateurs ne devraient pas affirmer que tous les fournisseurs s'entraînent sur les prompts, et ne devraient pas affirmer qu'aucun fournisseur ne le fait jamais. La bonne question est : qu'est-ce que ce produit approuvé, ce plan, ces paramètres et cet accord permettent aujourd'hui ?

Les contrôles d'accès comptent également. Un assistant renforcé par la récupération ne doit pas récupérer des documents qu'un utilisateur n'est pas autorisé à voir. Un assistant de codage ne doit pas révéler des secrets d'un dépôt. Un outil de support ne doit pas révéler un autre dossier client. Le partage selon le besoin de savoir s'applique aux workflows d'IA comme à tout autre logiciel.

Imaginons qu’un manager veuille qu’un assistant IA résume les commentaires des employés. Le fichier brut inclut des noms, des problèmes de performance, des notes sur les congés médicaux, des préoccupations liées aux salaires et des plaintes privées. Coller l'ensemble du fichier dans un outil général est risqué même si l'objectif est inoffensif.

Un meilleur workflow commence par vérifier si l'outil est approuvé pour cette classe de données. Le gestionnaire supprime les noms et les détails inutiles, conserve uniquement les thèmes nécessaires pour le résumé, stocke le fichier original dans le système approuvé et demande un résumé agrégé qui ne révèle pas les histoires individuelles. Même ainsi, une personne devrait examiner la sortie à la recherche de indices de réidentification avant de la partager.

Une idée fausse courante est que la censure garantit la sécurité. La censure peut réduire les risques, mais elle peut échouer si les détails restants identifient une personne, un client, une entreprise, un incident ou un système. La pseudonymisation réduit également l'identification directe, mais elle ne garantit pas l'anonymat lorsqu'il reste d'autres indices.

Une autre idée fausse est que les données sensibles ne signifient que les données personnelles. Une clé d'API privée, une feuille de route de produit non publiée, un contrat client, un rapport de vulnérabilité, un extrait de code propriétaire, une filière de ventes ou une enquête interne peuvent être sensibles même s'ils ne contiennent aucun nom personnel.

Les erreurs liées aux données sensibles peuvent entraîner un préjudice à la vie privée, une compromission de compte, une perte de confiance client, une exposition de propriété intellectuelle, un préjudice à l'emploi, une vérification réglementaire ou un incident de sécurité. Le risque peut provenir de la requête, des documents récupérés, de la sortie générée, des journaux, des plugins, des liens partagés ou des résumés copiés.

La réduction des risques n'est pas une garantie. Les outils approuvés, les contrôles d'accès, la suppression, la pseudonymisation, les paramètres de conservation et les contrôles contractuels aident tous, mais ils ne rendent pas chaque utilisation sûre. Lorsque les données sont très sensibles ou les règles sont floues, le choix le plus sûr peut être d'éviter d'utiliser un outil d'IA jusqu'à ce que le propriétaire approuve le workflow.

Avant d'utiliser des données avec l'IA, demandez-vous : Ce outil est-il approuvé pour ces données ? La tâche nécessite-t-elle les données brutes ? Puis-je supprimer les identifiants ou les détails ? Le résultat pourrait-il révéler une personne, un client, un secret, un contrat, une base de code ou un système ? Qui peut consulter les journaux et les conversations partagées ? Quelles sont les règles de conservation et d'utilisation de la formation ?

Pour un usage en entreprise, appliquez la règle la plus stricte en cas de doute. Utilisez des outils approuvés, un accès avec privilèges minimum, un partage sur nécessité, et une conservation documentée. Ne collez pas d'identifiants, de secrets, de dossiers clients privés ou de documents confidentiels dans des systèmes non approuvés. En cas de doute, demandez à la personne responsable des données ou au responsable de la sécurité/du secret avant de partager.