La propriété des données d’IA place les protections des entreprises et les outils grand public sur des trajectoires différentes

Google News a mis en avant une analyse de TechTarget qui place un conflit non résolu au cœur de l’adoption de l’IA en entreprise : la propriété ne garantit pas le contrôle. Les entreprises peuvent conserver les droits juridiques sur leurs données tout en perdant la maîtrise pratique de leur stockage, de leur examen, de leur récupération ou de leur réutilisation.

Cette distinction est devenue urgente à mesure que les employés connectent des assistants d’IA à des documents, des e-mails, du code source, des transcriptions de réunions et des dossiers clients. Chaque connexion élargit ce qu’un modèle peut récupérer, transformer et exposer par l’intermédiaire du compte d’un utilisateur autorisé.

Les principaux fournisseurs proposent désormais des produits professionnels qui excluent par défaut le contenu client de l’entraînement des modèles. Pourtant, ces engagements varient selon le produit, le type de compte, la configuration, le service connecté et le contrat.

La véritable opposition n’est donc pas celle des entreprises contre les fournisseurs d’IA. Elle met en regard la promesse de propriété par le client et la réalité d’un contrôle des données délégué.

Google News met en lumière un problème contractuel, pas seulement un problème de confidentialité

Le changement important est que la propriété des données d’IA est passée d’une question juridique abstraite à une décision quotidienne d’achat et de sécurité.

Le titre de TechTarget diffusé par Google News demande qui possède les données fournies aux systèmes d’IA. Cette question couvre les prompts, les fichiers téléversés, les dossiers d’entreprise récupérés, les réponses générées, les retours et les journaux d’interaction.

Ces catégories ne bénéficient pas toujours d’un traitement identique. Un fournisseur peut laisser un client posséder les prompts et les sorties tout en conservant des données opérationnelles à des fins de sécurité, de prévention des abus, de débogage ou de conformité légale.

Une clause de propriété n’indique pas non plus si des personnes examinent les informations soumises. Elle ne précise pas à quelle vitesse le contenu supprimé disparaît des sauvegardes, ni si une application connectée en conserve une autre copie.

C’est pourquoi une simple réponse affirmative peut induire les acheteurs en erreur. La propriété décrit des droits juridiques, tandis que la gouvernance des données couvre la collecte, l’accès, le traitement, la conservation, le transfert et la suppression.

Prenons le cas d’un chef de produit qui demande à un assistant de résumer une étude non publiée. L’entreprise possède probablement le rapport téléversé, mais ce seul fait ne détermine pas où le rapport circule.

L’assistant peut récupérer le fichier par le biais d’un connecteur d’entreprise. Il peut envoyer des extraits pertinents à un modèle, stocker la conversation, créer un enregistrement d’audit et transmettre des métadonnées via un autre service.

Chaque étape crée un point de contrôle différent. Les équipes de sécurité doivent savoir quelle partie exploite ce point et quelle politique le régit.

Le même problème se pose dans le développement logiciel. Un programmeur peut posséder un code source propriétaire tout en le divulguant en le plaçant dans un chatbot grand public non approuvé.

La propriété juridique n’annule pas cette divulgation. Elle ne rétablit pas non plus un secret commercial après que des éléments confidentiels ont atteint un destinataire non autorisé ou un service mal configuré.

Les sorties générées ajoutent une autre couche d’ambiguïté. Plusieurs fournisseurs destinés aux entreprises attribuent aux clients les droits disponibles sur les sorties, mais une telle attribution ne peut garantir que chaque sortie est unique.

Un modèle peut produire des contenus similaires pour différents utilisateurs. Il peut également reproduire une expression protégée, exposer des informations mémorisées ou générer du code soumis à une licence open source.

Google avertit lui-même que les utilisateurs restent responsables de leur utilisation du code généré par Gemini. Ses recommandations indiquent qu’un tel code peut être soumis à une licence open source.

Cet avertissement illustre la différence entre le langage de propriété et l’exclusivité réellement exploitable. Une entreprise peut recevoir des droits contractuels sans obtenir la garantie qu’aucun tiers ne détient de droits concurrents.

