re-ai-gov Sur la liste d'attente

Kennisbank

Ce que signifie réellement un niveau de risque élevé pour votre organisation

La question de savoir si une application d'IA est considérée comme à haut risque semble être une qualification technique. En pratique, il s'agit d'une classification qui dépend de plusieurs facteurs concrets, et cette classification déterminE ensuite le niveau de supervision, de documentation et de démonstrabilité qui est attendu de vous. Les définitions et seuils légaux actuels ne figurent pas sur cette page ; vous les trouverez ailleurs. Ici, nous expliquons de quoi dépend la classification et ce qui change dans votre organisation lorsque cette classification évolue.

De quoi dépend la classification

Il n'existe pas une seule caractéristique qui rend une application à haut risque. C'est une combinaison de facteurs qui forment ensemble le tableau : le domaine dans lequel l'application est déployée, la mesure dans laquelle une décision a des conséquences directes pour une personne, et la question de savoir s'il existe un être humain capable d'évaluer réellement l'avis ou le résultat de l'IA et de le corriger si nécessaire avant qu'il n'ait d'effet. Une application qui se contente de résumer du texte se situe généralement différemment dans cette classification qu'une application qui intervient dans une décision concernant un individu. Le contexte dans lequel une application est utilisée compte également : la même technologie sous-jacente peut être considérée comme à faible risque dans un domaine et à haut risque dans un autre, selon ce qui est fait du résultat.

C'est l'une des raisons pour lesquelles une liste de logiciels approuvés ne suffit pas. La classification ne dépend pas de l'étiquette apposée sur le produit, mais de la manière dont il est réellement utilisé et de sa place dans le processus décisionnel.

Ce qui change lorsque le niveau de risque s'avère plus élevé

Lorsqu'une application est évaluée comme présentant un risque plus élevé, ce qui est attendu de l'organisation change : davantage de documentation sur le fonctionnement et les tests de l'application, un mécanisme de contrôle plus clair sur les résultats, et un moyen de pouvoir démontrer après coup qui a été attentif à quoi. Il ne s'agit pas d'une action ponctuelle mais d'une obligation continue : la documentation et le contrôle doivent rester à jour tant que l'application est utilisée.

La classification n'est pas statique non plus. Une application considérée aujourd'hui comme à risque limité peut demain être déployée différemment — dans un autre domaine, avec un impact plus important sur les individus, ou avec moins d'intervention humaine qu'auparavant. Celui qui établit la classification une seule fois et ne la révise plus par la suite court le risque que la classification ne corresponde plus à l'usage réel. Cela vaut également pour les applications qui sont adaptées après leur acquisition ; ce qui change précisément lorsque vous ajustez vous-même un modèle dépend de la nature de cette adaptation, comme décrit sur la page consacrée aux adaptations d'un modèle.

Pourquoi la liste informatique ne donne pas une image complète

La classification d'une application n'a de sens que si elle est appliquée à ce qui est réellement utilisé. Une grande partie de l'usage au sein d'une organisation échappe à l'inventaire officiel : des équipes qui utilisent un modèle de langage pour rédiger un brouillon d'e-mail, un analyste qui se sert d'un modèle externe pour une première version d'un rapport, un service qui a acquis un outil sans le signaler. Cet usage ne naît pas de la mauvaise volonté. Il naît du fait que la voie officielle est plus lente que le besoin, ou parce que personne ne savait qu'une voie officielle devait être suivie.

La conséquence est que la liste informatique donne rarement une image complète. Celui qui veut savoir ce qui est réellement nécessaire en matière de classification des risques doit cartographier lui-même l'usage — ce qui nécessite de poser des questions aux personnes qui effectuent le travail, sans que cela n'entraîne de sanction. Celui qui sent déjà, dès le premier entretien, qu'une réponse honnête aura des conséquences, ne répond pas honnêtement. Cela rend l'inventaire inutilisable avant même qu'il ne soit terminé.

Ce qui relève de la classification et ce qui n'en relève pas

Toute application de l'IA ne relève pas du cadre dans lequel la classification des risques est pertinente. Certaines applications se situent, par nature ou par finalité, hors du champ d'application de la réglementation, et il est judicieux de faire cette distinction rapidement avant de consacrer du temps à une classification qui n'est pas nécessaire ; les applications concernées sont décrites sur la page relative aux applications qui se situent hors du champ des obligations. Le rôle joué par votre organisation — en tant que fournisseur d'un système ou en tant qu'utilisateur de celui-ci — influence également les obligations liées à une classification des risques, et ce rôle n'est pas toujours clair au préalable ; ce qui est déterminant à cet égard est expliqué sur la page consacrée à la distinction entre fournisseur et utilisateur. Ce même rôle peut d'ailleurs changer dès que vous adaptez un système ou le proposez sous votre propre nom, ce qui est expliqué plus en détail sur la page consacrée aux circonstances dans lesquelles votre rôle change.

Ce qui est urgent maintenant et ce qui peut encore être planifié

Une classification par niveau de risque soulève presque toujours la question suivante : qu'est-ce qui est urgent et qu'est-ce qui peut encore être planifié. Cette distinction n'est pas la même pour chaque organisation et dépend des applications déjà en production et de celles encore en développement. Un aperçu de ce qui nécessite généralement une attention immédiate et de ce qui peut suivre plus tard figure sur la page consacrée à ce qui doit se faire maintenant et ce qui peut être planifié.

La question suivante

Une fois qu'il est clair quelles applications de votre organisation sont considérées comme à haut risque, une autre question se pose naturellement : quelle part du travail sous-jacent est réellement effectuée par l'IA, et quelle part par des personnes qui contrôlent ou complètent le résultat. Cette question dépasse le cadre de cette analyse, mais elle trouve une réponse dans l'analyse de travail de FTE TO AI, qui calcule, tâche par tâche, quelle part du travail peut raisonnablement être reprise par l'IA.

Andrewde assistent van de Responsible AI Scan

Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.

Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.