Tokeniser avant que le modèle ne le voit : comment nous exécutons GenAI sur des données sensibles

Pseudonymiser d'abord, raisonner ensuite.

La raison la plus commune pour laquelle un projet GenAI dans une organisation réglementée n'atteint jamais la production n'est pas la précision. Ce n'est pas le coût. Ce n'est pas l'infrastructure. 🚫

C'est que personne ne pouvait se sentir à l'aise en envoyant les données à un modèle.

Et la conversation se bloque presque toujours au mauvais endroit. Elle devient un débat sur le fournisseur de modèles. Où il s'exécute. Ce qu'il conserve. Ce que dit le contrat. Si la région est bonne. Toutes des questions légitimes, et chacune d'elles est une tentative de rendre acceptable l'envoi de données sensibles.

Le déverrouillage plus simple est d'arrêter de l'envoyer. 🔄

Pseudonymiser d'abord, raisonner ensuite. Dans la plupart des cas d'usage, le modèle n'a pas du tout besoin des vrais identifiants. Il a besoin de la structure, du langage et des relations, et ceux-ci survivent à la tokenisation intacts.

🧠 Pourquoi cela fonctionne mieux que prévu

L'intuition qui bloque cela est qu'un modèle a besoin de données réelles pour être utile. Pour une grande part des cas d'usage d'entreprise, cela s'avère faux, et il vaut la peine d'être précis sur les raisons.

Considérez un ticket d'assistance :

« Le client Anna Müller, compte 4471-8823, ne peut pas effectuer de transfert vers l'IBAN DE89..., l'erreur apparaît après 2FA. »

De quoi le modèle a-t-il besoin pour classer, résumer ou rédiger une réponse ? Le mode de défaillance. L'étape du parcours. Le contexte de l'erreur. Le langage.

Le nom et le numéro de compte ne contribuent rien au raisonnement. Remplacez-les par des jetons stables et le modèle fonctionne de manière identique. Nous l'avons mesuré, et l'écart de précision se situe généralement dans la marge d'erreur de l'évaluation elle-même. 📊

Les cas où les valeurs réelles ont vraiment de l'importance sont étroits et identifiables :

• l'identifiant lui-même doit apparaître dans la sortie
• une recherche externe sur la valeur brute est requise
• l'analyse porte spécifiquement sur la structure de l'identifiant

Ces cas existent. Ils sont une minorité. Et savoir lesquels en font partie est la majeure partie du travail. 🔍

🏗️ Où la tokenisation doit avoir lieu

C'est là que les implémentations s'avèrent défaillantes, et l'échec est presque toujours le même.

Tokeniser à l'ingestion, pas au moment de l'appel du modèle. ⚡

La tokenisation tardive semble suffisante et ne l'est pas, car au moment où les données atteignent l'appel du modèle, elles ont généralement déjà été écrites quelque part. Journaux d'application. Un cache. Une file d'attente de messages. Une sauvegarde nocturne. Une trace de surveillance avec corps de requête activée par un ingénieur bien intentionné lors d'un incident en mars. 🗄️

Chacune de celles-ci est une copie d'une valeur réglementée reposant dans un système qui n'a jamais été évalué pour la contenir. Tokeniser à la limite du modèle protège l'appel du modèle et laisse les copies en place, et ce sont les copies qui apparaissent dans le rapport d'incident.

Bien faire cela en pratique :

• Tokeniser à la périphérie de la plate-forme, avant la persistance et avant la journalisation. 🚪
• Conservez la cartographie dans un coffre-fort unique avec ses propres contrôles d'accès, sa propre piste d'audit et son propre propriétaire. Le coffre-fort est maintenant le joyau de la couronne, et l'ensemble de la posture de sécurité s'y concentre. C'est une caractéristique, car le risque concentré est un risque gérable.
• Préservez les propriétés dont les systèmes en aval ont besoin : intégrité référentielle, format, cardinalité. 🔗 Un jeton qui casse une jointure sera contourné, et chaque contournement que nous avons trouvé dans la pratique a réintroduit la valeur réelle.
• Rendez la ré-identification une opération distincte, autorisée et journalisée. Pas une fonction que n'importe qui peut appeler. Une étape régie avec un objectif attaché.

🔒 Ce que cela fait à votre position de conformité

La raison pour laquelle nous promouvons si fortement ce modèle est qu'il change la forme de l'argument plutôt que de le renforcer simplement.

Le périmètre se réduit. 📉 Les systèmes qui ne conservent que des jetons sont largement en dehors du champ des contrôles que vous auriez autrement dû appliquer, documenter et auditer. Ce n'est pas une faille. C'est l'effet prévu de la pseudonymisation comme mesure technique.

La conversation avec le DPO change de caractère. 📝 « Le modèle raisonne sur des structures pseudonymisées, et la ré-identification est une étape séparée et contrôlée et journalisée » est une phrase avec laquelle un responsable de la protection des données s'engagera. « Nous envoyons des enregistrements à un modèle, mais le contrat est bon » est une phrase contre laquelle il repoussera, et à juste titre.

Le choix du fournisseur cesse d'être existentiel. 🌍 Une fois que la charge utile ne porte aucun identifiant, la question du déploiement devient un compromis d'ingénierie concernant la latence, le coût et la souveraineté plutôt qu'un bloqueur réglementaire.

Les options sur site et souveraines deviennent plus faciles, pas plus difficiles. 🇪🇺 Combiner la tokenisation avec le traitement sur site ou souverain vous donne deux contrôles indépendants plutôt qu'un, et les contrôles indépendants sont ce qui survit à un examen de surveillance.

⚠️ Où cela devient difficile, et nous préférerions le dire

Les identifiants structurés sont simples. Le texte libre ne l'est pas.

Un corps de ticket d'assistance, une note clinique ou un fil de discussion contient des noms, des références de compte et des adresses en prose, et les détecter de manière fiable est un véritable problème d'ingénierie. Des approches existent. Reconnaissance d'entité avec révision humaine sur faible confiance. Restriction des champs de texte libre à un pipeline plus étroit. Resserrement de ce qui est capturé en premier lieu. Aucun d'eux n'est gratuit.

Nous le soulevons plutôt tôt que tard, car un programme de tokenisation qui exclut silencieusement le texte libre n'a pas résolu le problème qu'il prétendait résoudre. 🔍

🧪 Quatre questions pour votre propre programme GenAI

1. Le modèle a-t-il vraiment besoin des valeurs réelles, ou simplement d'une référence cohérente ? Quelqu'un a-t-il posé cette question par cas d'usage ?
2. Où la tokenisation se produit-elle : à l'ingestion, ou juste avant l'appel du modèle ?
3. La ré-identification est-elle une opération régie et journalisée, ou une fonction que n'importe qui peut invoquer ?
4. Quel est votre plan pour les champs de texte libre, et le programme dépend-il de ce plan qui fonctionne ?

📅 Parlez-nous

Réservez une révision de 30 minutes. Nous vous dirons lesquels de vos cas d'usage peuvent s'exécuter sur des jetons aujourd'hui et lesquels ne le peuvent vraiment pas.

Confidentialité des données, GenAI et conseil : mejuvante.ai/enquiry-1