L’apparition de l’article dans un flux consacré à la réglementation et à la sécurité de l’IA reflète également une évolution plus large. Les questions liées aux données relient désormais la confidentialité, la cybersécurité, la propriété intellectuelle, la gestion des dossiers et la supervision des fournisseurs.

Ces fonctions relèvent souvent de responsables distincts. Les systèmes d’IA les obligent à examiner ensemble le même flux d’informations.

Un bon point de départ consiste à inventorier les informations entrant dans chaque service. Les équipes devraient distinguer les prompts, les fichiers sources, les extraits récupérés, les sorties, les retours, la télémétrie et les journaux administratifs.

Cet inventaire n’est pas un exercice théorique de conformité. Il détermine quelles promesses comptent et quels contrôles peuvent réellement être testés.

La distinction entre grand public et entreprise change la réponse

Le compte utilisé pour accéder à un service d’IA peut compter autant que le nom du fournisseur.

Une entreprise ne peut pas évaluer en toute sécurité « Gemini », « ChatGPT » ou « Copilot » comme un environnement de données unique et uniforme. Les applications grand public, les espaces de travail professionnels, les API et les modèles hébergés dans le cloud peuvent relever de conditions différentes.

OpenAI indique que ses produits professionnels et sa plateforme API n’utilisent pas par défaut les entrées ou sorties des clients pour l’entraînement des modèles. Sa politique relative aux données professionnelles couvre certaines offres professionnelles, éducatives, de santé et API.

L’entreprise précise également que les organisations admissibles peuvent configurer la conservation, y compris l’absence de conservation des données pour certains usages de l’API. La disponibilité et les exceptions techniques doivent néanmoins être examinées pour le service choisi.

OpenAI indique utiliser le chiffrement AES-256 au repos et TLS 1.2 ou version ultérieure en transit. Ces mesures protègent certaines étapes du cycle de vie des données, mais elles ne remplacent pas la gouvernance des accès.

Le chiffrement ne peut empêcher un employé autorisé de soumettre des informations restreintes. Il ne peut pas non plus corriger des autorisations excessives héritées par un assistant connecté.

Google établit une limite tout aussi importante. Pour l’utilisation gérée de Gemini dans Chrome, Google indique que les prompts et le contexte de navigation ne sont pas utilisés pour entraîner des modèles publics.

Ses contrôles de confidentialité pour les entreprises précisent également que les protections Workspace existantes s’appliquent. Google affirme que le contenu n’est pas examiné par des humains ni utilisé pour l’entraînement des modèles en dehors du domaine du client sans autorisation.

Cette protection dépend de l’utilisation d’un compte géré. Google le distingue explicitement d’un compte Gmail personnel dans les mêmes recommandations.

L’environnement Gemini grand public applique des contrôles et un comportement de conservation différents. L’avis de confidentialité de Gemini de Google indique que Keep Activity prévoit par défaut une suppression automatique après 18 mois.

Les utilisateurs peuvent modifier ce paramètre à trois mois, 36 mois ou une conservation indéfinie. Ils peuvent également supprimer les conversations manuellement.

Google indique qu’un sous-ensemble de discussions peut faire l’objet d’un examen humain afin d’améliorer ses services. Les discussions examinées peuvent être conservées jusqu’à trois ans après avoir été dissociées du compte de l’utilisateur.

Désactiver Keep Activity modifie l’utilisation future, mais ne produit pas une absence de conservation instantanée. Google indique que les discussions temporaires et celles créées lorsque ce paramètre est désactivé sont conservées pendant 72 heures.

Ce contraste est important pour les employés qui utilisent des comptes personnels au travail. Une interface familière peut masquer un accord sur les données sensiblement différent.

Microsoft indique que les prompts, les réponses et les données Microsoft Graph dans Microsoft 365 Copilot ne sont pas utilisés pour entraîner les modèles de fondation. Sa protection des données d’entreprise applique les contrôles Microsoft 365 d’identité, de conservation, de sensibilité et d’audit.

Microsoft agit également en tant que sous-traitant au titre de ses conditions applicables aux entreprises. Ce rôle implique des obligations contractuelles définies, mais les clients restent responsables des accès utilisateurs et des choix de déploiement.

