Les systèmes d'IA ne devraient pas apprendre de vous

De nombreuses entreprises disent : « Nous n'entraînons pas nos modèles sur vos données. » Cela semble précis. Rassurant, même. Mais en pratique, cela omet souvent la partie qui compte vraiment. Car selon la manière dont un système est construit, vos données peuvent toujours influencer son comportement sans jamais être utilisées pour réentraîner explicitement un modèle. Cette influence se manifeste simplement dans des endroits moins évidents. Les embeddings partagés sont mis à jour. Le classement s'améliore globalement. La logique de récupération s'adapte en fonction de l'utilisation agrégée. Rien n'est étiqueté comme « entraînement », mais le comportement évolue toujours en fonction d'entrées qui proviennent d'ailleurs. D'un point de vue technique, c'est là que les choses commencent à diverger. Il existe une différence significative entre les systèmes qui mettent à jour les poids des modèles partagés, les systèmes qui optimisent globalement entre les locataires (tenants) et les systèmes qui maintiennent chaque environnement correctement isolé. Ils peuvent sembler similaires de l'extérieur. Ils ne le sont pas.

La différence entre données et influence

La plupart des conversations sur la sécurité de l'IA tournent encore autour de l'exposition des données. Sont-elles chiffrées ? Qui peut y accéder ? Où sont-elles stockées ? Toutes des questions valides. Mais pas toute l'histoire. Un système peut garder les données techniquement sécurisées et permettre néanmoins à l'influence de circuler de manière beaucoup plus difficile à observer. Si les interactions d'un client affectent les embeddings partagés, modifient le comportement de classement ou façonnent la manière dont la récupération est optimisée globalement, alors un environnement influence un autre. Aucune donnée brute n'a besoin d'être visible pour que cela se produise. Au fil du temps, cela crée un couplage. Le comportement commence à dépendre de signaux qui ne sont pas visibles au sein d'un système donné. Lorsque quelque chose change, il devient difficile d'expliquer pourquoi. Nous avons vu des systèmes où le comportement changeait d'une semaine à l'autre, et personne ne pouvait pointer du doigt un seul changement qui en était la cause. C'est généralement le moment où les gens réalisent qu'ils n'ont plus le contrôle total du système.

Pourquoi les limites architecturales sont importantes

Beaucoup de systèmes actuels traitent les interactions localement mais optimisent globalement. Sur le papier, cela semble efficace. En pratique, cela introduit une inadéquation. L'exécution se fait à l'intérieur d'un locataire, mais l'apprentissage se fait entre les locataires. Le comportement évolue en fonction de signaux qui ne sont pas contenus dans le propre contexte du système. Vous pouvez vous en sortir pendant un certain temps. Dans les environnements réglementés, pas très longtemps. Si les sorties changent, quelqu'un finira par demander pourquoi. Si les décisions diffèrent, il doit y avoir un chemin traçable de l'entrée à la sortie. Une fois que l'influence est distribuée entre les environnements, cette traçabilité commence à s'effondrer. Le système fonctionne toujours. Mais il devient plus difficile à analyser – et encore plus difficile à défendre.

Ce que cela implique en pratique

De nombreux systèmes d'IA modernes s'appuient sur des fournisseurs de modèles externes pour générer des réponses. Cela signifie que les données quittent la limite du système, sont traitées par un modèle tiers, puis retournées sous forme de sortie. Les fournisseurs indiqueront généralement que les données ne sont pas stockées ni utilisées pour l'entraînement. Contractuellement, cela peut être vrai. Mais ce n'est pas toute l'histoire. Car le système dépend toujours de ce qui est envoyé à ce modèle. Et dans de nombreuses implémentations, cette responsabilité incombe au client ou à la couche applicative. Si des données personnelles sont incluses dans les prompts, elles seront traitées. Pas malicieusement. Pas incorrectement. Juste… par conception. À ce stade, vous n'avez plus affaire à un système purement contenu. Vous dépendez d'une combinaison de configuration, de discipline et, soyons honnêtes, d'un peu d'espoir que rien d'involontaire ne passe à travers. Et oui, cela inclut des systèmes comme Fin d'Intercom ou des agents d'IA similaires. Ils reposent sur des LLM externes. Ils génèrent des réponses basées sur les données clients. Et bien qu'ils offrent des contrôles, ils n'éliminent pas fondamentalement la possibilité que des données personnelles soient traitées en externe. Si votre architecture permet cette voie, vous assumez ce risque.

Une approche délibérée de l'isolation

