Le règlement européen sur l’Intelligence Artificielle

L’explosion du développement de l’IA (Intelligence Artificielle) ces dernières années est comparable à l’explosion d’Internet il y a 20 ans et, plus proche de nous, l’explosion des réseaux sociaux assortie de l’utilisation que les sites Web et ces mêmes réseaux font des données de leurs souscripteurs. À l’époque se posait alors la question : mais que font ces sites des données que je leur fournis ? Sont-ils même censés conserver ces données ad vitam æternam, au risque qu’elles fuitent lors d’un incident de Cybersécurité ? Est-ce un usage légitime ? Mes données servent-elles à faire de l’argent ?

Alors dans ce cadre, l’Union Européenne a édicté le Règlement Général sur la Protection des Données. De la même manière pour l’IA, des questions se posent sur son usage, encore plus s’il peut s’agir de systèmes embarquant des IA et dont le fonctionnement peut affecter des personnes. Suite aux risques potentiels posés par l’IA, l’Union Européenne a édicté le Règlement sur l’Intelligence Artificielle.

Ce texte a été publié en aout 2024 dans sa version finale, et voit sa mise en application étalée dans le temps, les deux premiers chapitres étant applicables depuis le 2 février 2025. Qui est concerné ? Tout citoyen européen, à des degrés divers ! Le présent article a pour objectif de donner une vue d’ensemble de ce règlement afin de donner aux lecteurs une première idée de la façon dont ce règlement peut s’appliquer à eux.

1. LES DIFFERENTES CATEGORIES D’IA & PRISE DE CONSCIENCE

Pour cadrer ce dont il est question, le règlement sur l’IA définit 3 catégories d’IA.

1.1. IA PROHIBEES

Certains cas d’usage sont purement et simplement interdits : pour résumer grossièrement, si une IA était utilisée à des fins de manipulation des personnes, exploiter leurs faiblesses, catégoriser des groupes de personnes, construire des bases de données a priori, faire de la biométrie sans garde-fou, elle serait interdite selon ce règlement. En quelques mots-clefs, les natures d’IA prohibées :

Manipulation en vue de fausser le comportement des personnes
Exploitation des personnes vulnérables, en raison de leur âge, d’un handicap, de leur situation socio-économique, etc
La classification des personnes sur la base de sur la base de leur comportement social ou de caractéristiques menant à des traitements préjudiciables appliqués en dehors du contexte de cette classification. Un exemple typique serait la délégation à un système d’IA du calcul de « crédit social » des personnes
L’évaluation des risques d’infraction pénale sur la seule base du profilage des personnes. En d’autres termes, une version IA du film « Minority Report ».
La création a priori de bases de données de reconnaissance biométrique par extraction d’images de l’espace public (Internet, télévision)
La reconnaissance d’émotions des personnes sur les lieux de travail et d’enseignement, sauf en vue d’utilisation médicale ou de sécurité
La création de base de données biométriques inférant les races, opinions politiques, croyances, orientations sexuelles des personnes. La seule exception ici concerne les base de données constituées selon un cadre légal
Les systèmes d’identification biométriques en temps réel dans l’espace public. Le règlement prévoit cependant des exceptions à cette interdiction, notamment la recherche de victimes, la prévention de menaces (vigipirate et les évévements publics sensibles en sont un bon exemple), et la localisation de personnes sous le coup de poursuites pénales, à partir d’un certain niveau de gravité desdites poursuites.

Pour résumer, les systèmes d’IA interdits sont ceux qui seraient considérés comme illégaux ou amoraux, qui prennent des décisions qui relèvent de l’humain, ou qui constituent des bases de données a priori. Dans ce dernier cas on perçoit l’influence du RGPD sur ce règlement. Les exceptions citées dans les derniers points ci-dessus sont strictement encadrés et sont sous couvert de validation qui par l’Union Européenne, qui par les autorités des états membres.

