Les promesses de confidentialité d’OpenAI Dots face à leur test le plus difficile

OpenAI a lancé Dots comme des agents toujours actifs malgré un conflit central : les protections de confidentialité d’OpenAI Dots exigent que le produit comprenne davantage la vie d’un utilisateur.

Un dot peut surveiller les applications connectées, conserver le contexte entre les conversations et continuer à travailler après le départ de son propriétaire. Ces capacités rendent l’agent utile. Elles lui donnent aussi accès aux messages, documents, agendas, identifiants et relations qui définissent son propriétaire.

OpenAI affirme que Dots peut conserver ces informations dans des environnements contrôlés et suspendre les actions risquées. Meta avance des affirmations similaires au sujet de Muse, son agent personnel concurrent. Il ne s’agit pas simplement d’une compétition visant à déterminer quel assistant accomplit le plus de tâches.

C’est une compétition pour savoir si l’une ou l’autre entreprise peut rendre un accès étendu aux données digne de confiance.

Le calendrier rend cette promesse difficile à évaluer. Les agents personnels quittent les fenêtres de chat pour s’intégrer aux e-mails, navigateurs, espaces de travail et plateformes de communication. Leur valeur augmente avec chaque compte connecté, mais l’impact d’une erreur aussi.

C’est pourquoi la confidentialité est devenue une fonctionnalité produit plutôt qu’une note de bas de page juridique. OpenAI et Meta ont besoin que les utilisateurs partagent suffisamment de contexte pour que leurs agents fonctionnent. Aucune des deux entreprises ne peut atteindre cet objectif sans que les utilisateurs fassent confiance aux systèmes avant que des preuves indépendantes ne soient complètes.

Ce que promet réellement la confidentialité d’OpenAI Dots

La confidentialité d’OpenAI Dots repose sur l’isolation, des autorisations limitées, une activité visible et l’approbation de l’utilisateur pour les actions sensibles.

OpenAI a présenté Dots lors de son événement DevDay le 29 septembre 2026. L’entreprise les décrit comme des agents persistants capables de gérer des responsabilités continues au lieu d’attendre des requêtes individuelles.

Un dot fonctionne depuis un ordinateur cloud dédié. Cela sépare l’environnement de travail de l’agent de l’appareil physique de l’utilisateur, sauf si celui-ci connecte des services supplémentaires.

Selon l’annonce de Dots, les utilisateurs peuvent communiquer avec ces agents via ChatGPT sur ordinateur, web et mobile. La prise en charge de Slack et Teams étend le même contexte de travail à plusieurs canaux.

Cette continuité constitue une partie importante du produit. Un utilisateur ne devrait pas avoir à expliquer le même projet à chaque fois que l’agent passe de ChatGPT à une conversation professionnelle.

OpenAI appelle l’activité de fond de l’agent « recherche proactive ». Au cours de ce processus, un dot peut examiner des informations provenant d’applications connectées via des outils en lecture seule. Ces outils ne peuvent pas envoyer de messages, modifier du contenu ou contrôler le navigateur de l’utilisateur.

OpenAI affirme également que ses systèmes de surveillance peuvent suspendre ou arrêter un dot lorsqu’ils détectent un problème de sécurité. Les règles personnalisées permettent aux utilisateurs d’autoriser, bloquer ou exiger une approbation pour certaines actions.

La distinction entre lire et agir est importante. Un agent qui lit un calendrier présente une catégorie de risque. Un agent capable d’annuler un rendez-vous, d’envoyer un e-mail ou d’acheter un billet en présente une autre.

La FAQ sur la confidentialité publiée par OpenAI indique que les actions très sensibles nécessitent l’intervention directe de l’utilisateur. Modifier un mot de passe ou transférer de l’argent devrait obliger l’utilisateur à reprendre la main.

D’autres actions peuvent exiger une approbation avant leur exécution. Cela inclut l’installation de logiciels ou la suppression définitive d’informations. OpenAI indique que les utilisateurs peuvent parfois fournir une approbation préalable pour des actions récurrentes et ciblées.

Ces contrôles établissent des limites, mais ils n’éliminent pas l’exposition sous-jacente. Un agent en lecture seule peut toujours découvrir des faits confidentiels, déduire des relations ou résumer des informations dans le mauvais contexte.

