Liste de contrôle 2026 du règlement sur l’IA : le guide complet

Mise à jour, 30 juillet 2026 : le Digital Omnibus (règlement (UE) 2026/1744) est entré en vigueur le 27 juillet 2026 et a reporté les obligations à haut risque au 2 décembre 2027 (annexe III) et au 2 août 2028 (annexe I). Les obligations de transparence et de marquage de l’article 50 n’ont pas été reportées et s’appliquent à compter du 2 août 2026. Cette liste de contrôle couvre l’ensemble des obligations à haut risque : le travail ne change pas, mais votre échéance haut risque est désormais le 2 décembre 2027, et non plus le 2 août 2026. Voir Ce qui s’applique réellement le 2 août 2026.

La plus lourde vague d’obligations du règlement sur l’IA, le régime à haut risque, était due à l’origine le 2 août 2026. Le Digital Omnibus (en vigueur depuis le 27 juillet 2026) l’a reportée au 2 décembre 2027 (annexe III) et au 2 août 2028 (annexe I). Les fournisseurs et les déployeurs de systèmes d’IA à haut risque doivent, d’ici là, satisfaire un catalogue exigeant, sous peine d’amendes pouvant aller jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial. Séparément, l’article 50 sur la transparence s’applique à compter du 2 août 2026 pour quiconque déploie un agent conversationnel ou génère des contenus par IA.

Cette liste de contrôle ramène le règlement (UE) 2024/1689 à un plan d’action concret. Elle s’adresse aux fondateurs de jeunes pousses, aux directeurs techniques et aux petites équipes de conformité qui doivent passer, dans les mois qui viennent, de « informé » à « prêt pour un contrôle ».

L’essentiel : ce que vous devez avoir en place (échéance haut risque désormais au 2 décembre 2027)

Si vous fournissez ou déployez un système d’IA à haut risque dans l’Union (d’ici le 2 décembre 2027, reporté du 2 août 2026 par le Digital Omnibus) :

• Un inventaire complet des systèmes d’IA, avec une classification des risques pour chacun.
• Un système de gestion des risques qui s’exécute de façon itérative tout au long du cycle de vie de l’IA (article 9).
• Une documentation technique de l’annexe IV, les neuf rubriques obligatoires (article 11).
• Un système de gestion de la qualité couvrant la conception, les essais, les données et la surveillance (article 17).
• Une évaluation de la conformité achevée, par contrôle interne ou par organisme notifié (article 43).
• Une déclaration UE de conformité et le marquage CE (articles 47-48).
• Un enregistrement dans la base de données de l’UE (article 49).
• Des processus actifs de surveillance après mise sur le marché et de signalement d’incidents (article 72).

Si vous êtes déployeur : conformité du fournisseur vérifiée, personnes chargées du contrôle humain désignées, conservation des journaux (6 mois au moins), information des personnes concernées et, le cas échéant, une analyse d’impact sur les droits fondamentaux achevée.

Tout faire à la main est possible, mais la plupart des jeunes pousses et des PME s’appuient sur des outils pour gérer l’inventaire, la classification et la documentation. Si vous pesez vos options, comparez les meilleurs logiciels de conformité au règlement sur l’IA pour les jeunes pousses et les PME avant de vous engager.

Phase 0 : comprendre votre point de départ

Avant de construire quoi que ce soit, vous avez besoin de trois réponses de base.

0.1 Construire un inventaire des systèmes d’IA

Listez chaque système d’IA que votre organisation développe, déploie, importe ou distribue. Incluez l’IA tierce embarquée dans les outils SaaS de vos équipes métier : notation des pistes dans le CRM, greffons d’agents conversationnels, assistants de code, outils de présélection RH. L’IA de l’ombre compte. Interrogez chaque service.

Pour chaque système, consignez :

• Le nom du système et l’éditeur
• La destination et l’usage réel
• Les données d’entrée et de sortie
• Qui est concerné (personnel, clients, public)
• Votre rôle : fournisseur, déployeur, importateur ou distributeur (article 3)

