Quand une entreprise évalue une solution d’IA, la question de la confidentialité arrive vite. Et la réponse, presque toujours, est la même : un engagement contractuel de non-entraînement, doublé d’un hébergement en Europe et d’un chiffrement. C’est utile. Mais ça ne répond pas à la vraie question que se pose un RSSI : est-ce que mes données quittent mon périmètre, oui ou non ?
Conforme au RGPD ne veut pas dire « la donnée ne part pas »
C’est la confusion la plus répandue. Une solution peut être parfaitement conforme au RGPD et envoyer vos données réelles à un fournisseur d’IA tiers. La conformité encadre comment la donnée est traitée (base légale, durée, droits des personnes). Elle ne garantit pas que la donnée reste chez vous.
Un engagement de non-entraînement relève de la même logique : c’est une promesse sur l’usage que le fournisseur fait de vos données une fois qu’il les a reçues. Le mot important, c’est « reçues ». La donnée est sortie de votre serveur. Vous ne pouvez ni le vérifier, ni le défaire.
La bonne question n'est pas « le fournisseur s'engage-t-il à bien se comporter ? » mais « la donnée réelle a-t-elle quitté mon serveur ? ». La première dépend de la confiance. La seconde se prouve.
L’approche par anonymisation locale
Il existe une autre voie : faire travailler l’IA sans jamais lui envoyer le réel. Concrètement, avant tout appel à un modèle (cloud ou local), les identifiants sensibles (noms, adresses, IBAN, numéros de sécurité sociale, identifiants clients) sont détectés et remplacés en local par des codes. Le modèle reçoit un texte où « Sophie Martin » est devenu un code, « FR76 1234… » un autre. Il raisonne sur les codes. La réponse revient, et elle est reconstruite en local avec les vraies valeurs.
Le modèle n’a jamais vu qui était concerné. Et surtout : chaque envoi est journalisé. Vous produisez vous-même le rapport de ce qui est sorti, à montrer à votre DPO, sans avoir à croire qui que ce soit sur parole.
Cette mécanique a ses limites, et il faut être honnête : aucune détection automatique n’est parfaite à 100 %. C’est pourquoi une bonne implémentation combine plusieurs couches (formats connus comme l’IBAN ou le numéro de sécurité sociale, reconnaissance d’entités, listes propres à l’entreprise) et adopte un principe de fail-closed : en cas de doute, on ne laisse pas sortir, on garde en local ou on demande à un humain. La sécurité tient par du code déterministe et un filet humain, pas par le bon vouloir du modèle.
Contrat ou preuve : la différence en deux lignes
- Engagement contractuel : la donnée part, un papier encadre son usage, vous faites confiance, vous ne pouvez pas vérifier.
- Preuve technique : le réel ne part pas, le modèle ne voit que des codes, chaque envoi est tracé, vous produisez le rapport vous-même.
Les deux ne s’excluent pas : on peut très bien avoir un contrat solide et une anonymisation locale. Mais si vous deviez n’en garder qu’un, lequel rassure vraiment un régulateur ou un client qui vous interdit d’exposer ses données ? Celui qui se prouve.
Pour aller plus loin
C’est exactement la philosophie de CLEVYA. Vous pouvez voir le détail des couches de sécurité sur la page Sécurité, le fonctionnement du composant qui se place devant vos appels IA sur la page Audit de clé API, et la lecture conformité sur la page RGPD & souveraineté. Vous devez trancher cette question chez vous, entre contrat et preuve ? Parlons-en.