Surveillance de l'utilisation des données

Une entreprise pharmaceutique a fait appel à un fournisseur d’analyse de données dans le cadre d’un DPA qui limitait expressément l’utilisation des données à des analyses de veille concurrentielle pour le périmètre contractuel. Deux ans après le début de la relation, un ancien employé du fournisseur a révélé lors de son entretien de départ que des jeux de données clients, dont ceux de l’entreprise pharmaceutique, étaient régulièrement utilisés comme données d’entrée du pipeline interne d’entraînement de modèles du fournisseur, lequel produisait des produits d’analyse prédictive vendus à d’autres clients. L’ancien employé avait découvert par hasard la configuration du pipeline et l’avait mentionnée en passant. Le DPA interdisait cette utilisation. La surveillance interne de l’utilisation des données chez le fournisseur était insuffisante pour détecter ou empêcher la violation du périmètre. L’entreprise pharmaceutique ne disposait d’aucun mécanisme pour surveiller l’utilisation de ses données dans l’environnement du fournisseur : le DPA précisait l’utilisation autorisée, mais aucune surveillance technique ou opérationnelle ne confirmait que cette utilisation était l’utilisation réelle. Lorsque la révélation a eu lieu, l’entreprise pharmaceutique n’a pas pu déterminer depuis combien de temps durait l’utilisation non autorisée, quels modèles avaient été entraînés sur ses données ni quels produits intégrant ses données avaient été vendus. Le DPA était clair. La surveillance était absente. La violation est restée non détectée pendant une durée indéterminée.

Qu’est-ce que le problème de la surveillance de l’utilisation des données, réellement ?

La surveillance de l’utilisation des données est la capacité d’observer la manière dont les données sont réellement traitées dans l’environnement d’un fournisseur : quelles requêtes sont exécutées sur elles, quels pipelines les consomment, quels produits y font référence, et si leur utilisation réelle est conforme à la spécification contractuelle. C’est la différence entre préciser l’utilisation autorisée dans un DPA et avoir une visibilité sur le fait que l’utilisation autorisée est bien celle qui a lieu. Sans surveillance de l’utilisation, un DPA est un instrument de gouvernance qui documente l’utilisation autorisée sans aucun mécanisme pour détecter une utilisation non autorisée.

L’écart entre confiance et vérification est le problème structurel. La plupart des relations régies par un DPA reposent sur la confiance : le fournisseur s’engage à n’utiliser les données qu’à des fins autorisées, et le client lui fait confiance pour respecter cet engagement. La confiance n’a rien de déraisonnable en soi dans des relations fournisseurs établies. Elle constitue une gouvernance insuffisante lorsque les conséquences d’un abus de confiance incluent un manquement réglementaire, la divulgation de renseignements concurrentiels et un entraînement de modèles non autorisé auquel il est impossible de remédier après coup. La surveillance de l’utilisation des données fait passer le modèle de gouvernance de la confiance à la vérification, en fournissant des preuves techniques de ce qui se passe réellement au lieu de s’en remettre à l’autocertification de conformité du fournisseur.

Le problème de la découverte des utilisations non autorisées est celui sur lequel la gouvernance fondée sur la confiance échoue systématiquement. Les utilisations non autorisées des données des clients (entraînement de modèles, analyses comparatives concurrentielles, développement de fonctionnalités produit) ne résultent pas d’une annonce de leurs intentions par les fournisseurs. Elles apparaissent au fil de décisions ordinaires de développement produit qui, au sein de l’organisation du fournisseur, peuvent ne pas être perçues comme des violations du DPA. Un ingénieur des données qui ajoute un jeu de données client à un pipeline d’entraînement parce que c’est la source de données la plus facilement disponible pour une tâche de développement de modèle peut ignorer ou ne pas se demander si le DPA applicable à ce jeu de données autorise son utilisation pour l’entraînement de modèles. La violation est réelle. Elle n’est pas nécessairement délibérée. Et sans surveillance, elle se poursuit jusqu’à ce qu’un élément extérieur (la révélation d’un employé, un audit réglementaire, la réponse à une DSAR) la rende visible.

• Aucune surveillance au niveau des requêtes : absence de visibilité technique sur les requêtes exécutées sur les données du client
• Aucune surveillance de l’utilisation par les pipelines : incapacité à détecter si les données du client sont consommées par des pipelines d’analyse ou d’entraînement de modèles au-delà du périmètre autorisé
• Aucune surveillance de l’attribution aux produits : absence de mécanisme permettant de détecter si les données du client contribuent aux produits commerciaux du fournisseur
• Conformité au DPA non imposée techniquement : utilisation autorisée précisée dans le contrat sans contrôles techniques imposant la restriction du périmètre
• Aucun mécanisme de visibilité pour le client : le client n’a accès à aucun journal ni rapport d’utilisation confirmant l’utilisation autorisée

Pourquoi c’est important

