OpenAI renforce la confidentialité de ses modèles API

OpenAI veut faire de la confidentialité un prérequis pour les usages les plus sensibles

OpenAI annonce renforcer son dispositif de confidentialité pour les entreprises qui utilisent ses modèles via API. Dans une publication intitulée “Offering Zero Data Retention for frontier models”, l’entreprise indique réaffirmer la disponibilité d’un régime de Zero Data Retention, ou ZDR, pour des clients API éligibles qui souhaitent employer ses modèles de pointe.

L’enjeu est central pour les organisations qui envisagent de confier à un modèle d’intelligence artificielle des informations issues de leurs processus métier : documents internes, tickets de support, données financières, contenus juridiques, code source, informations médicales, échanges avec des clients ou encore dossiers liés aux ressources humaines. Dans ces contextes, la qualité d’un modèle ne suffit pas. Les directions de la sécurité, les équipes juridiques et les responsables conformité cherchent également à savoir ce qui advient des données envoyées au fournisseur, combien de temps elles sont conservées, qui peut y accéder et dans quelles circonstances.

Le message d’OpenAI répond directement à cette préoccupation. L’entreprise explique que, dans le cadre de cette offre et sous réserve des conditions d’éligibilité, les requêtes envoyées à l’API et les réponses produites ne sont pas conservées par défaut. La précision est importante : le ZDR ne doit pas être assimilé à une promesse générale et indistincte applicable à tout produit, à tous les comptes ou à toutes les configurations. OpenAI le présente comme un dispositif destiné à des clients éligibles, dans un cadre précis.

Cette annonce ne porte donc pas seulement sur une modalité technique de stockage. Elle traite d’un frein commercial et réglementaire qui revient systématiquement dans les grands projets d’IA générative : comment exploiter des modèles avancés tout en limitant au maximum la circulation et la conservation d’informations potentiellement confidentielles ? Pour les secteurs régulés, cette question peut déterminer la possibilité même d’un déploiement.

OpenAI associe cette évolution à un projet baptisé Private Safety Processing. L’objectif annoncé est de pouvoir effectuer des vérifications de sécurité tout en évitant d’exposer les données des clients. L’entreprise cherche ainsi à résoudre une tension structurelle des modèles génératifs : les mécanismes de sûreté nécessitent des contrôles sur les usages, mais les entreprises attendent que ces contrôles ne se traduisent pas par une rétention large ou une exposition de leurs contenus.

Le sujet dépasse OpenAI. Anthropic, autre fournisseur majeur de modèles destinés aux entreprises et aux développeurs, a fait de la sécurité et de la confidentialité un élément visible de son positionnement. La rivalité entre les deux sociétés se joue sur les performances des modèles, les capacités de raisonnement, les outils de développement et les coûts d’inférence, mais aussi désormais sur les garanties opérationnelles offertes aux clients. La confidentialité tend à devenir une caractéristique concurrentielle aussi déterminante que la taille du contexte ou la vitesse de réponse.

Pour le marché français et européen, où le Règlement général sur la protection des données, le secret des affaires et les exigences de cybersécurité structurent fortement les achats technologiques, l’annonce est particulièrement suivie. Un régime de non-conservation peut alléger certains risques perçus par les clients, mais il ne remplace pas les analyses juridiques, contractuelles et techniques nécessaires à chaque cas d’usage. La promesse d’OpenAI constitue un outil supplémentaire pour rendre certains projets envisageables ; elle ne supprime pas l’obligation de gouverner les données.

Ce que recouvre l’offre Zero Data Retention annoncée pour l’API

La formule Zero Data Retention peut sembler simple, mais sa portée doit être lue avec précision. Dans sa communication, OpenAI indique que les requêtes et les réponses des clients concernés ne sont pas conservées par défaut dans le cadre de l’offre. Autrement dit, les données fournies dans une demande adressée à un modèle et le contenu généré en retour ne sont pas destinés à être stockés selon le régime standard de conservation applicable à d’autres configurations.

Pour une entreprise, la distinction entre une absence de conservation par défaut et une absence absolue de toute trace dans n’importe quelle couche d’un système est essentielle. Une architecture d’IA inclut potentiellement plusieurs composantes : l’application du client, ses journaux internes, son fournisseur de cloud, des outils d’observabilité, des services de mise en cache, des bases de données vectorielles, des passerelles de sécurité et, enfin, l’API du fournisseur de modèle. Le ZDR annoncé par OpenAI concerne le traitement côté OpenAI dans le cadre défini par l’offre ; il ne décharge pas l’organisation cliente de la gestion des données qu’elle conserve elle-même.

