IA et données clients : la checklist de conformité concrète

Les conseils sur la conformité IA oscillent entre boilerplate juridique et vague réassurance. Voici la checklist concrète que nous appliquons.

La question que pose tout client sérieux avant un projet IA est la bonne : qu'advient-il de nos données clients. Les réponses qui circulent en ligne se partagent inutilement entre formules juridiques et réassurance vague. Voici la checklist opérationnelle que nous déroulons avant qu'un seul enregistrement ne quitte les systèmes d'un client.

1. Lisez les vraies conditions de traitement du fournisseur

Les offres professionnelles et API des grands fournisseurs n'entraînent pas leurs modèles sur vos données par défaut. Les produits de chat grand public, fréquemment si. La distinction est contractuelle, pas technique : un collaborateur qui colle un contrat client dans un compte personnel constitue un événement matériellement différent du même texte transitant par une API professionnelle. Écrivez la règle et communiquez-la — c'est la fuite la plus courante dans la vraie vie, et c'est un problème de politique interne, pas d'ingénierie.

2. Minimisez avant d'envoyer

• Retirez les identifiants dont le modèle n'a pas besoin. Un classificateur de tickets n'a que rarement besoin d'un nom complet, d'une adresse email ou d'une référence de paiement pour faire son travail.
• Masquez ou pseudonymisez les champs sensibles à la frontière, et réinjectez-les après génération si la réponse en a besoin.
• Envoyez des extraits, pas des bases entières. La récupération doit renvoyer les trois passages pertinents, pas tout le corpus documentaire.

3. Sachez où vont physiquement les données

La région de traitement compte pour les clients du secteur de la santé, de la finance et du secteur public, et de plus en plus pour les services achats des grandes entreprises, quel que soit le secteur. Établissez dans quelles régions votre fournisseur traite les données, si cela est garanti contractuellement, et si un sous-traitant les déplace ailleurs. Ce point détermine ce que votre politique de confidentialité doit divulguer.

4. Fixez la durée de conservation délibérément

La plupart des plateformes IA conservent les journaux de requêtes pendant une période de surveillance des abus, souvent trente jours, et certaines proposent une conservation nulle sur demande. Séparément, votre propre application journalise probablement les prompts et les réponses — y compris ce que l'utilisateur y a collé. Les équipes resserrent régulièrement la rétention côté fournisseur pendant que leurs propres journaux de débogage accumulent discrètement des données clients pendant des années.

5. Couvrez les droits des personnes

Accès, rectification, effacement, opposition : ces droits s'appliquent aux données présentes dans vos systèmes IA comme ailleurs, y compris dans un index vectoriel. Construisez une seule capacité — localiser et supprimer tout ce qui est associé à une personne, index de récupération compris — et la majorité des obligations deviennent satisfiables d'un coup.

• 0 donnée transmise si la tâche ne l'exige pas
• 1 procédure pour localiser et effacer les données d'une personne partout
• 100% actions IA journalisées avec auteur et horodatage

6. Journalisez ce que l'IA fait, pas seulement ce qu'elle dit

Dès qu'un agent effectue des actions — envoyer des emails, mettre à jour des fiches, émettre des remboursements — il vous faut une piste d'audit : ce qui a été demandé, quelles données ont été récupérées, ce que le modèle a renvoyé, ce qui a été exécuté et sous quelle autorité. C'est ce qu'exigeront un auditeur, un assureur ou une réclamation client, et l'ajouter après un incident est douloureux.

7. Décidez de ce que l'IA ne touche jamais

Rédigez une liste explicite. Identifiants de connexion, données de carte bancaire complètes, dossiers médicaux non anonymisés et éléments sous confidentialité stricte en font couramment partie. Une liste d'interdits courte et sans ambiguïté est applicable ; une politique longue et nuancée est ignorée précisément par ceux qu'elle vise.

Le mode de défaillance réaliste n'est pas un modèle qui divulgue vos données. C'est une intégration aux permissions trop larges qui fait quelque chose de faux à grande échelle, sans aucun journal pour l'expliquer.

Vous voulez la même chose pour votre entreprise ? Voir ce que nous faisons.