Clauses de confidentialité à exiger d'un fournisseur de plateforme IA

Un accord de confidentialité standard part du principe d'un destinataire humain qui reçoit des informations, les garde confidentielles et ne les transmet pas. Une plateforme de stratégie IA fait quelque chose de structurellement différent : elle ingère des jeux entiers de documents, génère de nouveaux éléments dérivés de ces documents, conserve l'enregistrement de chaque interaction, et dans certaines architectures apprend de ce qu'on lui soumet. Cinq clauses comblent les lacunes : une garantie de non-entraînement assortie d'un droit d'audit ; des sous-traitants nommés et une résidence des données ; la suppression à la résiliation avec un certificat ; la journalisation des versions de modèles ; et un périmètre de notification d'incident couvrant les défaillances spécifiques à l'IA.

Rien dans cet article ne constitue une rédaction juridique ni un substitut à un conseil juridique sur un engagement particulier.

Un accord de confidentialité bilatéral est rédigé pour un destinataire humain. Une plateforme de stratégie IA ingère des jeux entiers de documents, génère de nouveaux éléments dérivés de ces documents, conserve l'enregistrement de chaque interaction, et dans certaines architectures apprend de ce qu'on lui soumet. Quatre catégories d'informations qu'un accord de confidentialité classique ne couvre pas de manière adéquate :

• Les données d'entrée : dossiers du conseil, modèles financiers et fichiers de due diligence téléversés sur la plateforme – bien plus importants et sensibles que ce qu'un processeur de données SaaS classique manipule.
• Les résultats générés : les nouveaux éléments que le système produit, qui peuvent citer, résumer ou recombiner des contenus confidentiels.
• Les requêtes : les instructions saisies par l'équipe, qui contiennent souvent des noms de clients, le contexte de la transaction et l'intention stratégique.
• Les métadonnées d'interaction avec le modèle : fréquence des requêtes, durées de session, heures d'interaction et localisations des utilisateurs, qui peuvent cartographier les flux de travail opérationnels, les calendriers de recherche et les schémas d'intelligence concurrentielle.

Deux lacunes supplémentaires méritent une attention explicite. Premièrement : un modèle affiné sur des données clients peut mémoriser et reproduire des fragments pour un autre client – transformant une violation de confidentialité en événement automatisé et répétable. Deuxièmement : « nous ne partageons jamais vos données » n'est pas la même chose que « nous ne nous entraînons jamais sur vos données ». Un fournisseur peut tenir des documents en stricte confidentialité tout en incorporant ce qu'il en a appris dans un modèle qui sert ensuite ses concurrents.

L'ambiguïté dans les termes définis se répercute dans chaque disposition opérationnelle. Les cinq termes définis qui décident le plus du résultat :

Trois domaines méritent une attention particulière lors de la négociation : les données d'utilisation doivent être élevées au rang d'informations confidentielles. Les requêtes doivent être traitées comme des données client à part entière. Une interdiction de l'ingestion de données fantôme empêche une dérive silencieuse du périmètre – où le fournisseur ingère du contenu des sessions client pour améliorer son service sans autorisation explicite.

Un cabinet de stratégie qui évalue une plateforme IA doit exiger cinq clauses que les modèles fournisseurs standard omettent ou affaiblissent habituellement :