Chez Kolsetu, nous avons choisi de supprimer toute cette catégorie de problèmes au niveau architectural. Nous ne procédons pas au fine-tuning de modèles fondamentaux partagés avec les données des clients, et nous ne permettons pas que l'optimisation du comportement se produise entre les locataires. Les poids des modèles restent exactement les mêmes, quelle que soit l'utilisation des systèmes individuels. Au lieu de cela, le comportement est façonné par le contexte. Chaque déploiement s'exécute dans son propre environnement, avec sa propre couche de connaissances et son propre pipeline de données. Les informations sont stockées et récupérées par locataire, en utilisant des embeddings et des bases vectorielles qui ne quittent jamais cette limite. La récupération est limitée, l'indexation est isolée et l'accès est contrôlé de bout en bout. Ce n'est pas la manière la plus « efficace » de construire un système global. C'est une manière beaucoup plus propre de construire quelque chose que vous pouvez réellement contrôler.

Comment les systèmes s'améliorent sans apprentissage partagé

Rien de tout cela ne signifie que le système stagne. L'amélioration se produit toujours. Elle se produit simplement localement. Au fil du temps, les systèmes deviennent plus efficaces car la base de connaissances s'affine, la récupération s'améliore et le contexte est assemblé plus précisément. Le modèle lui-même ne change pas. Ce qui change, c'est la manière dont l'information est sélectionnée et utilisée. C'est une forme d'apprentissage plus discrète. Moins impressionnante en démonstration. Beaucoup plus prévisible en production. Et surtout, lorsque le comportement s'améliore, vous pouvez réellement expliquer pourquoi.

Implications pour la protection et la gouvernance des données

Cette architecture a des conséquences directes. Les données personnelles restent là où elles sont générées. Il n'y a pas d'influence inter-locataires, pas d'agrégation de signaux comportementaux, et pas de mélange de contexte entre les systèmes. Lorsque les sorties changent, vous pouvez les retracer jusqu'à quelque chose de concret : données, configuration, flux de travail. Pas une boucle de rétroaction invisible enfouie dans un système partagé. Elle évite également de dériver vers des domaines qui suscitent des interrogations réglementaires. Il n'y a pas de profilage inter-contextes, pas de couche d'optimisation cachée qui mélange les signaux entre les environnements, et pas de dépendance vis-à-vis des clients pour qu'ils « fassent attention » à ce qu'ils envoient. Du point de vue de la conformité, cela compte.

La sécurité, c'est contrôler l'influence

La plupart des discussions sur la sécurité se concentrent encore sur la protection des données. C'est nécessaire, mais ce n'est que la moitié de l'histoire. Dans les systèmes d'IA, vous devez également contrôler comment les données affectent le comportement. Où circule l'influence. Où elle s'arrête. Ce qu'elle peut et ne peut pas changer. Si vous ne contrôlez pas cela, les systèmes deviennent lentement plus difficiles à expliquer – même si tout est chiffré et que l'accès est contrôlé. Si vous le contrôlez, le comportement reste prévisible, même lorsque le système évolue. Cette distinction a tendance à être plus importante avec le temps que ce que la plupart des gens ne pensent.

Le rôle des systèmes comme Elba

C'est le principe qui sous-tend la conception d'Elba. Elba opère dans des environnements structurés où le contexte persiste et les flux de travail sont explicites. Il conserve les informations pertinentes au fil du temps, mais uniquement dans la portée d'un système donné. Cela lui permet de combiner les interactions passées et les entrées actuelles d'une manière qui améliore les résultats – sans introduire de dépendances inter-locataires. Parce que la récupération est contrôlée, les sorties restent fondées. Parce que les flux de travail sont définis, les décisions restent traçables. Et parce que les environnements sont isolés, le comportement ne dérive pas simplement parce que quelque chose a changé ailleurs. C'est une approche légèrement moins magique. Mais c'est beaucoup plus fiable.

Conclusion

La vraie question n'est pas de savoir si un système s'entraîne sur vos données. C'est de savoir comment vos données peuvent influencer le système, tout court. Une fois que l'influence commence à circuler au-delà des limites, les systèmes deviennent plus difficiles à comprendre, plus difficiles à contrôler et plus difficiles à expliquer. Maintenir cette influence contenue ne rend pas les systèmes plus simples, mais cela les rend prévisibles. Chez Kolsetu, c'est un compromis que nous sommes prêts à faire. Car dans les systèmes opérationnels, en particulier dans les environnements réglementés, la prévisibilité a tendance à compter plus que l'ingéniosité.