Les conditions commerciales d’Anthropic fournissent un autre exemple. Dans les conditions publiées pour Claude via Google Vertex AI, Anthropic indique que les clients possèdent les sorties lorsque la loi le permet.

Ces conditions renoncent également aux droits d’Anthropic sur le contenu client et interdisent l’entraînement sur ce contenu client. Les données d’utilisation sont décrites séparément des prompts et des sorties.

Le schéma commun est encourageant, mais conditionnel. Les offres professionnelles formulent de plus en plus clairement leurs engagements en matière d’entraînement, de propriété et de contrôles administratifs.

La faiblesse apparaît lorsque les organisations supposent que ces protections accompagnent chaque employé dans chaque interface. Elles ne suivent pas nécessairement les comptes personnels, les fonctionnalités expérimentales, les connecteurs tiers ou les sorties copiées.

L’IA fantôme intensifie cet écart. Elle survient lorsque des employés utilisent des services d’IA non approuvés en dehors de l’environnement géré par leur employeur.

L’employé peut choisir un outil grand public parce qu’il est disponible, familier ou mieux adapté à une tâche. L’organisation perd alors son levier contractuel, sa journalisation centralisée et le contrôle de la configuration.

Bloquer chaque assistant public résout rarement le problème d’adoption. Les personnes ont toujours besoin d’options approuvées adaptées à leurs véritables flux de travail de recherche, de rédaction, de programmation et d’analyse.

Une conception plus sûre sépare les tâches autorisées selon la classe d’information. Les informations publiques peuvent être saisies dans un service grand public approuvé, tandis que les éléments confidentiels exigent un environnement d’entreprise géré.

Les informations restreintes peuvent nécessiter un service isolé ou interdire complètement le traitement par des modèles externes. La classification doit suivre l’impact sur l’entreprise, et non l’enthousiasme pour un fournisseur particulier.

Cette différence façonne également les systèmes personnels de gestion des connaissances. Une base de connaissances personnelle nécessite des limites claires entre les éléments individuels et les dossiers organisationnels partagés.

Sans ces limites, la récupération peut devenir un raccourci d’accès. Un assistant utile peut faire remonter des informations que son utilisateur actuel n’aurait jamais dû recevoir.

Les promesses de propriété se heurtent au contrôle délégué des données

Le compromis central est simple : une IA utile a besoin de contexte, mais chaque source supplémentaire élargit la frontière de sécurité du système.

Un chatbot autonome ne voit que ce qu’un utilisateur soumet. Un assistant d’entreprise connecté peut accéder aux e-mails, calendriers, historiques de discussion, référentiels de documents, plateformes de code et systèmes clients.

Ce contexte supplémentaire améliore la pertinence. Il transforme aussi la question centrale de sécurité, qui passe de « Qu’a collé l’employé ? » à « Que peut récupérer l’assistant ? »

La génération augmentée par récupération, souvent appelée RAG, fournit à un modèle des informations externes sélectionnées lorsqu’il répond à une demande. Le modèle n’a pas besoin d’être entraîné de façon permanente sur ces informations pour les exposer.

Cette distinction est essentielle. Une promesse de non-entraînement peut être exacte alors que du contenu sensible transite toujours par l’inférence, les journaux, les caches, les connecteurs ou les réponses générées.

Un assistant peut également révéler des données parce que le référentiel sous-jacent accorde déjà un accès excessif. L’interface d’IA rend ce vieux problème d’autorisations plus facile à exploiter.

Avant l’IA, un employé devait peut-être savoir quel dossier contenait une prévision confidentielle. Un système conversationnel peut localiser le fichier pertinent à partir d’une vaste question formulée en langage naturel.

Le modèle n’a pas créé le problème d’accès. Il a réduit l’effort nécessaire pour découvrir et combiner les informations exposées.

Les systèmes agentiques approfondissent le problème, car ils peuvent agir par l’intermédiaire d’outils connectés. Un agent peut lire un message, interroger une base de données, créer un document et envoyer le résultat.

Une attaque par injection de prompt place des instructions hostiles dans un contenu que le système lira ultérieurement. L’attaquant tente de rediriger l’agent, d’extraire des informations ou de déclencher une action non autorisée.

