Comment rapprocher les modèles d’IA des données sensibles

Les données dont l’IA a le plus besoin peuvent être celles que les entreprises ne peuvent pas déplacer

Certaines données d’entreprise au potentiel le plus élevé pour l’IA ne peuvent pas simplement être envoyées vers le cloud public. Les règles de souveraineté, la réglementation, les revues de sécurité, les exigences de prévisibilité des coûts et les opérations en environnement isolé maintiennent les enregistrements propriétaires dans des environnements contrôlés par l’entreprise. Les banques, les administrations publiques et les prestataires de santé en sont des exemples marquants. La question de déploiement qui en résulte est de plus en plus la suivante : comment amener les modèles de pointe jusqu’à ces données tout en préservant les contrôles exigés à la fois par l’entreprise et par le propriétaire du modèle.

« Les organisations comme les banques, les administrations publiques et les prestataires de santé disposent de nombreuses données qui n’ont jamais été destinées à être déplacées vers le cloud », explique Phil Manez, vice-président des initiatives stratégiques chez VAST Data. « Nous sommes arrivés à un point où le coût d’opportunité lié au fait de ne pas donner à ces modèles d’IA avancés accès à ces données devient critique. » Ces contraintes de localisation ont poussé une grande partie de l’IA d’entreprise vers des données qui peuvent être déplacées, laissant les enregistrements propriétaires intacts même lorsqu’ils pourraient fournir un contexte important à une application.

L’accès limité aux données affecte aussi le choix des modèles. VAST indique que, pendant des années, l’entreprise a pu traiter le versant entreprise du problème avec des modèles open source ou des modèles déjà proposés on premises, tandis que des modèles plus puissants disponibles uniquement dans le cloud restaient hors des environnements hébergeant des données soumises à restriction. Les modèles de pointe peuvent offrir des capacités qu’une entreprise souhaite exploiter, mais une exigence de fourniture via cloud public peut les exclure avant même que quiconque n’évalue leurs performances.

Pour répondre à ce problème de déploiement, VAST a récemment lancé DataEnclave au sein du VAST AI Operating System. VAST a un intérêt commercial dans cette architecture, car DataEnclave est son produit et une adoption plus large de l’IA d’entreprise confidentielle peut bénéficier à son activité. VAST décrit cette conception comme de l’IA confidentielle, dans laquelle les entreprises conservent l’autorité sur leurs informations tandis que les fournisseurs de modèles protègent les poids propriétaires des modèles sur une infrastructure qu’ils ne possèdent pas. La conception repose sur un contrôle réciproque : les autorisations de l’entreprise déterminent ce qui parvient à un modèle, tandis que des contrôles de sécurité pilotés par le fournisseur déterminent si le modèle peut s’exécuter.

Le déploiement on premises laisse subsister un problème de confiance mutuelle

Cette exigence de contrôle réciproque demeure lorsqu’un modèle est déplacé dans le centre de données d’un client. Un modèle peut s’exécuter sur un GPU on premises, mais son emplacement ne détermine pas quels enregistrements il peut recevoir, où sa sortie peut être envoyée, ni si l’entreprise peut reconstituer ce qui s’est passé. « J’ai besoin de moyens pour contrôler les données auxquelles l’IA peut accéder et d’avoir de la visibilité sur ce que l’IA faisait », explique Manez. « Si vous ne pouvez faire ni l’un ni l’autre, le simple fait d’autoriser le modèle à s’exécuter on prem ne vous apporte pas grand-chose. »

Le problème de contrôle de l’entreprise a son équivalent du côté du fournisseur. Les poids d’un LLM peuvent représenter des milliards de dollars d’investissement en entraînement, ainsi qu’une propriété intellectuelle propriétaire développée à partir de cet investissement. Lors de l’inférence, ces poids entrent dans la mémoire du GPU, où un administrateur capable d’inspecter cette mémoire pourrait potentiellement les copier et exploiter le modèle ailleurs. Un fournisseur qui expédie des poids dans le centre de données de quelqu’un d’autre a donc besoin d’un mécanisme empêchant les administrateurs et les opérateurs d’infrastructure d’accéder à cet actif.

Le contrôle du fournisseur peut aussi contribuer à faire respecter les règles d’usage acceptable. Anthropic a révélé en septembre avoir perturbé des tentatives d’utilisation de Claude pour des travaux susceptibles de soutenir le développement d’armes biologiques. L’exemple concerne un cas d’usage précis de mauvaise utilisation, mais il montre pourquoi un concepteur de modèle peut vouloir conserver un contrôle continu sur l’exécution pour des raisons qui dépassent la protection des revenus ou la prévention du vol de poids. Une architecture de déploiement qui retire au fournisseur la capacité de contrôler où son modèle s’exécute peut supprimer l’un des moyens de faire respecter ces restrictions.

