Article 12 pour l’IA des infrastructures critiques : enregistrement et journaux

L’article 12 fixe une obligation de conception pour le fournisseur. La conservation des journaux est une obligation distincte, indiquée dans les lignes ci-dessous.

• art. 12(1)
  Enregistrement automatique des événements sur toute la durée de vie

  Les systèmes d’IA à haut risque doivent permettre, techniquement, l’enregistrement automatique des événements (journaux) tout au long de la durée de vie du système.

• art. 12(2)
  Traçabilité adaptée à la finalité prévue

  Les fonctionnalités de journalisation doivent garantir un degré de traçabilité du fonctionnement du système adapté à sa finalité prévue. Elles doivent permettre l’enregistrement des événements pertinents pour trois objectifs. Le premier est de repérer les situations susceptibles d’avoir pour effet que le système présente un risque au sens de l’article 79, paragraphe 1 ou d’entraîner une modification substantielle. Le deuxième est de faciliter la surveillance après commercialisation (article 72). Le troisième est de surveiller le fonctionnement du système (article 26, paragraphe 5).

• art. 12(3)
  Contenu minimal des journaux : identification biométrique à distance uniquement

  L’article 12, paragraphe 3, énumère le contenu minimal des journaux pour les systèmes à haut risque de l’annexe III, point 1 a) (identification biométrique à distance). Il ne vise pas les systèmes du point 2, pour lesquels le règlement ne nomme aucun champ de journal minimal.

L’article 12 ne s’applique qu’aux systèmes d’IA à haut risque. Les lignes ci-dessous montrent où l’IA pour les infrastructures critiques devient à haut risque, et qui conserve les journaux.

• Les infrastructures critiques sont un domaine de l’annexe III, non un régime sectoriel

  Le règlement ne prévoit pas de régime sectoriel pour les infrastructures critiques à l’égard des fournisseurs ou des déployeurs. L’annexe III, point 2, est le domaine à haut risque intitulé « Infrastructures critiques ». Ce site emploie ces mots pour l’IA qui relève du règlement par ce point. Le point 2 vise les systèmes d’IA destinés à être utilisés en tant que composants de sécurité dans la gestion et l’exploitation d’infrastructures numériques critiques, du trafic routier ou de la fourniture d’eau, de gaz, de chauffage ou d’électricité. L’article 3, point 62), définit les « infrastructures critiques » par renvoi à l’article 2, point 4), de la directive (UE) 2022/2557. Le règlement ne définit pas séparément les « infrastructures numériques critiques ». Le point 2 ne nomme ni le transport ferroviaire, aérien ou maritime, ni les ports, ni les aéroports. Un système destiné à l’un de ces domaines n’est à haut risque que si un autre point de l’annexe III ou l’annexe I le couvre.

• Seuls les composants de sécurité sont visés

  Un composant de sécurité est un composant d’un produit ou d’un système d’IA qui remplit une fonction de sécurité pour ce produit ou ce système d’IA, ou dont la défaillance ou le dysfonctionnement met en danger la santé et la sécurité des personnes ou des biens. Un composant remplit une fonction de sécurité lorsque sa finalité prévue est de prévenir ou d’atténuer les risques pour la santé et la sécurité des personnes ou des biens (article 3, point 14)). Les systèmes d’IA qui sont uniquement utilisés pour des aspects non liés à la sécurité en ce qui concerne l’assistance aux utilisateurs, l’optimisation des performances, l’efficacité des services, l’automatisation, la commodité ou le contrôle de la qualité ne sont pas considérés comme des composants de sécurité (article 6, paragraphe 1 bis). Les systèmes d’IA dont la défaillance ou le dysfonctionnement mettrait en danger la santé et la sécurité sont considérés comme des composants de sécurité (article 6, paragraphe 1 ter). L’article 6, paragraphe 5, imposait à la Commission de fournir, au plus tard le 2 février 2026, des lignes directrices comprenant une liste exhaustive d’exemples pratiques de cas d’utilisation à haut risque et non à haut risque. Le considérant 55 du texte de 2024 décrit les composants de sécurité des infrastructures critiques comme des systèmes utilisés pour protéger directement l’intégrité physique des infrastructures critiques ou la santé et la sécurité des personnes et des biens, mais qui ne sont pas nécessaires au fonctionnement du système. Il indique que les composants destinés à être utilisés uniquement à des fins de cybersécurité ne devraient pas être considérés comme des composants de sécurité. Un considérant n’est pas une règle contraignante. Savoir si un outil donné de prévision, d’optimisation ou de maintenance est un composant de sécurité relève d’un juriste.