1.2. IA A HAUT RISQUE

Tout ce qui n’est pas interdit est autorisé, mais il n’est pas non plus question de faire ce que l’on veut. Certains systèmes d’IA posent des risques de par leur contexte d’utilisation (exemple : systèmes de reconnaissance d’objets sur la route dans une voiture à système de conduite autonome), aussi ces risques doivent pouvoir être cadrés. À cette fin l’UE définit les domaines d’usage d’IA qui peuvent poser de tels risques :

Les systèmes biométriques, dans la mesure leur utilisation est autorisée par l’UE ou le droit des états membres
Les infrastructures critiques : trafic routier, gestion des eaux, du gaz, de l’électricité p.ex.
L’éducation ou la formation professionnelle
L’emploi et la gestion du contexte de travail
L’accès aux services essentiels, qu’ils soient privés ou publics. Le règlement mentionne notamment les services de santé et d’assistance, les services financiers liés à la solvabilité des personnes, l’assurance vie/l’assurance maladie et les services d’urgence.
Les services répressifs pour la détection de victimes d’infraction, l’évaluation de la fiabilité d’éléments de preuve, l’évaluation du comportement antérieur, et même pour le profilage de personnes physiques mais selon un cadre déjà spécifié par d’autres règlements européens.
La gestion des flux migratoires
Le soutien aux processus de justice et aux processus démocratiques
Les domaines des produits visés à l’annexe I du règlement, c’est-à-dire : les machines, les jouets, les véhicules nautiques, les appareils de protection en atmosphère explosive, les équipements radioélectriques, les équipements pressurisés, l’installation de câbles, les équipements de protection individuelle, les appareils à gaz, les dispositifs médicaux, l’aviation civile, les véhicules, les équipements marins, le système ferroviaire. Globalement, tous les systèmes et équipements posant un risque par nature, dans lesquels il est plausible qu’un système IA soit utilisé, et qui font déjà l’objet de directives ou règlements européens.

Cette liste n’est qu’un résumé et tout un chacun est encouragé à consulter le règlement pour plus de détails. Cependant, si votre domaine d’application est susceptible d’affecter la santé, la sécurité, les droits fondamentaux, l’application de la loi ou l’environnement vis-à-vis des personnes et que vous comptez utiliser un système d’IA dans ce cadre, il est désormais de votre devoir de savoir si ce système tombe sous le coup du règlement et de connaître les droits et obligations attenants à cette utilisation.

1.3. IA A RISQUE SYSTEMIQUE

Dû à la nature des systèmes d’IA, il est possible que ces systèmes soient définis pour être adaptables et donc ne sont pas développés dans un but précis ou vers une fonction précise. On parle ici des systèmes d’IA à usage général.

À la différence des systèmes d’IA des deux précédentes sections où c’est l’usage – ou le domaine – de l’IA qui définit son niveau de risque, les IA d’usage général seront considérées comme étant à risque de manière circonstancielle. En effet, le règlement définit une IA à usage général comme posant des risques potentiels si elle remplit un des critères suivants :

Des indicateurs ou des critères de référence signalent pour cette IA des capacités d’impact élevées (par exemple, nombre de déploiements sur les smartphones dans la population)
Ses capacités sont suffisamment élevées : nombre de paramètres, taille et qualité des données manipulées, quantité de calcul utilisée pour l’entraînement du modèle, formats des entrées et sorties du modèle, sa capacité à s’auto-adapter à de nouvelles tâches, la taille du marché cible de l’IA.

Il est à noter que le règlement ne donne aucun seuil chiffré pour ces capacités, à l’exception de la quantité de calcul d’entraînement, qui est donné à 10²⁵ opérations en virgule flottante. À l’heure où ces lignes sont écrites, peu de modèles d’IA atteignent ou dépassent ce seuil, et correspondent à ceux qui sont relayés le plus souvent dans les médias généralistes (cf le graphique ci-après qui donne un classement de la quantité d’opérations utilisées pour entraîner divers modèles d’IA depuis 2020).