L’utilisation des données diffère aussi selon le type de compte. OpenAI affirme ne pas entraîner ses modèles sur les données des espaces de travail ChatGPT Business, Enterprise ou Edu par défaut.

Pour les forfaits personnels, le paramètre « Improve the model for everyone » détermine si les conversations et travaux Dots éligibles peuvent contribuer à l’amélioration des modèles. Ces travaux peuvent inclure des tâches déléguées, des données d’applications connectées et des actions réalisées par l’agent.

OpenAI indique ne pas entraîner directement ses modèles sur la recherche proactive ni sur les notes de travail privées d’un dot. Toutefois, les informations issues de cette recherche peuvent rejoindre une conversation éligible. Une fois présentes, leur traitement dépend des paramètres de l’utilisateur.

Cette distinction sera facile à manquer pour de nombreux utilisateurs. Les données peuvent passer d’un processus de fond protégé à une conversation sans sembler sensiblement différentes à la personne concernée.

L’entreprise a donc présenté un modèle de confidentialité à plusieurs niveaux, et non une garantie absolue. Sa crédibilité dépend de la cohérence du comportement de ces niveaux sous la pression des usages réels.

Pourquoi les agents personnels ont besoin de davantage de données que les chatbots

Un agent toujours actif ne peut devenir plus utile sans être mieux informé sur la personne qu’il représente.

Un chatbot peut répondre à une question isolée à l’aide d’une seule requête. Un agent personnel doit comprendre ce qui s’est passé auparavant, ce qui reste inachevé et quelle action future correspond aux intentions de l’utilisateur.

Cela exige de la mémoire. Cela nécessite aussi un accès à des systèmes en direct où les décisions ont des conséquences.

Prenons l’exemple d’un agent qui organise un déplacement professionnel. Il a besoin du calendrier du voyageur, de la destination, des préférences aériennes, de la politique de dépenses, des exigences liées au passeport et de l’historique des communications.

Il peut aussi avoir besoin d’accéder aux e-mails, aux outils de paiement, aux fichiers d’entreprise et aux emplois du temps d’autres personnes. Une réponse utile dépend de la combinaison de ces sources plutôt que de leur lecture séparée.

C’est la même raison pour laquelle un second cerveau d’IA personnel gagne en valeur à mesure qu’il accumule du contexte. Le système peut retrouver des connaissances pertinentes parce qu’il les a conservées et organisées.

Un agent autonome pousse ce même modèle un cran plus loin. Il ne se contente pas de récupérer du contexte. Il utilise ce contexte pour agir.

Le problème de confidentialité qui en résulte comporte trois niveaux.

Premièrement, l’agent peut accéder aux informations que l’utilisateur fournit sciemment. Cela comprend les messages, fichiers, préférences et comptes connectés.

Deuxièmement, il peut déduire des informations que l’utilisateur n’a jamais saisies comme faits formels. Des événements récurrents dans un calendrier peuvent révéler un traitement médical. Des schémas d’e-mails peuvent exposer des négociations commerciales ou des relations personnelles.

Troisièmement, l’agent rencontre des données concernant des personnes qui n’ont jamais accepté ses conditions. La boîte de réception d’un utilisateur contient des correspondances de collègues, clients, proches et amis.

Un agent peut avoir besoin de cette correspondance pour accomplir une tâche légitime. Les autres participants peuvent ne pas savoir qu’un système d’IA traite leurs mots ou construit un modèle opérationnel de leur relation.

Cela rend le consentement plus complexe que ne le suggère un écran standard d’autorisation d’application. Accorder l’accès aux e-mails ne répond pas à toutes les questions sur la manière dont les informations contenues dans ces messages doivent être interprétées ou conservées.

Les agents persistants modifient aussi le sens du principe du moindre privilège. Le moindre privilège est le principe de sécurité selon lequel un système ne devrait recevoir que les accès nécessaires à sa tâche immédiate.

Un agent toujours actif a rarement une seule tâche immédiate. Il est conçu pour repérer des opportunités, préparer du travail et conserver du contexte pour de futures demandes.

Un accès étendu soutient cette flexibilité. Un accès restreint réduit les dommages potentiels, mais limite aussi ce que l’agent peut accomplir.

