path: root/contexte/legal.tex

L'Union Européene a établie le règlement (UE) 2024/1689 du parlement européen et du conseil
du 13 juin 2024
établissant des règles harmonisées concernant l’intelligence artificielle.

Pour mieux comprendre les enjeux autour des différents scénarios d'attaques, 
outre la recherche inhérente au comportement sociétal humain à se dissimuler et à ne montrer que ce qu'il souhaite montrer,
penchons-nous du côté de la législation, des droits et des obligations qui entourent nos données.

\subsection{Protection des utilisateurs}
L'article 8 de la Charte des droits fondamentaux de l'Union Européenne dispose que : \og
\begin{enumerate}
    \item Toute personne a droit à la protection des données à caractère personnel la concernant.
    \item Ces données doivent être traitées loyalement, à des fins déterminées et sur la base du consentement
de la personne concernée ou en vertu d’un autre fondement légitime prévu par la loi. Toute personne a
le droit d’accéder aux données collectées la concernant et d’en obtenir la rectification.
    \item Le respect de ces règles est soumis au contrôle d’une autorité indépendante.
\end{enumerate}
\fg
L'objet de cette section est de comprendre comment ce droit fondamental entre en conflit avec les attaques décrites dans ce rapport au travers de l'étude de textes légaux.

L'article 4 paragraphe 1 du Règlement Général sur la Protection des Données, le R.G.P.D., dispose que 
\og Une donnée à caractère personnel est toute information se rapportant à une personne physique identifiée ou identifiable \fg.
Cette définition est importante dans le cadre des attaques de modèles car elle permet de rapidement identifier le cadre légal : 
si nous pouvons rattacher l'inférence à une personne, il s'agit d'une donnée personnelle, elle doit donc être utilisée conformément au R.G.P.D. \cite{RGPD}
et à la loi n° 78-17 du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés\cite{78-17}.

On se place dans le cadre où la base de données ayant servi d'entraînement au modèle de machine learning 
contient des données personnelles et des données sensibles.
On suppose aussi que l'utilisation de ces données pour l'entraînement du modèle est licite.

Dans nos travaux sur la fairness nous avons étudié plusieurs attaques sur les attributs sensibles tels que l'ethnie ou le genre.
Nous nous sommes placés notamment dans le cadre où l'attribut sensible n'est pas utilisé dans l'entraînement du modèle,
ce qui signifie que la personne ayant fourni la donnée n'a pas donné son accord pour l'utilisation de l'attribut sensible.
Nous avons montré que retrouver cet attribut sensible à partir du modèle est possible avec une grande précision, ce qui implique le traitement de cet attribut au sens de la définition de l'article 4 paragraphe 2 du R.G.P.D. le définissant comme:
\og
toute opération ou tout ensemble d'opérations effectuées ou non à l'aide de procédés automatisés et appliquées à des données ou des ensembles de données à caractère personnel, telles que la collecte, l'enregistrement, l'organisation, la structuration, la conservation, l'adaptation ou la modification, l'extraction, la consultation, l'utilisation, la communication par transmission, la diffusion ou toute autre forme de mise à disposition, le rapprochement ou l'interconnexion, la limitation, l'effacement ou la destruction.
\fg

L'article 9 paragraphe 1 du R.G.P.D. dispose que 
\og
Le traitement des données à caractère personnel qui révèle l'origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques ou l'appartenance syndicale, ainsi que le traitement des données génétiques, des données biométriques aux fins d'identifier une personne physique de manière unique, des données concernant la santé ou des données concernant la vie sexuelle ou l'orientation sexuelle d'une personne physique sont interdits.
\fg
Publier un modèle avec lequel il est possible de retrouver l'ethnie ou le genre est donc illégal, sauf exceptions.

Même si l'attribut sensible ne rentrait pas dans le cadre de l'article 9 paragraphe 1 du R.G.P.D. le fait de pouvoir utiliser une attaque d'attribut constitue une violation des données personnelles au sens de l'article 4 paragraphe 12 du R.G.P.D. qui dispose qu'une violation des données personnelles est
\og
 une violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l'altération, la divulgation non autorisée de données à caractère personnel transmises, conservées ou traitées d'une autre manière, ou l'accès non autorisé à de telles données.
\fg