Le contrôle d’accès traditionnel reste nécessaire, mais il n’est plus suffisant. L’agent a également besoin de restrictions sur les outils, de limites de contenu, de validations d’approbation et d’une surveillance des comportements de récupération inhabituels.

Microsoft affirme que ses produits destinés aux entreprises incluent des défenses contre l’injection de prompts. Aucun contrôle de fournisseur ne doit être interprété comme éliminant cette catégorie d’attaque.

Une autre collision concerne la finalité. Une entreprise peut autoriser un fournisseur à traiter des informations confidentielles afin de générer une réponse, sans autoriser leur utilisation pour améliorer le modèle.

Ce sont des finalités distinctes. Les contrats doivent les identifier séparément et empêcher qu’un langage vague sur l’amélioration n’engloutisse des restrictions plus étroites.

Les fonctions de retour d’information méritent une attention particulière. Un utilisateur qui attribue une note négative peut joindre involontairement la conversation, le contenu téléversé ou le contexte récent.

Le produit pourrait traiter cet ensemble dans le cadre d’un flux d’amélioration distinct. Un paramètre par défaut excluant l’entraînement pourrait donc comporter une exception explicite pour les retours d’information.

La rétention crée un conflit similaire. Un service peut permettre aux clients de supprimer des conversations visibles tout en conservant des données limitées pour des raisons de sécurité ou juridiques.

Cela ne signale pas automatiquement une mauvaise conduite. Cela signifie toutefois que « supprimer » a besoin d’une définition technique et contractuelle.

Les acheteurs doivent demander quand la suppression commence, quels systèmes conservent des copies, comment les sauvegardes expirent et quelles obligations de conservation légale peuvent interrompre le calendrier.

La résidence des données ajoute une autre protection partielle. Conserver le contenu stocké dans une région sélectionnée peut répondre à des exigences réglementaires ou opérationnelles.

La résidence ne signifie pas nécessairement que chaque étape de traitement reste dans cette région. Les acheteurs ont besoin de réponses distinctes pour le stockage, l’inférence, l’accès du support, la télémétrie et les sous-traitants.

Les fournisseurs de modèles s’appuient également sur des partenaires d’infrastructure. Un service peut impliquer le fournisseur d’application, l’opérateur cloud, le développeur du modèle, le fournisseur de connecteurs et l’administrateur du client.

L’accord doit répartir les responsabilités tout au long de cette chaîne. Sinon, chaque participant peut décrire uniquement sa propre couche tandis que le client suppose une couverture de l’ensemble du système.

La propriété des résultats demeure limitée par la loi. La protection par le droit d’auteur peut exiger une création humaine, et le traitement juridique varie selon les juridictions et les types de résultats.

La cession contractuelle couvre les droits que le fournisseur possède. Elle ne peut pas céder des droits que le fournisseur n’a jamais détenus ni annuler la réclamation valable d’un tiers.

La protection des secrets d’affaires crée une norme différente. Les entreprises la préservent en prenant des mesures raisonnables pour garder secrètes des informations précieuses.

Soumettre des documents confidentiels dans le cadre de conditions d’entreprise protectrices peut soutenir cet effort. Envoyer les mêmes documents vers un compte public non contrôlé peut l’affaiblir.

C’est pourquoi les achats ne peuvent pas s’arrêter à une phrase telle que : « Le client est propriétaire de ses données. » Cette phrase ne répond qu’à une partie du risque.

Un examen sérieux demande qui peut accéder aux données, à quelles fins, via quels systèmes, pendant combien de temps et selon quelles instructions.

Les contrôles de sécurité échouent encore lorsque les autorisations et les personnes évoluent

Les engagements des fournisseurs réduisent l’exposition, mais les choix de déploiement déterminent si ces engagements protègent réellement les informations de l’entreprise.

Le premier point de défaillance est l’identité. Les organisations ont besoin de l’authentification unique, de l’authentification multifacteur, d’un retrait rapide des accès et d’un contrôle d’accès basé sur les rôles pour les services d’IA gérés.

Lorsqu’un employé part, désactiver une identité d’entreprise devrait mettre fin à l’accès aux assistants connectés et à leurs espaces de travail conservés. Des comptes personnels distincts contournent ce contrôle.