OpenAI tente de gérer cette tension en séparant l’activité proactive en lecture seule des actions qui modifient des systèmes externes. Cette séparation est judicieuse, mais la lecture elle-même peut avoir des conséquences.

Un agent compromis pourrait exposer des résumés sensibles sans modifier un document source. Il pourrait aussi introduire du matériel confidentiel dans un canal partagé ou l’utiliser lors de la rédaction d’une réponse sans rapport.

L’injection de prompt ajoute une autre couche. Une injection de prompt est une instruction cachée dans un contenu qui tente de détourner un système d’IA de l’objectif réel de l’utilisateur.

Un agent qui navigue sur le web et traite des e-mails rencontre constamment des instructions non fiables. Il doit distinguer le contenu légitime des textes conçus pour manipuler son comportement.

OpenAI affirme que Dots intègre des contrôles de surveillance et d’autorisation. Pourtant, aucune conception actuelle ne fait disparaître les injections de prompt. La véritable question est de savoir à quelle fréquence les défenses échouent et quel niveau d’accès demeure disponible lorsqu’elles échouent.

Cela fait de la confidentialité un test architectural. Le langage des politiques compte, mais les frontières d’isolation, la gestion des identifiants, les journaux d’audit et les procédures de récupération comptent davantage.

OpenAI Dots face à Meta Muse : une compétition de confiance

La compétition entre OpenAI Dots et Meta Muse sera décidée par des limites vérifiables, et non par l’entreprise qui emploie le langage de confidentialité le plus affirmé.

Meta a présenté Muse quelques semaines avant qu’OpenAI ne dévoile Dots. Les deux produits promettent une assistance continue, une mémoire persistante, une exécution dans le cloud et un contrôle utilisateur sur les actions sensibles.

Muse fonctionne dans une machine virtuelle dédiée, ou VM. Une VM est un ordinateur logiciel isolé qui contient les fichiers, outils, navigateur et environnement d’exploitation de l’agent.

Meta indique que chaque utilisateur reçoit un environnement isolé. Les identifiants sont stockés dans un conteneur distinct, tandis qu’un agent Sentinel examine l’activité sortante de Muse.

Le lancement de Muse par l’entreprise indique que l’agent demande une autorisation avant des actions telles que l’envoi d’e-mails ou la réalisation d’achats. Les utilisateurs peuvent également consulter une piste d’audit.

Ces fonctionnalités ressemblent à l’approche d’OpenAI. Les deux entreprises isolent l’activité des agents dans le cloud, dissimulent les identifiants au modèle et placent des étapes d’approbation autour des actions importantes.

Les différences importantes apparaissent dans la manière dont chacune décrit l’accès et les protections futures.

Meta reconnaît que son architecture actuelle n’empêche pas techniquement l’entreprise d’accéder aux données de Muse. Ses politiques limitent l’accès des employés, mais Meta peut accéder aux informations lors de l’exploitation, de la sécurisation ou de l’assistance du service.

Meta indique prévoir d’introduire une Confidential VM plus tard en 2026. L’entreprise affirme que cette version empêchera cryptographiquement Meta et les autres fournisseurs de services de consulter les informations présentes dans l’environnement.

Cette protection renforcée faisait encore l’objet de tests et d’un examen externe lorsque Meta l’a décrite. Elle devrait donc être considérée comme une protection prévue plutôt que comme une propriété de chaque session Muse actuelle.

Meta indique également que les trajectoires de conversation de Muse peuvent contribuer à l’entraînement. Une trajectoire comprend les conversations, les appels d’outils et les transferts entre agents.

L’entreprise affirme retirer les principales informations permettant d’identifier une personne avant d’utiliser ces trajectoires. Les utilisateurs peuvent désactiver l’entraînement dans les paramètres.

OpenAI donne également aux utilisateurs de comptes personnels le contrôle de l’entraînement. Les deux modèles font peser une responsabilité importante sur des paramètres que les utilisateurs doivent comprendre et configurer.

L’explication de sécurité publiée par Meta fait une autre concession importante. Elle indique que Muse n’est pas immunisé contre les attaques et que l’injection de prompt reste un problème ouvert pour l’ensemble du secteur.

Cet aveu est plus utile qu’une affirmation de sécurité inconditionnelle. Il identifie le véritable critère que les acheteurs devraient appliquer : non pas si une attaque est possible, mais comment le système en limite les dégâts.

