Pour mieux comprendre les enjeux autour des différents scénarios d'attaque, 
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.

\FloatBarrier
\subsection{Protection des utilisateurs}
\label{sec:contexte-legal-util}
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 à travers l'étude de textes légaux.

L'article 4 paragraphe 1 du Règlement Général sur la Protection des Données, le RGPD, 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 traitée conformément au RGPD \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 d'apprentissage automatique 
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 l'équité 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.
Retrouver cet attribut sensible à partir du modèle est possible~\cite{malekzadeh2021honestbutcurious,Song2020Overlearning}.
Le traitement de cet attribut au sens de la définition de l'article 4 paragraphe 2 du RGPD est :
\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, tels 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 RGPD 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 Par conséquent, publier un modèle avec lequel il est possible de retrouver l'ethnie ou le genre est illégal, sauf exceptions.

Même si l'attribut sensible ne rentrait pas dans le cadre de l'article 9 paragraphe 1 du RGPD 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 RGPD 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{Discrimination}
\label{sec:contexte-legal-discrimination}
Les facteurs de discrimination et les données personnelles ont une grande intersection, (ethnie, couleur de peau, croyances religieuses, etc).
Si un adversaire utilise une attaque d'attribut pour inférer un facteur de discrimination et l'utilise pour réaliser une décision concernant un utilisateur, ou si un facteur de discrimination est implicitement ou explicitement utilisé par un modèle, il est possible que cette situation tombe dans le cadre des lois sur les discriminations.
Sur le site de \url{service-public.fr} nous trouvons la définition suivante de discrimination.
\textquote{La discrimination est un délit interdit par la loi et puni d'une amende et/ou d'une peine d'emprisonnement inférieure à 10 ans qui consiste à traiter défavorablement une personne en s'appuyant sur un motif interdit par la loi}~\cite{servicepubdiscrimination}.
Les motifs interdits par la loi se comptent au nombre de 25 critères de discrimination que nous listons en Annexe~\ref{anx:discri}. 
Nous remarquons que ces critères sont souvent ceux classifiés comme attribut sensible dans la littérature IA~\cite{Song2020Overlearning,malekzadeh2021honestbutcurious}.

En France, la lutte contre les discriminations fait partie des fondements de notre République.
Le mot \textquote{égalité} est dans la devise de la cinquième République comme en dispose l'article 2 de la Constitution du 3 Juin 1958.
L'article premier de notre Constitution dispose que
\textquote{Elle [la France] assure l'égalité devant la loi de tous les citoyens sans distinction d'origine, de race ou de religion. Elle respecte toutes les croyances.}.
De plus, l'article
71 alinéa 1 de la Constitution met en place 
la Défenseure des droits qui veille notamment à défendre les personnes victimes de discrimination~\cite{defenseure}.
Cette instance pousse aussi pour plus de responsabilisation des utilisateurs d'IA qui utilisent ces technologies sans considérer leurs biais~\cite{defenseure2024lutter}.

Donnons un cas concret : l'utilisation de l'IA pour automatiser le recrutement est de plus en plus courant~\cite{defenseur2015emploi}.
Si les logiciels utilisés présentent des facteurs de discrimination ou collectent trop d'informations sur les candidats au recrutement, l'employeur est dans l'illégalité.
En effet, l'article L.1221 alinéa 6 du Code du travail dispose que les informations demandées
\textquote{doivent présenter un lien direct et nécessaire avec l'emploi proposé ou avec l'évaluation des aptitudes professionnelles}.
De plus l'article L.1132 alinéa 1 dispose qu'\textquote{aucune personne ne peut être écartée d'une procédure de recrutement ou de nomination ou de l'accès à un stage ou à une période de formation en entreprise, aucun salarié ne peut être sanctionné, licencié ou faire l'objet d'une mesure discriminatoire, directe ou indirecte}.

Comparativement à la loi française, aux États-Unis d'Amérique, l'effet différencié\footnote{\textit{Disparate impact}} est une manière pratique de contrôler si une procédure crée un désavantage, une discrimination, contre une minorité~\cite{biddle2006adverse}.
Cet effet différencié est une quantité qui peut être calculée à partir du modèle d'IA ou de toute autre procédure qui réalise une sélection binaire comme l'admission dans une école, l'attribution de prêt ou encore l'embauche.
C'est tout simplement la proportion d'admis de la minorité discriminée divisée par la majorité favorisée.
Nous en donnerons une définition plus formelle à la Section~\ref{sec:background-eq}
C'est donc une quantité qui varie entre 0 et 1 où 0 indique que personne dans la minorité n'est sélectionné et 1 indique qu'autant de personnes de la majorité que de la minorité sont sélectionnées : c'est la parité.
Aux États-Unis, si l'effet différencié est inférieur à $0,8$ cela constitue une preuve, au regard de la loi qui fait jurisprudence (\textit{Common law}), que le système de sélection fait preuve de discrimination.
En France nous n'avons pas de tel précédent ou de métrique précise à utiliser.

