AI Act : la checklist de conformité pour les entreprises qui utilisent des agents et des outils IA

Pour appliquer l’AI Act dans votre entreprise, inventoriez les usages, identifiez votre rôle juridique, écartez les pratiques interdites et associez à chaque obligation une preuve vérifiable. Un agent IA n’est pas automatiquement un système à haut risque : sa destination, les personnes concernées et son influence sur les décisions déterminent l’analyse. Au 24 octobre 2026, certaines règles s’appliquent déjà, tandis que les obligations propres aux systèmes à haut risque suivent un calendrier reporté.

Partir du calendrier applicable en octobre 2026

La conformité commence par une distinction : ce qui doit fonctionner aujourd’hui et ce qui doit être préparé pour une échéance ultérieure. Reprendre une checklist publiée avant les modifications de 2026 peut conduire à appliquer les mauvaises dates.

Le calendrier officiel de la Commission européenne, consulté pour cette page au 24 octobre 2026, indique les étapes suivantes :

Ensemble de règles	Date d’application	Conséquence pour l’entreprise
Premières pratiques interdites et dispositions sur les compétences en IA	2 février 2025	Contrôler les usages et organiser des mesures adaptées
Gouvernance et obligations relatives aux modèles d’IA à usage général	2 août 2025	Distinguer les obligations du fournisseur de modèle de celles de l’utilisateur
Application générale, notamment transparence, sous réserve des transitions prévues	2 août 2026	Vérifier les interfaces et les contenus concernés
Systèmes à haut risque relevant de l’annexe III	2 décembre 2027	Préparer les obligations correspondant aux usages sensibles
Systèmes à haut risque liés aux produits réglementés de l’annexe I	2 août 2028	Articuler conformité IA et réglementation du produit

Le report du haut risque ne suspend pas les autres règles. Il ne reporte pas non plus vos obligations en matière de données personnelles, de droit du travail ou de protection des consommateurs.

Cette page constitue une méthode de préparation et de contrôle. Le glossaire de l’AI Act présente les notions essentielles ; l’article AI Act : ce qui change pour les agents IA traite l’évolution du cadre.

1. Inventorier des usages, pas seulement des abonnements

Un tableau des logiciels achetés ne suffit pas. Le même service peut servir à reformuler un message, analyser des candidatures ou proposer une décision commerciale. Créez une entrée par usage suffisamment distinct pour que sa finalité et ses risques soient compréhensibles.

Recensez les comptes professionnels, les comptes personnels employés au travail, les fonctions IA des logiciels métier et les automatisations réalisées par des prestataires. Le catalogue des outils IA peut aider à reconnaître les familles présentes dans votre organisation ; il ne remplace pas cet inventaire interne.

Pour chaque entrée, renseignez :

• le service responsable et la personne qui autorise l’usage ;
• la finalité précise et les usages exclus ;
• le fournisseur, le système utilisé et les composants identifiables ;
• les utilisateurs, les personnes affectées et les pays concernés ;
• les données consultées, transmises, conservées ou produites ;
• les actions possibles et la place de la décision humaine ;
• les documents contractuels et techniques disponibles.

Pour un agent construit dans n8n, par exemple, décrivez le scénario configuré plutôt que le seul nom de la plateforme. Un agent qui prépare un brouillon et un agent qui modifie un dossier salarié nécessitent des analyses différentes.

Preuve recommandée : une fiche d’usage datée, avec propriétaire désigné et schéma des flux. Les exemples de preuves proposés dans ce guide sont des moyens pratiques de documentation, pas une liste de formulaires universellement imposés.

2. Déterminer si vous êtes déployeur ou fournisseur

Une entreprise qui utilise un système sous son autorité est généralement déployeur. Une entreprise qui développe, ou fait développer, un système et le met sur le marché ou en service sous son nom peut être fournisseur, y compris pour un usage interne. Acheter une API ne tranche donc pas le rôle relatif au système assemblé.

Le règlement consolidé disponible sur EUR-Lex permet de vérifier ces définitions et les responsabilités dans la chaîne de valeur. Son article 25 prévoit notamment qu’un changement de destination rendant un système à haut risque peut faire basculer l’entreprise vers les obligations du fournisseur.

Point à examiner	Entreprise déployeuse	Entreprise fournisseur
Position habituelle	Utilise un système sous son autorité	Développe ou fait développer et met le système sur le marché ou en service sous son nom
Objet de l’analyse	Conditions d’utilisation et contexte réel	Conception, destination et mise en conformité du système
Documentation à rechercher	Instructions, limites et informations du fournisseur	Éléments démontrant le respect des exigences applicables
Changement à surveiller	Usage dépassant la destination prévue	Modification du système ou de sa destination

