Agents d’IA qui modifient des dossiers : qui est responsable au titre de l’AI Act ?

Le cas : une demande, un outil et un dossier modifié

Imaginons qu’une personne demande la mise à jour de l’adresse d’un client. Un agent interprète la demande, consulte un système d’entreprise, vérifie certaines informations puis envoie une instruction qui modifie le dossier. Pour répondre à la question juridique, il ne suffit pas de le qualifier d’« agent » ni de constater qu’il agit sans confirmation à chaque étape. Il faut d’abord déterminer quel système a été mis en service, dans quel but et par quelle entité.

Le règlement (UE) 2024/1689, connu sous le nom d’AI Act, ne crée pas de catégorie réglementaire distincte pour les agents. La Commission indique qu’un agent comprend généralement au moins un modèle d’IA à usage général et peut constituer un système d’IA. Cela ne signifie pas que chaque agent, considéré comme un ensemble technique ou un produit commercial, relève nécessairement d’une classification unique : plusieurs systèmes, composants et organisations aux fonctions différentes peuvent intervenir.

Pour analyser l’exemple, il faut décrire précisément le flux : qui fournit le système, qui le configure, quels outils y sont connectés, qui autorise les instructions et quelle décision entraîne la modification. Il importe également de savoir si l’agent prépare simplement une proposition ou exécute lui-même la modification, et si sa finalité consiste en une tâche administrative ordinaire ou en une activité relevant d’un domaine réglementé par le règlement. L’action externe est un élément pertinent pour l’analyse opérationnelle, mais elle ne suffit pas, à elle seule, à conclure que le système est à haut risque.

L’explication qui suit propose un cadre général de lecture de l’AI Act ; elle ne constitue pas une détermination juridique applicable à une mise en œuvre particulière. La répartition des rôles dépend de faits vérifiables et des relations entre les participants, pas seulement du nom donné au produit en interne.

Système, modèle, agent et rôles : des notions distinctes

Le règlement définit le « système d’IA » en fonction de caractéristiques telles que son fonctionnement avec différents degrés d’autonomie, sa capacité d’inférence et la production de résultats — par exemple des prédictions, contenus, recommandations ou décisions — susceptibles d’influencer des environnements physiques ou virtuels. La Commission a publié des lignes directrices pour aider à interpréter cette définition. L’analyse doit porter sur la solution concrète et ses capacités, plutôt que sur une appellation commerciale comme « agent », « copilote » ou « automatisation intelligente ».

Un modèle d’IA et un système d’IA ne sont pas synonymes. Un modèle peut être un composant du système ; le système comprend la manière dont le modèle est intégré, mis à disposition et utilisé. Quant au terme « agent », il décrit généralement une architecture ou un mode de fonctionnement pouvant combiner un modèle, des instructions, des outils, une mémoire et des mécanismes d’exécution. Cette description technique ne remplace pas les définitions du règlement.

Le « fournisseur » est, en termes généraux, la personne qui développe un système d’IA ou un modèle d’IA à usage général, ou en fait développer un, et le met sur le marché ou en service sous son nom ou sa marque, dans les conditions prévues par le règlement. Le « déployeur » est la personne qui utilise le système sous sa propre autorité, sauf dans le cadre d’un usage personnel non professionnel. Le rôle dépend des activités de l’entité et de la façon dont elle propose ou utilise le produit ; il peut différer d’un composant à l’autre au sein d’une même solution.

Le terme « intégrateur » ne constitue pas, à lui seul, une catégorie générale d’opérateur équivalente à celles de fournisseur ou de déployeur dans l’AI Act. Une entreprise qui connecte des outils peut se limiter à intégrer un système, mais ses activités peuvent aussi lui conférer un autre rôle selon les circonstances. L’article 25 prévoit des cas où un distributeur, un importateur, un déployeur ou un autre tiers est considéré comme fournisseur d’un système à haut risque, par exemple s’il le commercialise sous son nom, le modifie de manière substantielle ou change sa finalité prévue de sorte qu’il devienne un système à haut risque. Toute configuration ou intégration n’entraîne pas automatiquement cette conséquence.

