Sécurité de l’IA en entreprise :
ce que devient votre donnée

Sécurité de l’IA : les cinq risques réels

1. La fuite par l’usage courant

C’est de loin le plus fréquent, et il n’a rien de spectaculaire : un salarié colle un fichier de prospects, une grille tarifaire ou un contrat dans un outil grand public pour gagner du temps. L’information est sortie de l’entreprise, souvent sans que personne ne s’en aperçoive. Aucun pare-feu ne traite ce risque - seule compte la règle de ce qui a le droit de sortir, et l’existence d’un outil interne qui rende la manœuvre inutile.

2. L’entraînement sur vos données

Certains services grand public se réservent le droit d’utiliser ce que vous leur soumettez pour améliorer leurs modèles. Ce n’est pas une pratique universelle et les conditions varient d’un fournisseur à l’autre : c’est une clause à lire, pas une fatalité à subir.

3. Le lieu de traitement

Une donnée traitée hors de l’Union européenne relève d’un cadre juridique différent, avec des obligations propres à respecter. Le point à vérifier n’est pas seulement où le prestataire a son siège, mais où la donnée est effectivement traitée - et par quels sous-traitants.

4. La réponse plausible et fausse

Un système d’IA peut produire une réponse crédible et inexacte. Le risque n’est pas théorique quand la réponse part directement à un client : un devis chiffré sur un tarif inventé engage l’entreprise. La parade est de conception : information absente = on remonte, on ne devine pas.

5. L’accès trop large

Un agent branché sur l’ensemble d’une messagerie ou d’un espace de stockage voit tout, y compris ce qui ne le concerne pas. Le bon réglage est le plus étroit qui permette encore de faire le travail.

Ce que le RGPD implique concrètement

Le RGPD ne parle pas d’intelligence artificielle : il parle de traitement de données personnelles. Dès qu’un agent lit des mails de clients, des dossiers ou des coordonnées, vous en faites un traitement - et les mêmes obligations qu’ailleurs s’appliquent.

• Une finalité et une base légale. Pourquoi ces données sont-elles traitées, et à quel titre.
• La minimisation. On ne donne accès qu’à ce qui est nécessaire à la tâche. C’est aussi une bonne pratique de sécurité, indépendamment du droit.
• L’encadrement du sous-traitant. Un prestataire qui traite des données pour votre compte doit être encadré par un contrat qui précise ce qu’il en fait.
• Le registre des traitements et l’information des personnes. Vos clients et vos salariés doivent savoir que ce traitement existe.
• Les transferts hors UE, s’il y en a, obéissent à des règles spécifiques.

Les huit questions à poser à tout prestataire

À poser avant de signer, à n’importe quel fournisseur - nous compris. Une réponse évasive à l’une d’elles est en soi une réponse.

1. Où mes données sont-elles hébergées et traitées ? Demandez le pays, pas la nationalité de l’entreprise.
2. Quelles données sortent effectivement de chez moi, et lesquelles restent ? La question la plus importante de la liste, et celle qui distingue les architectures sérieuses.
3. Mes données servent-elles à entraîner un modèle ? Exigez la réponse par écrit, dans le contrat.
4. Quels sous-traitants interviennent ? Un prestataire s’appuie presque toujours sur des tiers. La liste doit être communicable.
5. Que se passe-t-il si je m’en vais ? Récupération de vos données, suppression des copies, délais.
6. Quels accès l’agent a-t-il exactement, et qui peut les modifier ?
7. Que fait le système quand il ne sait pas ? S’il produit une réponse plutôt que de remonter le cas, le risque d’erreur est structurel.
8. Puis-je vérifier ce qui a été fait ? Sans trace des actions, aucun contrôle n’est possible - ni le vôtre, ni celui d’un auditeur.

Les réponses de SoclAi

Nos réponses aux mêmes questions, pour que vous puissiez les comparer à celles des autres.

Le deuxième point est le cœur de notre approche technique, et celui sur lequel portent nos deux brevets déposés : plutôt que de demander à un fournisseur de modèle de ne pas regarder vos données, nous faisons en sorte qu’il ne les reçoive pas. Un engagement contractuel dit ce qu’un fournisseur s’interdit de faire de vos données. Une architecture qui ne les lui transmet pas ne lui laisse rien à s’interdire.

Les modalités complètes figurent dans notre politique de confidentialité.

La règle interne à écrire avant tout déploiement

La meilleure architecture ne protège pas d’un usage non encadré des outils grand public. Une note d’une page suffit, et elle devrait exister même sans projet d’IA :

• Ce qui ne sort jamais de l’entreprise : fichiers clients, grilles tarifaires, contrats, données de santé, informations RH.
• Les outils autorisés, et pour quels usages.
• Qui demander en cas de doute - une personne nommée, pas un service.
• Quoi faire si ça arrive quand même. Une règle qui ne prévoit pas l’erreur pousse à la dissimuler.

Si vous n’avez pas le temps d’écrire cette note, la version courte tient en trois phrases et vaut mieux que rien :

Aucun fichier client, grille tarifaire, contrat, donnée de santé ou information RH ne doit être collé dans un outil d’IA grand public. En cas de doute, demandez à [nom de la personne]. Si c’est déjà arrivé, dites-le : on corrige, on ne sanctionne pas.

Cette note est plus efficace qu’un outil de blocage : les gens contournent ce qui les empêche de travailler. Donnez-leur un outil interne qui fait le travail, et la question de l’outil grand public ne se pose plus.