1. Une garantie de non-entraînement assortie d'un droit d'audit. Le principe par défaut doit être que les données clients, les requêtes, les données d'entrée et les résultats ne sont pas utilisés pour entraîner un quelconque modèle. Toute exception nécessite un consentement exprès et opt-in ainsi que des garanties de dé-identification. Un droit d'audit – tel que le préconise l'ICO au titre de l'article 28(3)(h) du RGPD^[2] – transforme la promesse en quelque chose de vérifiable.
2. Résidence des données et liste nommée des sous-traitants. Préciser la région où les données sont stockées et traitées. Nommer chaque sous-traitant et exiger une autorisation préalable pour tout changement, comme l'exigent les articles 28(2) et 28(3)(d) du RGPD. La liste des sous-traitants doit inclure tout fournisseur tiers de modèle fondateur.
3. Suppression à la résiliation, avec un certificat. Exiger que le fournisseur, au choix du client, supprime ou restitue toutes les données à la fin du contrat et fournisse une preuve écrite que la suppression a bien eu lieu. Un fournisseur qui ne peut pas produire un certificat de suppression issu d'une résiliation client précédente n'a jamais testé son propre processus de fin de contrat.
4. Journalisation des versions de modèles. Chaque résultat doit être traçable jusqu'à la version du modèle qui l'a produit, afin que l'analyse puisse être auditée des mois plus tard et que les changements de comportement du modèle puissent être détectés. Cette clause soutient à la fois l'enregistrement de responsabilité et la carte affirmation-source pour les travaux réglementés.
5. Notification d'incident avec un périmètre de violation correctement défini. Les obligations de notification et la répartition des coûts doivent être expressément prévues. La définition d'un incident de sécurité doit couvrir l'inversion de modèle et l'extraction de données via les résultats – défaillances spécifiques à l'IA – et pas seulement l'intrusion réseau classique. S'engager à notifier dans un délai défini.

La discipline consiste à demander à chaque fournisseur un artefact – un document ou une démonstration – plutôt qu'une assurance verbale. Les assurances données lors d'une réunion commerciale ne sont pas contraignantes ; les réponses écrites versées au contrat le sont.

• Suppression : demander la piste de preuve d'un départ à terme – le journal de suppression et le certificat – et non une description du processus. Un fournisseur qui ne peut pas en produire un n'a jamais testé ce processus.
• Sous-traitants : demander la liste complète actuelle des sous-traitants, y compris tout fournisseur tiers de modèle fondateur et les localisations des centres de données pour chacun.
• Anonymisation : questionner la méthodologie de dé-identification et si la ré-identification est techniquement faisable. Un fournisseur qui ne peut pas répondre ne devrait pas avoir accès aux documents clients.
• Contrôles d'entraînement : demander si les données sont cloisonnées entre les clients, si les runs d'entraînement se font sur des modèles partagés ou dédiés, et si les données d'un client peuvent jamais influencer les résultats pour un autre client.
• Certifications : traiter SOC 2 et ISO 27001 comme un point de départ. Se fier aux seules certifications, sans les questions de due diligence ci-dessus, n'est pas suffisant.^[3]

Poser les questions par écrit et conserver les réponses. L'enregistrement écrit est également la preuve que le cabinet a conduit une due diligence appropriée si la relation devient ultérieurement la source d'un incident de confidentialité.

La confidentialité se gagne ou se perd discrètement à la fin d'un engagement. Trois dispositions de sortie empêchent le verrouillage et l'exposition des données à la résiliation :

• Format d'export : préciser le format dans lequel les données clients et les résultats d'analyse sont restitués, et si les requêtes sont récupérables avec eux. Si le fournisseur ne peut pas produire un export de données dans un format utilisable, la capacité pratique de partir est limitée quelle que soit le droit contractuel.
• Propriété des résultats : le contrat doit confirmer au minimum que le client détient une licence large pour utiliser les résultats à toute fin commerciale licite sans restriction. Tout modèle affiné construit sur les données du client doit faire l'objet d'un traitement séparé et explicite de la propriété et de la capacité du client à l'emporter lors de la résiliation.
• Conservation des journaux : préciser combien de temps le fournisseur conserve les journaux d'utilisation et les enregistrements d'interaction après la résiliation et selon quel cycle de suppression ils sont purgés.

Le plancher RGPD : l'article 28(3)(g) exige qu'à la fin d'un contrat, le sous-traitant supprime ou restitue toutes les données personnelles et en supprime les copies existantes, à moins que la loi n'impose une conservation.^[2] Une suppression différée depuis les sauvegardes n'est acceptable que si les données sont immédiatement mises hors d'atteinte et supprimées lors du prochain cycle de suppression du sous-traitant.

