IA et confidentialité : quelles données ne pas envoyer à un modèle

Un assistant d'IA peut recevoir en quelques secondes un contrat, un ticket client, un extrait de code ou une liste de salariés. La facilité du geste masque trois questions : la personne est-elle autorisée à transmettre ces données, où seront-elles traitées et combien de temps resteront-elles disponibles ?

Le périmètre avant l'outil

La classification doit être comprise par les équipes. Secret d'affaires, données personnelles, identifiants, informations de santé, code non publié et dossiers clients ne demandent pas tous la même décision. Une règle utile associe chaque classe à des outils autorisés, des transformations possibles et un responsable capable de trancher un cas nouveau.

Commencez par une unité que l'équipe sait nommer : un service, un processus, une classe de données ou un chemin d'accès. Associez-lui un propriétaire, une dépendance métier et une conséquence observable. Cette discipline évite les programmes trop larges où chaque équipe attend qu'une autre commence.

Les contrôles qui changent la situation

Interdire les secrets et identifiants dans les prompts. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Lister les outils d'IA autorisés avec leur configuration. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Désactiver l'entraînement sur les données lorsque le contrat le permet. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Limiter la conservation et les journaux accessibles. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.
Prévoir une validation humaine avant réutilisation. Vérifiez le responsable, la fréquence et la preuve produite avant de considérer ce contrôle comme actif.

Un contrôle n'est pas une intention. Il existe lorsque sa portée est connue, qu'une personne peut montrer sa configuration et qu'un test révèle son échec. Si l'une de ces conditions manque, classez-le comme chantier en cours avec une date de reprise.

Ce que disent les sources primaires

Le point de référence est IA et conformité au RGPD . La CNIL relie le développement d'un système d'IA à la finalité, à la base légale, à la minimisation, à l'information des personnes, aux durées de conservation et à la sécurité des données.

Pour vérifier le cadre, consultez AI Risk Management Framework . Le cadre propose quatre fonctions complémentaires, gouverner, cartographier, mesurer et gérer, afin de traiter les risques d'un système d'IA dans son contexte d'usage.

La méthode peut être rapprochée de OWASP Top 10 for LLM Applications . Le projet décrit notamment l'injection de consignes, la divulgation d'informations sensibles, les dépendances, la sortie non maîtrisée et les excès d'autonomie dans les applications fondées sur des modèles de langage.

Ces références donnent un cadre commun, pas une réponse automatique au cas particulier. Reprenez les termes applicables à votre système et indiquez ce qui reste à confirmer. Une source peut soutenir plusieurs décisions sans être répétée à chaque phrase.

Un scénario pour éprouver la méthode

Une équipe commerciale colle un compte rendu client dans un assistant public afin de préparer un courriel. La politique générale disait seulement « ne partagez rien de sensible ». Après l'incident, l'entreprise fournit un espace contractuel autorisé, un exemple anonymisé et une règle simple sur les dossiers clients, puis contrôle la configuration.

Le scénario sert à tester l'enchaînement des décisions. Changez une hypothèse, comme l'absence d'un responsable ou l'indisponibilité d'un fournisseur, puis observez si le plan garde un chemin praticable. Un dispositif robuste ne dépend pas d'une seule personne ni d'une seule console.

Le plan de travail en cinq passages

Observer dix usages réels plutôt que dix usages théoriques. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Classer les données rencontrées. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Vérifier contrat, localisation et sous-traitants. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Créer des exemples de prompt acceptables et refusés. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.
Mettre en place un canal de question rapide. Conservez le résultat, l'écart découvert et la décision suivante dans le dossier du service.

Chaque passage doit rester assez petit pour être repris. La progression vient de la fermeture des écarts, pas du nombre de réunions. Lorsque le test contredit la documentation, corrigez d'abord l'état réel, puis la procédure qui devra le reproduire.

Les preuves à conserver

Registre des outils
Exemples de données par classe
Contrat et paramètres de conservation
Décision du responsable de traitement
Journal des exceptions

Une preuve utile est datée, liée à un périmètre et compréhensible par une personne qui n'a pas participé au projet. Évitez les captures isolées sans contexte. Préférez un rapport court qui nomme la commande, le résultat attendu, l'écart et l'action décidée.

Les pièges qui affaiblissent le programme

Croire qu'un prénom retiré suffit à anonymiser. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Autoriser un outil sans vérifier sa configuration. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Rédiger une interdiction impossible à appliquer. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Oublier les données présentes dans les pièces jointes. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.
Réutiliser une sortie contenant un secret. Ce raccourci déplace le risque sans rendre la décision plus vérifiable.

Ces pièges viennent souvent d'une volonté d'aller vite. Leur antidote est un retour au service réel, à la personne qui en dépend et au test que l'on peut rejouer. Une décision prudente peut être temporaire, à condition que sa date de réexamen soit explicite.

La prochaine décision utile

Le contrôle le plus efficace intervient avant le copier-coller. L'utilisateur doit reconnaître la donnée, connaître l'espace autorisé et obtenir une réponse rapide lorsqu'il doute. La formation, le contrat et la configuration technique doivent raconter la même règle.

Écrivez la décision avec son responsable, sa date et la condition qui permettra de la fermer. Le sujet devient alors pilotable : l'entreprise sait ce qu'elle protège, ce qu'elle ignore encore et comment vérifier la prochaine étape.