Comme on peut le voir, le règlement prévoit donc le cas où une IA ne tombe pas sous le coup de la définition d’IA à haut risque car elle ne serait pas utilisée pour un usage sensible, mais pourrait poser un risque de par son adaptabilité à toute tâche (y compris les tâches à usage sensible) ou de par sa diffusion dans la sphère publique. Dans le premier cas c’est l’usage qui définit le risque, dans le second c’est la nature du modèle d’IA qui le définit.

1.4. REMARQUES

Il serait tentant de penser que ce règlement serait une réaction aux développements ultrarapides des IA ces 2 dernières années. Cependant, à la vue de la définition retenue pour ce qu’est une IA pertinente pour ce règlement, cela va plus loin que ça : par exemple, les systèmes de reconnaissance optiques développés depuis 5 à 10 ans dans le cadre de la voiture autonome tombent sous le coup du règlement.

On pourrait même pousser le trait jusqu’à des techniques d’IA encore plus anciennes, comme la reconnaissance de caractères basée sur des réseaux de neurones. Si cette reconnaissance est faite dans un contexte applicable au règlement, par exemple la numérisation de textes juridiques, alors des actions seront à mener pour, rétroactivement, s’assurer que ce système de reconnaissance coche toutes les cases selon le règlement.

2. LE ROLE DU REGLEMENT SUR L’IA

Ce règlement a pour but d’établir un cadre pour le développement d’outils basés sur de l’IA, leur mise sur le marché et leur usage, d’où la nécessité de définir précisément de quelle IA il est question, comme indiqué dans la section précédente.

Il vise à protéger tout citoyen européen pouvant être affecté par une IA, et en particulier sa santé, sa sécurité, ses droits fondamentaux. Il vise également à maintenir l’ordre (au sens du de l’application de la loi) et à protéger l’environnement.

Une question qui pourrait se poser à ce stade sur l’applicabilité est : et si un citoyen européen travaillait pour le compte d’un groupe extra-européen, et que ce groupe utilisait en interne des outils d’IA qui restent sur un territoire extra-européen (donc pas de diffusion dans l’UE), est-ce que ce règlement s’applique ? La réponse est oui : la protection du citoyen européen est le cœur de l’objectif du règlement, comme l’est le RGPD dans le contexte de la gestion des données personnelles.

Parallèlement à cela, même si aucun citoyen européen ne sera affecté (système d’IA pour l’export hors UE), à partir du moment une IA est développée dans l’UE, le règlement s’applique également.

3. RÔLES, DROITS ET OBLIGATIONS

Sans trop entrer dans les détails, le règlement définit différents rôles dans le cycle de vie d’une IA, rôles qui sont assortis de droits et obligation selon les cas. Les rôles définis sont :

Les fournisseurs, p.ex. une société qui développe des chatbots logiciels
Les déployeurs, les utilisateurs d’IA dans un but spécifique
Les fabricants, qui embarquent des systèmes d’IA dans leurs produits
Les importateurs, qui mettent sur le marché des systèmes d’IA
Les organismes notifiés, des organismes responsables de l’évaluation de la conformité au règlement
Les autorités notifiantes, des agences nationales responsables de faire appliquer le règlement, via la mise en place au niveau national de procédures dédiées et via la désignation d’organismes notifiés

En plus de ces rôles, le règlement identifie expressément les institutions publiques, de par leur implication future vis-à-vis des rôles définis ci-dessus, les petites/moyennes entreprises et startups, de par des exemptions qui peuvent s’appliquer à ces entités, et la population dans son ensemble de par les droits des citoyens vis-à-vis de ce qu’ils sont en droit de demander à toutes ces entités.