Répondre à ces deux ensembles d’exigences impose une protection sur l’ensemble du cycle de calcul. L’IA confidentielle vise à protéger les informations dans trois états : au repos dans le stockage, en transit sur les réseaux et en cours d’utilisation pendant le calcul. Le chiffrement traite depuis longtemps les deux premiers états. L’IA rend le troisième particulièrement important, car les poids, les prompts et les résultats intermédiaires de calcul doivent exister en mémoire pendant que les CPU et les GPU les traitent.

La protection du calcul actif modifie la frontière de sécurité. L’entreprise a besoin de contrôler les entrées, la récupération, les sorties et d’avoir de la visibilité sur l’exécution, tandis que le propriétaire du modèle a besoin que ses poids restent secrets et que ses clés ne soient libérées qu’à des environnements approuvés. Un serveur derrière le pare-feu de l’entreprise ne peut fournir à aucune des deux parties ces garanties par sa seule localisation. Une confiance opposable dépend du contrôle de ce qui se passe pendant l’exécution.

L’attestation permet au propriétaire du modèle de contrôler l’exécution

La protection de l’exécution commence par le confidential computing, qui isole la mémoire de travail des logiciels et des administrateurs qui contrôlent normalement la machine. Le confidential computing a d’abord traité les charges de travail CPU en empêchant le système d’exploitation hôte, l’hyperviseur et les utilisateurs disposant des privilèges root d’inspecter la mémoire protégée. L’IA étend cette exigence aux GPU, car l’inférence et l’entraînement placent des poids propriétaires, des prompts utilisateur et des résultats intermédiaires dans la mémoire GPU. Sans protection côté GPU, ces valeurs restent exposées pendant le calcul.

VAST indique que DataEnclave met en œuvre cette protection avec des machines virtuelles confidentielles couvrant les ressources CPU et GPU. Dans l’architecture de VAST, DataEnclave ajoute deux éléments à VAST DataEngine, le système chargé du calcul piloté par événements, du déploiement sécurisé des modèles et de l’inférence accélérée. L’un des composants décrits est un runtime sécurisé qui démarre chaque charge de travail dans sa propre VM confidentielle sur une infrastructure proche des données de l’entreprise. Sur les plateformes GPU les plus récentes, NVLink chiffré protège le trafic circulant d’un GPU à l’autre, tandis que la VM confidentielle protège les transferts entre les ressources CPU et GPU.

Une fois la mémoire isolée, le propriétaire du modèle doit encore décider si un environnement donné est autorisé à recevoir son modèle. L’attestation fournit ce mécanisme de décision : le matériel produit des preuves signées sur l’environnement, et le service d’attestation du propriétaire du modèle les vérifie par rapport à la politique du propriétaire. « Il faut disposer d’un moyen de valider que le modèle s’exécute dans un environnement sécurisé avant qu’il soit autorisé à s’exécuter, c’est la partie attestation », explique Manez.

Cette vérification doit avoir lieu avant qu’un modèle protégé puisse être utilisé. Le propriétaire du modèle exploite le serveur d’attestation, qui retient les clés de déchiffrement du modèle jusqu’à ce que les preuves matérielles montrent que l’environnement d’exécution est conforme à sa politique. VAST ne reçoit pas les clés d’une autre partie, et l’entreprise qui exploite l’infrastructure sous-jacente non plus. Posséder l’infrastructure ne donne donc pas automatiquement accès au modèle protégé.

Comme la libération des clés dépend de l’attestation, la politique du fournisseur reste une condition d’exécution plutôt qu’un contrôle effectué uniquement lors de l’installation. Chaque lancement doit être qualifié, y compris chaque nouvelle réplique d’une charge de travail. Le fournisseur peut conserver son autorité sur les environnements d’exécution acceptables même après que des actifs de modèle chiffrés ont été placés sur l’infrastructure de quelqu’un d’autre. Le client possède ou contrôle l’environnement, tandis que le propriétaire du modèle contrôle les conditions dans lesquelles sa propriété intellectuelle devient utilisable.

