Quelles données ne doivent jamais quitter l'entreprise, et comment en décider

Une entreprise interdit d’envoyer la moindre donnée interne à des services d’IA externes. Les salariés continuent pourtant à les utiliser, sur des comptes personnels, parce que la règle bloque le résumé d’un communiqué de presse public aussi fermement que le fichier de paie. Une autre entreprise autorise tout, et quelqu’un colle un contrat client, prix compris, dans un assistant grand public pour en reformuler le texte.

Les deux politiques échouent pour la même raison. Elles ont été écrites à propos des outils, pas des données. « Pouvons-nous utiliser le modèle X ? » n’a pas de bonne réponse. « Ce type de données peut-il être confié à un sous-traitant hors de notre contrôle, à ces conditions ? » en a une, et on peut y répondre une fois par type de données plutôt qu’une fois par demande.

« L’entreprise » désigne ici, par raccourci, l’infrastructure qu’elle contrôle : ses propres serveurs, ou du matériel loué dont personne d’autre ne détient les clés.

Où les politiques de données échouent

Une seule règle pour tout. Trop stricte, et les personnes la contournent. Trop souple, et le mal est fait avant que quiconque ne s’en aperçoive. Dans les deux cas, la politique cesse de décrire ce qui se passe réellement.

Une classification que personne ne sait appliquer. Cinq niveaux de confidentialité sont définis dans un PDF. Personne à l’entrepôt ni dans l’équipe commerciale ne sait à quel niveau appartient un bon de livraison, donc tout est traité au niveau le plus commode du jour.

L’oubli des données dérivées. Les prompts, les journaux, les résumés, les index de recherche et les embeddings portent tous le contenu dont ils sont issus. Un index de recherche sur des contrats doit être traité comme les contrats eux-mêmes.

Des conditions supposées. Qu’un fournisseur puisse conserver ce qu’il reçoit, et s’en servir pour l’entraînement, dépend du produit et du contrat que vous avez souscrits, pas de la marque. Lisez-les.

Les données personnelles traitées comme une catégorie de plus. Au titre du RGPD, confier des données personnelles à un sous-traitant externe exige un accord de traitement, et les transférer hors de l’Espace économique européen exige un mécanisme de transfert, comme une décision d’adéquation ou des clauses contractuelles types. Cela doit être réglé avant l’envoi de la première requête, pas après.

L’oubli de ce que protège le secret. Selon les règles européennes sur le secret des affaires, une information est protégée notamment parce que son détenteur a pris des mesures raisonnables pour la garder secrète. La coller dans un service que personne ne contrôle peut affaiblir cet argument au moment où il est le plus nécessaire.

Une règle que les personnes peuvent appliquer

Définissez les classes selon ce que coûterait une divulgation, pas selon des étiquettes, et gardez-en peu.

1. Public, ou destiné à l’être. Contenus publiés, textes marketing, documents déposés publiquement. N’importe quel modèle.
2. Interne. Informations opérationnelles courantes : procédures, correspondance générale, notes internes sans détail client ni personnel. Modèles externes, sous un contrat professionnel qui exclut l’entraînement sur vos données et fixe la durée de conservation.
3. Confidentiel. Contrats, prix, marges, listes de clients, données personnelles, projets non annoncés, code source. Uniquement des sous-traitants dont le contrat répond à vos obligations légales (pour les données personnelles, des conditions de traitement et de transfert en bonne et due forme), ou des modèles que vous exploitez vous-même.
4. Ne sort jamais. Données dont la divulgation serait grave et irréversible : secrets d’affaires précis, identifiants et clés, catégories particulières de données personnelles que vous n’avez aucune raison de partager, détails de votre propre sécurité. Traitées uniquement sur une infrastructure que vous contrôlez, par des modèles que vous exploitez, chaque accès étant journalisé.

Rattachez ensuite la classe au type d’objet, pas aux fichiers un par un. Si le modèle de l’entreprise sait qu’une donnée est un salaire, un prix contractuel ou une réclamation client, la décision de routage peut être prise automatiquement chaque fois qu’un agent y touche, au lieu de compter sur chacun pour se souvenir de la politique.

C’est ainsi que Hurukan est conçu. La couche Super Intelligence confie chaque tâche à un modèle autorisé pour les données concernées, y compris des modèles locaux lorsque les données ne doivent pas sortir. La couche Sécurité et souveraineté applique les droits côté serveur et journalise chaque accès. Les deux sont en construction. L’argument plus large en faveur d’un contrôle conçu dès l’origine plutôt qu’acheté figure dans la souveraineté est un choix d’architecture, et l’aspect pratique de l’exploitation de vos propres modèles dans petits modèles sur votre propre matériel.

Un test à faire dès aujourd’hui

Listez les vingt types d’objets que votre entreprise manipule le plus : client, commande, facture, liste de prix, salarié, contrat, plan, ticket de support, etc. En face de chacun, indiquez sa classe, de un à quatre, et une raison en une phrase.

Découvrez ensuite quels outils d’IA les personnes utilisent réellement. Demandez-leur, ne supposez pas. Pour chaque outil, notez quelles classes de données y parviennent et à quelles conditions contractuelles.

Il en sort deux listes. Chaque objet de classe trois ou quatre qui atteint un outil sans conditions adaptées figure sur votre liste de priorités du mois. Chaque objet de classe un bloqué hors d’un outil utile est la raison pour laquelle les personnes contournent votre politique, et corriger cela est ce qui rend le reste de la politique crédible.