• L’article 6, paragraphe 3, peut sortir un système de l’annexe III

  Un système relevant du point 2 est à haut risque au titre de l’article 6, paragraphe 2. Au titre de l’article 6, paragraphe 3, il n’est pas à haut risque s’il ne présente pas de risque important de préjudice pour la santé, la sécurité ou les droits fondamentaux. Cela inclut de ne pas avoir d’incidence significative sur le résultat de la prise de décision. Le règlement applique cette exception lorsqu’une des conditions suivantes est remplie (article 6, paragraphe 3, points a) à d)). Le système est destiné à accomplir une tâche procédurale étroite. Ou il est destiné à améliorer le résultat d’une activité humaine préalablement réalisée. Ou il est destiné à détecter les constantes en matière de prise de décision ou les écarts par rapport aux constantes habituelles antérieures et n’est pas destiné à se substituer à l’évaluation humaine préalablement réalisée, ni à influencer celle-ci, sans examen humain approprié. Ou il est destiné à exécuter une tâche préparatoire en vue d’une évaluation pertinente aux fins des cas d’utilisation visés à l’annexe III. Savoir comment ces conditions se combinent avec le critère du risque important relève d’un juriste. Le système est toujours à haut risque lorsqu’il effectue un profilage de personnes physiques. Le profilage est défini à l’article 4, point 4), du RGPD (article 3, point 52)). Le fournisseur qui invoque l’exception documente son évaluation avant la mise sur le marché ou la mise en service du système. Il doit aussi enregistrer le système (article 6, paragraphe 4, article 49, paragraphe 2).

• Les produits de l’annexe I forment une voie distincte

  Un système d’IA peut aussi être à haut risque au titre de l’article 6, paragraphe 1. Il faut pour cela qu’il soit un composant de sécurité d’un produit, ou un produit, couvert par la législation d’harmonisation de l’Union énumérée à l’annexe I, lorsque le produit doit faire l’objet d’une évaluation de la conformité par un tiers. La section A de l’annexe I énumère par exemple les équipements sous pression (point 7) et les appareils brûlant des combustibles gazeux (point 10). Les exigences pour ces systèmes s’appliquent à partir du 2 août 2028 (article 113, point c) ii)). La section B énumère par exemple le système ferroviaire (point 17, directive (UE) 2016/797). Pour les systèmes à haut risque liés à des produits relevant de la section B, seuls l’article 6, paragraphe 1, l’article 60 bis et les articles 102 à 112 s’appliquent. Les articles 57, 58 et 59 ne s’appliquent que dans la mesure où les exigences applicables aux systèmes d’IA à haut risque ont été intégrées dans cette législation (article 2, paragraphe 2). Les articles 9 à 15 ne figurent pas parmi les dispositions applicables.

• Fournisseur et déployeur

  Le fournisseur développe un système d’IA, ou le fait développer, et le met sur le marché ou le met en service sous son propre nom ou sa propre marque (article 3, point 3)). La mise en service inclut la fourniture pour usage propre du fournisseur (article 3, point 11)). Un gestionnaire de réseau, une commune ou une autorité routière qui développe un système et le met en service sous son propre nom est donc un fournisseur. Celui qui utilise un système sous son autorité est un déployeur (article 3, point 4)). Un déployeur devient fournisseur dans trois cas. Il appose son nom ou sa marque sur un système à haut risque déjà mis sur le marché, sans préjudice des dispositions contractuelles prévoyant une autre répartition des obligations. Il y apporte une modification substantielle qui le laisse à haut risque. Ou il modifie la finalité prévue d’un système qui n’était pas à haut risque, de sorte qu’il le devienne (article 25, paragraphe 1). Le fournisseur qui a initialement mis le système sur le marché ou en service n’est alors plus considéré comme le fournisseur de ce système spécifique, et coopère étroitement avec le nouveau fournisseur (article 25, paragraphe 2). Cela ne s’applique pas lorsque le fournisseur initial a clairement précisé que son système ne doit pas être transformé en système d’IA à haut risque.