\subsection{Protection des bases de données}
On considère dans cette section que le producteur de la base de données bénéficie d'une protection par le droit sui generis au sens de l'article L.341-1 du Code de la Propriété Intellectuelle qui dispose que \og Le producteur d'une base de données, entendu comme la
personne qui prend l'initiative et le risque des investissements
correspondants, bénéficie d'une protection du contenu de la base lorsque
la constitution, la vérification ou la présentation de celui-ci atteste d'un
investissement financier, matériel ou humain substantiel \fg.

On peut imaginer plusieurs cas où les attaques présentées dans mon stage peuvent porter atteinte aux droits du producteur de la base de données.
\begin{itemize}
    \item Supposons que le producteur décide d'interdire \og l'extraction ou la réutilisation répétée et systématique de parties qualitativement ou quantitativement non substantielles du contenu de la base lorsque ces opérations excèdent manifestement les conditions d'utilisation normales de la base de données.\fg,
comme le prévoit l'article L.342-2 du Code de la Propriété Intelectuelle.
Nous sommes alors en droit de penser qu'une inference attack représente l'extraction d'une partie de la base de données, en l'occurence une colonne de la base de données.
De plus cette attaque excède les conditions d'utilisation car, dans ce cas, la condition d'utilisation normale est l'entraînement d'un modèle de machine learning.
Ici, la personne menant l'attaque porte atteinte aux droits du producteur de la base de données.

    \item Ici, c'est le fournisseur de solution de machine learning, exploitant la base de données, qui porte atteinte aux droits du producteur.
    On se place dans le cas où le producteur interdit \og la réutilisation, par la mise à la disposition du public de la totalité ou d'une partie qualitativement ou quantitativement substantielle du contenu de la base, quelle qu'en soit la forme.\fg, conformément à l'article L.342-1 alinéa 2 du Code de la Propriété Intelectuelle.
        Dans le cas où le fournisseur de modèle de machine learning permet à ses clients (le public) de mener à bien des attributs inference attack, il met à disposition une partie de la base par sa négligence à utiliser une méthode d'apprentissage résistante à ce type d'attaque.
\end{itemize}

Notons que l'article L.343-4 du Code de la Propriété Intellectuelle dispose qu'\og est puni de trois ans d'emprisonnement et de 300 000 euros d'amende le fait de porter atteinte aux droits du producteur d'une base de données tels que définis à l'article L. 342-1.\fg

\subsection{Secret des affaires}
L'attaque property inference peut révéler des statistiques globales sur une entreprise ayant utilisé une base de données qu'elle tient secrète pour l'entraînement d'un modèle de machine learning ensuite publié.
Ces statistiques sont des informations qui :
\begin{itemize}
    \item Ne sont pas connues ou aisément accessibles pour les personnes familières de ce type d'information.
    \item Revêtent une valeur commerciale, effective ou potentielle, du fait de leur caractère secret.
    \item Font l'objet de la part de son détenteur légitime de mesures de protection raisonnables, compte tenu des circonstances, pour en conserver le caractère secret.
\end{itemize}
Au titre de l'article L.151-1 du Code de Commerce, ces statistiques sont protégées en tant que secret des affaires.

De plus l'article L.151-4 alinéa 2 du Code de Commerce dispose que \og L'obtention d'un secret des affaires est illicite lorsqu'elle est réalisée sans le consentement de son détenteur légitime et qu'elle résulte [...] de tout autre comportement considéré, compte tenu des circonstances, comme déloyal et contraire aux usages en matière commerciale. \fg 

Ces articles datent de la loi n° 2018-670 du 30 juillet 2018 relative à la protection du secret des affaires.
Il n'y a pas de jurisprudence pour confirmer mais on peut raisonnablement penser qu'une attaque sur un modèle de machine learning peut être considérée comme déloyale et contraire aux usages en matière commerciale.

Mais d'un autre côté, l'article L.151-3 alinéa 2 du Code de Commerce dispose que \og Constituent des modes d'obtention licite d'un secret des affaires l'observation, l'étude, le démontage ou le test d'un produit ou d'un objet qui a été mis à la disposition du public ou qui est de façon licite en possession de la personne qui obtient l'information, sauf stipulation contractuelle interdisant ou limitant l'obtention du secret. \fg
On pourrait donc dire que l'attaque s'apparente à une observation ou une étude d'un produit qui a été mis à la disposition du public.

Il faut donc attendre une jurisprudence en la matière pour savoir si cette attaque représente une atteinte au secret des affaires.
Quoi qu'il en soit, il est dans l'intérêt du producteur de la base de données de s'assurer que le fournisseur de solution machine learning sécurise convenablement ses modèles contre ce genre d'attaque.