La protec­tion des données est l’un des nombreux enjeux que pose le déve­lop­pe­ment des systèmes d’intelligence arti­fi­cielle. Compte tenu du rôle majeur que joue aujourd’hui le cadre règle­men­taire appli­cable aux données en matière d’innovation et, corol­lai­re­ment, sur le plan géopo­li­tique, il n’est pas surpre­nant que ce cadre soit en pleine évolu­tion, notam­ment au sein de l’Union euro­péenne.

Sans prétendre ici passer en revue ce cadre en deve­nir, cette contri­bu­tion s’interroge sur la mise en œuvre des grands prin­cipes appli­cables en protec­tion des données à ces systèmes. On consta­tera que ces prin­cipes font à bien des égards partie inté­grante des prin­cipes éthiques régis­sant le déve­lop­pe­ment des systèmes d’intelligence arti­fi­cielle que sont les notions de « fair­ness », « accoun­ta­bi­lity » et « trans­pa­rency » (I). Ceci fait, nous exami­ne­rons la manière dont la Proposition de Règlement sur l’IA (« Proposition »), compa­rée à l’approche qui prévaut pour le moment aux États-Unis, propose de gouver­ner le déve­lop­pe­ment et la mise en œuvre de ces systèmes, notam­ment en ce qui a trait à la gestion des risques (II). Nous formu­le­rons enfin quelques remarques conclu­sives s’agissant de l’adoption des stan­dards et des ques­tions de gouver­nance qui entourent le déploie­ment de ces systèmes (III).

Le cadre de cette étude étant limité en raison de sa briè­veté, le lecteur voudra bien excu­ser les raccour­cis parfois utili­sés, poten­tiel­le­ment source d’imprécision, le but étant avant tout de souli­gner les enjeux sans forcé­ment prétendre les résoudre ici.

I. Enjeux en matière de protec­tion des données

A. Répartition des rôles

Une première ques­tion consiste à savoir qui, dans un cas donné, sera consi­déré comme le respon­sable de trai­te­ment, puisque c’est avant tout sur ce dernier que repose le devoir de conformité.

Au stade du déve­lop­pe­ment du système, ce respon­sable sera à l’évidence le déve­lop­peur, le client utili­sa­teur ne jouant alors aucun rôle. C’est alors au déve­lop­peur qu’appartient le devoir de s’assurer que les grands prin­cipes mention­nés ci-dessous sont respectés.

Au stade de l’utilisation du système, le respon­sable sera en revanche en prin­cipe l’utilisateur, le déve­lop­peur n’apparaissant alors plus que comme le sous-trai­tant qui four­nit le système à son client à l’image de n’importe quel autre pres­ta­taire. La situa­tion peut toute­fois néces­si­ter une appré­cia­tion diffé­rente à partir du moment où le déve­lop­peur se réserve le droit d’utiliser les données ingé­rées par son client pour permettre l’amélioration de son algo­rithme. En cette hypo­thèse, le déve­lop­peur appa­raî­tra comme un respon­sable séparé (éven­tuel­le­ment conjoint si le client est contrac­tuel­le­ment en droit de profi­ter de ces amélio­ra­tions subsé­quentes) ; chacun sera alors tenu d’assurer le respect des exigences posées en matière de protec­tion des données.

Pour des raisons de place, on ne mention­nera pas ici le prin­cipe de licéité, dès lors qu’en pratique, le déve­lop­peur, respec­ti­ve­ment l’utilisateur, s’efforceront de faire valoir qu’ils détiennent un inté­rêt légi­time sous l’angle du RGPD, respec­ti­ve­ment un inté­rêt privé prépon­dé­rant à trai­ter de telles données sous l’angle de la LPD pour permettre la mise en œuvre du système. Si l’on peut à dire vrai s’interroger sur la perti­nence systé­ma­tique de ce motif justi­fi­ca­tif, véri­table fourre-tout dont le bien-fondé est de plus en plus tempéré par la CJUE, nous n’entrerons pas ici dans les détails d’une telle analyse qui méri­te­rait une contri­bu­tion en soi.

