AI Act : ce qui s'applique vraiment à vos déploiements IA en 2026

Mis à jour le 21 octobre 2026 : le Digital Omnibus, adopté en juin 2026, a repoussé les obligations haut risque. Le calendrier ci-dessous en tient compte.

Le règlement européen sur l'IA (EU 2024/1689) est entré en vigueur le 1er août 2024. La plupart des organisations savent qu'il existe. Beaucoup moins savent précisément quels déploiements sont déjà concernés, ce qui s'applique déjà en 2026, ce que le report voté à l'été 2026 change, et quelles obligations atterrissent sur leur bureau.

La question que nous posent le plus souvent les DSI n'est pas "est-ce que l'AI Act nous concerne ?". Il s'applique à toute organisation qui déploie des systèmes IA sur le marché européen, point. La vraie question est : dans quelle classe de risque tombent vos déploiements, et qu'est-ce que cette classification exige concrètement ?

Cet article est pratique, pas académique. On ne va pas recopier l'Article 15. On va parcourir les critères de classification qui déterminent si vous êtes dans la catégorie "haut risque", les obligations concrètes qui en découlent, l'exception de l'Article 6(3) qui vous permet de documenter votre sortie du périmètre, et l'articulation avec le RGPD qui va occuper votre DPO pendant les prochains mois.

Le calendrier réel : ce qui s'applique déjà et ce qui a été repoussé

L'AI Act se déploie par couches successives depuis son entrée en vigueur. Comprendre ce qui s'est déjà appliqué évite de mal calibrer l'urgence.