La surveillance de l’utilisation des données compte pour le TPRM, car c’est le mécanisme qui transforme un DPA, simple énoncé de l’utilisation autorisée, en instrument de gouvernance applicable. Un DPA sans surveillance de l’utilisation précise l’utilisation autorisée et ouvre un recours juridique en cas de non-respect. Un DPA assorti d’une surveillance de l’utilisation fournit la capacité de détection qui permet de découvrir les violations avant qu’elles ne deviennent des extensions du périmètre durables et non détectées.

La dimension de l’IA et du ML rend cette question de plus en plus urgente. À mesure que les fournisseurs intègrent des capacités d’IA dans leurs produits, la tentation d’utiliser de riches jeux de données clients comme données d’entraînement est commercialement importante : les données des clients produisent de meilleurs modèles, de meilleurs modèles produisent de meilleurs produits, de meilleurs produits génèrent davantage de revenus. L’incitation à utiliser les données des clients au-delà du périmètre contractuel existe à grande échelle dans tout le paysage des fournisseurs d’analyse, d’IA et de SaaS. La surveillance est le mécanisme qui distingue les fournisseurs qui respectent leurs engagements DPA de ceux qui trouvent toujours le moyen d’accéder à des données commodes.

Pour les praticiens du TPRM, la surveillance de l’utilisation des données représente une lacune de gouvernance importante dans la plupart des programmes de TPRM actuels : elle est rarement évaluée parce qu’elle est rarement présente, et son absence est devenue la norme pour le partage de données régi par un DPA. La demander relève le niveau d’exigence en matière de gouvernance et envoie au marché le signal que la surveillance compte.

Là où la plupart des équipes se trompent

L’échec le plus constant consiste à considérer le DPA comme l’instrument de gouvernance complet de l’utilisation des données. Le DPA précise l’utilisation autorisée. La surveillance confirme si l’utilisation autorisée correspond à l’utilisation réelle. L’un ne remplace pas l’autre. Un DPA sans surveillance, c’est une documentation de gouvernance sans vérification de gouvernance. Le DPA de l’entreprise pharmaceutique était clair. Cette clarté n’a pas permis de détecter le pipeline d’entraînement.

• Considérer le DPA comme une gouvernance complète sans surveillance
• Aucune exigence de surveillance de l’utilisation dans le DPA : utilisation autorisée précisée sans obligation de surveillance
• Aucune visibilité du client sur les journaux d’utilisation : le fournisseur détient les données d’utilisation sans que le client y ait accès
• Utilisation pour l’entraînement ML ni spécifiquement interdite ni surveillée : une utilisation secondaire qui devient de plus en plus la norme
• Gouvernance du DPA fondée sur la confiance plutôt que sur la vérification

À quoi ressemblent les bonnes pratiques

Les programmes matures de gouvernance de l’utilisation des données offrent au client une visibilité sur la manière dont ses données sont utilisées : journaux d’utilisation, rapports de requêtes, attribution des pipelines et confirmation régulière que l’utilisation réelle correspond à l’utilisation autorisée. Au minimum, le fournisseur dispose d’une surveillance interne qui détecte les violations du périmètre. Idéalement, le client a accès à des rapports d’utilisation qui permettent une vérification indépendante.

• Surveillance interne de l’utilisation : journaux des requêtes, attribution des pipelines et surveillance de l’utilisation dans les produits, capables de détecter les violations du périmètre
• Rapports d’utilisation destinés au client : rapports périodiques confirmant l’utilisation réelle des données par rapport au périmètre autorisé
• Surveillance des données d’entraînement ML : détection spécifique de l’entrée des données du client dans des pipelines d’entraînement de modèles
• Surveillance de la conformité au DPA : détection automatisée des schémas d’utilisation incompatibles avec le périmètre autorisé
• Alertes sur les anomalies d’utilisation : alertes automatisées sur les schémas d’utilisation qui s’écartent de la spécification d’utilisation prévue au contrat

Outils

Gouvernance des accès aux données : Imperva, Varonis, IBM Guardium

Les plateformes de surveillance de l’activité des bases de données et de gouvernance des accès aux données recueillent des données d’utilisation au niveau des requêtes, qui peuvent être analysées pour vérifier leur cohérence avec les spécifications d’utilisation autorisée. Pour les praticiens du TPRM, demander si la plateforme DAM du fournisseur peut générer des rapports d’utilisation propres à chaque client confirmant que les requêtes sur les données relevaient du périmètre autorisé constitue une question précise sur la capacité à rendre la surveillance visible pour le client.

Gouvernance des pipelines de ML : MLflow, Weights & Biases, Neptune.ai

Les plateformes de suivi des expériences de ML enregistrent la provenance des données d’entraînement, en documentant les jeux de données utilisés lors de chaque exécution d’entraînement de modèle. Pour les praticiens du TPRM, demander si l’infrastructure ML du fournisseur enregistre une traçabilité des données permettant de détecter l’utilisation non autorisée de jeux de données clients pour l’entraînement de modèles constitue une question précise sur la surveillance du périmètre AI/ML.

Enjeux de gouvernance