B. Principe de protec­tion des données dès la conception

Conformément au prin­cipe de protec­tion des données dès la concep­tion désor­mais ancré aux art. 25 RGPD et 7 LPD, le plus simple consiste à ne pas ingé­rer dans le système de données person­nelles pour l’entraîner.

De nombreuses tech­niques recen­sées par exemple par l’OCDE sont aujourd’hui envi­sa­geables, chacune présen­tant des avan­tages et des incon­vé­nients, que l’on pense à la simple anony­mi­sa­tion de données, le recours à des données synthé­tiques, à la confi­den­tia­lité diffé­ren­tielle (diffe­ren­tial privacy), aux divers systèmes de cryp­to­gra­phie ou encore à des tech­niques comme le « zero know­ledge proofs », à peu près intraduisible.

Outre le fait que ces tech­no­lo­gies néces­sitent une bonne gouver­nance pour être mises en œuvre dès le début du projet, leur recours peut s’avérer onéreux (par exemple en raison du volume de données à nettoyer) et, le cas échéant, ne pas permettre d’atteindre l’objectif visé (un des problèmes qui semble être évoqué s’agissant du recours à des données synthé­tiques, sans mention­ner le fait que l’anonymisation peut s’avérer toujours plus diffi­cile à atteindre en certains secteurs, notam­ment en ce qui a trait aux données de santé).

Lorsqu’une telle anony­mi­sa­tion s’avère impos­sible ou n’a pas été prise en compte dès le début comme l’exigerait pour­tant le prin­cipe « privacy by design », se pose la ques­tion du respect des prin­cipes de fina­lité, de mini­mi­sa­tion et de conser­va­tion des données.

C. Principes de fina­lité et de minimisation

Le prin­cipe de fina­lité commande que seules les données néces­saires pour atteindre le but visé soient trai­tées. Ce prin­cipe est ainsi étroi­te­ment lié à celui de mini­mi­sa­tion des données.

De prime abord, le respect de ces prin­cipes appa­raît raison­na­ble­ment envi­sa­geable pour les systèmes ayant une fina­lité clai­re­ment prédé­fi­nie lors de leur concep­tion. Leur respect est toute­fois à double tran­chant : un bon nettoyage des données pourra de prime abord permettre d’avoir des données de qualité et éviter une redon­dance inutile (suscep­tible de faci­li­ter des attaques) ou la favo­ri­sa­tion de biais. D’un autre côté, il peut toute­fois s’avérer diffi­cile pour le déve­lop­peur d’apprécier d’emblée quelles seront le type de données néces­saires pour entraî­ner au mieux l’algorithme et éviter des biais, un nettoyage trop impor­tant pouvant avoir un effet contre-produc­tif en la matière.

Assurer le respect de ces prin­cipes, même en partie, pour des modèles de fonda­tion (« foun­da­tio­nal models »), en vogue aujourd’hui et qui ont pour objec­tif de permettre un éven­tail d’utilisations aussi large que possible, appa­raît encore beau­coup plus hasar­deux. Est-ce à dire qu’au vu des fina­li­tés parti­cu­liè­re­ment larges envi­sa­geables de ces modèles, aucun prin­cipe de mini­mi­sa­tion ne serait appli­cable puisque, de prime abord, toutes les données auraient leur rôle à jour ? Tel n’est à mon avis pas le cas, bien au contraire.