L’avantage d’OpenAI réside dans sa relation établie avec les consommateurs et les entreprises via ChatGPT. Dots peut hériter des connexions, contrôles de compte et canaux de distribution professionnels de cette plateforme.

L’avantage de Meta réside dans sa présence sur WhatsApp, Instagram, Facebook et les appareils connectés. Ces services peuvent fournir un vaste contexte relationnel et comportemental.

Les mêmes avantages créent une pression. OpenAI doit démontrer qu’un dot ne transmettra pas de contexte sensible au mauvais espace de travail. Meta doit convaincre les utilisateurs que son activité publicitaire ne compromet pas les limites de confidentialité de Muse.

Meta indique que les conversations Muse et les données des VM ne transitent pas directement vers ses systèmes publicitaires. L’entreprise précise également que l’activité de navigation d’un agent peut influencer indirectement les publicités.

Par exemple, un détaillant visité par Muse peut ensuite exploiter cette visite pour cibler une publicité sur Instagram. Les données de l’agent peuvent rester hors des systèmes publicitaires de Meta alors que ses actions génèrent malgré tout des signaux publicitaires.

Cette distinction est techniquement importante. Elle peut ne pas sembler significative à un utilisateur qui voit une publicité liée à une tâche déléguée à l’agent.

OpenAI fait face à un problème de communication parallèle. Les utilisateurs doivent comprendre quand une recherche proactive reste exclue de l’entraînement et quand cette même information devient éligible après son entrée dans une conversation.

Dans les deux cas, le modèle de confidentialité comporte des limites difficiles à résumer. Un unique bouton de confidentialité ne peut pas expliquer chaque transition entre mémoire, inférence, entraînement, navigation et action.

Les entreprises vendent donc de la confiance avant que les utilisateurs puissent vérifier indépendamment l’ensemble du système. Celle qui fournira les journaux les plus clairs, les paramètres par défaut les plus solides et une infrastructure vérifiable avancera l’argument le plus crédible.

Les contrôles de confidentialité ne sont pas des garanties de confidentialité

Les demandes d’autorisation peuvent réduire les dommages accidentels, mais elles ne peuvent pas prouver qu’un agent a compris la bonne limite.

Les systèmes d’autorisation traditionnels supposent que l’accès correspond clairement à une ressource. Une application peut recevoir l’autorisation d’utiliser un appareil photo, de lire des contacts ou d’afficher un dossier.

Les autorisations des agents sont plus complexes, car le logiciel interprète les informations et choisit ses actions de manière dynamique. Le même accès à des e-mails peut permettre un résumé inoffensif ou exposer une négociation confidentielle.

Un écran d’approbation peut afficher l’action immédiate sans révéler chaque fait qui l’a déterminée. Un utilisateur pourrait approuver un e-mail sans réaliser que le brouillon s’appuie sur des éléments provenant d’un autre compte.

L’approbation préalable ajoute une incertitude supplémentaire. Elle peut aider un agent à effectuer un travail récurrent prévisible sans interrompre l’utilisateur à chaque fois.

Cependant, les conditions changent. Une autorisation permanente d’envoyer des mises à jour hebdomadaires peut rester active après qu’un projet est devenu confidentiel ou que ses destinataires ont changé de rôle.

Les journaux sont essentiels dans ces cas. Les utilisateurs doivent voir ce à quoi l’agent a accédé, ce qu’il a déduit, quel outil il a utilisé et pourquoi il a sélectionné une action.

Un enregistrement complet des événements aide également les enquêteurs à reconstituer les défaillances. Sans cela, les entreprises peuvent savoir qu’un agent a agi incorrectement sans savoir quelle instruction non fiable a modifié son comportement.

La visibilité après un incident ne prévient pas l’incident lui-même. Certaines actions peuvent être annulées, mais une divulgation ne peut souvent pas l’être.

Un agent peut rappeler un e-mail ou restaurer un fichier modifié. Il ne peut pas garantir qu’un destinataire oubliera des informations confidentielles.

La même limite s’applique aux données personnelles stockées en mémoire. Supprimer un message source ne permet pas nécessairement de savoir si l’agent a conservé ailleurs un fait qu’il en a extrait.