Cette nuance est particulièrement importante dans les déploiements dits de récupération augmentée par génération, souvent désignés par l’acronyme RAG. Dans cette architecture, l’entreprise cherche des informations dans ses propres sources documentaires, sélectionne les extraits pertinents puis les transmet au modèle avec une instruction. Même si le fournisseur de modèle ne conserve pas la requête et la réponse selon le régime ZDR, l’application métier peut avoir journalisé l’échange, conservé les documents d’origine ou enregistré la réponse afin d’assurer une traçabilité. La confidentialité finale dépend donc de l’ensemble de la chaîne.

OpenAI emploie également un vocabulaire qui appelle à la prudence : le dispositif vise des clients API éligibles. L’annonce ne détaille pas, dans les éléments communiqués, une ouverture universelle à tous les utilisateurs ni une liste exhaustive de critères. Les entreprises intéressées devront donc vérifier leur éligibilité, les modalités contractuelles, les modèles concernés, les éventuelles restrictions de fonctionnalités et les obligations techniques associées avant de bâtir une architecture de production sur cette base.

La référence aux modèles de pointe, ou frontier models, est elle aussi significative. Les organisations les plus susceptibles de demander des garanties renforcées de confidentialité sont souvent celles qui veulent utiliser les capacités les plus avancées pour automatiser des tâches à forte valeur : analyse de contrats, assistance aux analystes, génération ou revue de code, traitement de corpus techniques, production de synthèses à partir de documents non publics, ou agentification de processus internes. Or ce sont précisément les flux dans lesquels la sensibilité des informations est élevée.

Historiquement, l’API d’OpenAI s’est imposée comme l’un des moyens les plus directs d’intégrer des modèles de langage dans des logiciels tiers. Les développeurs peuvent l’appeler depuis leurs propres applications, plutôt que de demander aux employés de saisir manuellement leurs contenus dans une interface généraliste. Cette intégration apporte contrôle, automatisation et possibilité de relier le modèle à des systèmes existants. Elle augmente aussi les responsabilités : une requête API peut circuler à grande échelle, être déclenchée automatiquement et contenir des données qui ne devraient pas quitter un périmètre autorisé.

Dans ce cadre, la rétention devient une question de gouvernance, et non un détail de conditions générales. Une banque peut s’interroger sur la présence d’informations financières ou identifiantes dans les requêtes. Un cabinet d’avocats peut craindre l’exposition de pièces couvertes par le secret professionnel. Un industriel peut vouloir protéger des plans, des éléments de propriété intellectuelle ou des données de recherche. Un acteur de la santé doit, selon son cas d’usage, évaluer les implications de données particulièrement sensibles. À chaque fois, la possibilité de limiter la conservation chez le fournisseur d’IA fait partie des garanties recherchées.

Le ZDR peut également répondre à une difficulté plus opérationnelle : la multiplication des interlocuteurs internes. Un projet d’IA générative réunit habituellement les équipes métiers, les développeurs, le responsable de la protection des données, les équipes de cybersécurité, les achats et le juridique. Chacun examine un aspect distinct : valeur d’usage, robustesse technique, localisation et flux de données, clauses contractuelles, accès administrateur, gestion des incidents et effacement. Une politique de non-conservation clairement définie ne clôt pas le débat, mais elle permet de traiter plus directement l’un des points les plus sensibles.

La communication d’OpenAI ne doit pas être interprétée comme une dispense de vigilance sur les instructions transmises aux modèles. Une requête peut elle-même être trop détaillée, contenir des identifiants inutiles ou faire remonter un document qui ne devrait pas être utilisé pour cette finalité. La minimisation des données reste donc un principe pratique : envoyer seulement les éléments nécessaires au résultat recherché, pseudonymiser lorsque cela est possible et segmenter les cas d’usage selon leur niveau de sensibilité.

Dans l’Union européenne, ce raisonnement rejoint les exigences générales du RGPD, notamment autour de la limitation des finalités, de la minimisation des données, de la sécurité du traitement et de la responsabilité des organisations. Le règlement ne se réduit pas à une durée de conservation, mais cette durée fait partie des paramètres concrets à examiner. Pour une entreprise française, le ZDR peut ainsi contribuer à une analyse de conformité ; il ne constitue pas, à lui seul, une qualification juridique complète d’un traitement ni une garantie automatique de conformité.