Exemple concret : une jeune pousse du secteur financier qui utilise Stripe Radar pour la détection de fraude, un modèle interne d’évaluation de la solvabilité, et GitHub Copilot pour le développement a trois systèmes d’IA à inventorier. Stripe Radar et Copilot sont déployés (rôle de déployeur) ; le modèle d’évaluation de la solvabilité est fourni (rôle de fournisseur, haut risque au titre de l’annexe III, point 5, b), évaluation de la solvabilité).

Voir le guide complet de l’inventaire des systèmes d’IA pour la démarche entière, y compris le repérage de l’IA de l’ombre.

0.2 Classer chaque système selon le niveau de risque

Le règlement sur l’IA s’articule autour de quatre niveaux de risque. Vos obligations dépendent entièrement de l’endroit où tombe chaque système :

Pas sûr de savoir où tombe votre système ? Lancez une classification des risques gratuite au titre du règlement sur l’IA.

Exemple concret : une entreprise de technologies RH qui propose une présélection de candidatures assistée par l’IA tombe nettement sous l’annexe III, point 4, a), « systèmes d’IA destinés à être utilisés pour le recrutement ou la sélection de personnes physiques, en particulier pour publier des offres d’emploi ciblées, analyser et filtrer les candidatures et évaluer les candidats ». C’est du haut risque, quelle que soit la taille de l’entreprise.

0.3 Déterminer votre rôle pour chaque système

Vos obligations divergent fortement selon que vous êtes fournisseur (vous avez développé ou fait développer l’IA et la mettez sur le marché sous votre nom) ou déployeur (vous utilisez, dans le cadre de votre activité professionnelle, un système d’IA construit par un tiers).

Les fournisseurs portent la charge la plus lourde : gestion des risques, documentation technique, évaluation de la conformité, marquage CE, surveillance après mise sur le marché. Les déployeurs ont des obligations plus légères, mais tout aussi contraignantes : contrôle humain, conservation des journaux, information des personnes concernées et (dans certains cas) une analyse d’impact sur les droits fondamentaux.

Voir le guide comparatif fournisseur / déployeur pour le tableau d’obligations côte à côte.

Phase 1 : obligations du fournisseur à haut risque

Si vous fournissez un système d’IA à haut risque, voici les livrables de conformité obligatoires.

1.1 Établir un système de gestion des risques (article 9)

Le système de gestion des risques s’entend comme un processus itératif continu, planifié et mené sur l’ensemble du cycle de vie du système d’IA à haut risque. Ce n’est pas une évaluation ponctuelle.

Étapes requises :

1. Identifier et analyser les risques connus et raisonnablement prévisibles pour la santé, la sécurité ou les droits fondamentaux, lorsque le système est utilisé conformément à sa destination.
2. Estimer et évaluer les risques susceptibles d’apparaître lorsque le système est utilisé conformément à sa destination et dans des conditions de mauvaise utilisation raisonnablement prévisible.
3. Évaluer les autres risques susceptibles d’apparaître, sur la base de l’analyse des données recueillies au moyen du système de surveillance après mise sur le marché.
4. Adopter des mesures appropriées et ciblées de gestion des risques, en tenant compte de l’état de la technique, des pratiques généralement reconnues et des circonstances particulières d’utilisation du système.
5. Tester le système pour confirmer que le risque résiduel est acceptable ; les essais sont effectués sur la base d’indicateurs et de seuils probabilistes préalablement définis.

Exemple concret : un fournisseur d’un système d’IA utilisé pour les admissions universitaires (annexe III, point 3) doit identifier des risques tels que : biais au détriment des candidats issus de certains milieux socio-économiques, surpondération des notes d’examens standardisés, incapacité à prendre en compte des parcours non traditionnels, et désavantage systématique des candidats en situation de handicap. Pour chaque risque, le fournisseur documente la probabilité, la gravité, les mesures d’atténuation adoptées et le risque résiduel après atténuation.

1.2 Mettre en œuvre la gouvernance des données (article 10)