De prime abord, pour de tels systèmes (à tout le moins leur large majo­rité à ce jour), aucune donnée person­nelle ne s’avère néces­saire pour atteindre l’objectif visé. Pour les modèles de fonda­tion, le mot d’ordre devrait ainsi être de recou­rir à des tech­niques d’anonymisation des données ou l’interdiction de recou­rir à des données person­nelles pour éviter une viola­tion alors parti­cu­liè­re­ment aisée du prin­cipe de mini­mi­sa­tion. Est-il besoin de dire qu’à l’heure où les inves­tis­se­ments dans les modèles de fonda­tion sont colos­saux, le respect de telles exigences appa­raît utopique ? Faudrait-il consi­dé­rer que celui qui divulgue de manière publique sur le Net certaines données person­nelles consent impli­ci­te­ment à leur exploi­ta­tion à des fins d’entraînement des algo­rithmes ? Ce débat n’est pas sans rappe­ler celui qui avait animé les spécia­listes du droit d’auteur lors de l’avènement du World Wide Web à la fin des années 90 et la ques­tion de savoir si la mise en ligne de conte­nus proté­gés par les titu­laires de droits impli­quait une licence auto­ri­sant les tiers à lier ces conte­nus ; au final, l’introduction de dispo­si­tions légales auto­ri­sant les copies provi­soires rendues tech­ni­que­ment néces­saires avait mis un terme au débat. En ira-t-il de même de l’entraînement des algo­rithmes des modèles de fonda­tion au moyen de données rendues publiques ? Le débat est ouvert.

À ce jour, il n’est en tous les cas pas certain que la simple possi­bi­lité confé­rée aux utili­sa­teurs recou­rant à de tels systèmes de faire du « opt out » pour éviter que leurs données ne soient ingé­rées dans le système, comme le permettent de nombreux systèmes en leur version payante, aussi dite « busi­ness » ou « enter­prise », suffisent à satis­faire au prin­cipe de mini­mi­sa­tion (étant précisé que ces utili­sa­teurs devraient éviter que ces données ne soient person­nelles, ce que les condi­tions géné­rales prévoient du reste en principe).

Là encore, l’établissement d’une gouver­nance adéquate appa­raît dès lors comme primor­dial pour se poser les bonnes ques­tions dès le départ.

D. Durée de conservation

En prin­cipe, les données ne doivent pas être conser­vées plus long­temps que néces­saire. La ques­tion du « néces­saire » est bien souvent large­ment inter­pré­tée comme permet­tant une conser­va­tion des données aussi long­temps que la fina­lité n’est pas atteinte. Or, cette fina­lité peut être défi­nie assez large­ment, telle l’amélioration de l’algorithme, vidant au final cette exigence de son sens.

On peut dès lors douter qu’une telle durée soit accep­table s’agissant du trai­te­ment de données person­nelles à des fins d’améliorer ad aeter­nam un algo­rithme, ce d’autant si leur l’utilité est d’emblée discutable.

À partir du moment où il peut s’avérer tech­ni­que­ment parti­cu­liè­re­ment compli­qué de ne nettoyer que les données person­nelles des données d’entraînement une fois ingé­rées dans le système, on y voit là une autre raison pour éviter d’emblée le recours à de telles données, sauf si la fina­lité du système en exige le recours.

Si le respect des points susmen­tion­nés est impor­tant, l’un des points les plus cardi­naux en lien avec ces systèmes réside dans la mise sur pied de mesures tech­niques et orga­ni­sa­tion­nelles adéquates pour assu­rer la confi­den­tia­lité, l’intégrité et la dispo­ni­bi­lité des données exploi­tées, tel que prévu aux art. 32 RGPD et 8 LPD.

II. Mesures tech­niques et orga­ni­sa­tion­nelles : l’appréciation du risque

Les malveillances et incon­vé­nients suscep­tibles d’affecter de tels systèmes sont connus (du moins en partie), qu’ils aient trait au manque de qualité des données ingé­rées par le système (redon­dance, biais) abou­tis­sant à des résul­tats inap­pro­priés, ou à une exploi­ta­tion indue de ces données dues à des manque­ments sur le plan sécu­ri­taire (qu’il s’agisse de « privacy attacks », « adver­sa­rial attacks » ou encore « poiso­ning attacks » pour prendre celles réper­to­riées  par le Bundesamt für Sicherheit in der Informationstechnik en matière de Large Language Models).