Plutôt que détailler par le menu les droits et obligations de chaque rôle, ce qui ferait double emploi avec le texte du règlement, voici ci-après un synoptique qui résume les interactions entre ces différents rôles.

Ce synoptique est complété par les deux tableaux suivants, l’un résumant les obligations des rôles proches de la conception des IA, le second résumant les obligations des entités chargées de la surveillance des IA.

Ce premier tableau indique pour chaque rang l’obligation, et pour cette obligation, qui parmi les opérateurs de l’IA dans chaque colonne a un rôle identifié. Par exemple, les représentants autorisés ont pour obligation de conserver pendant 10 ans les informations de contact des fournisseurs d’IA qu’ils représentent.

1er tableau

Type d’obligation	Fournisseurs	Représentants autorisés	Importateurs	Distributeurs	Fournisseurs/ Fabricants
Conformité aux exigences	Assurer	Vérifier	Assurer	Vérifier	Assurer
Informations de contact	Indiquer	Conserver 10 ans	Indiquer	–	–
Système de gestion qualité	Posséder	–	–	–	–
Documentation	Élaborer & Archiver	Vérifier et conserver (10 ans), donner accès	Vérifier	–	Appliquer, évaluer la protection des données
Journaux	Conserver	Donner accès	–	–	Conserver
Audit de conformité	S’assurer de	Vérifier la mise en oeuvre	–	–	–
Déclaration de conformité EU	Préparer	Vérifier	Vérifier	Vérifier	–
Marquage CE	Apposer	–	Vérifier	Vérifier	–
Obligations d’enregistrement	Se conformer	Assurer	–	–	Se conformer (si le déployeurs est une institution publique)
Mesures correctives	Prendre	–	–	Prendre	–
Informations aux autorités	Fournir	Fournir	Fournir	Fournir	Fournir
Autorités	Coopérer	Coopérer	Coopérer	Coopérer	Coopérer
Employés/ Utilisateurs finaux	–	–	–	–	Informer
Utilisation (supervision humaine)	–	–	–	–	Surveiller
Application de la loi	–	–	–	–	Demander l’autorisation

Ce second tableau se focalise sur les acteurs du règlement et des actions qu’ils ont à mettre en oeuvre. Par exemple, il est attendu des états membres de l’UE qu’ils mettent en place des bacs à sable réglementaire chacun à leur niveau, pour soutenir l’accéleration de la standardisation pour les fournisseurs d’IA sur leur sol.

2ème tableau

Obligations	Commission IA de l’UE	Organismes notifiés	Autorités de surveillance du marché	Membres de l’UE
Directives	Développer	–	–	–
Requêtes de standardisation	Émettre	–	–	–
Conformité	Surveiller	–	Surveiller	–
Évaluations	Mener	–	Mener	–
Support technique	Fournir	–	–	–
Confidentialité	Assurer	Assurer	Assurer	Assurer
Commission	–	En référer à	En référer à	En référer à
Autres autorités	Coopérer	Coopérer	Coopérer	Coopérer
Bacs à sables réglementaires	–	–	–	Établir
Coopération transfrontalière	Faciliter	–	Faciliter	Faciliter
Autorités nationales compétentes	–	–	–	Désigner
Ressources et expertise	–	–	–	Fournir
Cybersécurité	–	–	Assurer	Assurer
Base de données EU des IA	Maintenir	–	–	–
Codes de bonnes pratiques	Développer	–	–	–
Pénalités	–	–	Implémenter	Implémenter
Petites/moyennes entreprises, startups	Soutenir	–	–	Soutenir

3.1. DOCUMENTATION ET TRANSPARENCE

Le règlement est très précis concernant les besoins de documentation, de gestion de la qualité et la transparence des IA conçues et déployées dans le contexte de l’UE.

Qualité : le texte insiste sur le test et la validation des IA, et sur les méthodes et processus et associés à la conception, la validation ainsi que la gestion du risque des IA. Il insiste encore plus fortement sur l’existence ou la mise en place d’un processus de gestion de données.