• Définir des critères de qualité pour les jeux de données d’entraînement, de validation et de test.
• Examiner les jeux de données à la recherche d’éventuels biais, surtout ceux susceptibles de se traduire par une discrimination à l’égard de groupes protégés.
• Prendre des mesures appropriées pour détecter, prévenir et atténuer les biais.
• Documenter l’origine des données, la méthode de collecte et les procédures de préparation (nettoyage, étiquetage, enrichissement, agrégation).
• Lorsque des catégories particulières de données à caractère personnel sont traitées pour la détection et la correction des biais, documenter la base juridique au titre de l’article 9 du RGPD et les garanties concrètes appliquées.

Exemple concret : un fournisseur d’IA d’évaluation de la solvabilité doit documenter que les données d’entraînement ont été examinées pour des biais contre des caractéristiques protégées (sexe, origine ethnique, âge). Si le modèle a été entraîné sur des décisions de crédit historiques, le fournisseur doit traiter le risque que des discriminations passées soient encodées dans les données, et décrire les techniques de correction des biais appliquées.

1.3 Préparer la documentation technique (article 11, annexe IV)

L’annexe IV prévoit neuf rubriques obligatoires :

1. Description générale du système d’IA, y compris la destination
2. Description détaillée des éléments du système et de son processus de développement
3. Informations détaillées sur la surveillance, le fonctionnement et le contrôle
4. Description de l’adéquation des indicateurs de performance
5. Description détaillée du système de gestion des risques
6. Description des modifications pertinentes tout au long du cycle de vie
7. Liste des normes harmonisées appliquées
8. Copie de la déclaration UE de conformité
9. Description du système de surveillance après mise sur le marché, y compris le plan

Commencez le brouillon maintenant : pour un système d’une complexité moyenne, comptez typiquement 40 à 80 heures. Ne tentez pas de la rédiger après coup. Les systèmes à architecture complexe ou à vastes jeux d’entraînement peuvent exiger 100 à 200 heures, voire plus.

Voir le guide complet de la documentation de l’annexe IV pour les consignes rubrique par rubrique.

1.4 Concevoir la journalisation automatique (article 12)

• Intégrez la journalisation dans l’architecture du système, pas comme un rajout.
• Les journaux doivent permettre un degré de traçabilité du fonctionnement du système adapté à sa destination, tout au long de sa durée de vie.
• Veillez à ce que les journaux enregistrent les événements pertinents pour repérer les situations dans lesquelles le système présenterait un risque, les modifications substantielles, et pour surveiller le fonctionnement comme le prévoit l’article 26, paragraphe 5.
• Les journaux doivent être conservés et mis à la disposition des autorités de surveillance du marché sur demande.

1.5 Fournir la transparence et la notice d’utilisation (article 13)

Rédigez une notice d’utilisation claire et complète pour les déployeurs, qui comporte :

• L’identité et les coordonnées du fournisseur
• La destination du système, ses capacités et ses limites
• Le niveau d’exactitude, de robustesse et de cybersécurité, avec une performance ventilée sur les sous-groupes pertinents le cas échéant
• Toute circonstance connue ou prévisible susceptible d’entraîner des risques
• Les mesures techniques de contrôle humain, y compris l’interprétabilité des sorties
• La durée de vie attendue, la maintenance et les exigences de mise à jour
• Le cas échéant, les spécifications relatives aux données d’entrée

1.6 Concevoir pour le contrôle humain (article 14)

Intégrez des fonctions de contrôle de sorte que les personnes physiques chargées d’effectuer un contrôle humain puissent :

• Comprendre correctement les capacités et les limites pertinentes du système
• Surveiller dûment son fonctionnement et détecter les anomalies, les dysfonctionnements et les performances inattendues
• Avoir conscience du biais d’automatisation, en particulier pour les systèmes qui fournissent des recommandations en vue de décisions
• Interpréter correctement la sortie du système, compte tenu de ses caractéristiques et des outils et méthodes d’interprétation disponibles
• Décider de ne pas utiliser le système, ou d’ignorer, de remplacer ou d’inverser la sortie
• Intervenir dans le fonctionnement ou interrompre le système au moyen d’un « bouton d’arrêt » ou d’une procédure similaire

1.7 Atteindre l’exactitude, la robustesse et la cybersécurité (article 15)