Ne confondez pas fournisseur du modèle et fournisseur du système final. Utiliser un modèle généraliste ne transfère pas automatiquement toutes les obligations liées à l’application vers son éditeur.

Avant de confier un projet à un intégrateur, faites préciser les rôles et les livrables attendus. Preuve recommandée : une note de qualification accompagnée d’une répartition contractuelle des tâches, sans supposer que le contrat efface une responsabilité prévue par le règlement.

3. Écarter les pratiques interdites avant le pilote

La première décision n’est pas de choisir une mesure de sécurité. Elle consiste à vérifier si l’usage peut être envisagé.

L’article 5 sur les pratiques interdites, dans sa présentation officielle à jour, vise notamment certaines manipulations préjudiciables, l’exploitation de vulnérabilités, certaines notations sociales et certaines catégorisations biométriques sensibles. L’inférence d’émotions à partir de données biométriques au travail ou dans les établissements d’enseignement est interdite, sauf raisons médicales ou de sécurité prévues par le texte.

Pour une entreprise, examinez particulièrement les fonctions qui prétendent déduire l’état émotionnel d’un candidat ou d’un salarié depuis sa voix ou son visage. Un consentement présenté dans l’interface ne suffit pas à neutraliser une interdiction.

La même source indique que les nouvelles interdictions concernant certains contenus intimes ou sexuellement explicites non consentis et les contenus d’abus sexuels sur enfants s’appliquent à partir du 2 décembre 2026. Ce calendrier ne préjuge pas des interdictions découlant déjà d’autres lois.

Preuve recommandée : une décision écrite d’exclusion, ou une analyse motivée lorsqu’une fonction présente une ambiguïté. Demandez une description technique au fournisseur plutôt que d’interpréter uniquement son argumentaire commercial.

4. Classer le système selon sa destination réelle

La présence d’une IA générative ou d’une boucle autonome n’entraîne pas, à elle seule, une qualification à haut risque. Examinez la destination prévue, le contexte et l’effet du système sur les personnes.

Les articles 6 et les annexes du règlement distinguent notamment les systèmes liés à certains produits réglementés et les usages sensibles de l’annexe III : recrutement, certaines décisions relatives aux travailleurs, éducation ou solvabilité, entre autres. Les exceptions sont encadrées ; une simple mention d’aide à la décision ne suffit pas à les établir.

Comparez ces scénarios illustratifs :

• reformuler une annonce de recrutement ;
• extraire des informations de dossiers de candidature ;
• classer des candidats pour déterminer qui sera reçu.

Ces descriptions ne permettent pas, seules, de conclure définitivement. Elles montrent pourquoi il faut examiner l’influence effective du résultat, les critères utilisés et le contrôle humain, plutôt que classer globalement le service des ressources humaines.

Ne considérez pas non plus qu’un paiement autonome rend nécessairement le système à haut risque au sens réglementaire. Le risque opérationnel et la catégorie juridique sont deux analyses à mener.

Preuve recommandée : une note indiquant la destination, la catégorie examinée, les dispositions pertinentes et les raisons du classement. Faites-la réexaminer quand un nouvel outil, une nouvelle population ou un nouveau pouvoir d’action modifie le scénario.

5. Organiser les compétences et la supervision

L’article 4 a été modifié en 2026. Selon la FAQ officielle sur les compétences en IA, les fournisseurs et déployeurs doivent prendre des mesures pour soutenir leur développement, sans niveau individuel uniforme ni certificat universel imposé.

Adaptez ces mesures aux tâches. Une personne qui reformule des textes doit savoir vérifier les affirmations et protéger les informations confidentielles. Une personne qui supervise un agent doit aussi comprendre ses permissions, ses déclencheurs et sa procédure d’arrêt.

Un programme pratique peut réunir :

• une présentation des usages autorisés et interdits ;
• un exercice de détection d’erreurs sur des documents représentatifs ;
• une démonstration des données accessibles à l’agent ;
• une procédure de signalement et de reprise manuelle ;
• une mise à jour lors des changements importants.

Pour la supervision, testez des situations concrètes : un document incohérent, une demande hors périmètre, une recommandation insuffisamment justifiée. Vérifiez que le responsable sait reconnaître le problème et dispose du pouvoir d’interrompre le traitement.