Private Safety Processing : chercher un équilibre entre contrôles et secret des données

Le point le plus stratégique de l’annonce est peut-être moins le ZDR lui-même que la mention de Private Safety Processing. OpenAI décrit ce mécanisme comme une approche en préparation visant à réaliser des vérifications de sécurité sans exposer les données des clients. La formulation reflète une contradiction que toute l’industrie tente de traiter : un fournisseur de modèles doit pouvoir préserver la sûreté de ses services, tandis que ses clients veulent réduire au strict nécessaire l’accès du fournisseur à leurs contenus.

Les modèles de langage ne sont pas de simples moteurs de recherche. Ils reçoivent des instructions parfois ambiguës, peuvent être sollicités pour des actions sensibles et sont exposés à des tentatives de contournement de leurs garde-fous. Les fournisseurs mettent donc en place des systèmes de contrôle afin de détecter ou de gérer certains usages. Mais ces systèmes peuvent nécessiter une inspection des flux, ce qui entre potentiellement en collision avec les attentes de confidentialité les plus élevées.

OpenAI ne présente pas, dans les éléments résumés par son annonce, une documentation technique exhaustive du fonctionnement de Private Safety Processing. Il serait donc prématuré d’en déduire la nature exacte des mécanismes utilisés, les données éventuellement traitées, l’architecture de séparation des accès ou les garanties cryptographiques qui pourraient être retenues. Le fait établi est l’intention : l’entreprise veut effectuer les vérifications nécessaires à la sécurité sans exposer les données de ses clients.

Cette orientation est néanmoins importante pour les acheteurs. Jusqu’ici, les discussions sur la confidentialité des IA génératives ont souvent opposé deux exigences de manière binaire : soit le fournisseur conserve des éléments afin d’améliorer, surveiller ou sécuriser le service, soit il s’engage à ne pas les conserver. L’approche annoncée par OpenAI suggère qu’il faut construire une voie intermédiaire, où la sûreté peut être maintenue grâce à des traitements qui limitent l’exposition des contenus.

Cette ambition répond à une objection fréquente des entreprises : la non-conservation ne doit pas devenir un angle mort en matière de contrôle. Dans un environnement professionnel, un responsable sécurité ne veut pas seulement savoir que les données ne sont pas retenues. Il veut aussi comprendre comment l’outil réagit en cas d’usage contraire aux politiques de l’entreprise, comment les incidents sont détectés, comment les équipes peuvent enquêter lorsque c’est nécessaire et quel niveau de visibilité est disponible. L’enjeu est de concilier confidentialité, sécurité et auditabilité sans transformer les données clients en matière première accessible au fournisseur.

Les modèles avancés intensifient cette nécessité. Plus ils sont employés dans des chaînes automatisées, plus les requêtes peuvent être nombreuses et intégrer des éléments provenant de systèmes variés. Un assistant qui résume des comptes rendus est relativement circonscrit. Un agent relié à une base documentaire, à une messagerie, à des outils de gestion de projet ou à un système de relation client soulève des questions plus larges : quelles autorisations reçoit-il, quels documents peut-il consulter, quelles actions peut-il déclencher et quelles traces sont nécessaires à l’entreprise pour exercer son contrôle ?

Private Safety Processing, tel qu’OpenAI le présente, s’inscrit dans cette évolution. La confidentialité ne se limite plus au refus d’utiliser les données pour l’entraînement ou à une durée de conservation réduite. Elle devient une propriété de l’architecture de traitement : quels composants voient le contenu, à quel moment, pour quelle finalité, avec quelles restrictions et avec quelles possibilités de preuve pour le client ?

La transparence sera décisive au moment où ce mécanisme sera détaillé ou rendu disponible. Les grands comptes demanderont notamment une description claire du périmètre de traitement, des responsabilités de chaque partie, des exceptions éventuelles, des procédures d’incident et de la compatibilité avec leurs propres politiques de conservation. Les exigences seront d’autant plus fortes pour les entreprises européennes soumises à des contrôles internes rigoureux, ou qui travaillent avec des administrations, des établissements de santé, des assureurs et des infrastructures critiques.