Les utilisateurs ont également besoin de clarté concernant les sauvegardes. Un système peut supprimer des données actives tout en conservant des copies récupérables pour des raisons de sécurité ou d’exploitation.

Les droits à l’effacement des données peuvent résoudre une partie de cette complexité. OpenAI indique que les utilisateurs peuvent demander l’accès, la rectification, la suppression ou des copies d’informations personnelles, lorsque cela s’applique.

Pourtant, un agent peut traiter des informations sur des non-utilisateurs. Ces personnes peuvent ne pas savoir quel agent de quel client a collecté les informations ni où adresser une demande.

Les premiers articles sur Muse illustrent cette préoccupation. Un chercheur indépendant en sécurité aurait extrait des instructions internes décrivant des pages sur les personnes présentes dans la vie d’un utilisateur.

Les constatations sur la mémoire de Muse qui en ont résulté suggèrent que ces pages pourraient inclure des membres de la famille, des collègues, des amis et d’autres contacts. Cette constatation n’établit pas que chaque utilisateur de Muse possède des profils détaillés sur chacun de ses contacts.

Elle montre toutefois comment la mémoire d’un agent peut s’étendre au-delà du titulaire du compte. Une personne peut ne jamais utiliser le produit tout en apparaissant dans le contexte relationnel d’un autre utilisateur.

OpenAI n’a pas publiquement présenté Dots comme utilisant la même structure de mémoire. L’exemple de Muse ne doit pas être considéré comme la preuve d’un comportement identique.

Il reste néanmoins un avertissement pertinent. Les agents personnels ont besoin de connaissances relationnelles, et ces connaissances appartiennent rarement à une seule personne.

La réponse privilégiée par le secteur est le contrôle de l’utilisateur. Ce principe demeure nécessaire, mais il est incomplet lorsqu’un utilisateur contrôle des données impliquant de nombreuses autres personnes.

Une confidentialité plus forte exige donc davantage que des paramètres. Elle exige des limites concernant la collecte, la conservation, l’inférence, la réutilisation entre contextes, l’accès des employés et l’entraînement secondaire.

Les entreprises doivent également rendre ces limites vérifiables. Des auditeurs indépendants doivent avoir accès aux conceptions des systèmes, aux modèles de menace et à des preuves reproductibles.

Les programmes de récompense pour la découverte de bugs peuvent aider les chercheurs à signaler les vulnérabilités en toute sécurité. Ils ne remplacent pas une évaluation formelle, en particulier lorsqu’une défaillance concerne un comportement ordinaire du produit plutôt qu’une exploitation logicielle.

Les preuves décisives viendront des incidents et des réponses qui leur seront apportées. La promesse de confidentialité d’une entreprise devient crédible lorsqu’elle divulgue les défaillances, limite les dégâts, corrige la cause et informe clairement les utilisateurs.

Ce que les premières défaillances révèlent sur la confidentialité des agents

La confidentialité des agents peut échouer même lorsque le modèle sous-jacent ne voit jamais un mot de passe et que l’utilisateur a approuvé chaque connexion.

L’isolation des identifiants répond à une menace sérieuse. Si un modèle ne peut pas lire un mot de passe stocké, une instruction malveillante a moins de possibilités de le voler directement.

Cette protection n’empêche pas un agent d’utiliser abusivement une session authentifiée. L’agent peut accéder à un service au moyen d’un jeton valide et effectuer une action que l’utilisateur n’avait pas l’intention de réaliser.

Une limite de sécurité doit donc régir à la fois les secrets et les capacités. Masquer un identifiant est insuffisant si l’agent peut utiliser librement l’accès que cet identifiant fournit.

OpenAI indique que Dots sépare les mots de passe enregistrés du modèle. Meta avance une affirmation similaire pour Muse. Les deux approches réduisent l’exposition, mais laissent les décisions d’autorisation au sein du système d’agent plus large.

La première vague de tests publics se concentrera sur les défaillances évidentes. Les chercheurs tenteront de pousser les agents à révéler des prompts système, à ignorer les règles d’autorisation ou à suivre des instructions intégrées dans des pages web.

Les défaillances les plus difficiles seront contextuelles. Un agent pourrait divulguer la bonne information à la mauvaise personne, programmer une action au mauvais moment ou combiner des faits entre plusieurs projets.