\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 ce manuscrit peuvent porter atteinte aux droits du producteur de la base de données.

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é Intellectuelle.
Nous sommes alors en droit de penser qu'une attaque de reconstruction représente l'extraction d'une partie de la base de données, en l'occurrence 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 d'apprentissage automatique.
Ici, la personne menant l'attaque porte atteinte aux droits du producteur de la base de données.

Considérons maintenant que c'est le fournisseur d'une solution d'apprentissage automatique, 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é Intellectuelle.
Dans le cas où le fournisseur de modèle permet à ses clients (le public) de mener à bien des attaques d'inférence d'attributs, il met à disposition une partie de la base par sa négligence à utiliser une méthode d'apprentissage résistante à ce type d'attaque.

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 d'inférence de propriété 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 d'apprentissage automatique 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 d'IA 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 IA sécurise convenablement ses modèles contre ce genre d'attaque.

\subsection{Usage illicite de l'IA}
\label{sec:contexte-aiact}
Comme nous l'avons vu à la Section~\ref{sec:contexte-insti} avec l'exemple de la Chine, l'IA peut-être utilisée pour des raisons qui vont à l'encontre des droits les plus fondamentaux.
Face à cette menace, 
l'Union Européenne a établi 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~\cite{aiact}.
Étant un règlement il est directement applicable en droit français.
Ce règlement a trois approches visant à limiter une utilisation de l'IA qui serait contraire aux droit fondamentaux.

La première approche consiste à responsabiliser les fournisseurs et les déployeurs de systèmes d'IA quant aux potentielles dérives avec l'article 4.
De plus l'article 50 dispose de l'obligation des fournisseurs et des déployeurs de transparence, c'est-à-dire informer les utilisateurs qu'ils interagissent avec une IA.
Enfin, de par leur nature générale et pouvant amener à la création d'IA multiples, les fournisseurs de modèle de fondation\footnote{\textit{Fundation model}} comme ChatGPT ou Llama sont soumis à de plus grandes obligations et responsabilités.

La seconde approche très pragmatique consiste à interdire un certain nombre de pratiques qui sont listées à l'article 5.
Citons certaines qui sont en rapport avec ce manuscrit.
Le paragraphe 1 alinéa c point (i) dispose que
\textquote{
Les pratiques en matière d’IA suivantes sont interdites:[...]
la mise sur le marché, la mise en service ou l’utilisation de systèmes d’IA pour l’évaluation ou la classification de
personnes physiques ou de groupes de personnes[...]
conduisant [au] 
traitement préjudiciable ou défavorable de certaines personnes physiques ou de groupes de personnes dans des
contextes sociaux dissociés du contexte dans lequel les données ont été générées ou collectées à l’origine
}
Ce qui, en plus des lois françaises sur les discriminations que nous avons citées plus haut, permet de clairement interdire l'utilisation d'IA qui vont utiliser des critères de discrimination dans leur décision.
Ce point est particulièrement important pour ce manuscrit car nous allons développer aux Chapitres~\ref{sec:fini} et~\ref{sec:aia} une méthode d'audit des systèmes d'IA qui permet de savoir si un système utilise un critère de discrimination pour réaliser une prédiction.

Citons aussi le paragraphe 1 alinéa d qui dispose que sont interdits les systèmes d'IA
\textquote{visant à évaluer ou à prédire le risque qu’une personne physique commette une infraction pénale}.
C'est un point de divergence important avec la législation des États-Unis qui utilise ce genre de système comme nous l'avons vu à la Section~\ref{sec:contexte-insti}.
Dans ce manuscrit nous avons utilisé des bases de données États-Uniennes pour construire ce genre de systèmes IA pour les étudier.
Bien que nos conclusions sur ces systèmes ne puissent pas s'appliquer dans l'Union Européenne étant donné qu'ils sont désormais interdits, notre analyse théorique reste valable et applicable à d'autres systèmes.
Nous avons d'ailleurs évalué nos solutions sur d'autres modèles n'impliquant pas la justice prédictive.

La troisième approche consiste à classifier un certain nombre de pratiques comme des \textquote{systèmes d'IA à hauts risques}.
Comme en dispose l'article 6, paragraphe 2 les systèmes à hauts risques sont par exemple des systèmes qui concernent :
\begin{itemize}
    \item Emploi, gestion de la main-d'œuvre et accès à l'emploi indépendant (Annexe III, paragraphe 4)
    \item Accès et droit aux services privés essentiels et aux services publics et prestations sociales essentiels (Annexe III, paragraphe 5)
\end{itemize}
Ce sont deux points pour lesquels nous avons construit des systèmes d'IA à titre illustratif dans ce manuscrit à la Section~\ref{sec:aia}.
Cette classification d'IA à hauts risque impose des règles plus restrictives pour le déploiement.
Par exemple l'article 9, paragraphe 1, dispose qu'un système de gestion des risques doit être établi.
L'article 13, quant à lui, impose un certain niveau d'explicabilité du système.
Enfin nous attirons l'attention du.de la lecteur.rice sur l'article 15 qui met l'accent sur la sécurité de tels systèmes, forçant les fournisseurs à contrôler par exemple que leur système ne contienne pas de porte dérobée.