Cette question concerne aussi les éditeurs de logiciels français qui construisent des produits sur l’API. Leur promesse de confidentialité envers leurs propres clients dépendra en partie de celle du fournisseur de modèle, mais aussi de leur capacité à configurer correctement l’outil, à éviter les logs excessifs et à mettre en œuvre des droits d’accès adaptés. Le niveau de confiance final sera rarement déterminé par une seule clause : il résultera de l’assemblage de garanties techniques, contractuelles et organisationnelles.

Une compétition frontale avec Anthropic et les autres fournisseurs d’IA d’entreprise

L’annonce d’OpenAI intervient dans un marché où la confidentialité est devenue un facteur de différenciation visible. Les premiers déploiements de modèles génératifs ont largement été tirés par la curiosité, les expérimentations de productivité et l’accès à des interfaces conversationnelles. À mesure que les projets passent en production, la discussion se déplace. Les clients ne comparent plus seulement la qualité d’une réponse ou les résultats d’un benchmark : ils évaluent le coût total, la disponibilité, la gouvernance, les intégrations, la sécurité et les conditions de traitement de leurs données.

Anthropic occupe une place particulière dans cette compétition. La société s’est fortement identifiée aux enjeux de sûreté des modèles et propose des services destinés aux développeurs et aux entreprises. Le brief d’OpenAI place explicitement l’annonce dans le contexte d’une concurrence accrue avec Anthropic sur la confidentialité. Cela souligne un changement de nature du marché : la protection des données n’est plus simplement un point de négociation entre une équipe achats et un fournisseur, elle devient un argument produit.

OpenAI ne se présente pas pour autant comme le seul acteur concerné. Les entreprises qui déploient des IA génératives peuvent également examiner les offres de grands fournisseurs de cloud, de sociétés spécialisées dans les modèles ou de solutions installées dans des environnements qu’elles contrôlent davantage. Les architectures auto-hébergées ou les modèles ouverts peuvent, dans certains cas, répondre à une volonté de garder les données dans une infrastructure choisie par l’organisation. Mais elles transfèrent alors vers le client d’autres responsabilités : exploitation, sécurité, mise à jour, supervision, coûts d’infrastructure et évaluation des modèles.

La comparaison ne peut donc pas se faire sur un seul critère. Un modèle fourni par API peut offrir un accès rapide à des capacités de pointe sans nécessiter d’héberger soi-même une importante infrastructure de calcul. En contrepartie, le client doit examiner le régime de traitement des données et son adéquation avec ses contraintes. Une solution gérée dans un environnement cloud particulier peut améliorer l’alignement avec des politiques existantes, mais ne supprime pas la nécessité de vérifier le contrat, les flux et les journaux. Une solution auto-hébergée peut réduire certains transferts externes, mais requiert des compétences et des ressources considérables.

Le ZDR annoncé par OpenAI vise précisément à réduire une partie du compromis associé à l’utilisation d’une API de modèle avancé. Pour certains clients, la crainte n’est pas le fait de traiter une requête à l’extérieur de leur propre système, mais la conservation ultérieure de cette requête ou de sa réponse. En proposant un cadre de non-conservation par défaut pour les clients éligibles, l’entreprise tente de rendre son offre plus compatible avec les politiques les plus restrictives.

Il faut cependant éviter de transformer la confidentialité en simple indicateur marketing. Deux offres peuvent employer des termes proches tout en couvrant des réalités différentes. La conservation des prompts et des réponses n’épuise pas le sujet. Les entreprises doivent aussi considérer l’usage éventuel des données, le statut des métadonnées, les données de diagnostic, les mécanismes de support, les options de journalisation, les localisations pertinentes pour leur conformité, les accès sous-traitants et les processus de suppression. Les réponses dépendent du fournisseur, du contrat et de la configuration retenue.

Pour les acheteurs, l’effet concurrentiel de l’annonce est néanmoins tangible. Lorsque plusieurs fournisseurs de modèles puissants cherchent à convaincre des comptes exigeants, une politique plus protectrice peut devenir déterminante au stade de la sélection. Un projet qui aurait été bloqué par la sécurité ou le juridique peut passer au stade de l’expérimentation si des garanties adaptées sont disponibles. Inversement, un fournisseur qui ne répond pas clairement aux exigences de conservation peut être écarté, même si son modèle est performant.