Transparence : les IA sont gourmandes de données, tant pour leur conception que pour leur utilisation, et le besoin de reproductibilité des résultats et d’observabilité du comportement des IA apparaît, tant explicitement qu’entre les lignes, dans ce texte. Les obligations de transparence édictées participent de cette observation : tout ce qui peut servir à reproduire, surveiller, interpréter une IA est indiqué comme faisant partie des informations à restituer aux organismes notifiés pour l’obtention d’un marquage CE.

Parmi les obligations de transparence, une partie concerne les caractéristiques mêmes de l’IA : son objectif, sa précision, ses risques potentiels, son explicabilité, sa performance, la typologie de ses données d’entrée ainsi que les jeux de tests ayant servi à sa conception/validation, ainsi que des informations sur la façon dont les sorties de l’IA doivent être interprétées. Les caractéristiques à renseigner comprennent, en points notables, un volet Cybersécurité (lié à l’IA elle-même mais aussi aux jeux de données qui y sont associés) et un volet sur les vulnérabilités spécifiques aux IA.

Sur la base de ce qui est demandé en termes de transparence, il y a une volonté forte d’obliger toutes les parties prenantes à garder la maîtrise de ce que sont et ce que font les IA.

Dans certains cas particuliers pour les déployeurs et fournisseurs, lorsque les données produites par IA sont susceptibles d’être « consommées » par des personnes, celles-ci doivent être informées qu’elles interagissent ou sont exposées à une IA, jusqu’à imposer l’ajout d’un filigrane aux données produites.

Il est à noter que le texte mentionne explicitement des exemptions de responsabilité et de documentation pour les systèmes d’IA, lorsque ceux-ci sont des modèles dits «open-source».

3.2. BACS A SABLE REGLEMENTAIRES

Si le résumé que constitue cet article n’était pas assez clair sur ce point, la règlementation impose beaucoup d’actions aux parties prenantes des systèmes d’IA. L’UE est consciente des difficultés apportées par ce règlement, et propose ce qu’elle appelle des « bacs à sable réglementaires ».

Ces bacs à sable s(er)ont des environnements physiques, logiciels et normatifs mis en place par les autorités nationales pour soutenir les concepteurs, fournisseurs, déployeurs, fabricants à la mise en conformité des systèmes d’IA qu’ils proposent. Cela inclurait notamment la mise à disposition de jeux de données anonymisés utilisables pour l’entraînement ou la validation de systèmes d’IA, voire des données réelles garanties conformes aux lois en vigueur.

L’intérêt de ces bacs à sable est l’accélération du marquage CE des IA : une IA développée et/ou validée sous couvert d’un bac à sable réglementaire serait déjà de facto conforme à un certain nombre d’articles du règlement et donc verrait sa mise en conformité facilitée d’autant.

3.3. ENTREE EN VIGUEUR

La frise chronologique fournie par la loi européenne sur l’IA est la suivante :

2024-07-12: publication
2024-08-01: entrée en vigueur officielle
2025-02-02: les chapitres I et II sur les IA prohibées, à haut risqué et à risques systémiques, et sur la prise de conscience des IA, deviennent applicables. [Nous sommes ici au moment d’écrire cet article]
2025-08-02: la plupart du texte s’applique, à l’exception de l’article 6(1) et de l’annexe I. Cela signifie que les autres domaines (automobile, nautique, ferroviaire, fourniture d’énergie, etc) qui souhaitent utiliser de l’IA dans leurs systèmes et leurs produits, auront un délai supplémentaire pour se mettre en conformité (août 2027, cf ci-après)
2026-08-02: les IA à haut risque déjà sur le marché depuis avant la publication du règlement et modifiées significativement doivent devenir conformes
2027-08-02:
- L’ article 6(1), annexe I s’applique (utilisation d’IA dans un produit couvert par d’autres régulations européennes telles que sur les véhicules à moteur, les avions, les jouets, etc)
- Les IA à usage général mises sur le marché avant le 2025-08-02 doivent se mettre en conformité
2030-08-02: les IA à haut risque déjà sur le marché et modifiées significativement doivent devenir conformes, dans le cas particulier où le fournisseur est une institution ou une autorité publique
2030-12-31: les systèmes d’IA à grande échelle mis sur le marché avant le 2027-08-02 doivent être conformes.