Le défi de gouvernance que pose la surveillance de l’utilisation des données tient à la sophistication opérationnelle qu’elle requiert. Surveiller les requêtes exécutées sur un jeu de données à l’échelle de la production exige une infrastructure de DAM. Surveiller les pipelines qui consomment un jeu de données exige des outils de traçabilité des données. Surveiller les produits qui font référence à un jeu de données exige une infrastructure d’attribution aux produits. Il s’agit d’un investissement technique non négligeable que la plupart des fournisseurs d’analyse n’ont pas réalisé spécifiquement pour garantir le respect du périmètre des données de leurs clients.

• Ajoutez une exigence de surveillance de l’utilisation au DPA : obligation pour le fournisseur de conserver et de fournir des journaux d’utilisation
• Exigez des rapports d’utilisation destinés au client : confirmation périodique de l’utilisation réelle par rapport au périmètre autorisé
• Ajoutez une surveillance de l’interdiction d’utiliser les données pour l’entraînement ML : obligation spécifique de détecter et de prévenir toute utilisation non autorisée de données d’entraînement
• Interrogez la détection interne des violations du périmètre : la surveillance du fournisseur détecterait-elle le scénario du pipeline d’entraînement ?
• Intégrez la surveillance de l’utilisation aux réévaluations des fournisseurs : confirmez que la capacité de surveillance existe et fonctionne

Si vous êtes une petite équipe

Ajoutez une exigence à vos accords de traitement des données les plus à risque lors de leur prochain renouvellement : le fournisseur doit conserver des journaux de toutes les requêtes exécutées sur les données du client et doit fournir un rapport d’utilisation trimestriel confirmant que toutes les requêtes journalisées relevaient du périmètre d’utilisation autorisé précisé dans le DPA. Cette seule exigence fait passer le DPA d’une gouvernance fondée sur la confiance à une gouvernance fondée sur la vérification. Le fournisseur qui ne peut pas la satisfaire ne peut pas démontrer qu’il respecte le DPA qu’il a signé.

• Ajoutez un rapport d’utilisation trimestriel lors du renouvellement des DPA les plus à risque
• Demandez si le fournisseur dispose d’une surveillance interne qui détecterait le scénario du pipeline d’entraînement de modèles
• Demandez si l’utilisation des données du client pour l’entraînement ML est spécifiquement journalisée et surveillée
• Demandez un exemple de rapport d’utilisation montrant ce que la surveillance enregistre

Ce qu’il faut exiger

Demandez directement :

« Conservez-vous des journaux de toutes les requêtes et de tous les processus de pipeline exécutés sur nos données, et pouvez-vous nous fournir des rapports d’utilisation périodiques confirmant que toute utilisation relevait du périmètre autorisé précisé dans notre DPA ? »

« Si nos données étaient ajoutées sans autorisation à un pipeline d’entraînement de modèles, quelle surveillance technique le détecterait et générerait une alerte, et cette surveillance s’est-elle déjà déclenchée pour les données d’un client ? »

« Quel est votre processus pour confirmer que l’utilisation des données des clients reste en permanence dans le périmètre du DPA : vous en remettez-vous à la confiance et aux obligations contractuelles, ou disposez-vous d’une surveillance technique qui vérifie le respect du périmètre ? »

Preuves attendues

• Confirmation de la surveillance interne de l’utilisation : journaux des requêtes et attribution des pipelines
• Exemple de rapport d’utilisation destiné au client
• Description de la surveillance des données d’entraînement ML
• Description de la capacité de détection des violations du périmètre

Un fournisseur qui répond à la question de la surveillance par « notre personnel connaît les restrictions du DPA » a décrit une gouvernance fondée sur la confiance. Demandez précisément quelle surveillance technique détecterait l’ajout, sans autorisation, de données du client à un pipeline d’entraînement par son équipe d’ingénierie des données. La réponse indique si une surveillance existe ou si le DPA repose sur le fait que chacun connaît et respecte les règles.

Comment le prouver

• Documentation de l’exigence de surveillance de l’utilisation dans le DPA
• Registres des rapports d’utilisation destinés au client
• Confirmation de la capacité de surveillance des violations du périmètre
• Preuves de la surveillance des données d’entraînement ML

À retenir

Le DPA précise l’utilisation autorisée. La surveillance confirme si l’utilisation autorisée est l’utilisation réelle. Sans surveillance, l’instrument de gouvernance qui définit la limite ne dispose d’aucun mécanisme pour détecter son franchissement. Les données de l’entreprise pharmaceutique ont alimenté un pipeline d’entraînement de modèles pendant une durée indéterminée, alors que le DPA indiquait que ce n’était pas autorisé. Le DPA disait juste sur ce qui était autorisé. Le pipeline d’entraînement disait vrai sur ce qui se passait. Entre l’autorisation et la réalité, deux années de violation non détectée du périmètre, découverte grâce à un entretien de départ. La surveillance comble cet écart. Elle transforme le DPA, simple déclaration d’intention, en une relation gouvernée et vérifiée. Le DPA est la limite. La surveillance est la clôture.