AI Act en 2026 : comment déterminer si un système d’IA déclenche des obligations, quelles preuves réunir et quand une personne intervient

Champ d’application de ce guide : une décision traçable, non un avis juridique

Ce guide s’adresse aux équipes produit, sécurité, conformité, achats et technologie qui développent, intègrent, distribuent ou utilisent des systèmes d’IA liés au marché de l’Union européenne. Son objectif est de transformer un cas d’usage en une fiche vérifiable : ce que fait le système, qui intervient dans la chaîne d’approvisionnement, où il est utilisé, quelle catégorie peut être pertinente, quelles obligations sont en vigueur et quelles preuves existent.

Il ne vise pas à trancher définitivement la qualification juridique d’un produit précis. L’application du règlement sur l’IA dépend des faits, de la finalité prévue, de la configuration réelle, des acteurs qui prennent des décisions et, dans certains secteurs, de règles supplémentaires. La vie privée, l’emploi, le crédit, les dispositifs médicaux, l’aviation, la biométrie et la fourniture de services publics peuvent exiger des évaluations au titre d’autres cadres.

Les dates comptent, mais il n’existe pas de date d’application unique pour l’ensemble du règlement. La Commission européenne présente un calendrier échelonné : certaines règles, notamment celles portant sur les pratiques interdites et la culture de l’IA, ont commencé à s’appliquer avant le régime général. En outre, une modification législative ultérieure modifie le calendrier de certaines obligations concernant les systèmes à haut risque.

Utilisez ce document comme une procédure de gouvernance. Pour examiner des contrôles opérationnels, consultez la section Sécurité ; pour évaluer des solutions techniques et des fournisseurs, la section Comparer ; et pour situer les capacités et les cas d’usage, la section Découvrir.

Étape 1 : délimitez le cas d’usage avant d’évaluer le risque

L’unité d’analyse ne devrait pas être seulement le nom commercial d’un outil. Il peut s’agir d’une fonctionnalité précise, d’une version de modèle, d’un flux automatisé ou d’une intégration. Un même produit peut comporter des fonctions présentant des niveaux d’exposition différents : résumer des documents internes n’équivaut pas à prioriser des personnes pour une prestation, ni à effectuer des modifications dans un compte externe.

Documentez la finalité prévue déclarée par la personne ou l’organisation qui fournit le système, ainsi que la finalité effective que votre organisation configure ou autorise. Incluez les territoires de mise sur le marché, d’utilisation ou de disponibilité des résultats ; les groupes potentiellement affectés ; l’environnement d’utilisation ; la phase du cycle de vie ; les interfaces ; et les actions ultérieures rendues possibles. Conservez les captures de configuration, les contrats, les instructions, les évaluations et les versions.

Identifiez également s’il s’agit d’un modèle d’IA à usage général, d’un système construit sur ce modèle, ou des deux. Les lignes directrices de la Commission sur les modèles d’IA à usage général sont interprétatives et aident à distinguer les obligations du fournisseur du modèle de celles de l’acteur qui propose ou déploie un système en aval. Elles ne remplacent ni le texte réglementaire ni une interprétation judiciaire.

Étape 2 : identifiez le rôle à partir de l’activité, non du nom du contrat

Une organisation peut exercer plus d’un rôle à l’égard de produits ou de composants différents. L’intitulé d’un contrat — par exemple « client », « partenaire » ou « revendeur » — ne détermine pas à lui seul le résultat. Ce qui compte pour l’analyse est l’acteur qui développe, fait développer, commercialise, met en service, importe, distribue, modifie ou utilise le système sous son autorité.

Dans un cadre opérationnel, considérez comme fournisseur potentiel l’acteur qui développe un système ou un modèle, ou en fait développer un, et le commercialise ou le met en service sous son nom ou sa marque. Considérez comme déployeur potentiel l’acteur qui utilise un système sous son autorité, sauf dans le cadre d’usages personnels non professionnels. L’importateur et le distributeur sont des rôles de la chaîne commerciale qui imposent d’examiner comment le système est introduit ou mis à disposition dans l’Union. La qualité de mandataire autorisé exige une désignation et un mandat vérifiables.

Une modification substantielle, un changement de finalité ou une commercialisation sous marque propre sont des signaux invitant à interrompre le flux automatique et à demander un examen spécialisé. Les lignes directrices disponibles sur le champ des obligations des fournisseurs de modèles d’IA à usage général traitent notamment de l’identification du fournisseur, de la mise sur le marché et des modifications ; leur statut de guide interprétatif doit être consigné dans le dossier.