Le deuxième point de défaillance est l’autorisation. Un assistant d’IA devrait hériter des autorisations actuelles de l’utilisateur et respecter les restrictions au niveau des documents.

Même des autorisations héritées peuvent être trop larges. Des années de liens partagés, de groupes ouverts et de dossiers hérités laissent souvent des fichiers sensibles accessibles à des employés non concernés.

Le déploiement de l’IA devrait déclencher une revue des autorisations avant le début d’une récupération à grande échelle. Attendre après le lancement permet à l’assistant d’indexer et de faire apparaître des erreurs existantes.

Le troisième point de défaillance est la classification des données. Les employés ne peuvent pas suivre des règles qu’ils ne peuvent pas appliquer dans une tâche réelle.

Une politique devrait fournir des exemples concrets de contenu public, interne, confidentiel et restreint. Elle devrait également identifier les outils approuvés pour chaque catégorie.

Le code source offre un scénario utile. Un développeur pourrait soumettre une courte fonction à des fins de débogage sans réaliser que les commentaires contiennent des noms d’hôtes internes ou des identifiants clients.

Un système de prévention des pertes de données peut détecter certains motifs. Il n’identifiera pas chaque fragment dont la valeur dépend du contexte métier.

La formation humaine reste donc nécessaire. Elle devrait expliquer la différence entre propriété, confidentialité, rétention et entraînement des modèles.

Un quatrième point de défaillance concerne les connecteurs. Chaque connexion devrait avoir un responsable, une finalité approuvée, un groupe d’utilisateurs autorisés et une date de révision.

Les administrateurs devraient accorder les périmètres les plus restreints possibles. L’accès en lecture seule est plus sûr que l’accès en écriture lorsque le cas d’usage exige seulement la synthèse ou la recherche.

Les actions à fort impact devraient nécessiter la confirmation de l’utilisateur. L’envoi de messages, la modification d’enregistrements, la publication de fichiers et le lancement d’activités financières méritent des contrôles plus stricts que la rédaction de texte.

Le cinquième point de défaillance est la journalisation. Les équipes de sécurité ont besoin de traces indiquant qui a utilisé le service, quel connecteur a été exécuté, quelle action a eu lieu et si une politique l’a bloquée.

Les journaux peuvent eux-mêmes contenir des informations sensibles. Les organisations doivent les protéger et éviter d’enregistrer les prompts complets lorsque des métadonnées peuvent servir l’objectif de sécurité.

La surveillance devrait rechercher des volumes inhabituels, des récupérations étendues, des violations répétées des politiques et des accès provenant d’identités inattendues. Elle ne devrait pas devenir une surveillance illimitée des employés.

Le sixième point de défaillance est l’évolution du fournisseur. Les services d’IA ajoutent fréquemment des modèles, des fonctions de mémoire, des outils de navigation, des agents et des intégrations.

Un contrat signé pour un chatbot textuel pourrait ne pas décrire entièrement une fonction ultérieure qui enregistre des écrans, accède à des navigateurs distants ou exécute des tâches.

Les documents de confidentialité destinés aux consommateurs de Google illustrent cette expansion. Ils décrivent des fichiers, de l’audio en direct, des vidéos, le partage d’écran, des applications connectées, le contexte de page et des données de navigateur distant.

Chaque capacité peut être utile. Chacune modifie aussi les informations disponibles pour le service.

L’examen de sécurité doit donc être lié aux changements de capacités, et pas seulement aux renouvellements annuels de contrat. Les administrateurs ont besoin d’un préavis et d’un moyen de désactiver les fonctionnalités non approuvées.

Le septième point de défaillance est la réponse aux incidents. Une entreprise devrait savoir quoi faire lorsqu’un employé soumet des informations restreintes au mauvais système.

La réponse peut comprendre la conservation des journaux pertinents, la désactivation du partage, la demande de suppression, l’examen des notifications contractuelles et l’évaluation de l’exposition juridique.

Les équipes devraient éviter de promettre que la suppression élimine tous les risques. Des copies peuvent exister dans des services connectés, des systèmes de destinataires, des sauvegardes ou des enregistrements de retours d’information examinés.

Le cadre de gestion des risques liés à l’IA du NIST offre une structure utile pour gouverner, cartographier, mesurer et gérer les risques liés à l’IA.