• Indiquer les niveaux d’exactitude et les indicateurs pertinents dans la notice d’utilisation.
• Concevoir le système pour qu’il fasse preuve d’autant de résilience que possible en cas d’erreurs, de défaillances ou d’incohérences, y compris dans l’interaction avec l’environnement, d’autres systèmes d’IA et des personnes physiques.
• Traiter les vulnérabilités spécifiques à l’IA : empoisonnement des données, empoisonnement de modèle, exemples contradictoires, invasion de modèle et attaques visant la confidentialité.
• Mettre en œuvre des solutions de redondance, y compris des plans de sauvegarde ou des mesures de sécurité après défaillance, le cas échéant.
• Pour les systèmes qui continuent leur apprentissage, traiter les risques de boucles de rétroaction susceptibles de compromettre la conformité.

1.8 Établir un système de gestion de la qualité (article 17)

Documenter des politiques et procédures couvrant :

• La stratégie de respect de la réglementation et les contrôles de conception / développement
• Les procédures d’essai, de validation et de vérification, y compris avant la mise en service et en continu
• Les pratiques de gestion des données et les contrôles de qualité des données
• Les procédures de surveillance après mise sur le marché
• Les procédures de signalement des incidents et des dysfonctionnements
• Les procédures de communication avec les autorités compétentes, les organismes notifiés et les autres acteurs
• La gestion des ressources (y compris la sécurité d’approvisionnement, le cas échéant)
• Un cadre de responsabilisation avec des responsabilités assignées au niveau de l’encadrement

1.9 Achever l’évaluation de la conformité (article 43)

Avant de mettre votre système sur le marché :

• La plupart des systèmes à haut risque de l’annexe III (points 2 à 8) : le contrôle interne (évaluation de la conformité interne, annexe VI) suffit.
• Systèmes d’identification biométrique (annexe III, point 1) et composants de sécurité de produits relevant du droit de l’Union existant : selon le cas, évaluation par un organisme notifié (annexe VII).
• Établir une déclaration UE de conformité (article 47).
• Apposer le marquage CE (article 48).

Voir le guide de l’évaluation de la conformité pour le détail de la démarche.

1.10 S’enregistrer dans la base de données de l’UE (article 49)

Enregistrez le système dans la base de données de l’UE pour les systèmes d’IA à haut risque avant de le mettre sur le marché ou de le mettre en service. La base est, pour l’essentiel, accessible au public et contient les descriptions de systèmes, les coordonnées du fournisseur, le statut de l’évaluation de la conformité et la destination.

1.11 Mettre en place la surveillance après mise sur le marché (article 72)

• Établir un système de surveillance après mise sur le marché proportionné à la nature des technologies d’IA et aux risques du système.
• Collecter et analyser activement les données de performance tout au long de la durée de vie du système.
• Réinjecter les données de surveillance dans le système de gestion des risques.
• Signaler les incidents graves aux autorités de surveillance du marché sans retard injustifié, et au plus tard 15 jours après en avoir eu connaissance (article 73).

Phase 2 : obligations du déployeur à haut risque

Si vous déployez (utilisez) un système d’IA à haut risque construit par un tiers, vos obligations sont plus légères, mais juridiquement contraignantes.

2.1 Vérifier la conformité du fournisseur

• Demander et examiner la déclaration UE de conformité.
• Confirmer que le marquage CE est présent.
• Obtenir la notice d’utilisation et vérifier qu’elle couvre votre contexte de déploiement.
• Si un fournisseur ne peut pas les fournir, tenez-le pour un signal d’alarme sérieux : demandez-vous si poursuivre l’usage est défendable.

2.2 Mettre en œuvre le contrôle humain (article 26)

• Confier le contrôle humain à des personnes physiques qui disposent des compétences, de la formation et de l’autorité nécessaires.
• Veiller à ce qu’elles comprennent les capacités et les limites du système, en particulier la tendance au biais d’automatisation.
• Suivre les instructions du fournisseur relatives au contrôle humain.
• Veiller à ce que les personnes chargées du contrôle aient le pouvoir et la capacité d’ignorer ou de remplacer la sortie du système.