Dans le cas du dossier, le fournisseur pourrait être celui qui propose le système agentique sous sa marque ; l’entreprise cliente pourrait être le déployeur si elle l’utilise sous sa propre autorité ; et une société technologique pourrait fournir des services d’intégration. Ces désignations ne sont toutefois que des hypothèses de travail : les contrats, la présentation du produit sur le marché, le contrôle de sa conception et les modifications effectuées peuvent changer l’analyse.

La finalité, et non l’autonomie prise isolément, guide la classification

L’AI Act ne classe pas comme systèmes à haut risque tous les systèmes autonomes, capables d’accéder à un outil ou de produire un effet externe. La classification dépend des critères et des domaines définis par le règlement. Il faut notamment déterminer si le système est un composant de sécurité d’un produit couvert par la législation énumérée, ou s’il correspond à l’un des cas d’usage de l’annexe III, en tenant compte des conditions et exceptions applicables.

Dans l’exemple, la modification d’une fiche client ne permet pas, à elle seule, d’affirmer que le système est à haut risque. Il faut identifier sa destination et le secteur ou le processus dans lequel il intervient. L’analyse pourrait changer si le système est utilisé, par exemple, pour une fonction expressément visée dans un domaine de l’annexe III, ou s’il fait partie d’un produit réglementé au sens du règlement. La présence de données à caractère personnel, l’automatisation ou l’importance commerciale d’une action ne suffisent pas à trancher.

La destination prévue se détermine à partir de ce que le fournisseur entend faire faire au système, comme l’indiquent notamment les instructions, la documentation technique et les supports commerciaux, ainsi que le contexte d’utilisation pertinent. Il faut aussi distinguer cette destination d’un usage réel qui s’en écarte. Si le déployeur modifie le système ou change sa destination, il peut être nécessaire de réévaluer sa classification et l’identité de la personne qui assume les obligations du fournisseur.

La Commission indique que les agents comprennent généralement au moins un modèle d’IA à usage général et peuvent constituer des systèmes d’IA. En pratique, il faut donc examiner séparément les règles applicables au modèle et celles qui s’appliquent au système intégré, sans déduire de la présence d’un modèle à usage général la classification du système dans son ensemble.

L’autonomie reste pertinente pour décrire le fonctionnement et évaluer les contrôles appropriés. Par exemple, le système peut proposer une modification qu’une personne exécute, l’appliquer après une approbation particulière ou l’effectuer automatiquement. Cette différence peut modifier l’évaluation opérationnelle, mais elle ne remplace pas les critères juridiques de classification prévus par l’AI Act.

Responsabilités : distinguer les obligations liées au système de celles liées à son usage professionnel

Le règlement répartit les obligations en fonction du rôle exercé et de la catégorie du système. Il serait donc inexact d’attribuer toutes les obligations au développeur du modèle ou de les transférer sans examen à l’entreprise cliente. Plusieurs entités peuvent être concernées par un même flux, mais seulement après avoir déterminé quel système est analysé, quelles règles lui sont applicables et qui répond à chaque définition.

Pour les systèmes à haut risque, l’article 16 fixe des obligations au fournisseur. Il s’agit notamment de veiller au respect des exigences applicables, de mettre en place un système de gestion de la qualité, de conserver la documentation et de satisfaire aux obligations d’évaluation de la conformité, d’enregistrement et aux autres exigences énoncées dans cet article. Cette référence ne transforme pas tout agent en système à haut risque et ne signifie pas que l’entreprise qui l’intègre est toujours son fournisseur.

L’article 26 régit les obligations des déployeurs de systèmes à haut risque. Il prévoit notamment qu’ils utilisent le système conformément aux instructions d’utilisation, confient la surveillance humaine à des personnes disposant des compétences et de l’autorité nécessaires et surveillent son fonctionnement dans les conditions prévues. La portée exacte dépend du fait que le système relève effectivement de la catégorie à haut risque et des dispositions applicables. Ces exigences ne doivent pas être étendues à toute action automatisée comme si elles constituaient une obligation générale de l’AI Act.