Ces défaillances sont difficiles à empêcher, car chaque étape individuelle peut sembler raisonnable. Le préjudice émerge de la séquence.

Supposons qu’un dot prépare une proposition client à l’aide d’e-mails connectés et de fichiers internes. Il identifie correctement le client, les exigences du produit et les négociations précédentes.

Un document partagé contient une ancienne note sur la remise accordée à un autre client. L’agent traite cette note comme une règle tarifaire générale et l’intègre à la nouvelle proposition.

Aucun attaquant n’a eu besoin de voler un mot de passe. Aucun logiciel malveillant n’a eu besoin de quitter l’ordinateur cloud. L’agent a simplement franchi une limite contextuelle.

La révision humaine peut détecter certaines erreurs. Toutefois, la promesse d’un agent toujours actif dépend de la réduction du niveau de révision nécessaire.

Si les utilisateurs doivent examiner chaque source et chaque inférence, une grande partie du gain d’efficacité disparaît. S’ils approuvent rapidement les actions, l’approbation devient cérémonielle.

Cela crée un compromis de conception produit. Des avertissements fréquents encouragent les utilisateurs à les ignorer, tandis que des avertissements moins nombreux donnent à l’agent davantage de latitude.

Les entreprises ont besoin de systèmes d’approbation fondés sur les risques, qui distinguent le travail courant et réversible des actions inhabituelles ou irréversibles. Ces systèmes doivent également expliquer pourquoi une action semble risquée.

L’environnement de sécurité plus large augmente les enjeux. La couverture de DevDay a souligné qu’OpenAI avait présenté Dots peu après avoir suspendu le déploiement d’un autre modèle pour des raisons de sécurité.

Cette séquence ne prouve pas que Dots est dangereux. Elle montre toutefois pourquoi les assurances d’OpenAI feront l’objet d’un examen attentif.

OpenAI demande aux utilisateurs d’accepter un système qui reste actif, observe des informations connectées et accomplit des tâches sur des services externes. Le niveau de preuve exigé devrait correspondre à ce niveau d’autorité.

Meta fait face à la même charge. Muse peut naviguer, remplir des formulaires, envoyer des communications, effectuer des achats et maintenir un contexte à long terme.

Les garde-fous publics des entreprises constituent des points de départ raisonnables. Ils n’établissent pas les taux de défaillance réels.

Les tests indépendants doivent examiner la fréquence à laquelle les agents demandent un accès inutile, classent mal des actions sensibles et exposent des informations entre comptes.

Les clients d’entreprise voudront également des preuves concernant les contrôles administrateurs. Une approbation personnelle peut ne pas satisfaire les règles organisationnelles relatives à la conservation, aux obligations de conservation légale ou aux informations réglementées.

Les consommateurs sont confrontés à des questions différentes. Ils ont besoin d’explications sur la confidentialité qui n’exigent pas une expertise en machines virtuelles, en entraînement de modèles ou en informatique confidentielle.

Un système peut être techniquement sophistiqué tout en échouant si ses paramètres créent un faux sentiment de confiance. L’interface utilisateur fait partie du modèle de sécurité.

La conception gagnante rendra les comportements sûrs plus faciles que les comportements dangereux. Elle supposera également que les utilisateurs manquent des avertissements, accordent un accès excessif et comprennent mal les flux de données.

Cette norme est exigeante, car les agents promettent d’éliminer les frictions. Les protections de confidentialité ajoutent souvent des frictions précisément là où l’automatisation tente de les éliminer.

Trois tests détermineront si les promesses tiennent

La prochaine étape de la confidentialité d’OpenAI Dots sera jugée au travers de tests indépendants, d’une gestion transparente des incidents et d’une adoption sans autorisations excessives.

Le premier signal est la vérification technique.

OpenAI devrait fournir suffisamment de détails pour que des chercheurs externes puissent examiner l’isolation, l’application des autorisations, la gestion des identifiants et les défenses contre les injections de prompts. Les affirmations de sécurité gagnent en force lorsque des chercheurs qualifiés peuvent reproduire les preuves sous-jacentes.

La Confidential VM prévue par Meta crée un test similaire. Meta indique que des auditeurs externes examineront la conception et que des informations d’audit continues deviendront publiquement visibles.