En résumé, les IA «pures» devront être conformes d’ici le second semestre 2025, les produits qui embarquent de l’IA pour une fonction déterminée en revanche ont jusqu’au second semestre 2027. La commission donne également un délai de grâce similaire pour les systèmes d’IA qui ont été développés avant que la version définitive du texte soit publiée officiellement.

Pour les organismes ne s’y conformant pas, le texte indique des pénalités pouvant se monter jusqu’à un pourcentage du chiffre d’affaires (7%), à adapter au circonstances de la non-conformité.

CONCLUSION

Si l’on devait extraire un schéma d’intentions du texte suite à sa lecture, les points suivants ressortiraient:

Il faut mettre en place des garde-fous. Les exemples d’utilisation néfaste des IA ne manquent pas, ce texte vise à les prévenir
Les IA sont un vecteur d’innovation: certes il faut prévenir les usages néfastes des IA, mais il serait dommage de se priver de ce qu’elles peuvent apporter. Ce texte en est conscient, de par la singularisation des petites/moyennes entreprises, des startups, des modèles open-source
En terme d’entités de surveillance et de support, tout est à faire: quelle forme prendront les organismes notifiés, les autorités notifiantes, les bacs à sable réglementaires, qui seront les panels d’expert ?

À l’heure où ces lignes sont publiées (premier semestre 2025), l’obligation principale pour tout un chacun est de prendre connaissance des types d’IA considérées par le règlement (reprises au début de cet article) et de mettre en place des formations qui dans sa société, qui dans son institut, destinés au personnel qui sera en charge de la mise en place et de la surveillance des IA utilisées au sein desdits société/institut.

CAS D’USAGE

Une des premières questions qui vient à l’esprit quant à la publication d’un nouveau règlement est «Suis-je concerné(e) ?» suivi de «Si oui, que devrai-je faire ?». L’objet de cette section est d’explorer les différents cas d’usage auxquels tout un chacun pourrait être confronté.

Usages généraux

J’utilise une IA telle que celles dont on parle dans les médias généralistes pour mon usage propre
- Rien de particulier à faire, en revanche vous serez en droit d’attendre et de demander plus de documentation et de transparence au fournisseur de ce système d’IA
Je fais partie d’un service informatique, j’ai autorisé l’accès à une IA généraliste dans le cloud aux employés de ma société
- Rien de particulier à faire, vous pouvez demander plus de documentation au fournisseur, ainsi qu’en plus du support pour la surveillance du système d’IA dans le cadre de l’utilisation qui en est faite par votre sociéte
Je fais partie d’un service informatique, je me méfie du cloud, je préfère héberger un modèle d’IA sur mes propres serveurs pour usage par les employés de ma société
- Dans ce cas vous êtes considéré comme un déployeur et devez suivre les obligations attenantes à ce rôle dans le règlement IA
Je suis dans le département R&D, j’ai pris un modèle d’IA et l’ai adapté à mes besoins
- Vous êtes considéré comme un fournisseur
Je suis chercheur, j’ai inventé un nouveau modèle d’IA à usage général…
- Vous êtes considéré comme un fournisseur, et devrez vous attendre à fournir un support pour aider à classifer votre système d’IA
… mais je diffuse mon modèle en open-source
- Vous êtes toujours considéré comme un fournisseur, mais aurez un peu moins d’obligations à remplir du fait que le modèle est open-source
Je développe un produit, j’utilise une IA pour m’épauler dans la rédaction du logiciel qui sera embarqué dans le produit
- C’est l’un des cas d’usage le plus courant de nos jours. Par rapport au règlement sur l’IA, il n’y a rien de particulier à faire. En revanche si votre catégorie de produits est soumis à d’autres régulations que celle sur l’IA, il faudra se poser la question de la compatibilité de ce que l’IA produit pour vous avec ces autres régulations, cf section suivante pour une discussion sur le sujet
Je développe un produit dans lequel je compte embarquer une IA prise sur étagère (par exemple un système de reconnaissance d’image)
- Vous devez déterminer dans quelle catégorie cette IA se classe (prohibées, à haut risque, à risque systémique)
- Puisque vous prenez cette IA «sur étagère», vous êtes considérés comme un déployeur
- Votre équipe de vente aura le rôle de distributeur
- Si vos clients à leur tour utilisent votre produit comme un composant de base pour concevoir leur propre produit, ils seront considérés comme des distributeurs vis-à-vis du règlement
Je développe un produit dans lequel je compte embarquer une IA que j’ai conçue ou prise sur étagère mais que j’ai adaptée à mon besoin