Cette séquence produit aussi des preuves liées à l’utilisation du modèle. « Ce n’est qu’une fois que vous avez prouvé que vous êtes dans cet environnement sécurisé que vous obtenez les clés pour déverrouiller ces informations propriétaires », explique Manez. « Ensuite, vous disposez de la piste d’audit qui prouve quand ce modèle a été déchiffré et comment il a été utilisé. » Le fournisseur obtient des preuves associées à l’utilisation réelle du modèle au lieu de s’appuyer sur l’affirmation d’un client selon laquelle l’infrastructure respectait les conditions convenues.

L’attestation ajoute une barrière de déploiement à la protection fournie par le chiffrement et l’isolation mémoire. L’isolation mémoire peut empêcher des tiers d’inspecter des éléments pendant le calcul, tandis que le chiffrement peut protéger ces éléments avant leur chargement. Une attestation réussie déclenche la libération des clés, tandis qu’un contrôle échoué laisse les poids protégés indisponibles pour le déchiffrement et l’exécution. La politique du fournisseur reste ainsi liée à l’exécution du modèle sur une infrastructure située hors du domaine administratif du fournisseur.

Les autorisations de l’entreprise doivent survivre à la récupération, aux vecteurs, aux prompts et à l’egress

L’exécution contrôlée par le fournisseur traite une direction du problème de confiance, l’entreprise a donc besoin d’une frontière correspondante autour de ses informations propriétaires. Dans la conception de VAST, le modèle ne recherche pas de manière indépendante dans les référentiels de l’entreprise. Une application située hors de l’enclave décide quelles informations le modèle reçoit, ce qui permet à l’entreprise d’appliquer ses propres autorisations avant que les informations n’atteignent l’environnement de modèle protégé.

Cette application définit le chemin de récupération. Une application de retrieval exécutée sur les systèmes de l’entreprise recherche des documents, sélectionne les extraits pertinents, les assemble dans un prompt et envoie le prompt finalisé à l’API d’inférence du modèle. Le prompt constitue donc l’information d’entreprise exposée au modèle. La recherche et la construction du prompt restent sur des systèmes contrôlés par l’entreprise, et VAST indique que le fournisseur du modèle ne dispose d’aucune voie administrative vers l’enclave qui lui permettrait d’inspecter ni le prompt ni la réponse produite.

Comme la récupération détermine le contenu des prompts, l’autorisation doit suivre l’information tout au long de ce pipeline. Les systèmes d’IA d’entreprise transforment couramment le matériau source en vecteurs, des représentations numériques utilisées pour trouver du contenu sémantiquement pertinent. Si l’index vectoriel perd les autorisations attachées au document d’origine, la récupération peut exposer des informations issues d’un fichier que le demandeur n’a pas le droit d’ouvrir. L’autorisation au niveau du référentiel documentaire doit donc rester liée à la récupération par l’IA.

VAST indique appliquer « un seul ensemble de contrôles d’accès » au matériau source, qu’il s’agisse d’un fichier, d’un objet ou d’une image, ainsi qu’au vecteur représentant ce matériau. Dans cette conception, une demande de récupération ne peut extraire du contenu source qu’à partir d’enregistrements auxquels le demandeur est autorisé à accéder. Préserver cette relation signifie que le prompt IA d’un employé ne peut pas obtenir le contenu de documents restreints simplement parce que le système de récupération les a jugés pertinents pour la question.

Ces contrôles de récupération déterminent ce qui entre finalement dans l’enclave. Comme la récupération et l’assemblage du prompt s’exécutent sur les systèmes de l’entreprise, le prompt assemblé contient des informations sélectionnées selon les autorisations existantes du demandeur. VAST indique que les règles d’egress existantes de l’entreprise déterminent ensuite où l’enclave peut transmettre des informations après l’inférence. Le contrôle d’accès se poursuit ainsi depuis l’enregistrement d’origine, à travers la récupération et la construction du prompt, jusqu’à la frontière réseau entourant le résultat.

Cette chaîne fait de l’autorisation de récupération une partie de la frontière de sécurité de l’IA confidentielle. Une VM isolée au niveau matériel peut protéger un prompt une fois qu’il atteint le modèle, mais l’isolation ne peut pas corriger un système de récupération en amont qui a sélectionné des enregistrements non autorisés. Le contrôle réciproque s’étend donc au-delà de la sécurité CPU et GPU jusqu’au chemin applicatif qui décide de ce que le modèle est autorisé à voir.

Des enregistrements indépendants rendent le contrôle réciproque auditable

Une fois que les deux parties peuvent appliquer des contrôles, chacune a besoin de preuves qu’elle peut comparer à ses propres enregistrements. VAST indique que son runtime enregistre quelle application et quelle version ont été lancées, sur quel nœud elles ont été exécutées et avec quelle configuration, en stockant ces enregistrements de lancement dans VAST DataBase. Cela donne à l’entreprise un enregistrement opérationnel de l’exécution associé à son propre environnement. L’enregistrement relie le calcul protégé à une application, une machine et une configuration précises.