L’article 25 peut modifier la répartition des rôles lorsqu’une entité change de position à l’égard d’un système à haut risque : par exemple si elle le met sur le marché sous son propre nom ou sa propre marque, le modifie substantiellement ou change sa destination prévue de sorte qu’il devienne à haut risque. L’analyse suppose d’examiner la modification effectuée et ses effets sur le système ; connecter une API ou modifier un modèle de formulaire ne relève pas nécessairement de ces cas.

L’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour garantir, dans toute la mesure du possible, un niveau suffisant de maîtrise de l’IA pour leur personnel et les autres personnes qui exploitent ou utilisent des systèmes pour leur compte. Il faut tenir compte des connaissances, de l’expérience, de la formation, du contexte d’utilisation et des personnes concernées. Cette obligation ne remplace pas l’analyse des rôles et ne transforme pas les recommandations de conception de cet article en obligations légales.

D’autres règles européennes ou nationales peuvent également s’appliquer en fonction des données traitées, de la décision automatisée, du secteur et des conséquences. Cette analyse se limite à situer les questions au regard de l’AI Act et ne détermine pas les obligations relevant d’autres cadres.

Autorisations, confirmation et journaux : des contrôles de prudence

Même si l’AI Act ne transforme pas chaque contrôle technique imaginable en obligation générale, un agent capable d’écrire dans des systèmes d’entreprise appelle des limites opérationnelles proportionnées. Restreindre les outils disponibles, l’accès aux données et les opérations autorisées réduit les conséquences potentielles d’erreurs, de mauvaises interprétations d’instructions ou de défaillances d’intégration. Il s’agit de recommandations de conception et de sécurité, et non de l’affirmation que l’AI Act impose chacune de ces mesures pour tout déploiement.

Une pratique utile consiste à accorder les permissions minimales : permettre à l’agent de consulter uniquement les champs nécessaires et séparer les droits de lecture des droits d’écriture. Si une mise à jour risque d’entraîner un préjudice important ou est difficile à annuler, une approbation humaine avant exécution peut être nécessaire. Pour des changements courants, la conception peut autoriser une exécution automatique dans des limites strictes, avec des validations préalables et un mécanisme de retour en arrière. Le choix dépend de l’impact et du contexte ; il n’existe pas de formule universelle.

Des journaux opérationnels peuvent aider à reconstituer la demande à l’origine de l’action, les données ou outils utilisés, l’instruction envoyée, le résultat renvoyé par le système et l’éventuelle intervention d’une personne. Il convient de définir l’accès à ces journaux, leur durée de conservation et leur protection conformément aux règles applicables. Le fait d’enregistrer une action ne prouve pas, à lui seul, que le déploiement est conforme et ne remplace pas la documentation ou les registres exigés par la loi lorsqu’ils sont applicables.

Le recours à une personne est une mesure de conception appropriée lorsque le système détecte des données incomplètes, une instruction ambiguë, une opération sortant du schéma autorisé ou une défaillance d’un outil. Il faut préciser qui reçoit le dossier, quelles informations lui sont communiquées et s’il peut interrompre ou corriger l’opération. Pour les systèmes à haut risque, l’article 26 prévoit des exigences spécifiques de surveillance humaine à la charge des déployeurs ; dans les autres cas, cette recommandation de prudence ne doit pas être présentée comme une obligation équivalente de l’AI Act.

Ces mesures permettent d’encadrer les actions externes, mais ne règlent pas la classification juridique. Une mise en œuvre techniquement contrôlée peut toujours nécessiter une analyse de sa destination et des rôles ; inversement, un système à haut risque ne satisfait pas aux exigences applicables du seul fait que ses autorisations sont limitées.

Dates d’application et limites dans le temps

Le calendrier doit être lu à partir du texte officiel du règlement, en distinguant son entrée en vigueur de l’application effective de chaque obligation. Le règlement (UE) 2024/1689 est entré en vigueur le 1er août 2024. La règle générale prévoit son application à partir du 2 août 2026, mais l’article 113 fixe des dates antérieures pour certaines parties et une date ultérieure pour certains systèmes à haut risque intégrés à des produits réglementés.