• Les fournisseurs conservent les journaux sous leur contrôle

  Les fournisseurs doivent assurer la tenue des journaux générés automatiquement par leurs systèmes à haut risque, dans la mesure où ces journaux se trouvent sous leur contrôle (article 19, paragraphe 1). Sans préjudice du droit de l’Union ou du droit national applicable, la période doit être adaptée à la finalité prévue et d’au moins six mois. Elle peut être différente si le droit de l’Union ou le droit national, en particulier sur la protection des données à caractère personnel, en dispose autrement.

• Les déployeurs conservent les journaux sous leur contrôle

  Les déployeurs doivent assurer la tenue des journaux générés automatiquement par le système, dans la mesure où ces journaux se trouvent sous leur contrôle (article 26, paragraphe 6). La période doit être adaptée à la finalité prévue et d’au moins six mois. Elle peut être différente si le droit de l’Union ou le droit national applicable, en particulier sur la protection des données à caractère personnel, en dispose autrement.

• Incidents graves touchant des infrastructures critiques

  Un incident grave comprend un incident ou un dysfonctionnement d’un système d’IA qui entraîne, directement ou indirectement, une perturbation grave et irréversible de la gestion ou de l’exploitation d’infrastructures critiques (article 3, point 49), point b)). Le fournisseur doit le signaler immédiatement, et au plus tard deux jours après que le fournisseur ou, le cas échéant, le déployeur en a eu connaissance (article 73, paragraphe 3). Un déployeur qui a constaté un incident grave en informe d’abord le fournisseur, puis l’importateur ou le distributeur et les autorités de surveillance du marché concernées (article 26, paragraphe 5). Pour les systèmes de l’annexe III mis sur le marché ou mis en service par des fournisseurs soumis à des instruments législatifs de l’Union prévoyant des obligations de signalement équivalentes, la notification est limitée aux incidents visés à l’article 3, point 49) c) (article 73, paragraphe 9). Savoir quels instruments entrent en compte relève d’un juriste. L’article 113 ne prévoit pas de date propre pour cette disposition ; voir la ligne sur les dates.

• Dates

  Les exigences pour ces usages de l’annexe III s’appliquent à partir du 2 décembre 2027 (article 113, point c) i)). Un système mis sur le marché ou mis en service avant cette date n’est couvert que si sa conception subit ensuite d’importantes modifications. En tout état de cause, les fournisseurs et les déployeurs de systèmes d’IA à haut risque destinés à être utilisés par des autorités publiques doivent prendre les mesures nécessaires pour se conformer au plus tard le 2 août 2030 (article 111, paragraphe 2). Les articles 43 et 49 (chapitre III, section 5) et les articles 72 et 73 (chapitre IX) ne relèvent pas de l’article 113, point c). L’article 113 ne prévoit pas de date propre pour eux ; selon sa règle générale, ils s’appliquent donc à partir du 2 août 2026. Savoir comment cela s’articule avec la date ci-dessus relève d’un juriste.

• Amendes

  Les fournisseurs doivent veiller à ce que leurs systèmes à haut risque respectent les exigences de la section 2 du chapitre III, qui comprend les articles 9 à 15 (article 16, point a)). Un manquement aux obligations du fournisseur de l’article 16 ou à celles du déployeur de l’article 26 peut être sanctionné d’une amende. Elle peut atteindre 15 millions d’EUR ou, pour une entreprise, 3 % de son chiffre d’affaires annuel mondial total de l’exercice précédent, le montant le plus élevé étant retenu (article 99, paragraphe 4, points a) et e)). Pour les PME, y compris les jeunes pousses, chaque amende est plafonnée au plus faible des deux montants (article 99, paragraphe 6). Le même plafond vaut pour les petites ETI (« petites entreprises à moyenne capitalisation » dans le règlement ; article 3, point 14 ter), article 99, paragraphe 6 bis). Chaque État membre établit les règles déterminant dans quelle mesure des amendes administratives peuvent être imposées aux autorités et organismes publics établis sur son territoire (article 99, paragraphe 8).