Le côté fournisseur conserve un compte rendu distinct via le service d’attestation. VAST indique que ce service enregistre les enclaves qu’il a vérifiées et les clés qu’il a libérées, en complément de la piste d’audit montrant quand un modèle protégé a été déchiffré et utilisé. Les deux enregistrements décrivent des parties différentes du même événement d’exécution. Leur séparation réduit la nécessité, pour l’entreprise comme pour le concepteur du modèle, d’accepter uniquement la version de la contrepartie sur ce qui s’est produit.

Cette indépendance fait du contrôle réciproque un élément que les deux parties peuvent examiner après l’exécution. Les enregistrements du runtime peuvent établir quelle application a été lancée et sous quelle configuration, tandis que les enregistrements d’attestation du fournisseur établissent quel environnement a passé ses contrôles et reçu les clés. La piste d’audit qui en résulte relie les conditions de déploiement à des événements enregistrés au lieu de laisser ces conditions uniquement dans des documents de politique.

Le problème le plus difficile est un modèle opérationnel unique dans chaque environnement de déploiement

Un contrôle auditable sur un site laisse malgré tout un problème opérationnel lorsque chaque nouvel environnement exige une collection différente de contrôles. L’IA d’entreprise confidentielle doit coordonner l’isolation CPU et GPU, la protection réseau, la gestion des clés, les autorisations de récupération, les restrictions d’egress, l’audit, l’attestation et la politique de déploiement. Les différences entre plateformes d’infrastructure créent des possibilités d’erreurs de configuration lorsque les équipes doivent traduire chaque contrôle séparément. Un modèle opérationnel commun vise à réduire ce travail de traduction.

Le besoin d’un modèle commun grandit parce que les environnements cibles diffèrent fortement. Un cloud public, un cloud souverain, le propre centre de données d’un client et une installation isolée peuvent avoir des contraintes administratives et de connectivité différentes. La réponse proposée par DataEnclave au sein du VAST AI Operating System est un mode opératoire commun à travers ces emplacements. Un site isolé, par exemple, peut exécuter localement ses systèmes d’attestation et de gestion des clés aux côtés des charges de travail qu’ils vérifient, car il ne peut pas dépendre d’un service externe.

VAST présente cette portabilité comme un moyen de préserver le sens des politiques d’un environnement à l’autre. « Traduire les différents contrôles, exigences d’accès et ce à quoi ressemble l’audit dans tous ces environnements est très difficile, et cela laisse de la place aux erreurs », explique Manez. « Avec un modèle opérationnel commun, je crée des politiques une seule fois, puis je déplace ces politiques à travers ces environnements. » L’objectif est de transporter la même politique entre les lieux de déploiement au lieu d’en reconstruire séparément le sens pour chaque environnement d’infrastructure.

La cohérence des politiques est importante parce que l’IA confidentielle dépend de contrôles qui traversent des frontières organisationnelles et techniques. La politique de clés du propriétaire du modèle doit s’aligner sur l’attestation matérielle ; les autorisations d’identité de l’entreprise doivent survivre à la récupération vectorielle ; la politique réseau doit limiter l’egress ; et les systèmes d’audit doivent enregistrer ce que chaque partie doit vérifier. Modifier un élément indépendamment peut affaiblir les garanties fournies ailleurs dans la stack. La portabilité dépend donc du maintien de ces relations à mesure que l’infrastructure évolue.

La vision à plus long terme de VAST étend ce modèle opérationnel au-delà des installations individuelles d’entreprise. L’entreprise décrit des concepteurs de modèles, des clouds IA et des partenaires d’infrastructure publiant dans une base de confiance dans laquelle l’emplacement du client cesse de déterminer quel modèle peut être concédé sous licence. La réalisation de cette vision dépend de la capacité à rendre les contrôles sous-jacents suffisamment portables pour que le passage entre infrastructure publique, souveraine, détenue par l’entreprise et déconnectée ne nécessite pas de reconstruire le modèle de sécurité à partir de zéro. Comme VAST vend l’infrastructure destinée à prendre en charge ce modèle, l’entreprise bénéficierait d’une adoption large de cette approche par les clients et les fournisseurs de modèles.

La souveraineté des données devient une contrainte de distribution et de revenus pour les fournisseurs de modèles