Février 2025 (déjà en vigueur). Les interdictions sur les pratiques IA à risque inacceptable sont applicables depuis le 2 février 2025. Scoring social par autorités publiques, identification biométrique à distance en temps réel dans des espaces publics (sauf exceptions étroites pour les forces de l'ordre), systèmes de manipulation qui exploitent des vulnérabilités psychologiques. Si votre organisation utilisait de tels systèmes, elle est en non-conformité depuis plus d'un an.

Août 2025 (déjà en vigueur). Les obligations pour les modèles d'IA à usage général (GPAI, General Purpose AI) sont entrées en application le 2 août 2025. Tous les fournisseurs qui placent des modèles GPAI sur le marché européen (OpenAI, Anthropic, Google, Mistral, etc.) devaient se conformer aux exigences de transparence et de documentation sur les droits d'auteur des Articles 53-55, et adhérer au Code de Pratique GPAI.

Mai 2026 (en projet). La Commission devait publier ses lignes directrices sur la classification haut risque (Article 6) le 2 février 2026. Elle a pris du retard : un projet de plus de 160 pages a été soumis à consultation le 19 mai 2026, jusqu'au 23 juin, selon l'IAPP. En attendant la version finale, c'est la meilleure base pour une auto-évaluation.

Juillet 2026 : le Digital Omnibus. Ce règlement de simplification, adopté par le Parlement puis par le Conseil en juin 2026 et publié au Journal officiel fin juillet, repousse les obligations haut risque. Les systèmes de l'Annexe III (recrutement, crédit, éducation, etc.) passent du 2 août 2026 au 2 décembre 2027. L'IA intégrée dans des produits réglementés de l'Annexe I (dispositifs médicaux, machines) passe du 2 août 2027 au 2 août 2028 (Orrick, DLA Piper).

2 août 2026 (déjà en vigueur). Les obligations de transparence envers les utilisateurs (Article 50) n'ont pas été repoussées. Vous devez informer les utilisateurs lorsqu'ils interagissent avec un système IA et lorsqu'un contenu a été généré par une IA. Seul le marquage technique des contenus générés (Article 50(2)) bénéficie d'un délai jusqu'au 2 décembre 2026, et uniquement pour les systèmes mis sur le marché avant le 2 août 2026.

2 décembre 2027. La nouvelle date centrale. Application des Articles 9 à 17 (obligations des fournisseurs de systèmes haut risque) et de l'Article 26 (obligations des déployeurs) pour les systèmes de l'Annexe III. À partir de cette date, déployer un système IA haut risque sans documentation de conformité, sans marquage CE pour les produits réglementés, sans enregistrement dans la base de données EU, sans mécanismes de supervision humaine et sans conservation des logs constitue une non-conformité caractérisée. Les sanctions montent à 15 millions d'euros ou 3% du chiffre d'affaires mondial annuel.

Le report donne un peu plus d'un an de marge. Ce n'est pas une raison d'attendre : un dossier de conformité solide demande plusieurs mois de travail entre équipes techniques, juridiques et RH.

La classification haut risque : êtes-vous concerné ?

La décision la plus structurante de votre programme de conformité est la classification. Vos systèmes IA sont-ils haut risque au sens de l'Annexe III ?

L'Annexe III liste huit catégories. Pour les entreprises qui déploient de l'IA dans un contexte professionnel, trois catégories sont les plus fréquemment concernées.

Emploi et gestion des travailleurs. Tout système IA utilisé pour le recrutement (ciblage d'annonces, filtrage de candidatures, ranking de CV), l'évaluation des performances, l'attribution des tâches, ou les décisions de promotion et de rupture de contrat est haut risque. Si votre équipe RH utilise un outil de screening avec un scoring automatique, c'est haut risque. Sans exception interprétative.

Accès aux services essentiels. Les systèmes d'évaluation de solvabilité et de scoring crédit (hors détection de fraude), la tarification des assurances vie et santé, les systèmes d'éligibilité aux aides publiques et aux soins. Un outil de credit scoring intégré dans un SaaS bancaire ou d'assurance tombe dans cette catégorie.

Infrastructure critique. Les composants de sécurité dans la gestion des réseaux électriques, de l'eau, du gaz, des routes, des infrastructures numériques critiques. Si votre agent IA supervise un réseau industriel classé Opérateur d'Importance Vitale (OIV) ou opérateur de services essentiels (OSE), il est haut risque par définition réglementaire.

Les autres catégories couvrent la biométrie (identification, catégorisation, reconnaissance d'émotions), l'éducation (sélection, évaluation), l'application des lois, et la migration.

Un point structurant : la classification s'appuie sur l'usage réel, pas sur la description marketing. Un LLM généraliste utilisé pour scorer des candidats RH est haut risque. Le même LLM utilisé pour rédiger des emails commerciaux ne l'est pas. L'usage fait la classification, pas l'architecture.

L'exception de l'Article 6(3) : documenter sa sortie du périmètre

Votre système figure dans l'Annexe III, mais vous êtes convaincu qu'il ne devrait pas être classé haut risque ? L'Article 6(3) vous ouvre une porte, à une condition stricte : la charge de la preuve vous incombe entièrement.

La dérogation s'applique quand le système ne pose pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux. Plus précisément, l'Article 6(3) cite le cas où le système n'influence pas matériellement l'issue d'une décision : l'IA fournit une information, un humain décide librement, et la recommandation de l'IA n'est pas déterminante dans la décision finale.

Deux exemples pour calibrer la frontière. Un outil RH qui génère un résumé narratif d'un CV pour un recruteur humain qui décide librement, sans score ni ranking automatique : potentiellement hors haut risque avec une documentation solide. Un outil qui produit un ranking de candidats par score et où le recruteur valide quasi-systématiquement les premières positions : haut risque, car la décision humaine est matériellement influencée par la sortie du système.

Vous devez documenter l'évaluation avant déploiement et vous enregistrer dans la base de données EU (Article 49). L'autorité nationale compétente peut demander ce document à tout moment. Une décision orale ou une affirmation non documentée n'est pas une position défendable en audit.

Le projet de lignes directrices de la Commission (mai 2026) donne les exemples de référence pour calibrer cette auto-évaluation. Le lire avant de statuer n'est pas optionnel.

Ce qu'Article 15 exige concrètement

L'Article 15 s'adresse aux fournisseurs de systèmes haut risque. Mais il structure deux choses pour les déployeurs : ce qu'ils doivent exiger contractuellement de leurs fournisseurs, et ce qu'ils doivent mettre en place s'ils sont eux-mêmes fournisseurs (développement en interne, ou solution fortement configurée).

Trois exigences concrètes ressortent du texte.

Exactitude tout au long du cycle de vie. Les métriques d'exactitude doivent être déclarées dans les instructions d'utilisation. Ce n'est pas un benchmark one-shot au lancement. Le système doit maintenir un niveau approprié pendant toute sa durée de vie opérationnelle. Concrètement : un eval set documenté, des métriques vérifiables, et un processus pour détecter la dérive dans le temps.

Robustesse, dont la gestion des boucles de rétroaction. Les systèmes qui continuent à apprendre après déploiement (fine-tuning continu, RAG nourri par des interactions récentes) doivent être conçus pour éviter que des sorties biaisées ne contaminent les données d'entraînement futures. C'est une contrainte architecturale à traiter en phase de conception, pas une case à cocher après coup.

Cybersécurité : résistance aux attaques spécifiques à l'IA. Le texte de l'Article 15 est remarquablement précis. Il cite nommément la résistance aux tentatives de modifier les sorties ou les performances du système en exploitant ses vulnérabilités, et liste l'empoisonnement de données, l'empoisonnement de modèles, les exemples adversariaux et les atteintes à la confidentialité. Ce n'est pas une obligation vague de sécurité générale. C'est une liste de vecteurs d'attaque spécifiques à l'IA auxquels le système doit résister, documentés.

Pour un DSI ou un RSSI, la traduction est directe : toute solution IA haut risque achetée chez un tiers doit venir avec une documentation Article 15 vérifiable. Si votre fournisseur SaaS ne peut pas la produire, c'est votre problème de conformité au 2 décembre 2027, pas le sien.

Les obligations du déployeur : Article 26 en pratique

L'Article 26 s'adresse spécifiquement aux déployeurs : les organisations qui utilisent un système IA haut risque développé par un tiers. C'est la situation de la majorité des entreprises qui intègrent un outil de scoring RH, une solution de crédit, ou un outil de détection d'anomalies dans leur infrastructure.

Cinq obligations opérationnelles à mettre en place avant le 2 décembre 2027.

Utilisation conforme aux instructions. Vous devez utiliser le système selon les instructions d'utilisation documentées par le fournisseur. Déployer un outil dans un contexte ou pour une population différente de ceux sur lesquels il a été validé vous place en non-conformité, indépendamment de ce que fait le fournisseur.

Désignation d'un responsable de supervision humaine. Une personne compétente, avec les ressources et l'autorité pour surveiller le système, comprendre ses sorties et intervenir si nécessaire. La supervision humaine ne se résume pas à "un humain relit la décision finale". Elle implique une compréhension des limites du système et une capacité d'intervention effective.

Conservation des logs pendant au moins 6 mois. Les journaux automatiquement générés par le système haut risque doivent être conservés 6 mois au minimum. Pour les organisations qui hébergent leur IA chez un fournisseur SaaS, cela implique une clause contractuelle explicite : le fournisseur doit vous donner accès aux logs ou les conserver pour vous.

Qualité des données d'entrée. Dans la mesure où vous contrôlez les données que vous fournissez au système, elles doivent être pertinentes et suffisamment représentatives au regard de la finalité prévue. Alimenter un outil de scoring avec des données historiquement biaisées vous rend co-responsable des sorties discriminatoires.

Information des salariés avant déploiement en milieu de travail. Avant de déployer un système haut risque sur des salariés, vous devez informer les représentants du personnel et les travailleurs concernés. C'est une obligation qui s'ajoute aux dispositions du code du travail français sur les consultations obligatoires du CSE : les deux s'appliquent en parallèle.

L'articulation avec le RGPD

Quasi tous les systèmes IA en entreprise traitent des données personnelles. Les deux règlements s'appliquent simultanément et de manière cumulative, comme la CNIL l'a confirmé dans ses premières questions-réponses sur l'entrée en vigueur du règlement. Ce n'est pas l'un ou l'autre. C'est les deux.

Deux points d'articulation méritent une attention particulière.

DPIA et évaluation d'impact sur les droits fondamentaux. Le RGPD impose une Analyse d'Impact relative à la Protection des Données (DPIA) pour les traitements à risque élevé. L'AI Act impose une évaluation d'impact sur les droits fondamentaux pour certains déployeurs de systèmes haut risque. Ces deux évaluations se chevauchent sur le fond. La CNIL recommande de les conduire conjointement avec une documentation commune. Si vous avez déjà une DPIA pour votre outil de scoring RH ou de crédit, elle doit être revue à l'aune des critères de l'AI Act avant l'échéance de décembre 2027.

Gouvernance des données d'entraînement. L'Article 10 de l'AI Act exige que les données d'entraînement des systèmes haut risque soient pertinentes, représentatives et exemptes d'erreurs. Ce critère entre en résonance directe avec les principes de qualité des données du RGPD, et avec les exigences d'audit des bases de données personnelles. Si vous fine-tunez un modèle sur des données clients, vous avez un sujet RGPD (base légale, finalité, durée de conservation) et un sujet Article 10 (qualité, représentativité, détection de biais) à traiter en parallèle, avec les mêmes équipes.

La bonne nouvelle : les organisations qui ont structuré leur conformité RGPD disposent déjà d'une partie de l'infrastructure documentaire nécessaire. Le registre des traitements, les DPIAs existantes, la cartographie des données constituent un point de départ. La mauvaise : beaucoup supposent que "RGPD couvre l'IA", ce qui est inexact. L'AI Act ajoute des obligations spécifiques aux systèmes IA haut risque que le RGPD ne couvre pas, notamment les exigences de robustesse, la documentation technique Article 11-12, et les obligations de supervision humaine.

Ce qu'on met en place chez GettIA

Quand une entreprise nous sollicite sur l'AI Act (notre accompagnement conformité RGPD et AI Act), on ne commence pas par les textes juridiques. On commence par l'inventaire des déploiements.

Avant de savoir si vous êtes conforme, il faut savoir ce que vous déployez réellement, shadow IT compris : les outils IA adoptés par les équipes sans passer par la DSI comptent aussi.

Notre processus en quatre étapes.

Inventaire et classification. On recense tous les systèmes IA en production et en développement, on applique l'arbre de décision Annexe III et Article 6(3) à chacun. En sortie : une carte des systèmes haut risque avérés, des systèmes à documenter sous Article 6(3), et de ceux qui sont clairement hors périmètre.

Écarts fournisseurs. Pour chaque système haut risque acheté à un tiers, on vérifie que le fournisseur peut produire la documentation Articles 9-17 (notamment Article 15 sur la robustesse et la cybersécurité). Si ce n'est pas le cas, on négocie des clauses contractuelles adaptées ou on identifie des alternatives conformes.

Mise en conformité déployeur. Désignation des responsables de supervision humaine, procédures de conservation des logs, revue des données d'entrée, plan d'information des représentants du personnel, et mise à jour des DPIAs en évaluations combinées AI Act et RGPD.

Eval set et monitoring. Pour les systèmes développés en interne ou fortement configurés : documentation des métriques d'exactitude, eval set documenté sur des cas représentatifs, processus de détection de dérive, et plan de réponse aux incidents. C'est aussi ce que l'Article 15 impose implicitement. On détaille la méthode dans notre guide pour évaluer un agent IA en production, et le volet cybersécurité dans notre analyse de la surface d'attaque des agents IA.

Comptez plusieurs mois pour une entreprise de taille intermédiaire avec plusieurs systèmes haut risque en production. Les organisations qui attendent l'automne 2027 pour démarrer prennent un risque réel, pas seulement réglementaire : la constitution d'un dossier de conformité solide demande du temps et de la collaboration entre équipes techniques, juridiques et RH.