À partir du 2 février 2025, les chapitres I et II sont applicables, conformément à l’article 113. Cela comprend notamment les définitions du chapitre I, l’obligation de maîtrise de l’IA prévue à l’article 4 et les pratiques interdites visées à l’article 5. Cette date ne signifie pas que l’ensemble du régime des systèmes à haut risque devient applicable à ce moment-là.

À partir du 2 août 2025, s’appliquent notamment les dispositions du chapitre V sur les modèles d’IA à usage général, ainsi que les règles institutionnelles et les dispositions relatives aux sanctions mentionnées à l’article 113. Pour les fournisseurs de modèles d’IA à usage général mis sur le marché avant le 2 août 2025, l’article 111 prévoit une disposition transitoire : ils doivent se conformer aux obligations applicables au plus tard le 2 août 2027.

L’application générale commence le 2 août 2026. Pour les systèmes à haut risque visés à l’article 6, paragraphe 1, qui sont des composants de sécurité de produits ou des produits relevant de la législation d’harmonisation énumérée à l’annexe I, l’article 113 indique la date du 2 août 2027. L’article 111 prévoit également des règles transitoires pour les systèmes à haut risque déjà mis sur le marché ou en service avant le 2 août 2026 ; leur portée dépend notamment de l’existence de modifications importantes de la conception et des autres conditions fixées par le texte.

Il ne suffit donc pas de citer une date générale dans un calendrier d’entreprise. Chaque obligation doit être associée à son article, à la catégorie concernée et à la disposition transitoire pertinente ; il faut également vérifier si le système ou le modèle était déjà sur le marché ou en service à la date considérée. Ce résumé reflète le texte du règlement (UE) 2024/1689 mentionné dans les sources fournies ; toute modification législative ultérieure doit conduire à vérifier de nouveau la version officielle avant de prendre une décision.

Liste de vérification avant le déploiement

Commencez par délimiter l’objet de l’analyse : s’agit-il d’un modèle, d’un système qui l’intègre ou d’un flux composé de plusieurs systèmes ? Représentez le chemin entre la demande initiale et la modification du dossier, en indiquant quel composant produit chaque résultat. Repérez toute action externe et l’entité qui en contrôle l’exécution.

Ensuite, établissez les rôles à partir d’éléments concrets : marque sous laquelle le système est proposé, contrats, documentation, entités qui commandent ou réalisent des modifications, personne qui décide de la finalité et entité qui utilise le système sous sa propre autorité. Vérifiez en particulier si une modification peut être substantielle ou si la destination prévue a changé d’une manière susceptible d’influer sur la catégorie du système.

Évaluez la classification sans raccourci : identifiez la destination prévue, examinez les critères de l’article 6 et les domaines pertinents des annexes, puis vérifiez les exceptions et conditions. Si les informations ne permettent pas de conclure, consignez la question comme non résolue et demandez un examen juridique ou réglementaire avant d’affirmer que le système est — ou n’est pas — à haut risque.

Enfin, distinguez les obligations légales des mesures de prudence : déterminez quelles dispositions s’appliquent au rôle de chaque entité et au système concerné ; notez les dates et transitions ; puis définissez les autorisations, approbations, journaux et procédures d’escalade comme des contrôles opérationnels assortis de responsables et de critères vérifiables. Le résultat doit pouvoir être réexaminé si le modèle, les outils, la finalité, le secteur ou les modalités d’utilisation changent.

Cette liste organise la vérification initiale, mais ne remplace pas un conseil juridique concernant un produit ou un déploiement particulier. Elle ne constitue pas non plus un guide complet de gestion des risques, de conformité des fournisseurs, d’évaluation d’impact ou de documentation des décisions. Son objectif est d’éviter que l’autonomie de l’agent ne se substitue à une analyse fondée sur le texte juridique et sur des faits vérifiables.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.