Exemple concret : une banque qui déploie un système d’IA d’un tiers pour des décisions de crédit doit s’assurer que des chargés de prêt formés examinent les recommandations de l’IA avant la décision finale, peuvent remplacer la sortie de l’IA, comprennent comment l’IA produit ses notes, et documentent le motif lorsqu’ils s’écartent de la recommandation.

2.3 Surveiller et conserver les journaux

• Surveiller le fonctionnement du système pour les risques nés du contexte de déploiement concret.
• Conserver les journaux générés automatiquement pendant une période d’au moins six mois (ou plus longtemps si le droit sectoriel l’exige, par exemple les durées de conservation des services financiers).
• Signaler les incidents graves ou les dysfonctionnements au fournisseur et à l’autorité de surveillance du marché concernée.

2.4 Informer les personnes concernées

• Informer les personnes physiques qu’elles sont soumises à l’utilisation d’un système d’IA à haut risque.
• Fournir des informations utiles sur le rôle du système dans la procédure décisionnelle et sur la portée de la sortie.
• Lorsqu’une décision prise sur la base des sorties du système produit des effets juridiques ou affecte significativement la personne de façon similaire, informer cette personne de son droit d’obtenir une explication (article 86).

2.5 Mener une analyse d’impact sur les droits fondamentaux (le cas échéant) (article 27)

Requise si vous êtes :

• Un organisme de droit public
• Une entité privée fournissant des services publics
• Un déployeur de systèmes d’IA à haut risque visés à l’annexe III, points 5, b) et c)

Achevez l’analyse d’impact (FRIA) avant le déploiement. Notifiez-en les résultats à l’autorité de surveillance du marché. Voir le guide FRIA pour la démarche pas à pas.

Phase 3 : obligations de transparence et GPAI

3.1 Transparence pour les systèmes à risque limité (article 50)

• Agents conversationnels et IA dialogique : informer les personnes physiques qu’elles interagissent avec un système d’IA, sauf si cela ressort clairement des circonstances et du contexte d’utilisation.
• Hypertrucages et contenus synthétiques : marquer les contenus image, audio ou vidéo générés ou manipulés par l’IA dans un format lisible par machine. Les déployeurs indiquent que le contenu a été généré ou manipulé artificiellement.
• Reconnaissance des émotions et catégorisation biométrique : informer les personnes physiques qui y sont exposées du fonctionnement du système.
• Texte généré par l’IA sur des questions d’intérêt public : si vous publiez un texte généré par l’IA sur des sujets d’intérêt public, indiquer qu’il a été généré par l’IA, sauf si une personne physique a procédé à un examen éditorial et en assume la responsabilité.

3.2 Obligations des modèles d’IA à usage général (articles 51-55)

Si vous fournissez un modèle GPAI (modèle de fondation, grand modèle de langage) :

• Élaborer et tenir à jour une documentation technique comprenant le processus d’entraînement, les sources de données et les résultats d’évaluation (article 53).
• Fournir des informations et de la documentation aux fournisseurs de systèmes d’IA qui envisagent d’intégrer le modèle.
• Mettre en place une politique visant à se conformer au droit de l’Union en matière de droit d’auteur, y compris à identifier et à respecter une réservation de droits exprimée conformément à l’article 4, paragraphe 3, de la directive (UE) 2019/790.
• Publier un résumé suffisamment détaillé du contenu utilisé pour l’entraînement.

Les modèles GPAI classés comme présentant un risque systémique (sur la base d’une quantité cumulée de calcul supérieure à 10^25 FLOPs, ou par désignation de la Commission) portent des obligations supplémentaires : essais contradictoires, suivi des incidents, et mesures de cybersécurité (article 55).

Phase 4 : gouvernance et clôture documentaire

4.1 Désigner un mandataire (si besoin)

Les fournisseurs établis hors de l’Union doivent désigner un mandataire établi dans l’Union avant de mettre leur système sur le marché (article 22). Le mandataire doit disposer d’un mandat écrit précisant les tâches à exécuter, y compris la tenue de la documentation technique, la coopération avec les autorités et l’enregistrement dans la base de données de l’UE.

4.2 Former vos équipes à la maîtrise de l’IA (article 4)