Preuve recommandée : supports, participants, exercices et corrections apportées. La signature d’une charte d’usage de l’IA en entreprise aide à diffuser les règles ; elle ne démontre pas, seule, que les personnes peuvent les appliquer.

6. Vérifier la transparence des interactions et des contenus

Les obligations de transparence ne concernent pas uniquement les systèmes à haut risque. La FAQ de la Commission sur l’article 50 distingue les responsabilités des fournisseurs et des déployeurs.

Les fournisseurs doivent notamment prévoir l’information des personnes interagissant directement avec une IA, sauf lorsque cela est évident. Pour une interface client, vérifiez concrètement comment cette information apparaît.

Les déployeurs doivent signaler les hypertrucages concernés. Le texte prévoit aussi une information pour certains textes générés ou manipulés publiés afin d’informer le public sur des sujets d’intérêt public, avec une exception encadrée lorsqu’existent une révision humaine ou un contrôle éditorial et une responsabilité éditoriale.

Le marquage technique lisible par machine, qui relève du fournisseur, est distinct de l’information destinée au public. L’article 50 s’applique depuis le 2 août 2026 ; la transition au 2 décembre 2026 concerne seulement certaines obligations de marquage et de détection pour les systèmes déjà commercialisés avant cette date.

Contrôle recommandé : examinez le parcours complet, du premier contact au contenu exporté. Conservez les écrans d’information, les règles de publication et les validations éditoriales pertinentes. Une vérification orthographique ne constitue pas une relecture du fond.

7. Préparer le dossier des usages à haut risque

Pour les usages concernés, préparez les obligations futures sans les présenter comme déjà toutes applicables en octobre 2026. L’article 26 relatif aux déployeurs prévoit notamment l’utilisation conforme aux instructions, une supervision compétente, la surveillance et la gestion des données d’entrée sous leur contrôle.

Il prévoit également la conservation des journaux automatiques sous le contrôle du déployeur pendant une durée adaptée, d’au moins six mois, sauf disposition contraire applicable. Cette durée légale ne doit pas devenir une consigne de conservation générale de toutes les conversations.

Le texte organise aussi l’information des travailleurs concernés et de leurs représentants, ainsi que celle des personnes faisant l’objet de certaines décisions assistées par ces systèmes. Il prévoit des démarches auprès du fournisseur et des autorités en présence de risques ou d’incidents.

Demandez dès la sélection du prestataire comment ces obligations pourront être exécutées : export des journaux, accès aux instructions, contact incident, possibilité de suspension.

L’analyse d’impact sur les droits fondamentaux prévue à l’article 27 ne concerne pas indistinctement toutes les PME. Elle vise notamment certains organismes publics, prestataires privés de services publics et usages liés à la solvabilité ou à l’assurance vie et santé.

Preuve recommandée : une liste des obligations applicables au scénario, chacune associée à un responsable, une échéance et un document attendu.

8. Traiter les données personnelles dans un dossier parallèle

La conformité à l’AI Act ne remplace pas celle au RGPD. Un usage qui ne relève pas du haut risque peut néanmoins traiter des informations personnelles sensibles ou produire une décision problématique.

La CNIL rappelle les garanties liées aux systèmes d’IA et aux décisions automatisées. En particulier, une personne présente dans le processus ne constitue pas nécessairement un contrôle effectif si elle ne peut pas réexaminer les résultats ou si des dossiers sont écartés sans examen réel.

Organisez le contrôle des données autour de questions précises :

• Quelle finalité justifie chaque catégorie de données ?
• Quelle base légale et quelles informations aux personnes sont prévues ?
• Quels prestataires reçoivent les données et dans quels pays ?
• Qui peut consulter les historiques et les résultats ?
• Comment les demandes des personnes seront-elles traitées ?
• Une analyse d’impact relative à la protection des données est-elle nécessaire ?

Pour un agent, suivez également les transmissions vers les outils connectés et les destinations d’export. Le modèle n’est qu’un destinataire potentiel parmi d’autres.

Preuve recommandée : une cartographie des traitements et des destinataires, reliée au registre et aux analyses pertinentes. L’article Agents IA et RGPD : quelles données partent, et où ? développe cette vérification des flux.

9. Contrôler les actions et les changements en production

Les mesures suivantes sont des recommandations techniques à adapter ; elles ne représentent pas des exigences identiques pour tous les systèmes au titre de l’AI Act.

Commencez par réduire les permissions : lecture seule lorsque possible, comptes dédiés, accès limités aux dossiers utiles. Réservez les validations aux points où elles permettent encore d’empêcher une conséquence indésirable, avant un envoi ou une modification sensible.