Étape 3 : classez l’usage et distinguez des catégories qui ne sont pas interchangeables

Commencez par déterminer si le cas peut être lié à une pratique interdite. Les pratiques interdites relèvent d’un régime d’application antérieur au calendrier général. La Commission a publié des lignes directrices sur ces pratiques ; elles sont utiles pour structurer les questions et les exemples, mais l’interprétation finale faisant autorité relève des juridictions compétentes de l’Union.

Évaluez ensuite, sans présumer du résultat, quatre dimensions différentes : si le système pourrait relever du haut risque parce qu’il constitue un composant de sécurité d’un produit réglementé ou en raison d’une autre hypothèse réglementée ; si son cas d’usage pourrait entrer dans des catégories à haut risque ; s’il déclenche des obligations de transparence ; et si un modèle d’IA à usage général intervient. Un système peut exiger de la transparence sans être à haut risque. Un modèle d’IA à usage général n’équivaut pas automatiquement à un système à haut risque déployé par un tiers.

Ne transformez pas une liste de secteurs en diagnostic. La finalité précise, l’effet sur les personnes, l’autonomie opérationnelle, le contexte de mise en œuvre et les exceptions applicables peuvent modifier la conclusion. Si le système affecte l’emploi, l’éducation, l’accès à des services essentiels, le crédit, la santé, la biométrie, l’administration de la justice ou les services publics, faites d’un examen juridique et sectoriel une condition de sortie.

Étape 4 : établissez une chronologie par obligation et par condition

La planification doit relier chaque obligation à une condition de déclenchement, et ne pas se limiter à une date globale. Le cadre présenté par la Commission indique que les pratiques interdites et les obligations de culture de l’IA s’appliquent depuis le 2 février 2025. Les obligations relatives aux modèles d’IA à usage général et certaines dispositions de gouvernance ont commencé à s’appliquer avant le régime général, le 2 août 2025. Le régime général prend comme référence le 2 août 2026, sous réserve des exceptions prévues.

Pour le haut risque, ne réutilisez pas automatiquement les dates antérieures. La modification législative publiée en 2026 reporte l’application liée aux systèmes de l’annexe III et aux systèmes liés à l’annexe I selon un calendrier distinct : le 2 décembre 2027 pour un groupe et le 2 août 2028 pour l’autre. La correspondance précise doit être validée à partir du texte consolidé et de la situation du système.

Les lignes directrices sur la transparence publiées par la Commission en 2026 sont présentées comme une orientation sur le champ pratique des obligations applicables à partir du 2 août 2026. Utilisez-les pour concevoir les contrôles et les preuves, et non pour remplacer l’analyse du texte légal ou d’actes ultérieurs.

Étape 5 : traduisez les exigences en preuves opérationnelles

Une obligation n’est gérable que si elle est liée à un responsable, une source, une date, une version et une preuve d’exécution. Le dossier ne doit pas se résumer à une déclaration commerciale générique. Il doit permettre de reconstituer quel système a été évalué, pour quelle finalité, avec quelle configuration, quels contrôles ont été appliqués et quelle décision a été prise.

Pour un cas susceptible de relever du haut risque, les domaines habituellement pertinents comprennent la gestion des risques, la gouvernance et la qualité des données lorsque cela est pertinent, la documentation technique, les journaux, les informations destinées aux déployeurs, la supervision humaine, l’exactitude, la robustesse et la cybersécurité. L’applicabilité concrète dépend de la classification et du rôle. N’affirmez pas qu’un contrôle satisfait à une exigence sans avoir vérifié son champ, son test et sa preuve.

La supervision humaine ne se démontre pas non plus par la phrase « une personne est dans la boucle ». Décrivez ce que la personne peut voir, à quel moment elle intervient, quelle autorité elle possède pour ignorer ou interrompre une sortie, quelle formation elle reçoit, comment les alertes sont gérées et ce qui se passe en cas d’automatisation excessive. Si elle ne peut pas intervenir matériellement avant une conséquence importante, documentez cette limite.

Étape 6 : appliquez l’analyse aux achats et à l’intégration de tiers

