S'applique-t-il hors de l'UE ?

« Nous ne sommes pas une entreprise européenne, donc cela ne nous concerne pas » est la lecture la plus fréquente et la plus coûteuse du règlement européen sur l'IA. L'article 2 atteint les fournisseurs et les déployeurs quel que soit leur lieu d'établissement. L'immatriculation n'est pas le critère. Ce qui compte, c'est le lieu où votre système est mis sur le marché, le lieu où se trouve votre déployeur et - la clause balai que presque tout le monde manque - le lieu où le résultat est utilisé.

L'article 2(1)(c) applique le règlement aux fournisseurs et aux déployeurs de pays tiers « lorsque les sorties produites par le système d'IA sont utilisées dans l'Union ». Une entreprise de San Francisco sans entité européenne, sans serveurs européens et sans personnel européen entre dans le champ d'application dès qu'un client de Dublin utilise ce que son modèle produit.

Les sept manières d'entrer dans le champ d'application

Les cas qui se présentent réellement

SaaS américain avec des clients européens. Dans le champ d'application. Vous êtes le fournisseur des fonctions d'IA que vous livrez, et l'usage qu'en font vos clients place le résultat dans l'Union. Une immatriculation au Delaware n'y change rien. Les spécificités SaaS.

Entreprise britannique après le Brexit. Le Royaume-Uni est un pays tiers à ces fins, de sorte que l'analyse est identique à celle des États-Unis : des utilisateurs européens signifient l'entrée dans le champ d'application. Le Royaume-Uni n'a pas de loi équivalente, ce qui veut dire que les entreprises britanniques héritent des obligations du règlement sans régime national auquel les aligner.

Entreprise européenne qui ne vend qu'en dehors de l'UE. Toujours dans le champ d'application en tant que déployeur au titre du 2(1)(b) pour les systèmes que vous utilisez vous-même, parce que ce membre de phrase tient au lieu de votre établissement et non à celui de vos clients. Votre outillage d'IA interne est attrapé même si aucun client n'est européen.

Entreprise non européenne, personnel européen. L'usage que vous faites de l'IA à l'égard de ces salariés est une activité de déployeur touchant des personnes dans l'Union. Les outils RH sont le déclencheur habituel - et c'est aussi le domaine de l'annexe III aux obligations les plus lourdes. Le détail RH.

Traitement de données personnelles européennes mais résultat utilisé ailleurs. C'est ici que le règlement sur l'IA et le RGPD se séparent. Le RGPD suit les données personnelles. Le règlement sur l'IA suit le système, le marché et le résultat. Vous pouvez être en plein dans le champ du RGPD et hors de celui du règlement sur l'IA, ou l'inverse. La correspondance, pour les équipes protection des données.

Les fournisseurs non européens de systèmes à haut risque ont besoin de quelqu'un dans l'Union

Au titre de l'article 22, un fournisseur établi dans un pays tiers doit désigner, par mandat écrit, un mandataire établi dans l'Union avant de mettre un système d'IA à haut risque à disposition sur le marché de l'Union. Le mandataire conserve la documentation, coopère avec les autorités et peut mettre fin au mandat si le fournisseur agit contrairement à ses obligations.

Une exigence parallèle vaut, au titre de l'article 54, pour les fournisseurs de pays tiers de modèles d'IA à usage général.

C'est l'obligation que la plupart des équipes non européennes découvrent en dernier, parce qu'elle est administrative plutôt que technique - et c'est une condition préalable à l'accès au marché, pas une formalité que l'on rattrape après coup. Elle ne s'applique que si ce que vous livrez est réellement à haut risque, ce qu'il vaut la peine d'établir avant de partir en quête d'un mandataire.

Ce qui est réellement hors du champ d'application

L'exclusion open source est celle que l'on invoque le plus souvent à tort. Publier un modèle sous licence permissive ne l'exempte pas s'il est mis en service comme système à haut risque, s'il met en jeu une pratique interdite, ou si les obligations de transparence de l'article 50 s'appliquent.

Entrer dans le champ d'application n'est pas la même chose qu'être accablé d'obligations

C'est la partie qui se perd. Le champ d'application et le niveau de risque sont deux questions distinctes, et presque toutes les entreprises non européennes qui paniquent sur la première découvrent que la seconde est peu exigeante.

La plupart des entreprises SaaS non européennes dans le champ d'application finissent fournisseurs de systèmes à risque limité ou minimal. Ce que cela veut dire en pratique : l'information prévue à l'article 50 si votre produit converse avec les utilisateurs, la maîtrise de l'IA prévue à l'article 4 pour le personnel, et une vérification au titre de l'article 5. Le chapitre III - évaluation de la conformité, marquage CE, enregistrement dans la base de données de l'UE - ne s'applique que si ce que vous livrez relève réellement du haut risque de l'annexe III.

Le livrable qui compte vraiment pour une entreprise non européenne est une position écrite et datée : lesquels de vos systèmes entrent dans le champ d'application, au titre de quel membre de l'article 2, à quel niveau de risque, et ce qui en découle. C'est ce que demandent les services achats des grands comptes européens, et c'est en général une journée de travail plutôt qu'un programme de conformité.

Le champ d'application territorial est réglé par l'article 2 d'après les faits de votre déploiement, non d'après l'emplacement de vos serveurs. Un hébergement aux États-Unis ne vous en sort pas, et un hébergement dans l'UE ne vous y met pas. Le scan gratuit parcourt les membres de l'article 2 avant de regarder le niveau de risque, parce qu'une erreur sur le champ d'application fausse tout ce qui suit.