• Portée et limites du règlement

  Le règlement s’applique aux fournisseurs et aux déployeurs qui ont leur lieu d’établissement ou sont situés dans un pays tiers, lorsque les sorties produites par le système d’IA sont utilisées dans l’Union (article 2, paragraphe 1, point c)). Il ne s’applique pas aux domaines qui ne relèvent pas du champ d’application du droit de l’Union et ne porte pas atteinte aux compétences des États membres en matière de sécurité nationale (article 2, paragraphe 3). Il ne s’applique pas aux systèmes d’IA lorsque et dans la mesure où ils sont mis sur le marché, mis en service ou utilisés, avec ou sans modification, exclusivement à des fins militaires, de défense ou de sécurité nationale (article 2, paragraphe 3). Il ne s’applique pas aux obligations des déployeurs qui sont des personnes physiques utilisant des systèmes d’IA dans le cadre d’une activité strictement personnelle à caractère non professionnel (article 2, paragraphe 10). Le règlement ne s’applique pas aux systèmes ou modèles d’IA, y compris leurs sorties, spécifiquement développés et mis en service uniquement à des fins de recherche et développement scientifiques (article 2, paragraphe 6). Il ne s’applique pas aux activités de recherche, d’essai et de développement avant la mise sur le marché ou la mise en service d’un système. Les essais en conditions réelles ne sont pas couverts par cette exclusion (article 2, paragraphe 8). Les systèmes d’IA publiés dans le cadre de licences libres et ouvertes sont hors du champ du règlement. Cette exclusion ne joue pas s’ils sont mis sur le marché ou mis en service en tant que systèmes d’IA à haut risque, ou s’ils relèvent de l’article 5 ou de l’article 50 (article 2, paragraphe 12).

• Pas de champs de journal, de format ni de durée de conservation propres aux infrastructures

  Au-delà de « au moins six mois, sauf disposition contraire », le règlement ne nomme ni champs de journal, ni format, ni durée de conservation pour les systèmes du point 2 (article 19, paragraphe 1, article 26, paragraphe 6). Le droit de l’Union ou le droit national peut en disposer autrement. Le règlement lui-même ne nomme aucune norme harmonisée. Les systèmes à haut risque conformes à des normes harmonisées dont les références sont publiées au Journal officiel sont présumés conformes aux exigences de la section 2, dans la mesure où ces normes les couvrent (article 40, paragraphe 1). La Commission élabore des lignes directrices sur l’application pratique des exigences et obligations des articles 8 à 15, 25 et 26 (article 96, paragraphe 1, point a)).

• Exemple : ce que pourrait contenir le journal d’un composant de sécurité

  Exemple, sans valeur d’exigence du règlement : le fournisseur d’un composant de sécurité pour un réseau d’eau pourrait enregistrer, pour chaque utilisation, l’heure, les entrées de capteurs sur lesquelles le système s’est appuyé et la sortie ou l’action déclenchée. Une action inattendue peut alors être retracée.

• Exemple : conserver les journaux du déployeur avec les registres d’exploitation

  Exemple, sans valeur d’exigence du règlement : un déployeur pourrait conserver les journaux sous son contrôle avec ses autres registres d’exploitation. La durée doit rester d’au moins six mois, sauf disposition contraire du droit de l’Union ou du droit national applicable (article 26, paragraphe 6).

• Article 12 règlement IA : enregistrement et journalisation

  L’article 12 pour tous les secteurs : exigences, dates et amendes.

• Règlement IA infrastructure critique : conformité

  Vue d’ensemble des infrastructures critiques : comment le règlement atteint l’IA des composants de sécurité.

• Article 13 pour l’IA des infrastructures critiques : transparence et notice d’utilisation

  L’IA des infrastructures critiques et l’article 13 : notice d’utilisation et déclaration d’exactitude.

• Article 72 : surveillance après commercialisation

  La surveillance après commercialisation, que la journalisation prévue à l’article 12, paragraphe 2, point b), vise à faciliter.