Une entreprise suisse utilise un assistant pour préparer des notes internes. Elle développe aussi un service de recrutement destiné à des clients européens. Les deux applications peuvent appeler le même modèle, sans relever des mêmes responsabilités ni des mêmes obligations.
Le règlement européen sur l’intelligence artificielle, souvent appelé AI Act, examine notamment le rôle de l’organisation, le rattachement à l’Union et l’usage prévu. Une première analyse peut suivre quatre questions. Elle rassemble les faits nécessaires au travail juridique et aux décisions techniques ; elle ne remplace pas la qualification d’un cas particulier.
1. L’entreprise fournit-elle le système ou l’utilise-t-elle ?
Le règlement définit un système d’IA par plusieurs caractéristiques, dont sa capacité à inférer, à partir de ses entrées, la manière de produire des résultats comme des prévisions, des contenus ou des recommandations. L’inférence distingue cette notion d’une simple étiquette commerciale. Toute automatisation ou formule fixe ne devient pas automatiquement un système d’IA.
Le modèle est un composant. Le système comprend également les données, les instructions, les outils, l’interface et les contrôles qui déterminent son usage. Pour un agent, la capacité d’appeler des logiciels ajoute des décisions sur les actions possibles et les permissions.
Les deux rôles suivants permettent de distinguer l’utilisation d’un système de sa mise à disposition.
- Le fournisseur développe un système, ou en fait réaliser le développement, puis le met sur le marché ou en service sous son nom selon les conditions du règlement.
- Le déployeur utilise un système sous son autorité dans le cadre concerné. L’achat d’un assistant pour les collaborateurs correspond souvent à cette situation.
Une entreprise peut donc être fournisseur d’un service à sa marque même si un prestataire a développé le logiciel. À l’inverse, les collaborateurs qui utilisent un outil sous les instructions de leur organisation ne deviennent pas nécessairement des déployeurs distincts. D’autres rôles existent dans la chaîne de commercialisation et demandent un examen lorsqu’ils sont pertinents.
L’inventaire précise le nom sous lequel le système est proposé, sa finalité, les acteurs qui le modifient et ceux qui contrôlent son usage. Une modification importante ou un changement de finalité peut nécessiter une nouvelle qualification. Le contrat ne suffit pas à décider du rôle si le fonctionnement réel décrit une autre situation.
Dans notre exemple, l’entreprise qui fournit le service de recrutement examine ses responsabilités sur l’ensemble du système. Pour l’assistant interne acheté à un éditeur, elle commence par celles liées à son utilisation et à son propre paramétrage.
2. Quel lien rattache cet usage à l’Union européenne ?
Le siège suisse ne suffit pas à écarter le règlement. Son champ territorial comprend plusieurs situations, notamment la mise sur le marché ou en service dans l’Union, les déployeurs qui y sont établis ou situés, et certains cas où le résultat d’un système exploité depuis un pays tiers est utilisé dans l’Union.
L’organisation doit donc décrire les entités et les usages. Un groupe suisse peut avoir une filiale européenne qui utilise un système. Un fournisseur suisse peut proposer un service sur le marché européen. Un résultat produit en Suisse peut être utilisé par une autre entité dans l’Union. Ces liens appellent des analyses distinctes.
Un assistant réservé à une équipe genevoise, sans autre rattachement établi, ne présente pas les mêmes faits qu’un score de candidature exploité par un bureau français. La disponibilité d’une page sur internet ne dispense pas de vérifier les destinataires, le marché visé et l’utilisation du résultat.
La fiche de cadrage indique les sociétés concernées, les pays, les utilisateurs et les destinataires des résultats. Elle doit permettre de retrouver les hypothèses de l’analyse. L’ouverture du service à un nouveau marché ou à une autre population peut changer la conclusion.
Cette étape détermine si les obligations européennes doivent être examinées pour l’usage. Elle ne dispense pas l’entreprise d’appliquer le droit suisse ou les règles sectorielles qui la concernent.
3. Quelle finalité et quels effets faut-il examiner ?
Le règlement distingue des pratiques interdites, des usages à haut risque et des obligations particulières, notamment de transparence. Ces dispositions ne forment pas toutes des catégories mutuellement exclusives. Une obligation d’information peut accompagner un système soumis à d’autres exigences.
Une pratique interdite ne devient pas autorisée par l’ajout d’un contrôle après son déploiement. L’organisation doit vérifier la finalité avant de consacrer des moyens à l’architecture. La notation sociale et certains usages de reconnaissance des émotions illustrent des domaines où le texte prévoit des interdictions et des conditions précises.
Les systèmes à haut risque demandent une qualification de l’usage et des exceptions éventuelles. Le recrutement, certaines décisions en matière d’éducation et l’accès à des services essentiels figurent parmi les domaines concernés. Un outil qui aide à rédiger une annonce n’a pas nécessairement la même finalité qu’un système qui classe les candidats.
Les règles de transparence examinent notamment les interactions avec des personnes et certains contenus générés. Le rôle de fournisseur ou de déployeur influence la responsabilité. Pour un assistant destiné au public, l’équipe vérifie l’information présentée dans l’interface et les conditions prévues par l’article 50, plutôt que de supposer qu’une mention générale suffit.
| Usage illustratif | Question déterminante | Conséquence technique à examiner |
|---|---|---|
| Assistant de rédaction interne | Quels contenus et quelles décisions l’outil influence-t-il ? | Données autorisées, réglages et relecture du message |
| Assistant destiné aux clients | Quelles obligations d’information et quels accès personnels s’appliquent ? | Identification de l’IA, séparation des dossiers et contact humain |
| Classement de candidatures | La finalité entre-t-elle dans le régime du haut risque ? | Critères, données, erreurs entre groupes et contrôle indépendant |
| Préparation d’écritures comptables | Quels droits permettent de préparer ou d’exécuter une action ? | Séparation entre proposition, validation et paiement |
Ces exemples orientent l’analyse sans fournir une conclusion juridique valable dans tous les contextes. Le passage de la rédaction à l’envoi, ou de la recommandation à la décision, peut modifier les risques et les obligations sans changer le modèle.
Le calendrier mérite également une lecture par disposition. La Commission européenne présente les échéances du règlement. Les interdictions et les dispositions relatives à la maîtrise de l’IA ont commencé à s’appliquer en février 2025, et les obligations de transparence en août 2026. Son calendrier distingue les usages à haut risque de l’annexe III, avec une échéance au 2 décembre 2027, et les systèmes liés aux produits réglementés de l’annexe I, au 2 août 2028. Les conditions et mesures transitoires doivent être vérifiées dans les textes applicables.
Une échéance future ne supprime pas les obligations déjà issues du droit du travail ou de la protection des données. Elle ne réduit pas non plus le temps nécessaire pour réunir les données, tester un système et organiser son contrôle humain.
4. Quelles décisions la conception et les essais doivent-ils démontrer ?
Le dossier technique part de l’usage qualifié. Il décrit les personnes autorisées, la tâche, les sources et les actions possibles. Ces éléments permettent de distinguer une évolution approuvée d’un élargissement du système qui demanderait un nouvel examen.
La carte des flux suit les données depuis leur collecte jusqu’aux résultats et aux journaux. Elle identifie les prestataires, les lieux de traitement et les durées de conservation. Un engagement de non-entraînement et une durée de conservation répondent à des questions différentes ; les deux doivent correspondre au produit et aux paramètres retenus.
Les essais mesurent le résultat sur un ensemble représentatif de cas. Ils distinguent les réponses utiles, les erreurs et les refus. Lorsqu’un système influence l’évaluation de personnes, l’analyse examine aussi les différences d’erreur entre groupes et les limites des données disponibles. Un résultat global favorable peut masquer une difficulté importante sur une partie de la population.
Le contrôle humain doit disposer des moyens nécessaires. La personne chargée de la revue reçoit les éléments d’origine, peut contester le résultat et possède le pouvoir de le modifier ou de le refuser. L’équipe examine sa charge de travail et les cas où elle suit systématiquement la machine. Une signature ajoutée après coup ne démontre pas ce contrôle.
Les permissions traduisent ensuite les limites dans les outils. Un agent autorisé à préparer une écriture ne reçoit pas automatiquement le droit de déclencher un paiement. Un assistant ne doit pas accéder aux données d’un autre client pour améliorer sa réponse. L’application vérifie ces règles lors des appels, au-delà des seules instructions données au modèle.
Les journaux doivent permettre de reconstituer les opérations utiles sans accumuler des informations personnelles sans finalité. L’équipe prévoit également l’arrêt du système, le retrait des accès et les conditions de reprise. Un exercice vérifie ces mécanismes avant leur utilisation dans un incident réel.
Cette documentation représente une méthode de préparation du projet. Le règlement n’impose pas ce dossier identique à tous les systèmes ; les exigences précises dépendent du rôle et de la qualification retenus.
Articuler cet examen avec les obligations suisses
L’absence d’un régime européen applicable à un usage ne crée pas une absence de règles. Le PFPDT rappelle que la LPD encadre déjà les traitements d’IA portant sur des données personnelles. La finalité, l’information, les données utilisées et les mesures de protection restent donc à examiner.
Une décision individuelle automatisée au sens de l’article 21 LPD possède des caractéristiques précises, notamment un effet juridique ou une atteinte significative à la personne sans intervention humaine dans la décision. Les obligations d’information et de réexamen s’apprécient avec les exceptions prévues par la loi. Une simple aide à la rédaction ne doit pas être confondue avec une décision répondant à cette définition.
Une analyse d’impact relative à la protection des données peut être nécessaire lorsque le traitement envisagé présente le risque élevé prévu par la LPD. Elle possède un objet juridique propre. La fiche de mise en production et les tests techniques peuvent fournir des éléments utiles sans remplacer cette analyse.
L’analyse documente le rôle de l’entreprise, le champ territorial, la finalité de l’application et les configurations techniques à vérifier. Cette continuité donne aux personnes chargées du projet une base commune pour examiner ses évolutions.
Sources et date de référence
- Commission européenne | cadre et calendrier du règlement sur l’IA
- Commission européenne | modifications liées à l’AI Omnibus
- PFPDT | IA et protection des données
- PFPDT | devoir d’informer
- PFPDT | analyse d’impact
Le calendrier cité correspond aux informations officielles consultées pour la révision du 7 octobre 2026. L’article fournit une méthode de premier examen ; les textes en vigueur et les faits du projet déterminent la qualification juridique finale.