À ce titre, l’exécution d’une analyse d’impact quant à l’éventuelle surve­nance des risques liés à la mise sur pied d’un système donné risque fort de deve­nir un stan­dard sur le plan inter­na­tio­nal comme en témoignent les approches euro­péenne et améri­caine résu­mées ci-dessous :

A. La Proposition de Règlement sur l’intelligence artificielle

Sur le plan euro­péen tout d’abord, la Proposition prévoit un cadre de gouver­nance rigou­reux pour les systèmes dits à « risques élevés », qui ne s’appliquent certes pas dans leur inté­gra­lité aux autres systèmes, lesquels n’en seront pas moins soumis dans leur déve­lop­pe­ment et leur exploi­ta­tion à certaines exigences, notam­ment de trans­pa­rence s’ils présentent un risque limité.

Est ainsi prévu en premier lieu pour les systèmes à « risques élevés » à l’art. 9 de la Proposition la mise sur pied d’un système de gestion des risques visant à iden­ti­fier les risques connus ou prévi­sibles ou suscep­tibles d’apparaître tant dans le cadre d’une bonne ou mauvaise utili­sa­tion ainsi que les mesures envi­sa­gées pour réduire ou atté­nuer à tout le moins le risque résiduel.

Cette métho­do­lo­gie n’est pas sans rappe­ler celle de l’analyse d’impact en matière de protec­tion des données prévue à l’art. 35 RGPD. Il n’est donc guère surpre­nant que de nombreuses entre­prises envi­sagent d’intégrer une telle analyse à celle de l’art. 35 RGPD, 40% des entre­prises consul­tées lors d’une étude menée par l’IAPP ayant de surcroît prévu d’intégrer de telles analyses algo­rith­miques à leur analyse d’impact en matière de protec­tion des données. Parmi les risques devant être pris en compte dans le cadre de l’actuel art. 9 de la Proposition figure en en effet celui que le système porte atteinte aux droits fonda­men­taux des indi­vi­dus, une atteinte qui peut évidem­ment avoir lieu à bien des niveaux, la protec­tion des données étant l’un d’entre eux. On peut toute­fois se deman­der si, en lieu et place d’intégrer l’analyse algo­rith­mique prévue à l’art. 9 de la Proposition au sein de l’analyse d’impact prévue par l’art. 35 RGPD (et désor­mais de l’art. 22 LPD), ce n’est pas cette dernière qui devrait être inté­grée à l’analyse algo­rith­mique prévue par l’art. 9 de la Proposition, puisque cette analyse couvre à mon sens un éven­tail de risques beau­coup plus large.

S’ajoute à la mise sur pied de cette analyse et de système de gestion des risques en décou­lant, un certain nombre de dispo­si­tions aux art. 10 et suivants de la Proposition des obli­ga­tions renfor­çant cette gouver­nance en ce qui a trait à (1) la gouver­nance autour des données utili­sées, (2) l’établissement d’une docu­men­ta­tion tech­nique, (3) l’enregistrement dans un registre central, (4) le devoir d’information et de trans­pa­rence dus aux utili­sa­teurs, (5) le contrôle humain ainsi que des exigences autour de la (6) l’exactitude, la robus­tesse et la cybersécurité.

Formellement, force est dès lors d’admettre que la Proposition de Règlement couvre assez large­ment les préoc­cu­pa­tions rela­tives à la protec­tion des données en impo­sant un cadre rigou­reux au déploie­ment à tout le moins de ces systèmes à « risques élevés ». On ne saurait cepen­dant voir dans cette couver­ture théo­rique une garan­tie pratique du respect de ces exigences.