Acheter un système ou une API ne supprime pas les responsabilités de l’organisation qui le configure et l’utilise. L’acheteur doit distinguer la documentation reçue du fournisseur et les preuves produites sur sa propre mise en œuvre. Par exemple, le fournisseur peut apporter des instructions, des caractéristiques déclarées et une documentation de conformité lorsqu’elle est requise ; le déployeur doit pouvoir expliquer la finalité locale, les utilisateurs autorisés, les données connectées, les autorisations et les décisions prises à la suite d’une sortie.

Intégrez des questions de conformité dans la sélection, le contrat, la réception technique et la revue périodique. Demandez des informations d’un niveau de détail proportionné à l’usage prévu. Si le fournisseur refuse d’identifier la version, les changements significatifs, les limites connues, les conditions d’utilisation ou le mécanisme de gestion des incidents, considérez ce manque d’information comme un risque d’acquisition et non comme une simple question administrative.

Le code de bonnes pratiques pour l’IA à usage général, publié en 2025 et considéré par la Commission comme un outil volontaire approprié, peut constituer un indicateur documentaire utile dans certains cas. Il ne démontre pas à lui seul la conformité légale et ne remplace pas les preuves spécifiques au système intégré.

Trois scénarios : quels faits changent l’analyse

Premier scénario : un assistant interne rédige des brouillons à partir de documents chargés manuellement par l’équipe. S’il ne prend pas de décision concernant des personnes, n’exécute pas d’actions externes et est utilisé avec une revue humaine substantielle, le dossier peut initialement se concentrer sur la finalité, les données, l’information des utilisateurs, les autorisations, les fournisseurs et la formation. La classification change toutefois si les brouillons sont utilisés pour des décisions en matière d’emploi, de crédit, de santé ou d’accès à des services sans revue effective.

Deuxième scénario : un système priorise des demandes de clients. Le terme « priorisation » ne résout rien. Il importe de savoir s’il ordonne seulement une file opérationnelle ou s’il détermine de fait qui reçoit un service, dans quel délai, à quelles conditions et avec quelles possibilités de correction. Il convient de documenter les variables, les règles, les métriques, les biais connus, les responsables de l’annulation et les effets des faux positifs et des faux négatifs.

Troisième scénario : un agent peut envoyer des courriels, modifier des enregistrements ou déclencher des actions dans des outils externes. Le fait déterminant n’est pas qu’il utilise le langage naturel, mais l’étendue de ses autorisations, la réversibilité des actions, les seuils d’autorisation, l’identité qui exécute l’action et les contrôles avant et après l’action. Une capacité d’exécution étendue peut exiger une évaluation de sécurité plus approfondie même lorsque la classification réglementaire demeure incertaine.

Modèle textuel de fiche d’applicabilité

Conservez une fiche pour chaque cas d’usage et mettez-la à jour lorsque la finalité, le modèle, l’intégration, le fournisseur, les données ou la population affectée changent. La fiche doit pouvoir être lue par les équipes produit, sécurité, achats et conformité sans les obliger à reconstituer les décisions à partir de messages ou de réunions isolées.

Il est préférable de consigner explicitement une incertitude plutôt que de conclure une classification sans base suffisante. Indiquez quelle conclusion est un fait documenté, quel élément est une analyse interne et quelle question attend une confirmation juridique, technique ou contractuelle.

Erreurs fréquentes et situations dans lesquelles il faut s’arrêter pour escalader

Une erreur fréquente consiste à supposer que le fournisseur absorbe toute responsabilité. Une autre consiste à accepter une affirmation commerciale de conformité sans vérifier quel produit, quelle version, quelle finalité et quel acteur elle couvre. Il est également fréquent d’utiliser une date unique pour l’ensemble du règlement ou de transformer l’évaluation des risques en une case qui n’est plus revue après un changement technique ou contextuel.

Arrêtez le déploiement ou l’extension et sollicitez un avis juridique en présence d’une pratique potentiellement interdite ; d’une incertitude raisonnable sur le haut risque ; d’un traitement sensible ou de décisions produisant des effets significatifs sur des personnes ; de biométrie ; d’emploi ; de crédit ; de santé ; d’éducation ; de services publics ; d’activité policière ou judiciaire ; de commercialisation transfrontalière complexe ; de modification substantielle ; ou d’un conflit entre la finalité déclarée et l’usage réel.

Escalader ne revient pas à bloquer définitivement le produit. Cela signifie formuler une question précise, joindre les faits et les preuves, identifier la décision en attente et préserver une version du système évalué. Cette discipline rend l’examen juridique, relatif à la vie privée, à la sécurité ou aux droits fondamentaux plus rapide et vérifiable.

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.