Les fournisseurs et les déployeurs prennent 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 s’occupant du fonctionnement et de l’utilisation des systèmes d’IA pour leur compte, en prenant en considération leurs connaissances techniques, leur expérience, leur éducation et leur formation, ainsi que le contexte dans lequel les systèmes d’IA sont destinés à être utilisés, et en tenant compte des personnes ou des groupes de personnes à l’égard desquels les systèmes d’IA sont destinés à être utilisés.

Cette obligation est déjà en vigueur depuis le 2 février 2025.

Exemple concret : un établissement de santé qui déploie des outils d’aide au diagnostic assistés par l’IA doit s’assurer que les radiologues comprennent la destination de l’IA, ses limites d’exactitude dans les cas limites, comment interpréter les valeurs de confiance, et quand remplacer le système. Une sensibilisation générique à l’IA ne suffit pas : elle doit être adaptée au système et au contexte concrets.

4.3 Se préparer à la surveillance du marché

Les autorités nationales de surveillance du marché peuvent :

• Demander la documentation et l’accès aux systèmes d’IA, y compris au code source dans certaines circonstances
• Procéder à des inspections sur site inopinées
• Exiger des fournisseurs qu’ils prennent des mesures correctives dans un délai déterminé
• Ordonner le retrait ou le rappel de systèmes d’IA non conformes du marché
• Restreindre ou interdire l’utilisation de systèmes d’IA présentant des risques graves
• Infliger des amendes administratives

Veillez à ce que votre documentation soit prête pour un contrôle, accessible sur demande, et tenue dans au moins une langue officielle de l’Union.

Synthèse du calendrier

Erreurs fréquentes qui retardent la conformité

Erreur 1 : commencer par la documentation plutôt que par la classification

Les équipes qui sautent directement à la documentation technique de l’annexe IV sans avoir d’abord classé leurs systèmes découvrent souvent, des mois plus tard, qu’elles ont documenté les mauvais systèmes, retenu le mauvais périmètre, ou manqué des systèmes entièrement. Commencez toujours par l’inventaire et la classification.

Erreur 2 : traiter la conformité comme un projet uniquement juridique

La conformité au règlement sur l’IA exige l’apport de l’ingénierie (architecture système, journalisation, essais), de la science des données (gouvernance des données, évaluation des biais, indicateurs d’exactitude), du produit (destination, notice d’utilisation) et du juridique (gestion des risques, évaluation de la conformité). La cantonner au seul service juridique garantit le retard.

Erreur 3 : supposer que l’IA tierce est le problème de quelqu’un d’autre

Si vous déployez un système d’IA à haut risque construit par un fournisseur, vous avez votre propre jeu d’obligations de déployeur. « Notre fournisseur est conforme » est nécessaire mais pas suffisant : il vous faut encore le contrôle humain, la conservation des journaux, l’information des personnes concernées, et éventuellement une FRIA.

Erreur 4 : attendre les normes harmonisées

À la mi-2026, les organisations européennes de normalisation (CEN/CENELEC) n’ont pas encore publié toutes les normes harmonisées du règlement sur l’IA. Attendre ces normes pour commencer le travail de conformité, c’est manquer de temps. Les obligations légales s’appliquent à leur échéance (2 décembre 2027 pour le haut risque autonome, 2 août 2026 pour la transparence de l’article 50), quel que soit l’état des normes. Utilisez directement les exigences des articles 8 à 15.

Erreur 5 : confondre maîtrise de l’IA et conformité au règlement sur l’IA

La maîtrise de l’IA (article 4) est une obligation parmi d’autres, et elle est déjà en vigueur. Les équipes qui s’arrêtent à « nous avons fait une formation IA » et traitent cela comme la conformité au règlement manquent les obligations de fond : gestion des risques, documentation, évaluation de la conformité et surveillance.

Estimation pratique de l’effort

Commencez maintenant

L’écart entre « informé » et « conforme » est plus large que la plupart des équipes ne l’attendent. La seule documentation technique peut prendre 40 à 80 heures par système. Une évaluation de la conformité par un organisme notifié peut prendre 6 à 24 mois.