Sans entrer dans les détails, la Proposition, qui est encore en cours d’examen, n’est en effet pas sans susci­ter quelques inter­ro­ga­tions quant à la gouver­nance néces­saire pour assu­rer sa mise en œuvre et son respect. Compte tenu du fait que cet examen risque fort d’être un auto­con­trôle, est-il sérieu­se­ment imagi­nable à ce jour d’avoir une agence par pays et une agence euro­péenne à même de s’assurer du respect de l’ensemble de ces exigences, ne serait-ce que compte tenu de la multi­tude d’industries au sein desquelles ces outils peuvent être déployés, aux spéci­fi­ci­tés si diffé­rentes les unes des autres ? On peut en douter.

B. L’approche américaine

À ce jour, l’État fédé­ral n’a pas encore jugé utile de légi­fé­rer en la matière, et même si le parti Démocrate appelle désor­mais de ces vœux une régle­men­ta­tion en la matière, la pratique améri­caine consiste plutôt à lais­ser le soin aux diffé­rentes agences d’aborder certaines problé­ma­tiques spéci­fiques les concer­nant au travers de recom­man­da­tions ou de direc­tives, que l’on pense par exemple au US Copyright Office ou à la FTC. Le risque existe donc que les diffé­rents États passent eux-mêmes à l’offensive en adop­tant leur propre légis­la­tion, tels l’État de la Californie ou celui du Colorado sur certains points spéci­fiques, avec pour consé­quence un éven­tuel patch­work auquel les entre­prises seraient soumises au gré de leurs acti­vi­tés ce qui, est-il besoin de le dire, n’apparaît guère opti­mal ; voilà donc une affaire à suivre.

Toujours est-il que l’appréciation des risques liés à la mise en œuvre de systèmes d’intelligence arti­fi­cielle n’est évidem­ment pas absente des débats aux États-Unis, bien au contraire, puisque le National Institute of Standards and Technology a adopté le 26 janvier 2023 un docu­ment inti­tulé Artificial Intelligence Risk Management Framework (AI RMF 1.0). Ce docu­ment four­nit un cadre désor­mais consi­déré comme un stan­dard aux États-Unis et dont la prise en compte dépasse large­ment les fron­tières. Il s’articule autour de quatre piliers – ici large­ment résu­més – que sont :

• « Governance » : la gouver­nance implique la mise en place tant des ressources néces­saires que des proces­sus tenant compte à la fois de l’environnement régle­men­taire et des risques liés au déve­lop­pe­ment ainsi qu’à la mise en œuvre de ces systèmes tout au long de leur cycle de vie. Cette gouver­nance s’applique à l’ensemble du cadre envi­sagé par le NIST AI RMF 1.0, et fait donc partie inté­grante des trois autres piliers.
• « Mapping » : le déploie­ment de ces systèmes au sein d’une entre­prise néces­site de s’assurer qu’ils s’intègrent à la stra­té­gie de l’entreprise, que leur fina­lité et leurs objec­tifs sont bien défi­nis, leurs limites et risques bien compris et que tous ces points sont dûment docu­men­tés, le tout s’insérant dans une analyse guidée par une approche coûts/​bénéfices.
• « Measure » : suite à cette caté­go­ri­sa­tion des risques, il convient de les mesu­rer au travers de métho­do­lo­gies adéquates (ques­tion évidem­ment loin d’être anodine…). L’analyse doit porter sur les éléments permet­tant de s’assure que le système est « digne de confiance » (« trust­wor­thy AI »), ce qui intègre les aspects sécu­ri­taires et de protec­tion de la vie privée autour d’un audit de l’algorithme. Un tel contrôle doit avoir lieu non seule­ment au moment du déploie­ment, mais égale­ment lors de la vie de chacun de ces systèmes. L’un des objec­tifs pour­sui­vis par cette phase consiste à satis­faire aux exigences de trans­pa­rence (« trans­pa­rency ») et d’explicabilité (« explai­na­bi­lity ») de l’algorithme, même si l’effet « black box » rend un tel objec­tif poten­tiel­le­ment diffi­cile à atteindre, tout dépen­dant au final du niveau d’exigences que l’on souhaite atteindre au travers de ces concepts.
• « Manage » : l’aspect gestion exige la mise en place des ressources néces­saires pour permettre la bonne exécu­tion des aspects susmen­tion­nés, leur docu­men­ta­tion et la gestion des inci­dents suscep­tibles de survenir.