La compétition se joue aussi dans la capacité à servir des cas d’usage transversaux. Une entreprise n’achète pas nécessairement un modèle pour une seule tâche. Elle peut vouloir une plateforme capable de soutenir des assistants internes, des outils de rédaction, des systèmes de recherche documentaire, de l’analyse de données, du développement logiciel et des agents métier. Plus les cas d’usage sont nombreux, plus les catégories de données exposées sont variées. Les garanties de confidentialité doivent alors être suffisamment robustes pour fonctionner dans des environnements hétérogènes.

OpenAI cherche ici à consolider son attractivité auprès de ces organisations. L’entreprise ne renonce pas à la sécurité de ses modèles : Private Safety Processing est justement présenté comme une réponse au risque de voir la confidentialité réduire les capacités de contrôle. La promesse est ambitieuse car elle tente de réunir deux attentes qui ont longtemps été traitées séparément : la confidentialité des flux clients et la responsabilité du fournisseur dans le fonctionnement de modèles avancés.

Ce que l’annonce change pour les entreprises françaises et européennes

En France, l’adoption de l’IA générative dans les entreprises avance avec une prudence marquée dès lors que les projets touchent à des informations non publiques. Cette prudence concerne les grandes organisations, mais aussi les PME, les cabinets de conseil, les éditeurs de logiciels et les acteurs publics. Beaucoup peuvent tester un outil avec des données génériques, mais hésitent à l’intégrer à leurs processus réels sans garanties fortes sur les données.

Le régime ZDR d’OpenAI peut modifier cette étape de qualification pour les clients API éligibles. Un éditeur français qui souhaite intégrer un modèle de pointe dans son logiciel peut être mieux placé pour expliquer à ses clients que les requêtes et réponses ne sont pas conservées par défaut dans le cadre de l’offre annoncée. Une entreprise qui veut résumer des documents internes ou assister ses équipes sur un corpus privé peut disposer d’un élément supplémentaire pour évaluer le risque. Dans les deux cas, la formulation doit rester exacte : elle porte sur le périmètre et les conditions définis par OpenAI, non sur l’ensemble des systèmes utilisés par le client.

La question de la souveraineté numérique restera distincte. L’absence de conservation ne résout pas à elle seule les interrogations relatives à la localisation, au contrôle opérationnel, au droit applicable, aux dépendances technologiques ou à la réversibilité. En Europe, ces sujets sont souvent au cœur des décisions, notamment pour les administrations et les opérateurs soumis à des contraintes particulières. L’annonce d’OpenAI améliore potentiellement le profil de confidentialité de certains usages, mais elle ne met pas fin au débat sur le choix d’un fournisseur et d’une infrastructure.

Les organisations devront également distinguer les données personnelles des données simplement confidentielles. Le RGPD protège les données à caractère personnel, mais une entreprise peut vouloir préserver d’autres informations : stratégie commerciale, secrets de fabrication, négociations, prix, code source ou propriété intellectuelle. Le ZDR est susceptible d’intéresser ces deux catégories de données, car la question de la rétention ne se limite pas à la réglementation sur les données personnelles.

Pour les responsables de la protection des données, l’annonce appelle une démarche structurée. Il faudra identifier précisément les données qui peuvent être envoyées à l’API, définir les finalités, déterminer les rôles de chaque partie dans le traitement, vérifier les documents contractuels disponibles et analyser les mesures techniques. Les équipes de sécurité devront, elles, examiner la gestion des secrets d’API, l’authentification des utilisateurs, les droits d’accès aux sources documentaires, la prévention des fuites par les sorties du modèle et la journalisation interne.

La gestion des sorties est un point souvent sous-estimé. Un modèle peut produire une réponse qui reprend des informations confidentielles présentes dans son contexte. Même lorsque l’API ne conserve pas cette réponse dans le cadre du ZDR, l’application cliente peut la transmettre à un utilisateur, l’afficher dans une interface, l’envoyer par e-mail ou l’inscrire dans un outil de ticketing. Les mécanismes de classification, de contrôle d’accès et de prévention des fuites doivent donc couvrir l’aval du traitement, pas seulement l’appel au modèle.

De même, l’entreprise doit déterminer si elle souhaite conserver elle-même les échanges à des fins de qualité, de conformité ou de support. Une absence de rétention chez le fournisseur ne signifie pas qu’aucune trace n’est disponible pour l’organisation. Certaines entreprises auront besoin de journaux internes limités et protégés afin d’investiguer un incident ou de comprendre une décision automatisée. D’autres chercheront à minimiser ces traces. La bonne configuration dépend de l’usage, du niveau de risque et des obligations propres à chaque secteur.

