Sauf mention contraire, les citations de sources publiées en anglais sont traduites par nos soins ; les extraits de textes juridiques de l'Union européenne reprennent leur version française officielle.
Le même modèle de fondation peut servir un assistant de rédaction, un copilote de maintenance ou un robot. Appeler ces trois systèmes des « produits d'IA » masque des différences d'autorité, de conséquences des défaillances, d'environnement et de preuves.
Ce livre blanc examine ce que chacune des trois classes, l'IA générative, l'IA opérationnelle et l'IA physique, change en matière d'architecture, de réglementation, de preuves et de responsabilité. C'est un outil de gestion de produit, pas une classification juridique, et il ne remplace pas une évaluation de sûreté, de cybersécurité ou réglementaire propre au système.
Synthèse
- La frontière entre les classes est l'autorité, pas la famille de modèles. Le même modèle peut rédiger une note, classer une file de travail ou commander un actionneur.
- La recherche sur les modèles franchit désormais directement la frontière physique. RT-2 combine des données d'Internet avec des trajectoires robotiques annotées d'instructions et représente les actions « sous forme de jetons textuels » pour entraîner une politique de contrôle robotique.
- Chaque classe défaille différemment. Les systèmes génératifs confabulent, les systèmes opérationnels induisent un biais d'automatisation et des boucles de rétroaction, et les systèmes physiques y ajoutent les contraintes temporelles, le décalage de distribution et des actions hors d'un espace de mouvement défini.
- Le contrôle humain a une limite physique. Lorsqu'un effet devient irréversible plus vite qu'une personne ne peut intervenir, le contrôle doit être intégré dans une couche déterministe ; un ratio de faisabilité du contrôle humain, proposé ici, rend ce test explicite.
- Après l'omnibus numérique, le cadre réglementaire d'un système d'IA tend à suivre sa classe d'autorité. Les obligations de l'annexe III s'appliquent à partir du 2 décembre 2027, celles de l'annexe I à partir du 2 août 2028, et l'IA intégrée aux machines passe à un traitement sectoriel.
- La reclassification est un événement, pas une note de bas de page. Modifier la destination d'un système d'IA peut faire de l'auteur de la modification le fournisseur d'un système à haut risque ; les changements d'autorité exigent donc une étape de validation produit.
- Le livrable pratique est une revue du chemin d'autorité : six questions, un niveau d'autorité, une vérification de faisabilité et des déclencheurs de reclassification.
Le problème et pourquoi il compte maintenant
Une étiquette, trois produits
Une équipe peut décrire un système par son modèle : « une fonctionnalité LLM », « un modèle de vision ». Cela aide au choix des fournisseurs, mais les conséquences d'une sortie dépendent de ce qui la reçoit.
Prenons un même modèle de maintenance.
- S'il rédige une note de technicien destinée à être relue, il se comporte comme une IA générative.
- S'il priorise des ordres de travail, il se comporte comme une IA opérationnelle.
- S'il modifie le fonctionnement d'une machine ou déclenche une réponse physique automatisée, il participe à l'IA physique.
Le modèle n'a pas changé. L'usage prévu, l'intégration et l'autorité, si.
Pourquoi la question est plus aiguë en 2026
Premièrement, la frontière du modèle s'est dissoute. L'article RT-2 propose d'« exprimer les actions sous forme de jetons textuels et de les intégrer directement dans l'ensemble d'entraînement du modèle de la même manière que les jetons de langage naturel ». Une famille de modèles autrefois considérée comme un générateur de contenu peut alors émettre des commandes motrices, et la question produit devient : « où va sa sortie ? »
Deuxièmement, le calendrier de l'UE sépare les classes dans le temps. Le calendrier haut risque du règlement sur l'intelligence artificielle, tel que modifié par l'omnibus numérique sur l'IA, règlement (UE) 2026/1744, fixe le 2 décembre 2027 pour les systèmes classés à haut risque au titre de l'article 6(2) et de l'annexe III, et le 2 août 2028 pour les systèmes classés au titre de l'article 6(1) et de l'annexe I.
Troisièmement, le droit des produits voisin évolue. Le règlement Machines (UE) 2023/1230, tel que corrigé par son rectificatif de juillet 2023, s'applique à partir du 20 janvier 2027. Le règlement sur la cyberrésilience (CRA), règlement (UE) 2024/2847, s'applique à partir du 11 décembre 2027, les obligations de signalement des fabricants prévues à l'article 14 s'appliquant à partir du 11 septembre 2026.
flowchart LR A["11 sept. 2026 : obligations de signalement de l'art. 14 du CRA applicables"] --> B["2 déc. 2026 : échéance du marquage de l'art. 50(2) pour les systèmes déjà sur le marché"] B --> C["20 janv. 2027 : règlement sur les machines applicable"] C --> D["2 déc. 2027 : obligations haut risque de l'annexe III du règlement sur l'IA"] D --> E["11 déc. 2027 : principales obligations du CRA"] E --> F["2 août 2028 : obligations haut risque de l'annexe I du règlement sur l'IA et actes délégués IA pour les machines"]
| Date | Instrument | Ce qui s'applique | Classe la plus exposée |
|---|---|---|---|
| 11 sept. 2026 | CRA, art. 71(2) | Signalement au titre de l'article 14 des vulnérabilités activement exploitées | Toute classe livrée sous forme de produit comportant des éléments numériques |
| 2 déc. 2026 | Règlement IA, art. 111(4) tel que modifié | Marquage au titre de l'article 50(2) pour les systèmes génératifs mis sur le marché avant le 2 août 2026 | Générative |
| 20 janvier 2027 | Règlement Machines, art. 54 tel que corrigé | Application générale, y compris les exigences essentielles relatives au comportement à auto-évolution | Physique |
| 2 déc. 2027 | Règlement IA, art. 113 tel que modifié | Chapitre III, sections 1 à 3, sauf l'article 6(5), pour les systèmes relevant de l'annexe III | Opérationnelle, et certains usages physiques dans les infrastructures critiques |
| 11 déc. 2027 | CRA, art. 71(2) | Obligations principales | Toute classe livrée sous forme de produit comportant des éléments numériques |
| 2 août 2028 | Règlement IA, art. 113 tel que modifié ; règlement Machines, art. 8 tel que modifié (règlement applicable à partir du 20 janvier 2027) | Chapitre III, sections 1 à 3, sauf l'article 6(5), pour les systèmes relevant de l'annexe I ; actes délégués ajoutant des exigences relatives à l'IA pour les machines | Physique |
La dernière colonne est une aide à la lecture dérivée de la taxonomie, pas une correspondance juridique.
La taxonomie : trois classes définies par l'autorité
La définition courte
L'IA générative crée ou transforme de l'information qu'une personne évalue.
L'IA opérationnelle éclaire ou coordonne un processus métier ou opérationnel, tandis qu'une personne ou un processus déterministe conserve l'autorité de décision.
L'IA physique perçoit, décide ou recommande au sein d'un système capable de modifier le monde physique. Sa sortie est reliée, directement ou par l'intermédiaire d'un opérateur, à une machine, un véhicule, un robot, un actif énergétique ou un procédé industriel.
La frontière est l'autorité, pas l'image de marque : un modèle de langage peut apparaître dans les trois catégories.
Les définitions s'alignent sur la définition juridique d'un système d'IA sans en dépendre. L'article 3(1) du règlement sur l'IA définit un système d'IA comme un système qui déduit « la manière de générer des sorties telles que des prédictions, du contenu, des recommandations ou des décisions qui peuvent influencer les environnements physiques ou virtuels ». La taxonomie demande lequel de ces environnements la sortie atteint, et par l'intermédiaire de qui.
IA générative : le contenu reste soumis au jugement humain
Un système génératif rédige du texte, du code, des images, de l'audio ou des informations structurées, et l'utilisateur examine la sortie avant qu'elle n'ait des conséquences : rédaction de documents, exploration de conception, assistance au code.
Axes de preuve : qualité des tâches, comportement de relecture des utilisateurs, provenance, traitement des données et divulgation des défaillances.
IA opérationnelle : le produit façonne un processus
L'IA opérationnelle classe, prédit, recommande ou coordonne au sein d'un processus, et peut influencer sensiblement le travail sans commander de machine. Exemples : planification de la maintenance prédictive, assistance aux opérateurs, prévision de la demande, priorisation des ordres de travail et tri des exceptions d'une flotte.
Axes de preuve : qualité des décisions, adéquation au processus, contrôle humain, escalade, traçabilité et responsabilité opérationnelle.
IA physique : le produit participe à un système physique
L'IA physique relie la perception ou une logique de décision apprise à une action physique : un actionneur, une trajectoire, une réponse de machine, ou un opérateur dont l'étape suivante a une conséquence physique. Le produit n'est jamais seulement le modèle : il comprend les capteurs, le calcul, la connectivité, les commandes déterministes, l'autorité humaine, les chemins de mise à jour, le comportement en mode dégradé et la réponse aux incidents. Exemples : manipulation robotique, navigation autonome, vision industrielle reliée à une action sur la ligne et fonctions d'aide à la conduite.
Axes de preuve : enveloppe de fonctionnement, latence, état sûr, autorité humaine, variabilité du matériel, réception sur site et maîtrise des mises à jour.
Les six questions de classification
Posez-les à l'étape Stratégie, puis de nouveau avant l'Industrialisation :
- Que peut observer le système ? Définissez les capteurs, les sources de données, le contexte et les angles morts.
- Que peut décider ou recommander le système ? Formulez la sortie en termes opérationnels.
- Qui ou quoi reçoit la sortie ? Un utilisateur, un moteur de workflow, un contrôleur ou un actionneur crée un chemin d'autorité différent.
- Que peut-il changer dans le monde ? Incluez les changements indirects passant par un opérateur.
- Qu'est-ce qui prime sur le système ? Nommez les commandes déterministes, l'autorité humaine et l'état sûr.
- Quelles preuves autorisent la mise en production et les changements ? Définissez l'évaluation, la réception sur site, la surveillance et l'approbation des mises à jour.
Une équipe qui ne peut pas y répondre n'a pas classé le produit assez finement pour choisir l'architecture, les preuves ou la responsabilité.
flowchart TD Q1["Q3 : qui ou quoi reçoit la sortie ?"] --> P["Une personne qui la vérifie avant usage"] Q1 --> W["Un flux de travail, une file ou un système métier"] Q1 --> C["Un contrôleur, un actionneur ou un opérateur agissant sur l'équipement"] P --> Q4a["Q4 : la sortie vérifiée peut-elle changer l'état de l'équipement ?"] Q4a -->|"Non"| G["IA générative"] Q4a -->|"Oui, via l'opérateur"| PH["IA physique"] W --> Q4b["Q4 : le flux de travail déclenche-t-il automatiquement une action physique ?"] Q4b -->|"Non"| O["IA opérationnelle"] Q4b -->|"Oui"| PH C --> PH PH --> Q5["Q5 : nommer la reprise en main et l'état sûr"] O --> Q5b["Q5 : nommer le responsable de l'escalade"] G --> Q6["Q6 : définir les preuves de vérification et de provenance"]
Analyse technique : ce que la classe change dans l'architecture
L'autorité comme étape de la chaîne d'automatisation
Parasuraman, Sheridan et Wickens (2000) proposent que l'automatisation puisse s'appliquer à quatre grandes classes de fonctions : « 1) l'acquisition d'informations ; 2) l'analyse d'informations ; 3) la décision et la sélection d'actions ; et 4) la mise en œuvre de l'action ». Ils ajoutent qu'« un système donné peut impliquer l'automatisation des quatre types à des niveaux différents ».
Rapportée à la taxonomie, l'IA générative automatise l'analyse et la rédaction, et s'arrête avant la sélection. L'IA opérationnelle s'étend à la décision et à la sélection d'actions, tandis qu'une personne ou un processus déterministe exécute. L'IA physique atteint la mise en œuvre de l'action, directement ou par l'intermédiaire d'un opérateur dont l'étape suivante a une conséquence physique. Cette correspondance est une interprétation ; le modèle de 2000 ne nomme pas ces catégories.
Différences d'architecture selon la classe
| Dimension | IA générative | IA opérationnelle | IA physique |
|---|---|---|---|
| Destinataire de la sortie | Une personne qui relit | Un processus, une file ou un décideur | Un contrôleur, un actionneur ou un opérateur sur l'équipement |
| Contrainte temporelle | Temps de lecture humain | Cycle du processus (poste, ticket, lot) | Période de la boucle de commande et distance d'arrêt |
| Où l'inférence peut s'exécuter | Cloud ou local ; la latence est une question d'ergonomie | Cloud, sur site ou edge ; la disponibilité compte pour le processus | Edge ou embarqué lorsque la boucle ne tolère pas une perte de réseau ; cloud pour les tâches non temps réel |
| Frontière déterministe | Filtres d'accès et de contenu | Règles métier, étapes d'approbation | Fonctions de sécurité, verrouillages, une tâche et un espace de mouvement définis |
| Défaillance caractéristique | Confabulation, fuite, perte de provenance | Biais d'automatisation, boucles de rétroaction, dérive silencieuse | Décalage de distribution, défauts temporels, action hors de l'enveloppe |
| État sûr | Écarter le brouillon | Revenir au processus manuel | Un arrêt défini ou un mode dégradé que le matériel peut atteindre |
| Finalité de la journalisation | Provenance et examen des usages abusifs | Traçabilité des décisions | Reconstitution des décisions liées à la sécurité |
| Chemin de mise à jour | Publication du modèle ou du prompt | Publication du modèle plus maîtrise des changements du processus | Publication du modèle plus réévaluation de la sécurité du système couplé |
Où l'inférence peut s'exécuter. RT-2 illustre le compromis. Ses auteurs ont déployé les modèles « dans un service cloud multi-TPU » interrogé « via le réseau ». Le plus grand modèle, de 55 milliards de paramètres, « peut fonctionner à une fréquence de 1-3 Hz » et la version de 5 milliards de paramètres « à une fréquence d'environ 5 Hz ». Les auteurs avertissent que « à mesure que ces méthodes seront appliquées à des contextes exigeant une commande à haute fréquence, l'inférence en temps réel pourrait devenir un goulot d'étranglement majeur ». Une politique apprise a une fréquence, et cette fréquence doit être comparée à la dynamique de la machine et à la perte du chemin réseau. Des articles connexes traitent du placement : Cloud, edge ou contrôleur ? et les modes de défaillance de l'edge AI en production.
Frontière déterministe. Le règlement Machines dispose que les systèmes de commande des machines « au comportement ou à la logique totalement ou partiellement auto-évolutifs » sont conçus de manière à « ne pas amener la machine ou le produit connexe à exécuter des actions allant au-delà de leur espace défini de travail et de mouvement ». La même clause exige qu'« il soit possible à tout moment de corriger la machine ou le produit connexe afin de préserver leur sécurité intrinsèque ». Une enveloppe définie et une possibilité de correction permanente sont des propriétés de l'architecture, pas du modèle.
Modes de défaillance par classe
Générative : confabulation et confiance mal placée. Le profil IA générative du NIST (NIST AI 600-1) définit la confabulation comme « la production de contenu erroné ou faux énoncé avec assurance ». Il nomme aussi un risque de « configuration humain-IA », incluant « le biais d'automatisation, la dépendance excessive ou l'attachement émotionnel ». La défaillance générative est détectée, ou manquée, à la relecture.
Opérationnelle : biais d'automatisation et boucles de rétroaction. Dans une revue d'études empiriques, Parasuraman et Manzey (2010) rapportent que « le biais d'automatisation conduit à commettre des erreurs d'omission comme de commission lorsque les aides à la décision sont imparfaites » et qu'il « ne peut être empêché par la formation ou les consignes ». Une recommandation qu'un planificateur accepte sans examen est plus proche d'une décision automatique que ne le laisse penser son schéma. Sculley et al. (2015) notent que les systèmes en production peuvent « finir par influencer leur propre comportement s'ils se mettent à jour au fil du temps » et mettent en garde contre les « boucles de rétroaction cachées, dans lesquelles deux systèmes s'influencent mutuellement de manière indirecte à travers le monde ». Un modèle qui classe les actifs à inspecter décide aussi lesquels génèrent des données d'inspection.
Physique : décalage de distribution, contraintes temporelles et enveloppe. Le benchmark WILDS rapporte, sur dix jeux de données présentant des décalages naturels, que « l'entraînement standard produit des performances hors distribution nettement inférieures aux performances dans la distribution ». Les déploiements physiques rencontrent de tels décalages par construction. Les auteurs de RT-2 notent aussi que « le robot n'acquiert aucune capacité à effectuer de nouveaux mouvements » grâce au pré-entraînement sur le web ; « les compétences physiques du modèle restent limitées à la distribution des compétences vues dans les données robotiques ». La généralisation du sens n'implique pas la généralisation du mouvement.
Assurance à l'exécution : maintenir l'autorité bornée
L'architecture Black-Box Simplex décrit Simplex comme « un cadre d'assurance à l'exécution dans lequel l'autorité de commande peut basculer d'un contrôleur avancé non vérifié et potentiellement dangereux vers un contrôleur de référence de secours afin de maintenir la sécurité d'un système cyber-physique autonome ». Safe Reinforcement Learning via Shielding propose un « bouclier » qui « surveille les actions de l'apprenant et ne les corrige que si l'action choisie entraîne une violation de la spécification ».
Dans les deux cas, le composant appris propose et un composant plus simple et vérifiable dispose.
sequenceDiagram
participant S as Capteurs
participant M as Politique apprise
participant R as Moniteur d'exécution
participant B as Contrôleur de référence
participant A as Actionneur
participant L as Journal des événements
S->>M: Observation
M->>R: Action proposée
R->>R: Vérifier par rapport à l'enveloppe de tâche et de mouvement
alt Proposition dans l'enveloppe
R->>A: Transmettre l'action proposée
else Proposition hors enveloppe ou tardive
R->>B: Transférer l'autorité de commande
B->>A: Action sûre ou dégradée
end
R->>L: Consigner la décision et sa raison
Le schéma est un modèle de conception, pas une conception certifiée ; la nécessité pour le moniteur de disposer de son propre argumentaire de sécurité fonctionnelle dépend de l'analyse des dangers du système.
Mesure par classe
| Classe | Ce qu'il faut mesurer | Dans quelles conditions | Qui accepte le résultat |
|---|---|---|---|
| Générative | Qualité des tâches, taux d'erreur après relecture, couverture de la provenance | Entrées représentatives, adverses et hors périmètre | Responsable produit et relecteurs |
| Opérationnelle | Qualité des décisions au regard des résultats, taux de dérogation et d'acceptation, dérive | Mode fantôme (shadow mode), avec des données de résultats que le modèle n'a pas sélectionnées | Responsable du processus détenant l'autorité de décision |
| Physique | Respect de l'enveloppe, temps de réaction, atteignabilité de l'état sûr, performance d'un site à l'autre | Essais terrain bornés, injection de fautes, capteurs dégradés, perte de réseau | Responsables sécurité et exploitation, avec le responsable produit |
Un taux d'acceptation élevé est ambigu : un bon modèle ou un biais d'automatisation. Les dérogations sur des cas où le modèle est connu pour se tromper permettent de distinguer les deux.
Une métrique originale : le ratio de faisabilité du contrôle humain
L'article 14 du règlement sur l'IA attend, pour les systèmes à haut risque, que les personnes chargées du contrôle humain aient la possibilité « d'intervenir dans le fonctionnement du système d'IA à haut risque ou d'interrompre le système au moyen d'un bouton d'arrêt ou d'une procédure similaire permettant au système de s'arrêter de manière sécurisée ». Le texte ne dit pas en combien de temps. Ce livre blanc propose un test, présenté comme un raisonnement Hyperion et non comme une norme :
Le numérateur est le temps qui s'écoule entre la sortie de l'IA et le moment où son effet ne peut plus être annulé ; le dénominateur est le temps nécessaire pour remarquer un problème, décider, actionner la commande et atteindre l'état sûr.
- Nettement supérieur à un : le contrôle humain peut être une protection principale, si la personne est attentive et informée.
- Proche de un ou inférieur : l'autorité doit être bornée par une couche déterministe, telle qu'un moniteur d'exécution, un verrouillage ou un espace de mouvement défini, et la personne supervise le système borné.
Les sorties génératives ont des temps d'irréversibilité longs, les sorties opérationnelles des temps à l'échelle du processus, et les sorties physiques peuvent avoir des temps plus courts que le temps de réaction humain. Les termes restent des estimations tant qu'ils n'ont pas été mesurés.
Données de recherche et textes réglementaires
Types de preuves
| Source | Type | Ce qu'elle étaye ici | Cadre ou limite déclarés |
|---|---|---|---|
| Parasuraman, Sheridan et Wickens (2000) | Modèle évalué par les pairs | Quatre types de fonctions de l'automatisation | Un cadre de conception, pas un résultat empirique |
| Parasuraman et Manzey (2010) | Revue évaluée par les pairs | Biais d'automatisation chez les utilisateurs novices et experts | Synthèse d'études sur les aides à la décision |
| Sculley et al. (2015) | Article de praticiens évalué par les pairs | Boucles de rétroaction dans les systèmes de ML en production | Fondé sur l'expérience, pas une étude contrôlée |
| WILDS (Koh et al.) | Article de benchmark | Écart de performance hors distribution | Dix jeux de données sélectionnés ; pas de commande robotique |
| RT-2 (Brohan et al.) | Article de recherche d'un développeur de modèles | Actions sous forme de jetons ; fréquences de commande ; limites de mouvement | « 6k essais d'évaluation », menés par le développeur |
| Black-Box Simplex ; Shielding | Articles de recherche | Modèles d'assurance à l'exécution | Études de cas et arguments formels, pas des déploiements sur le terrain |
| NIST AI RMF et AI 600-1 | Cadre volontaire | Cartographie du contexte, vocabulaire des risques génératifs | Volontaire ; pas une voie de conformité |
| Règlement IA, omnibus, règlement Machines, CRA | Texte réglementaire | Obligations et dates | Droit contraignant ; l'application dépend du système concerné |
Les résultats de RT-2 proviennent de son développeur, selon sa propre évaluation : une preuve de faisabilité, pas de fiabilité sur le terrain.
Ce que disent les cadres sur le contexte
Le NIST AI RMF Core organise la gestion des risques en quatre fonctions : « gouverner, cartographier, mesurer et gérer ». Sa sous-catégorie MAP 1.1 demande que les finalités prévues et « les contextes prospectifs dans lesquels le système d'IA sera déployé soient compris et documentés », et MANAGE 2.4 demande des mécanismes « pour supplanter, désengager ou désactiver les systèmes d'IA dont les performances ou les résultats sont incompatibles avec l'usage prévu ».
Ce que dit le règlement sur l'IA pour chaque classe
La taxonomie n'attribue pas de classe de risque au sens du règlement sur l'IA ; elle indique quelles dispositions lire en premier.
| Classe | Dispositions à examiner en premier | Pourquoi |
|---|---|---|
| Générative | Art. 50(2), marquage des contenus de synthèse ; art. 50(4), transparence pour les hypertrucages et certains textes d'intérêt public | L'art. 50(2) exige que les sorties soient « marquées dans un format lisible par machine et identifiables comme ayant été générées ou manipulées par une IA » |
| Opérationnelle | Art. 6(2) et annexe III ; dérogations de l'art. 6(3) ; art. 14(4)(b) sur le biais d'automatisation | Le point 4(b) de l'annexe III couvre les systèmes utilisés « pour attribuer des tâches sur la base du comportement individuel, de traits de personnalité ou de caractéristiques personnelles ou pour suivre et évaluer les performances et le comportement de personnes » dans le cadre de relations de travail |
| Opérationnelle ou physique | Annexe III, point 2 | Couvre les systèmes « 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é » |
| Physique | Art. 6(1) et annexe I ; nouveaux art. 6(1a) et 6(1b) ; pour les machines, le règlement Machines | Les composants de sécurité intégrés aux produits relèvent du droit sectoriel des produits et de la date la plus tardive |
| Toutes les classes | Art. 25(1)(c), modification de la destination ; art. 3(23), modification substantielle | Les changements d'autorité peuvent changer l'identité du fournisseur |
Trois détails textuels comptent à la frontière entre l'opérationnel et le physique.
Le critère du composant de sécurité comporte une exclusion explicite. L'omnibus insère l'article 6(1a) : les systèmes « 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é ». L'article 6(1b) ajoute que les systèmes « 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é ». Un optimiseur utilisé uniquement pour des aspects non liés à la sécurité est exclu au titre de l'article 6(1a), sous réserve du critère des conséquences d'une défaillance de l'article 6(1b).
La dérogation de l'annexe III repose sur l'influence. En vertu de l'article 6(3), un système relevant de l'annexe III « n'est pas considéré comme étant à haut risque lorsqu'il ne présente pas de risque important de préjudice pour la santé, la sécurité ou les droits fondamentaux des personnes physiques, y compris en n'ayant pas d'incidence significative sur le résultat de la prise de décision », sous réserve de conditions énumérées telles qu'une « tâche procédurale étroite ». La dérogation ne s'applique pas lorsque le système effectue un profilage de personnes physiques : un tel système « est toujours considéré comme étant à haut risque ». Des recommandations acceptées sans examen peuvent influencer de manière significative les décisions malgré une étape d'approbation humaine. L'article 6(4) exige qu'un fournisseur qui invoque la dérogation « documente son évaluation » avant la mise sur le marché du système.
L'IA intégrée aux machines passe à un traitement sectoriel. L'omnibus supprime l'entrée relative aux machines de la section A de l'annexe I et ajoute le règlement (UE) 2023/1230 à la section B, pour laquelle l'article 2(2) modifié prévoit que « seuls l'article 6, paragraphe 1, l'article 60 bis, et les articles 102 à 112 s'appliquent ». Le règlement Machines lui-même s'applique à partir du 20 janvier 2027 ; la Commission doit ajouter des exigences relatives à l'IA à son annexe III par des actes délégués qui « sont applicables le 2 août 2028 au plus tard ».
Enseignement dérivé : le cadre réglementaire suit la classe d'autorité
Lues ensemble, les dispositions suggèrent un schéma (raisonnement à partir du texte, pas une conclusion juridique) :
- L'IA générative rencontre le règlement sur l'IA principalement à travers les obligations de transparence de l'article 50.
- L'IA opérationnelle relevant d'un cas d'usage de l'annexe III rencontre directement le règlement sur l'IA, à travers l'article 6(2) et le critère d'influence de l'article 6(3), à partir du 2 décembre 2027.
- L'IA physique intégrée aux machines rencontre les exigences relatives à l'IA principalement à travers le règlement Machines, qui, à partir du 20 janvier 2027, exige que les systèmes de commande « au comportement ou à la logique totalement ou partiellement auto-évolutifs qui sont conçus pour fonctionner avec différents niveaux d'autonomie » permettent l'enregistrement des « données relatives au processus décisionnel en matière de systèmes de sécurité basés sur des logiciels assurant des fonctions de sécurité, y compris de composants de sécurité », ces données étant conservées « pendant un an après leur collecte ».
La fonction qui détient les preuves réglementaires diffère donc selon la classe. Les preuves relatives à l'IA d'une machine aboutissent dans son dossier technique au titre du règlement Machines lorsque cette voie s'applique ; pour un système opérationnel relevant de l'annexe III, la voie de preuve dépend de sa classification à haut risque et de toute évaluation documentée au titre de l'article 6(3). Pour les produits relevant des deux régimes, l'article 12 du CRA prévoit que les produits comportant des éléments numériques classés comme systèmes d'IA à haut risque sont réputés satisfaire aux exigences de cybersécurité de l'article 15 du règlement sur l'IA lorsqu'ils satisfont aux exigences essentielles de cybersécurité du CRA et aux autres conditions de cet article.
Analyse métier et décisionnelle
Conséquences décisionnelles par classe
| Décision | IA générative | IA opérationnelle | IA physique |
|---|---|---|---|
| Test de valeur principal | Temps gagné et qualité après relecture | De meilleures décisions, mesurées au regard des résultats | Performance physique reproductible dans une enveloppe |
| Principaux facteurs de coût | Volume d'inférence, effort de relecture, outillage de provenance | Intégration aux systèmes de référence, collecte des données de résultats, conduite du changement | Capteurs et calcul par unité, essais terrain, ingénierie de sécurité, réception sur site, maîtrise des mises à jour |
| Étape de validation avant mise en production | Évaluation de la qualité et transparence | Preuves en mode fantôme et validation par le responsable | Analyse des dangers, vérification de l'enveloppe, réception sur site |
| Responsable redevable | Responsable produit | Responsable du processus détenant l'autorité de décision | Responsable produit conjointement avec la sécurité et l'exploitation |
| Réversibilité d'une mauvaise mise en production | Élevée ; retirer la fonctionnalité | Moyenne ; les décisions déjà prises persistent | Faible ; les effets physiques persistent et les unités sur le terrain doivent être mises à jour |
L'effort récurrent se concentre différemment : la relecture humaine dans les produits génératifs ; les données de résultats que le modèle n'a pas sélectionnées, pour échapper aux boucles de rétroaction, dans les produits opérationnels ; les preuves couvrant les variantes matérielles et les sites, comptées en heures d'essais terrain et d'ingénierie, dans les produits physiques.
Une table de décision pour les cas limites
| Si l'équipe observe... | Alors le produit est probablement... | Décision à prendre maintenant |
|---|---|---|
| Les utilisateurs copient les sorties dans des documents après les avoir modifiées | Générative | Investir dans l'ergonomie de la relecture et la provenance |
| Une file est réordonnée par le modèle et les planificateurs la modifient rarement | Opérationnelle, avec une influence significative possible | Mesurer les dérogations sur des cas connus comme erronés ; examiner le raisonnement au titre de l'art. 6(3) |
| Des tâches sont attribuées à des travailleurs nommément désignés en fonction de leur comportement | Opérationnelle, relevant possiblement du point 4(b) de l'annexe III | Avancer l'examen juridique |
| Un opérateur exécute la recommandation du modèle sur l'équipement | Physique, par l'intermédiaire d'un opérateur | Calculer le ratio de faisabilité du contrôle humain ; nommer l'état sûr |
| La sortie atteint un contrôleur ou un actionneur | Physique | Concevoir la frontière déterministe avant d'ajuster le modèle |
| Une mise à jour du modèle change le comportement sur le terrain | Toute classe, mais la plus coûteuse en physique | Traiter comme un changement exigeant une réévaluation, pas comme une mise en production ordinaire |
Organisation et responsabilité
Des dirigeants en désaccord sur une « fonctionnalité d'IA » peuvent parler de classes différentes : un cadrage génératif invite à des mises en production rapides, un cadrage physique impose la maîtrise des changements. La responsabilité suit l'autorité : quiconque détient l'autorité de décision sur une sortie devrait être responsable de ses preuves d'acceptation. Si personne ne la détient, le produit porte un risque non attribué.
Une méthode : la revue du chemin d'autorité
La revue du chemin d'autorité est un outil de raisonnement Hyperion : une manière structurée d'appliquer la taxonomie, pas une méthodologie validée sur le terrain.
Étape 1 : tracer le chemin
Répondez aux six questions et tracez le chemin de l'observation à l'effet, en nommant chaque destinataire.
Étape 2 : attribuer un niveau d'autorité
| Niveau | Description | Classe indicative |
|---|---|---|
| A0 | La sortie informe une personne qui décide si elle l'utilise ou non | Générative |
| A1 | La sortie est une recommandation au sein d'un processus ; une personne décide | Opérationnelle |
| A2 | La sortie est exécutée par défaut, sauf si une personne ou une règle intervient | Opérationnelle avec influence significative, ou physique |
| A3 | La sortie pilote l'équipement par l'intermédiaire d'un opérateur ou d'un contrôleur, dans une enveloppe déterministe | Physique |
| A4 | La sortie pilote l'équipement et aucune enveloppe déterministe n'existe | Physique, et pas prête pour la mise en production |
Les niveaux s'inspirent de Parasuraman, Sheridan et Wickens ; les libellés sont propres à ce livre blanc.
Étape 3 : effectuer la vérification de faisabilité
Estimez le ratio de faisabilité du contrôle humain pour la pire sortie plausible. Lorsqu'il est proche de un ou inférieur, la frontière déterministe devient une exigence de mise en production.
Étape 4 : lister les déclencheurs de reclassification
Listez les changements qui feraient passer le produit dans une autre classe : une nouvelle intégration ou un nouveau destinataire, l'automatisation d'une étape humaine, un nouveau type de site, ou une mise à jour du modèle qui change son comportement. Chaque déclencheur est une étape de validation produit. L'article 25(1)(c) du règlement sur l'IA explique pourquoi : une partie qui modifie « la destination d'un système d'IA » de telle manière que celui-ci « devient un système d'IA à haut risque » est considérée comme un fournisseur.
stateDiagram-v2 state "Usage génératif, brouillon à vérifier" as G state "Usage opérationnel, classer la file de travail" as O state "Usage physique, déclencher une action de l'équipement" as P state "Point de contrôle de reclassification" as R [*] --> G G --> R: Nouveau destinataire ou nouvelle intégration O --> R: Automatisation d'une étape humaine R --> O: Niveau d'autorité A1 ou A2 R --> P: Niveau d'autorité A3 R --> G: Niveau d'autorité A0 P --> R: Une mise à jour du modèle change le comportement P --> [*]: Retiré avec mise hors service sûre
Exemple détaillé (hypothétique)
Les chiffres sont des hypothèses illustratives, pas des mesures.
Un fabricant de pompes industrielles construit un modèle de détection d'anomalies sur des données de vibration.
Déploiement 1, notes de technicien. Le modèle rédige une note qu'un technicien modifie. Destinataire : une personne. Niveau A0. Classe : générative.
Déploiement 2, classement des ordres de travail. Le modèle réordonne la file de maintenance, et les planificateurs la modifient rarement. Niveau A2, car l'exécution est le comportement par défaut. Classe : opérationnelle. L'équipe mesure les dérogations sur des classements délibérément erronés introduits à cet effet et vérifie si des tâches sont attribuées à des travailleurs nommément désignés en fonction de leur comportement (point 4(b) de l'annexe III).
Déploiement 3, arrêt automatique. Le modèle déclenche désormais l'arrêt d'une pompe lorsqu'il prédit une défaillance de roulement. Destinataire : un contrôleur. Supposons, à titre d'hypothèse, que le délai avant dommage après une décision erronée de « maintien en marche » soit d'environ 20 secondes et qu'une personne ait besoin d'environ 10 secondes pour remarquer le problème, 10 pour décider, 5 pour atteindre une commande et 5 pour que la pompe s'arrête.
En dessous de un, un superviseur ne peut pas être la protection principale. L'équipe conserve le déclenchement de protection comme frontière déterministe, autorise seulement le modèle à demander un arrêt contrôlé anticipé, journalise chaque décision et traite le déploiement 3 comme une étape de reclassification. C'est le dossier technique de la machine, et non la fiche du modèle (model card), qui contient les preuves.
Le modèle est identique dans les trois déploiements ; le produit, ses preuves et son responsable ne le sont pas.
Feuille de route de mise en œuvre
Le Physical AI Product System transforme la classification en étapes de décision couvrant la Stratégie, la Découverte, l'Industrialisation, le Lancement et le Passage à l'échelle. La liste de contrôle ci-dessous applique la taxonomie à chaque étape.
Stratégie
- Indiquez la classe et le niveau d'autorité de chaque usage prévu.
- Consignez la destination dans les propres termes du fournisseur, car l'article 3(12) la rattache à « la notice d'utilisation, les indications publicitaires ou de vente et les déclarations ».
- Identifiez les instruments datés qui s'appliquent et qui détient les preuves réglementaires.
Découverte
- Observez les opérateurs, les mainteneurs et l'environnement ; consignez les contournements et l'autorité d'acceptation.
- Mesurez comment les personnes passent outre les aides à la décision actuelles ou les ignorent.
Industrialisation
- Décidez où l'inférence s'exécute et comparez la fréquence de la politique à la dynamique qu'elle influence.
- Définissez la frontière déterministe et l'état sûr avant d'ajuster le modèle.
- Estimez le ratio de faisabilité du contrôle humain et concevez le chemin d'arrêt.
- Spécifiez la journalisation selon sa finalité : provenance, traçabilité des décisions ou reconstitution de sécurité.
Lancement
- Définissez l'acceptation, le support, la réponse aux incidents et l'autorité sur les changements.
- Préparez le chemin de signalement des vulnérabilités si le produit comporte des éléments numériques relevant du CRA.
Passage à l'échelle
- Vérifiez si la valeur et l'économie se reproduisent d'un site et d'une variante matérielle à l'autre.
- Réexaminez les déclencheurs de reclassification à chaque changement de modèle ou d'intégration.
- N'inférez pas la reproductibilité à partir d'un seul test borné ; voir l'autonomie fiable.
Limites et questions ouvertes
- La taxonomie n'est pas le droit. L'IA générative, l'IA opérationnelle et l'IA physique sont des catégories de produits Hyperion, pas des classes définies par la loi ou par des normes.
- Les actes délégués sont en attente. Les exigences spécifiques à l'IA pour les machines doivent être fixées par des actes délégués ; leur contenu affectera la ligne « physique » de chacun des tableaux ci-dessus.
- Les normes harmonisées sont incomplètes. Les considérants de l'omnibus citent « le retard pris dans l'élaboration des normes ».
- Le ratio de faisabilité du contrôle humain n'a pas été testé. Ses termes sont difficiles à estimer, et Parasuraman et Manzey rapportent que la complaisance envers l'automatisation « se produit dans des conditions de charge multitâche », c'est-à-dire précisément lorsque les estimations du temps de détection sont les moins fiables.
- Les données de recherche sur la généralisation physique sont maigres. L'évaluation de RT-2 est celle du développeur lui-même ; WILDS ne couvre pas la commande robotique. Les sources examinées contiennent peu de preuves indépendantes de terrain sur les politiques industrielles apprises.
- Les produits mixtes sont difficiles à classer pour toute taxonomie. Un même produit peut contenir les trois chemins ; la méthode classe chaque chemin, pas le produit.
FAQ
L'IA physique est-elle la même chose que la robotique ?
Non. L'IA physique inclut tout système dont la sortie atteint des équipements, des véhicules, des actifs énergétiques ou des procédés industriels, directement ou par l'intermédiaire d'un opérateur. Une recommandation exécutée sur une machine en fonctionnement se trouve sur le chemin physique.
Utiliser un grand modèle de langage fait-il d'un produit une IA générative ?
Non. La classe dépend de qui ou quoi reçoit la sortie et de ce qu'elle peut changer. Un modèle de langage qui écrit une consigne de commande participe à l'IA physique.
Une étape d'approbation humaine rend-elle un produit peu risqué ?
Pas à elle seule. Le biais d'automatisation produit des erreurs d'omission et de commission avec des aides imparfaites, et l'article 6(3) demande si un système influence de manière significative la prise de décision. Mesurez la part des approbations qui changent les résultats.
Quand un produit doit-il être reclassé ?
Chaque fois que changent le destinataire, l'intégration, l'automatisation d'une étape humaine ou le comportement sur le terrain. L'article 25(1)(c) montre que modifier la destination peut changer l'identité du fournisseur.
Sources de référence et limites
Les définitions de l'article 3 du règlement sur l'IA et la cartographie du contexte du NIST AI RMF ancrent cette grille de lecture ; elles ne font pas de cette taxonomie une classification juridique. Pour une décision de mise sur le marché, appuyez-vous sur les textes réglementaires primaires en vigueur et sur un conseil juridique qualifié.
La provenance des contenus générés est un domaine de normalisation actif ; la C2PA se présente comme fournissant « une norme technique ouverte permettant aux éditeurs, aux créateurs et aux consommateurs d'établir l'origine et les modifications des contenus numériques ». La C2PA traite de la provenance des contenus ; son adéquation au marquage prévu à l'article 50(2) nécessite une évaluation distincte.
Faites appel à la Product Decision Review lorsque l'autorité, le périmètre du produit ou la responsabilité des preuves ne sont pas tranchés.