N’attendez pas le mois d’août. Commencez par votre classification des risques :

Lancez l’évaluation gratuite au titre du règlement sur l’IA

Puis utilisez le guide complet du règlement sur l’IA pour approfondir chaque article et chaque annexe cités dans cette liste de contrôle.

Questions fréquentes

Le règlement sur l’IA s’applique-t-il aux entreprises hors de l’Union ?

Oui. Le règlement s’applique aux fournisseurs qui mettent des systèmes d’IA sur le marché de l’Union ou les mettent en service dans l’Union, et aux déployeurs établis ou situés dans l’Union, quel que soit le lieu d’établissement du fournisseur (article 2). Il s’applique aussi aux fournisseurs et aux déployeurs situés hors de l’Union lorsque les sorties produites par le système d’IA sont utilisées dans l’Union.

Existe-t-il une exonération selon la taille pour les jeunes pousses et les PME ?

Pas d’exonération générale. Les obligations de fond (gestion des risques, documentation, évaluation de la conformité) s’appliquent quelle que soit la taille de l’entreprise. Les PME bénéficient toutefois de certaines simplifications procédurales : formulaires simplifiés de documentation technique (une fois publiés par la Commission), frais d’évaluation de la conformité réduits auprès des organismes notifiés, et accès prioritaire aux bacs à sable réglementaires (article 57). Les plafonds d’amende sont aussi adaptés pour les PME : le pourcentage du chiffre d’affaires s’applique plutôt que le montant forfaitaire en euros, le chiffre le plus faible étant retenu.

Que se passe-t-il si je manque l’échéance ?

Pour les systèmes autonomes à haut risque, l’échéance est désormais le 2 décembre 2027 (reportée par le Digital Omnibus du 2 août 2026) ; pour la transparence de l’article 50, c’est le 2 août 2026. La non-conformité aux obligations relatives aux systèmes d’IA à haut risque (articles 8 à 15) emporte des amendes pouvant aller jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Fournir des informations inexactes aux autorités ajoute 7,5 millions d’euros ou 1 %. En pratique, le contrôle de l’application se concentrera d’abord sur les dossiers visibles et les réclamations, mais l’exposition juridique commence à la date d’échéance. Voir le guide des sanctions et amendes pour le détail.

Puis-je réutiliser mes contrôles ISO 27001 ou SOC 2 existants ?

En partie. Les contrôles existants en sécurité de l’information, gestion de la qualité et gouvernance des données fournissent une base, mais le règlement sur l’IA a des exigences spécifiques qui dépassent les cadres généraux. Par exemple, ISO 27001 traite la cybersécurité mais ne couvre pas les vulnérabilités spécifiques à l’IA (empoisonnement des données, exemples contradictoires). SOC 2 couvre la disponibilité et l’intégrité du traitement, mais pas la gestion des risques pour les droits fondamentaux. Utilisez les contrôles existants comme briques, pas comme substituts.

Comment le règlement sur l’IA interagit-il avec le RGPD ?

Les deux règlements s’appliquent simultanément lorsque des systèmes d’IA traitent des données à caractère personnel, ce qui couvre la plupart des outils d’IA métier. Le RGPD régit le traitement des données ; le règlement sur l’IA régit le système d’IA lui-même. Les analyses d’impact peuvent être combinées (analyse d’impact relative à la protection des données + FRIA), et la documentation peut être coordonnée. Les amendes se cumulent indépendamment. Voir le guide comparatif règlement sur l’IA / RGPD pour le détail.

Que faire si mon système d’IA est à la fois composant de sécurité d’un produit et système autonome de l’annexe III ?

C’est la voie la plus stricte qui s’applique. Si le système tombe à la fois sous l’annexe I (sécurité des produits) et sous l’annexe III (haut risque autonome), le fournisseur doit satisfaire les exigences des deux voies et suivre la procédure d’évaluation de la conformité qui s’applique à la législation de sécurité des produits.

Legalithm est un outil d’accompagnement à la conformité assisté par l’IA, ce n’est pas un conseil juridique. Les décisions finales de conformité doivent être revues par un conseil juridique qualifié.