Si ces contrôles deviennent portables, la disponibilité des modèles peut s’étendre à des marchés où les données clients doivent rester à un endroit précis. Un fournisseur uniquement cloud peut s’adresser aux acheteurs libres d’envoyer leurs données dans son cloud, tandis que les clients contraints à d’autres localisations peuvent être exclus avant même que la qualité du modèle n’entre dans la décision d’achat. Cette contrainte peut affecter les opportunités dans l’administration publique, la santé, les services financiers et en Europe, où les exigences de confidentialité, de souveraineté ou de réglementation limitent le déploiement.

Manez relie directement ces limites de déploiement aux marchés adressables. « Si vous ne pouvez fonctionner que dans le cloud public, votre portefeuille commercial sera fortement orienté vers les secteurs grand public et non réglementés », explique Manez. « Je passe à côté de l’administration publique. Je pourrais potentiellement passer à côté de toute l’Europe. Je passe à côté des clients de la santé et des services financiers, alors qu’il peut s’agir d’un marché lucratif pour ces concepteurs de modèles s’ils répondent aux exigences de confidentialité et de réglementation. » Ces exemples identifient les types de marchés en jeu plutôt que d’établir l’ampleur que l’opportunité finira par prendre.

Servir ces marchés exige plus que de placer un package logiciel on premises à côté des données de l’entreprise. Un fournisseur doit préserver les contrôles qui rendaient acceptable pour lui une fourniture via le cloud : protection de ses poids, libération sélective des clés, restrictions de déploiement et preuves d’utilisation. Dans le même temps, les banques, les administrations publiques, les organisations de santé et les autres acheteurs réglementés doivent conserver leurs propres autorisations, restrictions d’egress et enregistrements. Le modèle commercial dépend donc des mêmes contrôles réciproques que l’architecture technique.

Manez soutient que ce modèle opérationnel est devenu une contrainte commerciale sur le déploiement de l’IA. « Le modèle opérationnel et de revenus devient le principal frein », explique Manez. « La propriété intellectuelle du modèle a évolué très vite et elle bouge en permanence. Mais sans le modèle opérationnel qui répond aux exigences de l’entreprise, l’IA donnera l’impression d’être une bulle de hype. C’est bien plus qu’une technologie de VM, de chiffrement des données ou de réseau. C’est toute l’infrastructure et tout l’écosystème autour du modèle. » Pour les fournisseurs de modèles, la frontière de déploiement qui en résulte est de savoir si cet écosystème peut rendre les contrôles réciproques opposables et portables partout où les données du client doivent rester.

Recap

Pour les dirigeants, la question centrale n’est plus de savoir si les données sensibles de l’entreprise doivent être déplacées vers l’IA. Dans de nombreux environnements réglementés, souverains ou déconnectés, elles ne le peuvent pas. La question plus pratique est de savoir si les organisations peuvent amener des modèles avancés jusqu’à ces données sans obliger ni l’entreprise ni le fournisseur du modèle à abandonner le contrôle.

Cela fait de l’IA confidentielle une décision de modèle opérationnel autant qu’une décision de sécurité. Les entreprises ont besoin que les autorisations, les contrôles de récupération, les politiques d’egress et l’auditabilité restent applicables partout où les charges de travail s’exécutent. Les fournisseurs de modèles ont besoin de garanties équivalentes autour de leurs poids, de la libération des clés, des environnements d’exécution et des politiques d’usage acceptable. Le confidential computing et l’attestation fournissent des fondations techniques importantes, mais leur valeur dépend de la cohérence avec laquelle ces contrôles fonctionnent sur l’ensemble de la stack d’infrastructure.

Les dirigeants qui évaluent ces architectures devraient donc regarder au-delà de la simple question de savoir si une plateforme chiffre les données ou prend en charge des GPU confidentiels. La question la plus déterminante est de savoir si elle peut préserver les mêmes politiques de sécurité et de gouvernance à travers les clouds publics, les environnements souverains, les centres de données privés et les sites isolés, tout en donnant aux deux parties des preuves indépendantes que ces politiques ont bien été appliquées.

Si ce modèle opérationnel devient praticable à grande échelle, la souveraineté des données devient moins un obstacle à l’adoption et à la distribution des modèles. Les entreprises accèdent à une IA avancée sans abandonner le contrôle des informations sensibles, tandis que les fournisseurs de modèles peuvent atteindre des marchés réglementés sans renoncer au contrôle de leur propriété intellectuelle. L’avantage concurrentiel viendra de la capacité à rendre ces contrôles réciproques routiniers plutôt que de reconstruire la confiance pour chaque déploiement.