Pour les startups françaises, le développement peut être plus rapide. Elles n’ont pas toujours les moyens d’opérer leurs propres modèles ou une infrastructure de calcul sophistiquée. Pouvoir accéder à des modèles de pointe par API dans un cadre de confidentialité renforcée peut abaisser une barrière à l’entrée pour des produits B2B qui manipulent des contenus professionnels. Mais ces entreprises devront elles aussi éviter les formulations excessives dans leur communication : elles ne peuvent pas promettre à leurs clients une sécurité globale sur la seule base d’une option de conservation côté fournisseur.

La portée économique de cette évolution dépendra donc de sa mise en œuvre concrète. Si l’accès au ZDR couvre effectivement les besoins des grands déploiements et si Private Safety Processing apporte des réponses vérifiables à la tension entre sûreté et confidentialité, OpenAI pourrait lever une objection récurrente dans les appels d’offres. Si les conditions sont trop étroites, les clients pourraient continuer à se tourner vers des architectures alternatives ou vers des concurrents dont les garanties leur paraissent plus directement adaptées.

Vers une nouvelle norme de marché pour les modèles de pointe

L’annonce d’OpenAI illustre une maturation rapide du marché de l’IA générative. Au début de la diffusion massive des assistants conversationnels, la question dominante était souvent celle de la capacité : que peut faire le modèle, à quel niveau de qualité, et pour quelles tâches ? Aujourd’hui, les entreprises demandent aussi si cette capacité peut être utilisée dans des flux réels sans compromettre leurs obligations de confidentialité, de sécurité et de contrôle.

Le ZDR pour les clients API éligibles utilisant des modèles de pointe répond à cette transition. La confidentialité n’est plus seulement une annexe contractuelle réservée aux négociations les plus complexes. Elle devient une fonctionnalité attendue pour que les modèles puissent entrer dans les systèmes de production. L’intérêt du dispositif dépendra de la précision de son périmètre, mais son positionnement envoie un signal : les fournisseurs devront expliquer plus clairement ce qu’ils conservent, ce qu’ils ne conservent pas et comment ils maintiennent la sécurité lorsque les données restent privées.

Private Safety Processing pourrait constituer l’étape suivante de cette évolution. Si OpenAI parvient à démontrer que des contrôles de sécurité peuvent être effectués sans exposer les contenus des clients, le débat se déplacera de la seule conservation vers les garanties de traitement. Les acheteurs demanderont alors des preuves sur la séparation des données, la limitation des accès et les mécanismes de vérification, plutôt que de se contenter d’une opposition entre rétention et absence de rétention.

Cette dynamique devrait également accroître la pression sur les concurrents d’OpenAI, dont Anthropic, mais aussi sur l’ensemble des fournisseurs qui ciblent les usages professionnels. À performances comparables, les entreprises privilégieront de plus en plus les offres capables de répondre à des questionnaires de sécurité exigeants, de s’intégrer à leurs processus de conformité et de limiter les zones d’incertitude sur les données. Les modèles les plus avancés ne seront pas seulement évalués pour ce qu’ils savent générer, mais pour les conditions dans lesquelles ils peuvent être utilisés.

Pour les organisations françaises et européennes, la perspective est double. Elles disposeront potentiellement de davantage d’options pour exploiter des modèles avancés dans des cas d’usage sensibles. Mais elles devront aussi devenir plus précises dans leurs exigences : demander un ZDR ne suffira pas si les applications, les connecteurs et les journaux internes restent mal maîtrisés. La confidentialité de l’IA s’imposera comme un sujet d’architecture et de gouvernance de bout en bout.

OpenAI tente ainsi de traiter ce qui pourrait être le dernier grand frein à la généralisation de certains déploiements : non pas la capacité technique des modèles, mais la confiance nécessaire pour leur confier des données de valeur. La réponse apportée par l’entreprise reste encadrée par l’éligibilité et par des modalités qui devront être examinées par chaque client. Elle confirme toutefois une tendance durable : dans l’IA d’entreprise, la frontière compétitive ne se situera plus uniquement dans le modèle, mais dans la manière dont le fournisseur protège les données qui lui sont confiées tout en conservant les garde-fous attendus pour des systèmes de plus en plus puissants.