Testez aussi la séparation entre données et instructions. Un agent peut lire un document qui cherche à détourner son comportement. Vérifiez qu’un contenu reçu ne lui permet pas d’élargir ses droits ou de contourner une approbation.

Le guide Sécuriser un agent IA détaille ces contrôles ; le diagnostic de sécurité aide à repérer les protections manquantes.

Préparez une procédure d’incident qui nomme la personne capable de désactiver l’agent, préserver les éléments utiles et reprendre le travail manuellement. Distinguez la correction technique des notifications juridiquement nécessaires selon les textes applicables.

Enfin, définissez les changements qui déclenchent une réévaluation : nouvelle finalité, nouveau modèle, nouvelle source de données, nouvelle population ou nouveau droit d’écriture. Preuve recommandée : une fiche de changement décrivant l’effet sur les risques, les tests réalisés et la décision de remise en service.

10. Utiliser une checklist avec preuves et décisions

Cette checklist sert à piloter le travail. Pour chaque ligne, attribuez un responsable, joignez une preuve et indiquez si le point est satisfait, à corriger ou non applicable avec justification. Une case cochée sans pièce ni raisonnement apporte peu de visibilité.

Contrôles à réaliser maintenant

• Les usages professionnels, y compris ceux des prestataires, sont inventoriés.
• La finalité et les usages exclus sont écrits pour chaque scénario.
• Les rôles de déployeur et de fournisseur ont été examinés.
• Les pratiques interdites ont fait l’objet d’un contrôle.
• La qualification du système et son calendrier sont documentés.
• Les mesures de développement des compétences sont adaptées aux fonctions.
• Les obligations de transparence applicables sont mises en œuvre.
• Les flux de données et les obligations RGPD sont examinés.
• Les permissions, validations et procédures d’arrêt ont été testées.

Préparation conditionnelle du haut risque

• Les instructions et limites du fournisseur sont disponibles.
• La supervision et la surveillance du fonctionnement sont organisées.
• La conservation des journaux est définie selon les règles applicables.
• Les informations aux travailleurs et aux personnes concernées sont préparées.
• La nécessité d’une analyse des droits fondamentaux est examinée.
• Les éventuelles obligations d’enregistrement sont vérifiées selon le rôle.

Suivi du dossier

• Une procédure d’incident identifie les interlocuteurs et les actions.
• Les changements susceptibles de modifier la qualification sont suivis.
• Chaque écart possède une action, une échéance et un décideur.
• Les textes et documents fournisseurs utilisés sont datés et archivés.

Le livrable utile est un dossier qui permet de comprendre pourquoi un usage a été autorisé, sous quelles conditions et avec quels contrôles. Il doit aussi permettre de reconnaître le moment où cette autorisation mérite d’être réexaminée.

Pages liées

• n8n
• ChatGPT
• Microsoft 365 Copilot
• Langfuse

Questions fréquentes

Une PME qui utilise un assistant IA est-elle concernée par l’AI Act ?

Oui, l’usage professionnel peut placer une PME dans le rôle de déployeur. Les obligations dépendent toutefois du système et de sa destination : utiliser un assistant de rédaction ne déclenche pas automatiquement le régime des systèmes à haut risque.

Faut-il un certificat AI Act pour chaque salarié ?

Le règlement ne prévoit pas de certificat universel obligatoire. L’entreprise doit prendre des mesures adaptées pour soutenir le développement des compétences en IA ; elle peut documenter des ateliers internes, des consignes et des exercices propres aux outils utilisés.

Les obligations sur les systèmes à haut risque s’appliquent-elles déjà en octobre 2026 ?

Le calendrier modifié prévoit leur application à partir du 2 décembre 2027 pour les systèmes de l’annexe III et du 2 août 2028 pour ceux liés aux produits réglementés de l’annexe I. Les interdictions et d’autres obligations, dont la transparence, ont un calendrier distinct.

Un outil IA installé en local échappe-t-il au règlement ?

L’hébergement local ne constitue pas une exemption générale. Il peut modifier les flux de données et les risques techniques, mais la qualification juridique reste liée au système, à son usage et au rôle de l’entreprise.

Une validation humaine suffit-elle à rendre un agent conforme ?

Une validation ne remplace ni la classification du système ni les autres obligations applicables. Elle doit aussi être effective : la personne doit disposer des informations, du temps et du pouvoir nécessaires pour refuser ou corriger le résultat.