La plupart des questionnaires fournisseurs passent à côté de la clause d'amélioration du service. La plupart des accords technologiques permettent au fournisseur d'utiliser les données clients pour améliorer ses offres, et les fournisseurs cherchent de plus en plus à étendre ce droit à l'entraînement de modèles IA. Une telle formulation a des implications bien plus larges qu'une clause d'amélioration du service classique.

Le problème fondamental : la propriété des données n'est pas égale au contrôle des données. Même si une entreprise conserve la propriété de ses données brutes, des droits larges sur les dérivés agrégés ou anonymisés peuvent permettre à un fournisseur de construire des modèles incorporant les enseignements tirés de ces données indéfiniment – et ces modèles continueront à servir d'autres clients du fournisseur après la fin du contrat.

Quatre points à traiter explicitement dans le contrat :

1. Définir explicitement les usages à valeur dérivée : benchmarks, produits analytiques, nouvelles fonctionnalités et entraînement de modèles doivent chacun être nommés – et non laissés à une clause ouverte d'« amélioration de nos services ».
2. Interdire les usages dérivés que vous n'accepterez pas : les nommer individuellement plutôt que de s'appuyer sur une disposition générale de confidentialité.
3. Limiter tout usage autorisé à votre propre instance – et non à l'entraînement agrégé sur l'ensemble de la base clients.
4. Subordonner tout usage autorisé à la durée du contrat – et non à une licence indéfinie qui survit à la résiliation.

Cet exemple est illustratif, il ne s'agit pas d'un engagement réel ni d'un conseil juridique. Un cabinet de stratégie de taille moyenne qui évaluait une plateforme IA a conduit sa revue précontractuelle en trois passes.

1. Première passe, les définitions : confirmation que les données d'entrée, les résultats, les données client, les données d'utilisation et les données d'entraînement étaient toutes définies, que les requêtes figuraient dans les données client, et que la clause d'amélioration du service était limitée à la propre instance du client.
2. Deuxième passe, les cinq clauses : demande d'un engagement de non-entraînement par écrit, de la liste publiée des sous-traitants, de la preuve d'un certificat de suppression antérieur, de la spécification de journalisation des versions de modèles, et des conditions de notification d'incident couvrant les attaques d'extraction propres à l'IA.
3. Troisième passe, les clauses de sortie : fixation du format d'export, confirmation d'une licence large sur les résultats, et plafonnement de la conservation des journaux post-résiliation à 90 jours pour les journaux non personnels.

Une question a mis en lumière la lacune qui importait le plus : le fournisseur ne pouvait pas documenter sa méthodologie de dé-identification ni exclure la ré-identification des données du cabinet ou des clients, même après deux demandes de suivi. Le contrat a été amendé avant la signature : un standard de dé-identification défini, une interdiction de la ré-identification et une fin explicite de l'usage à valeur dérivée à l'expiration du contrat.

Decisity affirme clairement que les données clients ne sont jamais utilisées pour entraîner des modèles d'IA et associe cet engagement à une traçabilité complète des sources et à une résidence des données en Europe. La présentation de la sécurité couvre les engagements techniques et contractuels en détail.

Lectures associées :

• Documents confidentiels et outils IA : que vérifier
• Analyse de transactions assistée par IA : répondre aux exigences du comité d'investissement et des LP
• Divulgation de la version du modèle IA : ce que votre conseil doit savoir
• Comment fonctionne Decisity

• Ward and Smith : Architecture contractuelle – clauses IA essentielles pour les accords fournisseurs
• ICO : Contrats et responsabilités entre responsables de traitement et sous-traitants – ce qui doit être inclus
• Ward and Smith : Due diligence précontractuelle et garanties opérationnelles pour les engagements avec des fournisseurs IA
• Morgan Lewis : Considérations clés lors de l'autorisation d'un fournisseur à entraîner ses modèles IA sur des données client (juin 2026)