Le cadre reste volontaire, et le NIST révise AI RMF 1.0. Sa valeur réside dans sa capacité à transformer de grands principes en responsabilités documentées et en examens reproductibles.

Pourtant, les cadres ne résolvent pas les faits propres à chaque produit. Une entreprise a toujours besoin de preuves concernant le compte, la fonctionnalité, la région, le connecteur et le contrat exacts qu’elle déploie.

C’est aussi à ce stade que le marketing des fournisseurs mérite du scepticisme. « De niveau entreprise » peut décrire un ensemble de contrôles sans prouver que chacun est activé.

Une certification peut confirmer que des processus définis ont été audités. Elle n’établit pas qu’un client a correctement configuré les autorisations ou choisi le bon produit.

La rétention nulle des données exige également une lecture attentive. L’expression peut s’appliquer à des points de terminaison éligibles tout en excluant la surveillance des abus, le traitement d’images, les fichiers ou les outils tiers.

Les engagements de non-entraînement méritent la même précision. Le fournisseur peut exclure le contenu client de l’entraînement des modèles de fondation tout en conservant des données limitées pour l’exploitation du service.

Ces distinctions n’effacent pas la valeur de l’engagement. Elles montrent pourquoi les acheteurs ont besoin d’un diagramme de flux de données et d’une annexe contractuelle à côté de la promesse publique.

Ce que les lecteurs de Google News devraient surveiller ensuite

Trois signaux indiqueront si la propriété des données d’IA devient un contrôle applicable ou reste un langage contractuel rassurant.

Le premier signal est de savoir si les fournisseurs unifient les protections entre leurs produits. Les offres grand public, professionnelles, API et cloud apportent actuellement des réponses différentes à des questions similaires.

Un fournisseur clair devrait identifier les règles d’entraînement, de rétention, d’examen, de résidence et de suppression au niveau du produit. Il devrait également divulguer les exceptions dans un langage simple.

Des contrôles plus cohérents renforceraient l’idée que les promesses de propriété peuvent fonctionner à grande échelle. Une fragmentation persistante maintiendrait le risque concentré dans la sélection des comptes et le comportement des employés.

Surveillez attentivement les paramètres par défaut. Un contrôle de désinscription offre moins de protection qu’un produit professionnel qui exclut le contenu client de l’entraînement avant le premier prompt.

La rétention par défaut est également importante. Des périodes plus courtes, contrôlées par l’administrateur, réduisent les conséquences des erreurs, même lorsqu’elles ne peuvent empêcher chaque divulgation.

Le deuxième signal est de savoir si les entreprises mesurent l’exposition des connecteurs avant d’activer des agents. Les inventaires d’accès et le nettoyage des autorisations devraient précéder un déploiement à grande échelle.

Les preuves d’une adoption mature incluront des registres de connecteurs, des autorisations limitées, des validations et des audits liés à des actions individuelles. Des politiques générales sur l’IA ne suffiront pas.

Le déploiement d’agents sans ces contrôles affaiblirait les assurances des fournisseurs concernant la propriété. Le système pourrait exposer des informations appartenant au client par le biais d’autorisations que celui-ci n’a pas su gouverner.

Les équipes de sécurité devraient tester l’injection indirecte de prompts et la récupération excessive. Elles devraient également vérifier que les assistants ne peuvent pas franchir les frontières entre utilisateurs, projets ou locataires.

Les tests doivent inclure des documents réalistes plutôt que des démonstrations aseptisées. Des instructions cachées dans des e-mails, des fichiers partagés, des tickets de support et des pages web créent des vecteurs d’attaque concrets.

Le troisième signal est la manière dont les régulateurs et les tribunaux traitent l’entraînement, les droits sur les résultats et la confidentialité. Les décisions juridiques peuvent clarifier quelles cessions contractuelles résistent aux litiges relatifs à la paternité ou à la contrefaçon.

L’action réglementaire peut également vérifier si les déclarations de confidentialité décrivent les pratiques réelles en matière de données. Une application claire renforcerait la valeur de contrôles précis de rétention et de consentement.

L’incertitude persistera selon les juridictions. Les entreprises ne devraient pas attendre une définition universelle de la propriété des données d’IA avant d’établir des règles internes.