Le cadre proposé par le NIST AI RMF consti­tue de prime abord un cadre utile permet­tant la mise en œuvre de nombreuses exigences posées aux articles 9 et suivants de la Proposition de Règlement susmentionnée.

Ce n’est toute­fois, et de loin, pas le seul réfé­ren­tiel possible.

III. Standards et gouver­nance : le cœur du problème ?

Les stan­dards ayant trait aux systèmes d’intelligence arti­fi­cielle se multi­plient, au point qu’il est aisé pour le néophyte de s’y perdre.

Pour bon nombre d’entre eux, ces stan­dards sont élabo­rés au sein du sous-comité 42 du « ISO/​IEC JTC 1 », soit le comité tech­nique commun à l’International Organisation for Standardization (ISO) et l’International Electrotechnical Commission (IEC). À ce jour, le SC 42 a publié 17 stan­dards, et 30 sont en déve­lop­pe­ment.

Parmi ces stan­dards, on mention­nera en parti­cu­lier ISO/​IEC 23894 :2023 en matière de gestion des risques, ISO/​IEC 38507 : 2022 en matière de gouver­nance, ainsi que les normes ISO/​IEC 5259–5 concer­nant la qualité des données, ISO 42005 concer­nant l’analyse d’impact en matière d’intelligence arti­fi­cielle ou encore ISO/​IEC 6254 concer­nant l’explicabilité des systèmes.

L’environnement est donc riche. Se pose cepen­dant la ques­tion de savoir si ces stan­dards reflètent un large consen­sus et, à ce titre, de savoir quel est le proces­sus d’élaboration de ces stan­dards ; si le proces­sus légis­la­tif est connu, celui des stan­dards l’est moins, et il semble­rait que leur contenu dépende pour l’essentiel du nombre de personnes d’un pays donné qui se trouvent à la table, avec une prédo­mi­nance de certains acteurs… de là à dire qu’au final les absents ont toujours tort, il n’y a qu’un pas.

Au final, on constate que le cadre régle­men­taire se met en place, soutenu par des stan­dards qui devraient en prin­cipe large­ment tenir compte des exigences posées en matière de protec­tion des données et four­nir une aide utile aux entre­prises pour les aider dans la gouver­nance de tels systèmes.

À mon sens, deux risques majeurs existent néan­moins à ce stade. Tout d’abord, celui d’une approche écla­tée et frag­men­tée de stan­dards aux notions revê­tant des accep­tions diffé­rentes et ne reflé­tant qu’un consen­sus au fond discu­table, enca­drés par des régle­men­ta­tions fort diverses d’un pays ou d’une région du monde à l’autre. Ensuite, compte tenu de l’asymétrie d’informations qui existe aujourd’hui en matière d’intelligence arti­fi­cielle entre les véri­tables experts et… le reste du monde, il existe un risque évident de ne voir aucune agence gouver­ne­men­tale ou non gouver­ne­men­tale à même d’assurer le contrôle du respect de ces exigences, exigences de surcroît appli­cables à des indus­tries les plus diverses néces­si­tant des compé­tences impos­sibles à réunir au sein d’une seule et même agence. Il me semble donc que l’éducation et l’acquisition des connais­sances sont des compo­santes essen­tielles pour permettre une bonne gouver­nance de ces systèmes.

Poser un cadre est utile ; en permettre le contrôle et le respect est une néces­sité qui, à ce jour, me semble loin d’être assu­rée. Affaire à suivre.