Si ce système est lancé avec des preuves accessibles, il relèvera les attentes envers chaque fournisseur d’agents personnels. S’il reste limité ou est retardé, la promesse de confidentialité la plus forte de Meta restera non prouvée.

La vérification technique devrait également couvrir les limites entre les services. Dots peut maintenir un contexte entre ChatGPT, Slack, Teams et des applications connectées.

Les chercheurs doivent vérifier que les informations respectent les limites prévues entre utilisateurs et espaces de travail. Un ordinateur cloud sécurisé offre peu de protection si le contexte atteint un canal non autorisé.

Le deuxième signal est la divulgation des incidents.

Les agents feront des erreurs. OpenAI et Meta reconnaissent toutes deux cette réalité, directement ou à travers les garde-fous qu’elles décrivent.

Les questions importantes sont la rapidité avec laquelle chaque entreprise détecte les défaillances et l’étendue des informations qu’elle communique aux utilisateurs concernés. Des divulgations utiles devraient identifier les informations impliquées, le contrôle défaillant et la mesure corrective.

Observez si les entreprises publient des explications limitées ou des changements mesurables. Une assurance vague selon laquelle la sécurité s’est améliorée ne montre pas quelle limite a échoué.

Les utilisateurs devraient également vérifier si les agents fournissent des historiques d’activité complets. Une piste d’audit doit contenir suffisamment de détails pour distinguer une erreur de modèle d’une défaillance d’autorisation ou d’une instruction malveillante.

Le troisième signal est le comportement des utilisateurs.

Une architecture de protection de la vie privée peut sembler convaincante alors même que les utilisateurs continuent de ne pas connecter leurs comptes sensibles. Des démonstrations à faible risque ne prouvent pas que les gens font confiance à des agents pour gérer leurs finances, documents professionnels, informations de santé ou communications privées.

L’adoption par les clients d’entreprise offrira un indicateur utile. Les équipes de sécurité exigent généralement des contrôles plus clairs, des engagements contractuels et une visibilité administrative.

Le comportement des consommateurs compte aussi. Les utilisateurs peuvent adopter largement les agents tout en les limitant aux achats, à la recherche de voyages et aux informations publiques.

Un tel schéma indiquerait un intérêt pour l’automatisation sans confiance totale. Des connexions plus poussées aux e-mails, calendriers et archives personnelles signaleraient une confiance accrue, même si les entreprises doivent communiquer ces indicateurs avec prudence.

Les schémas d’autorisation sont plus révélateurs que le simple total de comptes. Un agent comptant des millions d’utilisateurs peut néanmoins n’avoir qu’un accès limité aux systèmes ayant des conséquences importantes.

Les lecteurs devraient également surveiller si les paramètres de confidentialité par défaut deviennent plus stricts. OpenAI et Meta permettent tous deux aux utilisateurs particuliers de contrôler si certaines interactions servent à l’entraînement des modèles.

Un paramètre par défaut qui réduit au minimum les usages secondaires allégerait la charge pour les utilisateurs qui ne modifient jamais leurs réglages. Un paramètre par défaut autorisant un usage plus large accorde davantage de poids à la divulgation et au consentement éclairé.

La question fondamentale n’est pas de savoir si OpenAI ou Meta peuvent rédiger une déclaration de confidentialité persuasive. Les deux entreprises peuvent décrire des contrôles à plusieurs niveaux et des intentions responsables.

La question est de savoir si ces contrôles résistent aux utilisateurs ordinaires, aux contenus hostiles, aux instructions ambiguës et à la pression visant à rendre les agents plus autonomes.

Les agents personnels ont besoin d’un contexte intime pour offrir la valeur qu’ils promettent. Il ne s’agit pas d’un risque de confidentialité accidentel. C’est l’exigence opérationnelle centrale du produit.

La protection de la vie privée d’OpenAI Dots ne gagnera la confiance que lorsque les utilisateurs pourront vérifier ce que l’agent savait, pourquoi il a agi et où leurs informations ont été envoyées. Meta Muse est soumis au même critère.

Avant de connecter un agent toujours actif au cœur de votre vie numérique, vérifiez son paramètre d’entraînement, limitez les autorisations et examinez son historique d’activité. Posez-vous ensuite une question plus difficile : si l’agent tire demain une mauvaise conclusion, pouvez-vous la voir, l’arrêter et réparer les dégâts ?