L’approche la plus solide à court terme traite les informations d’IA comme un cycle de vie. Il commence par la collecte et se poursuit par la récupération, la génération, le stockage, le partage, la suppression et la réponse aux incidents.

Google News continuera de faire remonter des litiges sur les données d’entraînement, les prompts confidentiels et les œuvres générées. Les lecteurs devraient séparer ces questions plutôt que de les forcer dans une seule question de propriété.

Les préoccupations relatives aux données d’entraînement concernent ce que les développeurs utilisent pour construire ou améliorer les modèles. La confidentialité des prompts concerne ce qu’un service fait de l’interaction d’un utilisateur.

La propriété des résultats concerne les droits juridiques sur le matériel généré. La sécurité concerne les personnes qui peuvent accéder aux informations et les actions qu’un système peut entreprendre.

Le risque lié aux informations propriétaires traverse ces quatre domaines. Une entreprise peut être propriétaire d’une entrée, interdire son utilisation pour l’entraînement et tout de même l’exposer par un connecteur mal configuré.

Elle peut aussi être propriétaire d’un résultat en vertu d’un contrat tout en ne bénéficiant pas d’une protection exclusive par le droit d’auteur. Aucun de ces résultats n’est couvert par une case à cocher intitulée « le client est propriétaire des données ».

Les acheteurs d’entreprise devraient demander cinq éléments concrets à chaque fournisseur. Il s’agit d’un diagramme de flux de données, d’un calendrier de rétention, d’une liste de sous-traitants, d’une matrice de contrôles de sécurité et d’un processus de notification des incidents.

Ils devraient comparer ces éléments à un déploiement précis. Les réponses concernant un chatbot public ne peuvent pas établir le comportement d’une API d’entreprise, et l’inverse est également vrai.

Les travailleurs du savoir ont une décision plus immédiate à prendre. Avant de soumettre des informations, ils doivent identifier le compte, la catégorie de données, les applications connectées et le destinataire prévu.

Si une réponse n’est pas claire, la tâche doit être effectuée dans un environnement approuvé ou en dehors de l’outil d’IA. La commodité ne change pas la sensibilité du contenu source.

Les développeurs doivent également considérer le code généré comme un point de départ. Avant toute mise en production, ils doivent procéder à un examen de sécurité, à des vérifications de licence, à des tests et assurer une responsabilité humaine.

Les responsables produit doivent définir si un assistant conseille, rédige, récupère des informations ou agit. Chaque verbe supplémentaire élargit la surface de contrôle.

Les équipes juridiques doivent négocier les finalités, plutôt que de se limiter au langage de propriété. Les équipes de sécurité doivent vérifier que la configuration du produit correspond à ces finalités négociées.

Les équipes achats doivent réexaminer l’évaluation lorsqu’un fournisseur ajoute de la mémoire, des agents, de nouveaux connecteurs ou un autre fournisseur de modèles. Les changements importants de capacités méritent une supervision à la hauteur.

La question de la propriété appelle une réponse utile, mais il ne s’agit pas d’un nom imprimé dans un contrat. En pratique, le propriétaire est la partie qui peut définir les accès, limiter les finalités, vérifier les contrôles et mettre fin au traitement.

Les organisations doivent vérifier qu’elles détiennent réellement ces pouvoirs. Si elles ne peuvent pas suivre une invite sensible depuis sa soumission jusqu’à sa suppression, leur contrôle reste incomplet.

Posez à votre fournisseur d’IA la question plus difficile soulevée par Google News : ne demandez pas seulement « Sommes-nous propriétaires de nos données ? » Demandez qui peut les traiter, où des copies subsistent et quels paramètres modifient la réponse. Testez ensuite ces affirmations avec un compte réel, un connecteur réel et des informations représentatives. Si le flux documenté diffère du système déployé, suspendez le déploiement et comblez cet écart avant d’élargir les accès. Le programme d’IA le plus sûr n’est pas celui qui dispose de la politique la plus longue. C’est celui dans lequel les employés savent quel environnement utiliser, les administrateurs peuvent imposer ce choix et l’organisation peut vérifier ce qui se passe après chaque soumission.