Comme le cas précédent, à la différence que cette fois vous serez considéré comme un fournisseur et non un déployeur, et vous aurez donc plus d’actions à entreprendre pour être conforme

Usages soumis à autres régulations

Un cas d’usage courant est l’utilisation de l’IA comme support aux activités, sans qu’au final il n’y ait d’IA dans le produit final. Par exemple une IA aura pu être utilisée pour la rédaction de documentation sur un projet, ou la rédaction de code logiciel. Dans ce cas, toutes les productions de l’IA restent soumises aux régulations, normes ou standards qui s’appliquent à votre produit, et seront scrutées à la lueur des ces normes. Il y a deux écoles de pensée à considérer:

L’IA est un outil logiciel
L’IA est comme un humain avec certaines particularités et limitations:
- Une connaissance étendue de beaucoup de sujets, mais
- Incapable ou quasi-incapable de raisonner
- Susceptible de mentir pour compenser son manque de connaissance sur des sujets pointus (les fameuses hallucinations des IA dont on entend souvent parler)

Un peu comme un humain avec un syndrome du savant, mais qui n’hésiterait pas à mentir, pour pousser la métaphore jusqu’au bout. À y réfléchir, la comparaison avec l’humain est idoine: lorsque vous cherchez à embaucher quelqu’un pour écrire du code pour votre produit, vous ne choisissez pas n’importe qui. Vous scrutez sa formation, ses diplômes, ses expériences passées, vous le soumettez peut-être même à quelques tests pour vous en assurer: pourquoi n’en irait-il pas de même pour des IA vouées à réaliser des activités similaires ? La documentation imposée par le règlement sur l’IA participe de cette idée. Selon les écoles de pensée citées ci-avant, deux approches se dégagent:

Si l’IA est considérée comme un outil logiciel, alors vous devrez appliquer les procédés des normes qui s’appliquent au logiciel comme outil support. Par exemple, l’ISO 26262 a tout un chapitre dédié à la Software Tool Qualification, donc les actions visent à obtenir certaines garanties que l’outil logiciel fait bien ce qu’il prétend faire et n’introduit pas d’erreur. Selon les systèmes d’IA, ces garanties peuvent être conceptuellement impossibles à démontrer, et constituent des sujets de recherche actifs aujourd’hui
Si l’IA est considéré comme un humain peu fiable, alors il est nécessaire de renforcer les étapes de revue, vérification et/ou validation en sortie de ce que fait l’IA.

Selon le modèle d’IA et selon les cas, l’une ou l’autre approche sera plus facile à mettre en oeuvre (si elle est possible) et plus ou moins coûteuse, mais c’est la norme du système final qui en sera l’arbitre.