Aller au contenu
Chapitre 03 · 11 min

Fuite de données et vie privée

Les modèles fuient. Ils divulguent ce que vous avez mis dans le contexte, ils reproduisent parfois ce sur quoi ils ont été entraînés, et ils fuient par l'intermédiaire des tiers auxquels vous envoyez des données. Pour une entreprise européenne soumise au RGPD ou à des règles sectorielles comme les exigences HDS pour la santé, ce ne sont pas des curiosités — ce sont des expositions de conformité. Ce chapitre présente les formes que prend la fuite et comment la contenir.

Tout ce que vous mettez dans le prompt, vous l'avez dit à voix haute dans une pièce que vous ne contrôlez pas.

Fuite de contexte : la plus courante

La fuite la plus fréquente est la plus simple : tout ce que vous mettez dans le prompt peut ressortir du modèle. Les prompts système sont extraits. Les données d'un utilisateur, laissées dans un contexte partagé, remontent dans la réponse d'un autre utilisateur. Des documents confidentiels soumis pour résumé sont cités à quelqu'un qui n'aurait pas dû les voir. Le modèle n'a pas de notion de « cette partie est secrète » — le contexte est le contexte.

Les défenses relèvent de l'hygiène, non de l'ingéniosité : ne mettez jamais dans un contexte des données que l'utilisateur demandeur n'est pas autorisé à voir ; isolez les sessions pour qu'une données d'un utilisateur ne puisse pas contaminer celle d'un autre ; et supposez que votre prompt système est public, parce qu'un utilisateur déterminé finira par l'extraire. Concevez comme si le prompt était lisible par quiconque vous servez.

Extraction de données d'entraînement

Les modèles peuvent mémoriser des fragments de leurs données d'entraînement et, sous le bon prompt, les reproduire — des secrets textuels, des données personnelles, du texte protégé par le droit d'auteur. Cela importe dans deux directions. Si vous utilisez un modèle public, il peut émettre du contenu mémorisé de son jeu de données d'entraînement. Si vous effectuez un ajustement fin d'un modèle sur vos propres données, ce modèle peut divulguer vos données à quiconque l'interroge.

Le problème des tiers

Lorsque vous appelez une API de modèle hébergé, votre prompt quitte votre infrastructure. C'est un événement de traitement de données ayant un poids juridique : où vont les données, qui peut les lire, sont-elles utilisées pour l'entraînement, combien de temps sont-elles conservées, et cela satisfait-il les contrats et réglementations auxquels vous êtes soumis ? « Nous envoyons des dossiers clients à une API de modèle » est une phrase que vos responsables de la confidentialité et de la conformité doivent avoir approuvée.

Des positions pratiques, de la plus au moins grande maîtrise : héberger soi-même un modèle ouvert pour que les données ne quittent jamais les lieux (la meilleure proposition en matière de confidentialité, mais avec plus de coûts opérationnels) ; utiliser un niveau d'API entreprise avec une garantie contractuelle de non-entraînement et de résidence des données ; ou minimiser et caviarder — n'envoyer jamais plus que ce que la tâche exige, et retirer les identificateurs avant l'appel. Le parti pris de SDEN pour l'infrastructure auto-hébergée existe en partie pour cette raison.

La conformité est une contrainte de conception, pas une réflexion a posteriori

Si vous traitez des données personnelles de personnes en Europe, l'IA ne bénéficie d'aucune exemption réglementaire. Le RGPD, l'AI Act et les règles sectorielles (exigences HDS pour la santé, DSP2 pour la finance) s'appliquent tous aux données que vous acheminez par un modèle. Les questions sont les classiques : quelle est la base légale, pouvez-vous honorer une demande de suppression, où les données sont-elles traitées, et pouvez-vous produire une piste d'audit.

  • Résidence des données — pouvez-vous garantir où les données sont traitées et stockées ?
  • Droit à l'effacement — si des données sont dans un modèle ayant subi un ajustement fin, pouvez-vous les supprimer réellement ? (Habituellement non, sans ré-entraînement.)
  • Limitation de la finalité — le fournisseur du modèle est-il autorisé à s'entraîner sur vos données ? Obtenez-le par écrit.
  • Auditabilité — pouvez-vous montrer quelles données sont allées où, pour un régulateur ou un client ?
  • Minimisation — n'envoyez-vous que ce que la tâche requiert, ou l'enregistrement complet parce que c'était plus facile ?

Le contrôle de confidentialité le moins coûteux est le plus ancien : ne pas collecter ni envoyer des données dont vous n'avez pas besoin. Un modèle qui ne reçoit jamais de numéro d'assurance sociale ne peut jamais le divulguer. La minimisation à la frontière surpasse tous les contrôles en aval.

En une ligne chacun

  • La fuite de contexte est le cas courant : tout ce qui se trouve dans le prompt peut en ressortir. Isolez les sessions, autorisez le contexte, supposez que le prompt système est public.
  • Les modèles mémorisent les données d'entraînement ; effectuer un ajustement fin sur des données sensibles les intègre dans les poids et ne constitue pas une frontière de confidentialité.
  • Les API hébergées envoient vos données hors site — contrôlez cela par l'auto-hébergement, des contrats d'entreprise de non-entraînement, ou le caviardage.
  • Le RGPD s'applique toujours ; la minimisation à la frontière est le contrôle le moins coûteux et le plus attendu.
Fuite de données et vie privée · Cours d'IA · SDEN